Kolibri 1 im Detail: hybride RNoPE-Attention, Sparse MoE und FP8-Serving

Kolibri 1 ist ein veröffentlichtes englisch-deutsches Sprachmodell mit offenen Gewichten, keine Architekturvorschau. Aleph Alpha veröffentlichte am 3. Oktober 2026 FP8- und BF16-Checkpoints unter Apache 2.0 sowie eine Model Card, einen 189-seitigen Technical Report und ein reines Inferenz-Plugin für vLLM. Das veröffentlichte Modell besitzt 78,1 Milliarden Parameter insgesamt und aktiviert laut Hersteller 3,46 Milliarden pro Token. Dieser Artikel beschreibt diese veröffentlichten Artefakte; Benchmark- und Durchsatzwerte bleiben Herstellermessungen.¹²³

Interessant ist nicht nur, dass Kolibri ein Mixture of Experts ist. Jeder seiner 50 Blöcke kombiniert Grouped-Query Attention (GQA) mit einem MoE. Vierzig Blöcke verwenden ein kurzes Sliding Window und RoPE, zehn regelmäßig eingefügte globale Blöcke nutzen vollständige kausale Attention ohne Positionskodierung. Jedes MoE berechnet einen gemeinsamen und sechs von 384 gerouteten Experten. Dadurch wird der größte Teil der Long-Range-Attention gegen lokale Attention getauscht, ohne den wachsenden globalen KV-Cache oder den residenten 78B-Gewichtssatz zu beseitigen.

Der veröffentlichte Stack

Der Block verwendet Sandwich-Normalisierung: RMSNorm vor und nach Attention sowie MoE, jeweils mit anschließender Residual-Addition. Queries und Keys erhalten zusätzlich RMSNorm pro Head. In logischer, ungeshardeter Form bildet Attention damit [N, 2560] auf Q-, K- und V-Tensoren der Form [N, 48, 128], [N, 4, 128] und [N, 4, 128] ab. Die 6.144-dimensionale Attention-Ausgabe wird wieder auf den 2.560-dimensionalen Residual Stream projiziert. Das sind Checkpoint-Formen; Tensor Parallelism zerlegt sie in der Serving-Implementierung.⁴⁵

Lokales RoPE plus globale NoPE-Attention

In den 40 lokalen Blöcken rotiert RoPE die normalisierten Queries und Keys; die kausale Maske gibt höchstens 512 frühere Token frei. Decode-Arbeit und erhaltener KV-Zustand dieser Blöcke wachsen nicht weiter, sobald das Fenster gefüllt ist. In jedem fünften Block entfällt das Fenster und ein Token kann den vollständigen Prefix betrachten. Diese zehn Blöcke wenden überhaupt kein RoPE an, ein für den globalen Pfad häufig RNoPE genanntes Muster. Informationen können damit über die globalen Schichten Fenstergrenzen überschreiten, obwohl die meisten Schichten lokal bleiben.²⁵

Das ist keine lineare Attention. Für einen Prefill der Länge S berechnen die lokalen Schichten Attention über ungefähr S × 513 Positionen; in den zehn globalen Schichten entstehen weiterhin quadratische S²-Attention-Matrizen. Beim Decoding liest jedes neue Token in diesen globalen Schichten den vollständigen erhaltenen Cache. Das Design senkt den Anteil globaler Attention um vier Fünftel, beseitigt den Long-Context-Engpass aber nicht.

Die logische Cache-Untergrenze macht den Unterschied konkret. Pro Token entstehen K und V für vier Heads der Breite 128. Über zehn Full-Attention-Schichten sind das

$10 \times 2_{K,V} \times 4_{KV\text{-}Heads} \times 128 = 10{.}240$

gespeicherte Werte pro behaltenem Token: 20 KiB in BF16 oder 10 KiB in FP8. Bei 262.144 Token benötigt allein der globale Teil 5 GiB in BF16 oder 2,5 GiB in FP8 pro Anfrage; bei 1.048.576 Token sind es 20 GiB beziehungsweise 10 GiB. Die 40 vollständig gefüllten lokalen Fenster addieren etwa 40,1 MiB in BF16 oder 20,0 MiB in FP8. Diese Werte sind rechnerische Untergrenzen aus veröffentlichten Tensorformen, noch ohne Blocktabellen, Alignment, Fragmentierung und Workspace. Der KV-Cache-Leitfaden erklärt, warum die reale Reservierung einer Engine größer ist.

Routing: Auswahl-Bias und Mischgewichte sind getrennt

Für eine flach angeordnete Tokenmatrix x der Form [N, 2560] erzeugt der Router FP32-Logits [N, 384]. Das veröffentlichte Plugin implementiert eine subtile Regel in zwei Schritten:

1. Zu den Logits wird ein gelernter Experten-Korrektur-Bias addiert; aus der Summe werden die sechs höchsten Experten-IDs ausgewählt.
2. Für diese IDs werden die unveränderten Logits gelesen, mit Sigmoid gewichtet und ohne Renormalisierung auf Summe eins als sechs Mischgewichte verwendet.

Der Korrektur-Bias kann folglich verändern, welche Experten ein Token erhalten, ohne die Ausgaben der ausgewählten Experten direkt zu skalieren. Der Technical Report verbindet die gespeicherten Bias-Werte mit Exact Quantile Balancing im Training. Bei der Inferenz bleibt das Routing Token-Choice-Top-k: Es erzwingt keine exakte Kapazität pro Experte innerhalb eines Batches. Reale Expert-Parallel-Deployments müssen weiterhin Schieflasten und den All-to-all-Verkehr handhaben, der Token zu den Geräten ihrer ausgewählten Experten bringt.²⁵

Jeder geroutete oder gemeinsame Experte ist ein SwiGLU-MLP. Zwei Projektionen 2560 -> 512 bilden SiLU(gate) × up; danach folgt eine Projektion 512 -> 2560. Ohne Bias enthält ein Experte somit

$3 \times 2560 \times 512 = 3{.}932{.}160$

Matrixgewichte. Sechs geroutete Experten plus der immer aktive gemeinsame Experte berühren pro Block und Token ungefähr 27,5 Millionen Experten-Matrixgewichte. Alle 385 Experten enthalten dagegen etwa 1,51 Milliarden solcher Gewichte pro Block. Sparse Aktivierung senkt Arithmetik und Gewichtsverkehr eines Tokens, macht aus dem Checkpoint aber kein 3,46B-Speicherproblem. Gewichtsspeicher, Expertenplatzierung und Interconnect-Bandbreite bleiben eigenständige Kapazitätsgrenzen.

Der FP8-Pfad ist ausdrücklich Mixed Precision

Der Haupt-Checkpoint speichert geeignete lineare Gewichte als FP8 E4M3 in Blöcken von 128 × 128 mit einem FP32-Skalierungswert pro Block. Aktivierungen werden dynamisch in Gruppen von 1 × 128 quantisiert. Embeddings, Normalisierungsschichten, LM Head und MoE-Router bleiben in BF16; der Serving-Pfad gibt Router-Logits in FP32 aus. Der offizielle Startbefehl wählt außerdem einen FP8-KV-Cache. „FP8-Modell“ bedeutet daher nicht, dass jeder Wert ein Byte belegt. Der angegebene Gewichtsspeicher von ungefähr 78 GB enthält zudem weder den KV-Cache pro Anfrage noch Engine-Workspace oder duplizierten beziehungsweise geshardeten Laufzeitzustand.¹²

Hinzu kommt eine konkrete Kernelgrenze. Das offizielle Plugin lehnt für diesen Checkpoint den E8M0-Skalierungspfad von vLLMs DeepGEMM ab: Kolibri trägt FP32-Blockskalierungen, während dieser Pfad sie auf Zweierpotenzen runden würde. Die Implementierung weist Betreiber an, VLLM_USE_DEEP_GEMM_E8M0 zu deaktivieren. Das ist eine Kompatibilitätsanforderung des veröffentlichten Codes und keine allgemeine Aussage, dass DeepGEMM oder FP8 ungenau sei.⁵

Aleph Alpha stellt einen Container und das Paket aleph-alpha-inference bereit, derzeit an vLLM 0.29 gebunden. Der dokumentierte Befehl startet Aleph-Alpha/Kolibri-1 mit --kv-cache-dtype fp8; beim BF16-Checkpoint Aleph-Alpha/Kolibri-1-BF16 entfällt dieses Flag. Die Model Card nennt ungefähr 78 GB für die FP8-Gewichte sowie mindestens eine H200/B200/B300 oder zwei A100/H100 mit je 80 GB. Das sind Deployment-Minima des Herstellers und keine Zusagen für eine gewählte Kontextlänge oder Parallelität. Der VRAM-Leitfaden behandelt die zusätzlichen Speicheranteile.¹³

Native 256K und evaluierte 1M sind verschiedene Aussagen

Kolibri wurde zunächst mit 16.384 Token vortrainiert, anschließend mit 65.536 Token weitertrainiert und erhielt eine letzte Long-Context-Phase mit 262.144 Token. Entsprechend setzt seine Konfiguration max_position_embeddings: 262144. Da nur die begrenzten lokalen Schichten RoPE verwenden und die globalen Schichten ohne Positionskodierung arbeiten, kann die Runtime die Sequenz ohne veränderte RoPE-Skalierung verlängern. Das offizielle Rezept erreicht 1.048.576 Token durch Überschreiben von Modelllänge und Konfiguration.¹⁴³

Eine Million Token ist damit eine evaluierte Extrapolation, nicht die native Trainingslänge. Der Report evaluiert RULER bis 1M und stellt ausdrücklich aufgabenabhängige Verschlechterung fest: Einige Teilaufgaben bleiben stabil, andere fallen ab. Aleph Alpha empfiehlt für Effizienz und komplexe Aufgaben höchstens 262.144 Token. Eine höhere Grenze lässt außerdem die zehn globalen KV-Caches auf die oben berechneten Größen wachsen und behält den quadratischen globalen Prefill-Aufwand. „Keine Positionsskalierung nötig“ ist folglich nicht gleichbedeutend mit „keine Qualitäts-, Latenz- oder Speicherkosten“.

Kolibri 1 ist im hier relevanten praktischen Sinn produktiv nutzbar: Gewichte, Lizenz, Konfiguration, BF16-Fallback, Container und eine versionierte Serving-Implementierung sind verfügbar. Der betriebliche Tausch bleibt konkret. Hybride Attention begrenzt die meisten Caches, behält aber zehn teure globale Schichten; schmale Sparse-Experten senken aktive Rechenarbeit, benötigen jedoch einen residenten 78B-Pool und Routing-Kommunikation; FP8 reduziert Gewichts- und Cache-Bytes, hängt aber von einem bestimmten Mixed-Precision-Kernelpfad ab. Kapazitätsplanung muss alle drei gemeinsam bewerten, statt die 3,46 Milliarden aktiven Parameter als Hardwareanforderung zu lesen.

Quellen