Kurzfassung: Aleph Alpha veröffentlichte Kolibri am 3. Oktober. Der technische Bericht nennt insgesamt 78,1 Milliarden Parameter und 3,46 Milliarden aktive Parameter pro Token.[2][3] Die Modellkarte empfiehlt höchstens 262.144 Token, obwohl 1.048.576 validiert wurden.[1] Damit entsteht eine deutsch-englische Betriebsoption. Die Beschaffung sollte jedoch den vollständigen laufenden Dienst kalkulieren.
Kolibri wurde in einer offiziellen X-Ankündigung vorgestellt. Folgebeiträge verlinkten Modellgewichte und technischen Bericht.[4] Diese Analyse vom 5. Oktober behandelt die Veröffentlichung vom 3. Oktober. Der herunterladbare Checkpoint mit seinen Begleitdateien macht die Ankündigung greifbar.[7]
Für Unternehmenskunden ist entscheidend, welche Kontrolle die Veröffentlichung ermöglicht. Ein Sprachmodell kann zu einer Abhängigkeit werden, die das Unternehmen selbst auswählt und pflegt. Diese Option hat einen Wert, bevor jemand nachweist, dass sie günstiger als ein gehosteter Dienst ist. Zugleich verpflichtet sie dazu, den gesamten Dienst zu prüfen. Eine Parameterzahl allein ist keine Beschaffungsspezifikation.
Warum das jetzt relevant ist
Aleph Alpha stellt die zweisprachige Spezialisierung in den Mittelpunkt.[3] Teams mit deutschen und englischen Dokumenten können nun einen öffentlichen Checkpoint untersuchen und prüfen, ob eigener Betrieb Kosten, Zuverlässigkeit und Kontrolle verbessert.
Titelbild: Neu generierte redaktionelle Illustration. Tuscheillustration eines Kolibris, der eine Schublade in einem großen Speicherarchiv aktiviert. Sie ist keine Produktaufnahme und kein Messbeleg.
Modellgröße: Aktive Berechnung bezahlt keinen Speicher
Die Modellkarte nennt 78.103.074.560 Gesamtparameter, 3.457.573.120 aktive Parameter pro Token und für FP8-Gewichte einen geschätzten Speicherbedarf von rund 78 GB. Letzteres ist eine Herstellerschätzung, keine exakte Messung des gesamten Dienstes.[1]
Der technische Bericht beschreibt den Zielkonflikt: Mehr Gesamtkapazität belegt Speicher, der sonst Aktivierungen und dem Key-Value-Cache zur Verfügung stünde. Das begrenzt gleichzeitige lange Anfragen. Die Architektur verbindet 40 Sliding-Window-Blöcke mit 10 Blöcken vollständiger Attention.[2] Das sind Architekturentscheidungen. Sie ersetzen keine Kapazitätsplanung.
Die separate BF16-Modellkarte schätzt den Gewichtsspeicher auf rund 156 GB und nennt vier H100-SXM5-GPUs als empfohlene Konfiguration.[9] Die Präzision verändert die Betriebsgrenze. Keine der Speicherschätzungen garantiert eine gemessene Parallelität.
Eine brauchbare Beschaffungsübersicht braucht deshalb getrennte Angaben für Modellablage, Arbeitsspeicher, gleichzeitige Sitzungen und Antwortfristen. Die Zahl aktiver Parameter kann diese vier Fragen nicht beantworten. Wer allein danach Hardware auswählt, optimiert womöglich die falsche Grenze: Der Checkpoint passt, aber die Anwendung scheitert an der Arbeitslast, für die er gekauft wurde.
Kontextlänge: Erst das Arbeitsbudget, dann die Obergrenze
Zwischen Empfehlung und validierter Länge liegt der Faktor vier, berechnet aus 1.048.576 geteilt durch 262.144.[1] Die Empfehlung sollte zunächst die Grenze des Piloten bilden. Eine Erweiterung braucht eine konkrete Begründung: Welche notwendigen Belege lassen sich im kleineren Budget weder finden noch sinnvoll zusammenfassen?
Assistenten für lange Dokumente müssen mehr beweisen als eine erfolgreiche Antwort auf einen großen Prompt. Prüfen Sie widersprüchliche Passagen, überarbeitete Fassungen, verstreute Belege und Fragen, die das Material nicht beantwortet. Halten Sie fest, ob die Antwort die richtige Passage zitiert, ob eine Person sie prüfen kann und wie viele Nutzer diese Aufgaben gleichzeitig erledigen können. Ohne solche Beobachtungen bleibt die Million-Token-Grenze eine Kapazitätsangabe und kein Abnahmeergebnis.
Betriebssoftware: Der Parser gehört zum Produkt
Aleph Alphas Inferenz-Repository liefert ein vLLM-Plugin mit Kolibri-spezifischer Architektur sowie Parsern für Reasoning und Werkzeugaufrufe. Zum Prüfzeitpunkt nennt die README Unterstützung für vLLM 0.29.[5] Plugin, Tokenizer und Checkpoint-Version sollten gemeinsam in einem festgelegten Betriebsstand dokumentiert sein. Drei unabhängig wechselnde Annahmen reichen nicht.
Das Paketmanifest legt die Kompatibilitätsgrenze fest: vllm>=0.29.0,<0.30.0, torch>=2.9.0 und transformers>=5.5.3.[10] Die Dockerfile installiert das Release-Wheel mit --no-deps und erhält damit die Bibliotheken des Basisimages.[11] Ein ungeplantes Abhängigkeitsupdate kann den geprüften Betriebsstand entwerten. Dokumentieren Sie deshalb auch den Container-Digest.
Die Dateiliste enthält Gewichtsteile und Tokenizer-Dateien.[7] Erfassen Sie deren Revisionen zusammen mit der Engine-Version. Prüfen Sie anschließend normale Antworten, deaktiviertes Reasoning und strukturierte Werkzeuganfragen, bevor interne Unterlagen in den Piloten gelangen. Plausibler Fließtext beweist nicht, dass die Anwendung Werkzeugaufrufe richtig interpretiert.
Die allgemeine vLLM-Dokumentation erläutert den geringeren Cache-Speicherbedarf durch FP8-Quantisierung und behandelt Kalibrierung.[8] Deshalb sollte die Cache-Konfiguration getrennt von der Gewichtspräzision geprüft werden. Eine konkrete Kolibri-Installation wird dadurch nicht zertifiziert. Vorgeschlagene Verbesserungen müssen dieselben Dokumenttests bestehen wie die Ausgangskonfiguration.
Zweisprachige Kontrolle: Die Arbeit entscheidet
Der Veröffentlichungsbeitrag betont die Spezialisierung auf Deutsch und Englisch.[3] Für ein zweisprachiges Unternehmen zählt, ob derselbe Ablauf beide Sprachen konsistent behandelt. Stellen Sie dieselbe Richtlinienfrage in beiden Sprachen, nutzen Sie Passagen mit juristischen oder technischen Begriffen und wechseln Sie die Sprache während einer Sitzung.
Dem Checkpoint liegt der Lizenztext von Apache 2.0 bei.[6] Lizenzierung und erfolgreicher Betrieb beantworten unterschiedliche Fragen. Verfügbare Gewichte schaffen Spielraum für Prüfung, Anpassung und Betrieb. Sie belegen nicht, dass eine bestimmte Anwendung ihre vertraglichen oder regulatorischen Pflichten erfüllt. Das hängt vom System und seinem Einsatz ab. Käufer sollten Nachweise für ihre eigenen Datengrenzen, Zugriffskontrollen und Prüfabläufe verlangen.
Abnahme: Unabhängigkeit muss ihren Platz verdienen
Ein sinnvoller Pilot misst erfolgreich geprüfte Aufgaben im Verhältnis zum Betriebsbudget. Dokumentieren Sie Hardware, Präzision, Ein- und Ausgabelängen, Parallelität, Reasoning-Einstellungen, Latenz und Fehlerbehandlung. Herstellerbewertungen bleiben von diesen Messungen getrennt. Auch der technische Bericht behandelt schwache Benchmark-Ergebnisse neben den Stärken.[2] Nur vorteilhafte Ergebnisse auszuwählen würde gerade die Fälle verdecken, die ein Betriebsteam entdecken muss.
Diese Behauptung trägt nicht
Sparse Compute macht aus dem vollständigen Checkpoint kein Modell mit kleinem Speicherbedarf. Weder herunterladbare Gewichte noch eine große Kontextgrenze beweisen, dass eine Anwendung sicher, regelkonform oder wirtschaftlich überlegen ist.
Kolibri gibt Käufern eine weitere Komponente, deren Betrieb sie selbst übernehmen können. Der Vorteil entsteht durch den Nachweis, wo diese Entscheidung die tatsächliche Arbeit verbessert, und durch Verantwortung für den umgebenden Dienst. Kontrolle ist wertvoll, wenn das Unternehmen sie ausüben kann.
Quellen: Materialien und Einordnung
Die ersten drei Quellen sind die zentralen Veröffentlichungsmaterialien. Herstellerangaben sind als solche eingeordnet.
Zum Lesen aller Spalten seitlich scrollen.
| Nr. | Quelle | Anbieter | Datum | Bedeutung |
|---|---|---|---|---|
| [1] | Kolibri 1: Modellkarte | Aleph Alpha / Hugging Face | Abgerufen am 5. Oktober 2026 | Exakte Parameterzahlen, Kontextempfehlung und Speicherschätzung des Herstellers. |
| [2] | Kolibri: Technischer Bericht | Aleph Alpha | Abgerufen am 5. Oktober 2026 | Architektur und Speicheranalyse, S. 11–14; Bewertungsgrenzen, S. 97–98. |
| [3] | Kolibri: Veröffentlichungsbeitrag | Aleph Alpha | 3. Oktober 2026 | Veröffentlichung am 3. Oktober und zweisprachige Spezialisierung; Herstellerpositionierung. |
| [4] | Ursprünglicher Ankündigungsthread | Aleph Alpha / X | 3. Oktober 2026 | Öffentliche Ankündigung und weiterführende Links. |
| [5] | Aleph Alpha: Inferenz-Plugin | Aleph Alpha / GitHub | Abgerufen am 5. Oktober 2026 | Unterstützte vLLM-Version, Architektur und Parser. |
| [6] | Lizenz des Kolibri-Checkpoints | Aleph Alpha / Hugging Face | Abgerufen am 5. Oktober 2026 | Apache-2.0-Lizenztext der veröffentlichten Gewichte. |
| [7] | Dateien des veröffentlichten Checkpoints | Aleph Alpha / Hugging Face | Abgerufen am 5. Oktober 2026 | Herunterladbare Gewichtsteile, Tokenizer und Konfiguration. |
| [8] | Dokumentation zum quantisierten KV-Cache | vLLM | Abgerufen am 5. Oktober 2026 | Cache-Speicher und Kalibrierung; allgemeine Engine-Dokumentation. |
| [9] | Kolibri 1: BF16-Modellkarte | Aleph Alpha / Hugging Face | Abgerufen am 5. Oktober 2026 | BF16-Speicherschätzung und Hardwareempfehlung des Herstellers; keine gemessene Parallelitätsgarantie. |
| [10] | Abhängigkeiten des Inferenzpakets | Aleph Alpha / GitHub | Abgerufen am 5. Oktober 2026 | Expliziter vLLM-Versionsbereich und Mindestversionen für torch und transformers. |
| [11] | Dockerfile des Inferenzcontainers | Aleph Alpha / GitHub | Abgerufen am 5. Oktober 2026 | Installation des Release-Wheels ohne Austausch der Bibliotheken des Basisimages. |
Zuletzt aktualisiert: 5. Oktober 2026




