Kolibri-1 im Eigenbetrieb: 78 Milliarden im Speicher, 3,46 Milliarden am Rechnen

/01Was am 3. Oktober veröffentlicht wurde

Am 3. Oktober 2026 hat Aleph Alpha die Gewichte von Kolibri-1 auf Hugging Face gestellt, die Pressemitteilung aus Heidelberg folgte am 5. Oktober. Die Modellkarte unter Aleph-Alpha/Kolibri-1 nennt 78.103.074.560 Parameter insgesamt und 3.457.573.120 aktive je Token, eine Mixture-of-Experts-Architektur, die Sprachen Deutsch und Englisch, ein natives Kontextfenster von 262.144 Token mit Erweiterung auf 1.048.576 Token — und als Lizenz Apache 2.0, nachlesbar in der LICENSE-Datei des Repositories.

Daneben liegt ein zweites Repository Aleph-Alpha/Kolibri-1-BF16 mit den Gewichten in voller Präzision. Das Hauptrepository ist bereits FP8: „float8_e4m3fn weights in 128×128 blocks with dynamically quantized activations", Embeddings, LM-Head, Normen und MoE-Router bleiben in BF16. Das ist ungewöhnlich und praktisch: Der Hersteller liefert die Präzision aus, mit der er selbst evaluiert hat, inklusive FP8-KV-Cache.

Die Herstellerbenchmarks vom 3. Oktober 2026: MMLU-Pro (CoT) 80,0, GPQA Diamond 84,3, AIME 2026 96,0, HumanEval+ 92,7 — jeweils Englisch. Für Deutsch nennt die Karte MMLU-ProX 75,5, GPQA Diamond 81,3 und AIME 2026 90,0. Wissensstand laut Karte: 18. Juni 2026 für beide Sprachen. Das Modell beherrscht einen expliziten Reasoning-Modus mit vier Stufen (none, low, medium, high) und natives Tool-Calling.

Zur Einordnung des Anbieters: Aleph Alpha war in diesem Jahr Gegenstand einer Übernahmemeldung, die wir in Souveräne KI-Anbieterwahl 2026 besprochen haben. Für den Betrieb ist das zweitrangig: Apache-2.0-Gewichte bleiben nutzbar, egal wem der Hersteller morgen gehört. Für Support-Verträge und Folgeversionen ist es nicht zweitrangig.

/02Architektur: 384 Experten je Schicht, sechs davon pro Token

Kolibri-1 hat 50 Transformer-Schichten mit einer Hidden Size von 2.560, 48 Attention-Köpfen und 4 KV-Köpfen. Je Schicht stehen 384 geroutete Experten bereit, von denen der Router für jedes Token sechs auswählt; dazu kommt ein geteilter Experte, der immer rechnet. So kommen die 3,46 Milliarden aktiven Parameter zustande — rund 4,4 % der Gesamtzahl.

Für den Betrieb hat das zwei gegenläufige Folgen. Erstens: Die Rechenlast je Token entspricht grob der eines dichten 3,5-B-Modells. Das macht Kolibri-1 bei wenigen parallelen Anfragen schnell und bei vielen parallelen Anfragen günstig — solange der Speicher reicht. Zweitens: Der Speicher muss alle 78 Milliarden Parameter halten, weil nicht vorhersehbar ist, welche sechs Experten das nächste Token braucht. Ein MoE-Modell tauscht also Speicher gegen Rechenzeit. Wer viel VRAM und wenig GPU-Leistung hat, fährt damit besser als mit einem dichten Modell; wer eine einzelne 24-GB-Karte hat, fährt gar nicht.

Die vier KV-Köpfe sind der zweite Grund, warum der lange Kontext bezahlbar ist: Der KV-Cache wächst mit der Zahl der KV-Köpfe, nicht mit den 48 Attention-Köpfen. Zusammen mit dem FP8-Cache aus der Modellkarte bleibt der Speicher für 262.144 Token in einem Rahmen, der auf einer 80-GB-Karte neben die Gewichte passt — die gemessenen Werte dazu stehen im nächsten Abschnitt. Der Tokenizer ist ein eigener („UniBPE", 128.000 Einträge) und laut Aleph Alpha für Deutsch optimiert; das wirkt sich direkt auf die Zahl der Token je deutschem Satz aus, also auf Kontextverbrauch und Durchsatz.

/03VRAM je Präzision: was belegt ist und was Rechnung

Belegt sind drei Zahlen: die offiziellen FP8-Safetensors (32 Dateien, zusammen rund 78,6 GB), die Hardwareangabe der Modellkarte und die Messwerte eines Drittanbieters für eine Q4_K_M-GGUF-Fassung. Alles andere ist aus der Parameterzahl hergeleitet und so gekennzeichnet.

Die Drittanbieter-Messung ist aufschlussreich, weil sie den Preis des Kontexts zeigt: Von 8.192 auf 262.144 Token wachsen rund 5,2 GB dazu, von 262.144 auf 1.048.576 noch einmal rund 16 GB. Ein Modell mit 48 KV-Köpfen in FP16 läge um ein Vielfaches darüber; wie man solche Werte für die eigene Konfiguration vorab rechnet, steht in KV-Cache verstehen. Für ein 192-GB-System heißt das konkret: FP8-Gewichte plus 262k-Kontext plus Puffer liegen deutlich unter der Grenze; es bleibt Platz für ein Embedding-Modell und einen Reranker daneben.

/04vLLM-Start: der Befehl aus der Modellkarte und was dahintersteckt

Aleph Alpha empfiehlt vLLM mit einem eigenen Python-Paket, das Parser für Reasoning-Blöcke und Tool-Aufrufe nachrüstet. Der Startbefehl stammt wörtlich aus der Modellkarte:

pip install 'aleph-alpha-inference>=1'

vllm serve Aleph-Alpha/Kolibri-1 \
  --kv-cache-dtype fp8 \
  --reasoning-parser kolibri1 \
  --tool-call-parser kolibri1 \
  --enable-auto-tool-choice

Vier Dinge sind daran nicht selbstverständlich. --kv-cache-dtype fp8 halbiert den Cache gegenüber FP16 und entspricht der Konfiguration, mit der Aleph Alpha die Benchmarks gemessen hat — wer den Schalter weglässt, misst ein anderes Modell. --reasoning-parser kolibri1 trennt den Denkanteil von der Antwort, damit Ihre Anwendung nicht die Überlegungen des Modells an den Nutzer durchreicht. --tool-call-parser kolibri1 mit --enable-auto-tool-choice schaltet Function Calling im OpenAI-kompatiblen Format frei. Und das vorangestellte pip install ist Pflicht: Ohne das Paket kennt vLLM die beiden Parser nicht und startet mit einer Fehlermeldung.

Was im Befehl fehlt, ist eine Kontextbegrenzung. vLLM reserviert standardmäßig Cache für die in der Konfiguration hinterlegte Maximallänge; wer nur 32k Kontext braucht, setzt --max-model-len 32768 und gewinnt Platz für mehr parallele Anfragen. Auf zwei Karten kommt --tensor-parallel-size 2 dazu. Den Reasoning-Aufwand steuert die Anwendung je Anfrage über das reasoning_effort-Feld; für Klassifikation und Extraktion ist none oder low die richtige Wahl, für Vertragsanalysen high. Belastbare Durchsatzwerte liefert nur eine Messung mit Ihrem Prompt-Mix — die 126 Token/s aus der Drittanbieter-Messung stammen aus llama.cpp mit einem Nutzer und sagen nichts über 32 parallele Anfragen in vLLM.

/05Vergleich mit Qwen3.8-27B und Gemma 4 31B: dicht gegen MoE

Die beiden naheliegenden Gegenkandidaten sind dichte Modelle unter Apache 2.0, die auf eine 24-GB-Karte passen: Qwen3.8-27B und Gemma 4 31B. Die Gegenüberstellung zeigt den Zielkonflikt zwischen Speicher und Rechenlast:

Die Benchmark-Spalte ist mit Vorsicht zu lesen: drei Hersteller, drei Messaufbauten, keine unabhängige Prüfung. Was die Tabelle verlässlich zeigt, ist die Struktur. Kolibri-1 braucht knapp das Dreifache an Speicher der beiden dichten Modelle, rechnet aber je Token mit rund einem Achtel der aktiven Parameter. Bei einem Nutzer merkt man davon wenig; bei fünfzig parallelen Anfragen wird der Unterschied zum entscheidenden Faktor für den Durchsatz je GPU. Qwen3.8-27B hat nach unserer Messung auf einem 192-GB-System 3.900 Token/s erreicht — als Summe über viele parallele Anfragen; einen vergleichbaren Wert für Kolibri-1 liefern wir nach, wenn er gemessen ist.

In der Praxis heißt das: Auf einer 24-GB-Karte stellt sich die Frage nicht, dort laufen nur die beiden dichten Modelle. Auf einem 192-GB-System stellt sie sich umgekehrt: Dort passt Kolibri-1 in FP8 mit vollem Kontext, und die geringe Rechenlast je Token erlaubt mehr gleichzeitige Nutzer als ein dichtes 27-B-Modell in BF16. Wer deutsche Fachtexte verarbeitet und viele Nutzer hat, hat mit Kolibri-1 den natürlichen Kandidaten; wer Code schreibt oder Bilder auswerten muss, bleibt bei Qwen — Kolibri-1 ist ein reines Textmodell.

/06Datenherkunft und Dokumentation: das Argument für regulierte Branchen

Aleph Alpha veröffentlicht zu Kolibri-1, was die meisten Hersteller weglassen: die Zusammensetzung der Trainingsdaten. Laut Modellkarte umfasste das Vortraining 20 Billionen Token — rund 62,5 % Englisch, 23,9 % Deutsch, 13,6 % Code —, gefolgt von 3,44 Billionen Token Mid-Training und 201 Milliarden Token Kontexterweiterung. Die Pressemitteilung ergänzt, dass die Quellen gegen eine Sperrliste von mehr als 4,5 Millionen URLs geprüft wurden, darunter die Piracy Watch List der Europäischen Kommission, und dass das Modell darauf trainiert ist, sich zu enthalten, wenn die mitgegebenen Dokumente keine ausreichende Grundlage liefern.

Für ein Haus unter Aufsicht — Versicherung, Bank, Kanzlei, Gesundheitswesen — ist das kein Marketing, sondern Prüfmaterial. Die KI-Verordnung legt die Dokumentationspflichten für Allzweck-KI-Modelle beim Anbieter ab, nicht beim Betreiber; wer ein Modell einsetzt, dessen Hersteller diese Dokumentation öffentlich liefert, hat im Audit etwas vorzulegen. Bei Modellen, deren Karte zur Datenherkunft schweigt, hat er das nicht. Das ist keine Formsache, sondern der Unterschied zwischen „wir haben geprüft" und „wir vertrauen".

Das Enthaltungsverhalten ist der zweite Punkt. In einer RAG-Anwendung ist eine Antwort, die ohne Beleg in den Dokumenten erfunden wird, der teuerste Fehler — und bei einem Modell, das auf Enthaltung trainiert ist, lässt sich das Grounding im Eval-Set direkt messen: Wie oft antwortet es, obwohl die Quelle fehlt? Welche Embedding-Modelle für deutsche Texte davor sinnvoll sind, steht in Embedding-Modelle für Deutsch.

/07Wann Kolibri-1 die falsche Wahl ist

Ehrlich: Für die Mehrheit der Häuser, die heute mit einer einzelnen Workstation-GPU arbeiten, ist Kolibri-1 nicht die nächste, sondern die übernächste Stufe. Die falsche Wahl ist es in fünf Fällen:

• Eine 24-GB-Karte. Die kleinste belegte Fassung braucht rund 46 GB im Betrieb. Es gibt keinen Trick, der das ändert; CPU-Offloading von Expertengewichten macht aus einem schnellen Modell ein langsames, und die Drittanbieter-Messung ohne GPU brauchte rund 250 GB Arbeitsspeicher.
• Code, Bilder, Audio. Kolibri-1 verarbeitet Text. Wer Screenshots auswerten, Konstruktionszeichnungen lesen oder einen Coding-Agenten betreiben will, braucht ein multimodales Modell wie Qwen3.8-27B oder Gemma 4.
• Andere Sprachen als Deutsch und Englisch. Die Modellkarte nennt zwei Sprachen. Ein Haus mit Niederlassungen in Polen oder Tschechien sollte das vor dem Proof of Concept mit eigenen Texten prüfen und nicht hoffen.
• Ein einzelner Nutzer mit gelegentlichen Anfragen. Der Vorteil der 3,46 Milliarden aktiven Parameter zeigt sich bei Parallelität. Für einen Nutzer, der dreimal am Tag einen Brief entwerfen lässt, ist ein dichtes 27-B-Modell auf einer günstigeren Karte die bessere Rechnung.
• Wer ohne eigenes Eval-Set entscheidet. Die Benchmarkwerte sind Herstellerangaben vom Erscheinungstag. Zwischen 84,3 und 89,2 auf GPQA Diamond liegt kein Unterschied, den Sie in Ihrer Vertragsprüfung wiederfinden werden; ob Kolibri-1 deutsche Fachbegriffe Ihrer Branche besser trifft als Qwen, zeigt nur Ihr eigener Testsatz.

Dazu kommt die Reife: Am 11. Oktober 2026 gibt es offizielle Gewichte in FP8 und BF16, aber keine vom Hersteller validierte 4-Bit-Fassung und keine NVFP4-Variante. Wer heute Q4 fährt, fährt eine Drittanbieter-Quantisierung — und sollte das eigene Eval-Set vor und nach dem Wechsel laufen lassen.

/08Entscheidung: für wen sich der Umstieg lohnt

Die Entscheidung hängt an drei Größen: VRAM im Haus, Zahl der gleichzeitigen Nutzer, Anteil deutscher Fachtexte.

Lohnt sich: ein Haus ab etwa zwanzig täglichen Nutzern, das deutsche Dokumente verarbeitet — Verträge, Gutachten, Schadenakten, Patientenbriefe — und ein 192-GB-System oder mindestens eine 80-GB-Karte betreibt oder plant. Hier liefert Kolibri-1 in FP8 den vollen nativen Kontext, eine dokumentierte Datenherkunft für das Audit und eine Rechenlast je Token, die viele parallele Nutzer auf einer Maschine erlaubt. Der Umstieg von einem dichten 27-B-Modell lohnt, wenn der Engpass heute der Durchsatz bei Parallelität ist, nicht die Qualität der Einzelantwort.

Lohnt sich nicht: ein Haus mit einer 24-GB-Karte, ein Haus mit vor allem englischen oder gemischtsprachigen Texten, ein Haus mit Coding- oder Bildaufgaben, und jedes Haus, das die Entscheidung ohne Messung treffen will. Für diese Gruppe bleibt Qwen3.8-27B die Empfehlung — und wenn Deutsch wichtig ist, ein Vergleichstest beider Modelle, sobald eine zweite Karte oder ein größeres System im Plan steht.

Noch offen: Häuser, die über die Beschaffung eines GPU-Servers ab rund 15.000 € nachdenken. Für sie ist Kolibri-1 ein Argument, bei der Speichergröße nicht zu knapp zu planen: Ein 48-GB-System deckt Qwen und Gemma in jeder Präzision ab, aber Kolibri-1 nur zu zweit; erst ab 80 GB je Karte oder 192 GB im System wird das MoE-Modell zur Option. Die Referenzrechnung aus unserem On-Premise-Konzept — rund 55.000 € über 36 Monate gegenüber rund 108.000 € Cloud-API bei 100.000 Anfragen je Monat — geht von einem A100-System aus; genau diese Klasse nennt Aleph Alpha als Mindesthardware.

/09Prüfplan für die ersten zwei Wochen

Wer Kolibri-1 ernsthaft prüfen will, braucht keine Benchmark-Suite, sondern einen Plan mit vier Messpunkten:

1. Tag 1–2: Start und Speicher. FP8-Gewichte laden, Befehl aus Abschnitt /04 mit --max-model-len 32768, dann nvidia-smi lesen. Notieren Sie den Speicher nach dem Start und nach der ersten langen Anfrage; die Differenz ist Ihr Cache-Bedarf je Token.
2. Tag 3–5: Eval-Set. 50 bis 100 echte Aufgaben aus Ihrem Haus mit bekannten Soll-Antworten, davon mindestens 20 ohne ausreichende Quelle — um das Enthaltungsverhalten zu messen. Dasselbe Set gegen Qwen3.8-27B, gleiche Prompts, gleiche Temperatur.
3. Tag 6–8: Parallelität. Lasttest mit 8, 16 und 32 gleichzeitigen Anfragen, Time-to-First-Token und Token je Sekunde je Anfrage protokollieren. Hier zeigt sich, ob die 3,46 Milliarden aktiven Parameter in Ihrem Mix ankommen.
4. Tag 9–10: Reasoning-Stufen. Dieselben Aufgaben mit reasoning_effort none, low und high. Oft reicht low bei einem Bruchteil der Ausgabe-Token — das ist im Eigenbetrieb kein Kosten-, aber ein Latenz- und Auslastungshebel.

Danach wissen Sie, ob Kolibri-1 für Ihr Haus das richtige Modell ist. Vorher wissen Sie, was die Modellkarte sagt — und das ist, wie bei jedem Modell, der Anfang der Prüfung, nicht ihr Ergebnis.