Kolibri aus Heidelberg: ein deutscher Tokenizer, der nicht auf unsere GPUs passt

Aleph Alpha hat am 3. Oktober 2026 die Gewichte von Kolibri freigegeben, am 5. Oktober die Pressemitteilung nachgelegt. Ein Mixture-of-Experts-Modell mit 78,1 Milliarden Hauptgewichten, 3,46 Milliarden aktiven Parametern je Token, 262.144 Token Kontext nativ und gut eine Million per Extrapolation, dazu ein Tokenizer, der ausdrücklich für Deutsch gebaut wurde. Lizenz Apache 2.0, ohne Zusatzklausel, im Repo liegt der unveränderte Standardtext.

Der Anlass für unseren Blick ist nicht die Pressemitteilung, sondern die Diskussion darum. In einem LinkedIn-Beitrag wird Kolibri als deutsches Modell auf Augenhöhe mit deutlich größeren Offenmodellen beschrieben, mit dem Zusatz, die Benchmarkwerte kämen vom Hersteller. Genau an dem Punkt hören wir auf zu lesen undfangen an zu messen. Drei Fragen interessieren uns: Was sagt die Primarquelle wirklich, was davon gilt in unserem Haus, und was kostet uns der Betrieb hier.

Was das Modell technisch ist

Die Werte stammen aus der Modellkarte und dem 189 Seiten starken Technikbericht, beides direkt bei Aleph Alpha geholt.

Erwähnenswert sind zwei Details aus dem Anhang. Die synthetischen Daten entstanden nach Angabe des Autorenteams mit GLM-5.2, GLM-5.3 und Qwen3.8-27B als Lehrmodellen, das deutsche Vorlernkorpus wurde mit einer eigenen Web-Pipeline auf über 2 Billionen Tokens ergänzt. Und die Angabe zum Trainingsort ist ein einziger Satz im gesamten Bericht: Teams in Deutschland hätten das Modell entwickelt und auf Infrastruktur in Deutschland und Finnland trainiert. Welcher Cluster in Finnland gemeint ist, steht weder im Bericht noch in der Pressemitteilung, die nur von Europa spricht.

Der Tokenizer ist der Teil, den wir selbst messen können

Die Modellkarte wirbt mit höherer deutscher Kompression als Modelle mit größerem Vokabular. Eine Behauptung über ein Modell kann man nicht prüfen, eine über einen Tokenizer schon. Wir haben dazu zwei Dateien nebeneinander gelegt: die tokenizer.json aus dem Kolibri-Repo und die tokenizer.json des Modells, das bei uns die Anfragen bedient, Qwen3.8-Flash-Next-Hybrid auf unserem 4×-RTX-5090-Host. Vokabular 127.900 gegen 248.044 Einträge.

Zuerst das Einzelwort aus der Diskussion, Bundesverfassungsgericht:

Die Zahl aus dem LinkedIn-Beitrag stimmt also, unser eigenes Modell liegt in der Mitte. Interessanter ist ein richtiger Text. Wir haben vier Absätze genommen, so wie wir sie für diese Fälle schreiben: eine Auftragsbestätigung für eine Spedition, eine Datenschutzklausel für unser Portal, eine Gefahrguterklärung, eine Mahnung wegen einer falschen Stückzahl. 1.526 Bytes UTF-8, je Tokenizer im selben Messlauf, Korpus und Skript liegen im Dossier zu diesem Beitrag.

Bytes pro Token auf dem Geschäftsdeutsch: 5,17 für Kolibri, 4,24 für unsere Lane, 4,48 für o200k. Der Herstellerwert für deutsches Webdeutsch liegt bei 4,90, unsere förmliche Prosa liegt also noch darüber, weil sie lange Komposita hat. Der englische Kontrolltext zeigt den Preis nicht: 112 gegen 114 Tokens, praktisch kein Nachteil.

Zwei Einschränkungen gehören zu der Zahl dazu, beide stehen nicht in der Modellkarte.

Umlaute sind ein Kostenfaktor. Dieselben vier Texte, einmal mit korrekter Rechtschreibung und einmal mit ae, oe, ue und ss geschrieben, so wie es Exporte aus älteren ERP-Systemen liefern: Kolibri fällt von 5,17 auf 4,31 Bytes pro Token zurück, der Abstand zu unserer Lane schrumpft von 18,1 auf 11,3 Prozent. An der eigenen Kodierung zu arbeiten ist also der billigere Hebel als ein Modelltausch. Wer deutsche Texte mit kaputter Kodierung in eine KI-Strecke schickt, verschenkt bei jedem Tokenizer Geld, bei diesem hier nur am deutlichsten.

Technische Mischkost holt den Vorteil ein. Wir haben zusätzlich unsere eigenen 14 zuletzt veröffentlichten Beiträge gemessen, 25.505 Bytes echte gemischte Dokumentation. Dort bleiben nur 8,7 Prozent Unterschied, in der Spanne von 5,9 bis 12,6 Prozent, Median 8,8. Die mitgezählte Wortdichte erklärt das: 149 bis 180 englische Fachwörter pro Text gegen 11 bis 33 Nicht-ASCII-Zeichen. Kolibri ist ein starker deutscher Tokenizer, kein Zauberer.

Die Qualitätstabelle bleibt eine Herstellertabelle

Wir haben am 5. Oktober an zwei Stellen nach einer unabhängigen Zahl gesucht und sie nicht gefunden. Die Sitemap von Artificial Analysis, 200 OK und vollständig abrufbar, enthält null URLs mit Kolibri. OpenRouter führt in seiner Modelliste mit 464 Einträgen ebenfalls null Treffer. Bis zu unserer Recherche gab es also keine Messung von außerhalb von Aleph Alpha.

Die Chart, die in der Diskussion herumgereicht wird, ist übrigens Abbildung 46 des Technikberichts. Ihre Achse ist nicht der Speicherbedarf und nicht der Durchsatz, sondern die Zahl der aktiven Parameter. Bei dieser Achse liegt ein Modell mit 3,46 Milliarden aktiven Parametern naturgemäß weit links und wandert auf die Hüllkurve. Der Bericht sagt das offen: Qwen3.8-27B erreiche den höchsten Gesamtwert, sei aber ein dichtes Modell mit mehr als dem Achtfachen an aktiven Parametern. Wer dichte Modelle von der Achse ausschließt, bekommt die erwartete Hülle. Der zweite Punkt zeigt, wie leicht sich solche Tabellen lesen lassen: In derselben Messreihe liegt Qwen3.6 35B-A3B mit 71,4 Punkten im englischen Gesamtwert unter Qwen3.5 35B-A3B mit 74,7. Das ist kein Qualitätsbeweis gegen Kolibri, es ist ein Hinweis darauf, dass hier Momentaufnahmen verschiedener Versionen stehen.

Und dann die Zeilen, die der Hersteller selbst als schwach benennt. Wir haben sie gegen unsere eigenen Schwächen abgeklopft:

Die letzte Zeile ist die interessante. Kolibri wurde nachweislich darauf trainiert, eine Antwort zu verweigern, wenn der Kontext sie nicht trägt, mit eigens gebauten RL-Umgebungen und Enthaltungssdaten. Auf der Achse, die Aleph Alpha dafür selbst ansetzt, schneidet das Modell schlechter ab als der kleinere Qwen3.6 35B-A3B: −32,8 gegen −15,3, die Rate echter Antworten ohne Halluzination 44,0 gegen 56,7. Die Methode ist im Bericht minutiös dokumentiert, das Ergebnis auf eben dieser Methode ist in derselben Tabelle das schlechteste der Vergleichsgruppe. Das ist der Unterschied zwischen einer trainierten Absicht und einem Messwert.

Die Hardware-Rechnung für unser Haus

Wir haben am Abend des 5. Oktober auf beiden GPU-Hosten nachgesehen, nicht gerechnet.

Der Serving-Weg ist der eigentliche Zwang. Das Paket aleph-alpha-inference, das die Architektur überhaupt erst in vLLM bringt, erklärt im Projekttext, dass jeder Release genau eine vLLM-Nebenversion unterstützt, hier vllm>=0.29.0,<0.30.0. Unsere Produktivlane läuft auf einem eigenen Entwicklungsstand, der Ersatz-Host auf 0.30.0. Kolibri wäre also ein zweiter Container mit einer zweiten vLLM-Version, nicht ein weiterer Modellordner im bestehenden Bild. Das Repository des Pakets ist am 28. September angelegt worden, hat 19 Sterne und zwei offene Anfragen.

Der Umweg über llama.cpp, den mehrere Kommentatoren nennen, existiert, aber nur mit Pflaster. Ein Community-Repo liefert Q4_K_M mit 47,5 GB, Q6_K mit 64,2 GB und Q8_0 mit 83,1 GB, dazu einen Patch, der auf einen bestimmten llama.cpp-Stand greift. Der Grund steht im selben README: Der Router entscheidet über Logits plus Expert-Bias und gewichtet mit dem unentzerrten Sigmoid, die vorhandene DeepSeek-V3-Routingbehandlung in llama.cpp rechnet an dieser Stelle anders. Der Autor dieser Konversion misst für Q4_K_M im reinen CPU-Betrieb 11,9 Token pro Sekunde bei 46,6 GB Speicherbedarf, und der CUDA-Pfad fällt auf die MoE-Ausführung ohne Kernel-Fusion zurück. Auf unserem Ersatz-Host mit einem EPYC 7502 ohne AVX-512 wäre das keine Sprachspur, das eine Warteschlange.

Was wir daraus machen

Kein Einbau, keine Testspur, Wiedervorlage. Vier Bedingungen, bei denen wir neu messen: eine unabhängige Bewertung, die gegen Qwen3.8-Flash-Next und nicht gegen einen Mittelwert aus offenen Baselines antritt. Eine unterstützte vLLM-Version, die auf einer unserer Boxen läuft. Ein freier Host mit zwei 80-GB-Karten oder einem H200. Und viertens der Fall, dass Verträge, Frachtbriefe und ERP-Texte bei uns wirklich in eine RAG-Strecke gehen, denn dann ist UniBPE als Referenz für Tokenkosten auf Deutsch interessant, unabhängig davon, ob die Gewichte je bei uns laufen.

Was bleibt, ist die Erkenntnis, dass die produktive Frage bei einem deutschen Modell nicht die Benchmarkzeile ist, sondern der Tokenizer und die Speicherbandbreite. Beides lässt sich ohne das Modell prüfen, und beides haben wir jetzt in Zahlen.

Weiterführende Quellen

• Modellkarte mit allen Werten, Architektur und Serving-Anleitung: Kolibri-1 auf Hugging Face
• Technikbericht mit 189 Seiten, dort Abbildung 46 mit der bekannten Chart: Tech-Report als PDF
• Serving-Plugin mit dem vLLM-Pinning im Projekttext: aleph-alpha-inference auf GitHub
• Community-GGUF samt llama.cpp-Patch und CPU-Messwerten: Kolibri-1-GGUF auf Hugging Face
• offenes vLLM-Problem zur FP8-KV-Ausbeute bei Hybridarchitekturen, im Bericht selbst zitiert: Issue 55196
• unser eigener Viertagestest derselben Hardwareklasse: Qwen3.8-Flash-Next im Feldtest
• warum wir überhaupt eine eigene Strecke betreiben: eigene KI-Strecke mit LiteLLM und vLLM