Colibrì streamt große MoE-Modelle über VRAM, RAM und Speicher

Eine C-Engine in einer Datei zum Streamen von MoE-Experten

colibri ist eine in reinem C geschriebene Inferenz-Engine ohne Laufzeitabhängigkeiten. Sie wurde entwickelt, um sehr große Mixture-of-Experts-Modelle auf Hardware auszuführen, die nicht genügend VRAM oder RAM hat, um das gesamte Modell zu halten. Die README listet vier Modellfamilien auf, die derzeit laufen: GLM-5.2 mit 744B Parametern, Inkling mit 975B, Kimi K3 mit 2,8T und OLMoE mit 7B. Die Engine behandelt VRAM, RAM und NVMe-Speicher als eine Speicherhierarchie und streamt die gerouteten Experten bei Bedarf von der Festplatte. Die zentrale Behauptung ist, dass ein Modell nicht in schnellen Speicher passen muss, sondern nur über Ebenen platziert werden muss. Die README spezifiziert nicht die genaue Binärgröße, sondern sagt nur, dass das Programm ein paar hundert Kilobyte groß ist.

Warum ein 744B-Modell auf 25 GB RAM laufen kann

Ein 744B-MoE-Modell aktiviert nur etwa 40B Parameter pro Token, und nur etwa 11 GB davon ändern sich von Token zu Token, die gerouteten Experten. Der dichte Teil, etwa 17B Parameter, bleibt in int4 im RAM resident, etwa 9,9 GB. Die 19.456 gerouteten Experten liegen auf der Festplatte, etwa 370 GB, und werden bei Bedarf mit einem pro-Layer-LRU-Cache, einem gelernten gepinnten Hot-Store und einer optionalen VRAM-Ebene gestreamt. Die README beschreibt dies als JIT für Gewichte: Die Engine beobachtet die Routing-Hitze und stützt die tatsächlich benötigten Experten, anstatt alles zu laden. Sie berichtet auch, dass Routing eine Ebene voraus zu 71,6% vorhersagbar ist, aber die genauen Messbedingungen werden nicht angegeben.

Der Fünf-Schritte-Pfad pro Token und der Dual-SSD-Spiegel

Jede Schicht jedes Tokens durchläuft dieselben fünf Schritte: Route, Union, Platz, Überlappung, Lernen. Das Designziel ist, dass Platzierung nur Geschwindigkeit entscheidet, niemals Semantik. Für Speicher unterstützt colibri eine Dual-SSD-Konfiguration, bei der ein zweites Laufwerk eine vollständige Kopie des Modells hält und die Engine von beiden Laufwerken gleichzeitig streamt. Der Spiegel wird beim Start validiert, indem Dateigrößen und Safetensors-Header verglichen werden, und er wird nie geschrieben. Ein teilweiser Spiegel ist erlaubt; ein Lesefehler auf dem Spiegel fällt auf das primäre Laufwerk zurück. Die README gibt ein Beispiel, bei dem ein 9-GB/s- und 3-GB/s-Paar Experten etwa 33% schneller liest als das schnelle Laufwerk allein. Die Spiegel-Funktion erfordert, dass das zweite Laufwerk vorhanden und lesbar ist, aber das genaue Verhalten, wenn der Spiegel teilweise fehlt, wird beschrieben.

Techniken, die sich durch End-to-End-Messung ihren Platz verdienen

Die README listet mehrere Techniken auf: einen JIT für Gewichte basierend auf Routing-Hitze, gepufferte Experten-Unions, überlappende Lese- und Rechenoperationen, O_DIRECT, gewichtetes Dual-SSD-Striping, heterogene Ausführung über CPU, CUDA, Metal, NUMA und komprimierten KV-Zustand, der 57-mal kleiner ist als der unkomprimierte MLA-Zustand. Spekulatives Dekodieren verwendet den nativen MTP-Head des Modells, aber die README warnt, dass der MTP-Head int8 und nicht int4 sein muss, da int4-Heads auf 0-4% Akzeptanz zusammenbrechen. Die Standardrichtlinie ändert niemals stillschweigend die Modellgenauigkeit oder die Router-Semantik. Die README betont, dass alle Optimierungen als Hypothesen behandelt werden, bis ein kontrollierter End-to-End-A/B-Test sie beweist, und dass ein gut kontrollierter Fehlschlag wertvoller ist als eine unerklärliche schnelle Zahl.

Was gemessen wird und was noch offen ist

Die README berichtet über gemessene Dekodiergeschwindigkeiten auf spezifischer Hardware: 5,8-6,8 tok/s auf 6x RTX 5090 mit vollständiger Residenz, etwa 1,8 tok/s auf einem 128-GB-CPU-Desktop, 1,07 tok/s auf einem einzelnen RTX-5070-Ti-Laptop und 0,05-0,1 tok/s auf einer 25-GB-Entwicklungsbox. Diese werden als Highlights aus den Benchmark-Tabellen präsentiert, und die README sagt, dass Qualität mit Korrektheits-Gates gemessen wird. Die Tabelle der offenen Hypothesen listet sechs Experimente auf, die noch durchgeführt werden müssen, wie z.B. Hold-out-Cross-Session-A/Bs für Routing-Verlauf, Cold-Cache-Ein-Laufwerk-gegen-Zwei-Laufwerk-GLM-5.2-Läufe und Vergleiche hardwarebewusster Planer. Die README lädt Mitwirkende ein, negative Ergebnisse zu veröffentlichen, und spezifiziert die aufzuzeichnenden Daten.

Erste Schritte und was die Quelle nicht erzählt

Die README sagt, dass Sie das Programm (ein paar hundert KB) und das Modell (etwa 372 GB für den GLM-5.2-int4-Container) benötigen. Vorgefertigte Releases sind für Linux, macOS und Windows verfügbar, und der Launcher benötigt Python 3, aber die Engine selbst ist reines C. Der Aufbau aus dem Quellcode erfordert gcc oder clang mit OpenMP. Das Modell ist auf Hugging Face, und die README warnt davor, den gs64-Build mit int8-MTP-Head zu verwenden. Die Befehlszeilenschnittstelle umfasst `coli chat`, `coli serve`, `coli web` sowie mehrere Diagnosebefehle wie `coli plan`, `coli doctor` und `coli tune`. Die README gibt nicht die genaue Befehlssyntax für alle Plattformen an und dokumentiert auch nicht die vollständige Liste der Umgebungsvariablen, verweist aber auf docs/ENVIRONMENT.md. Die Lizenz ist Apache 2.0, und die README merkt an, dass GLM-5.2-Gewichte von Z.ai unter MIT veröffentlicht werden.

Redaktionelles Fazit

Der Ansatz von colibri besteht darin, Expertengewichte als zu stufende Daten zu behandeln und nicht als zu haltenden Zustand, und jede Optimierung Ende-zu-Ende zu messen. Die Quelle gibt noch nicht den vollständigen Inventar der Umgebungsvariablen oder das genaue Verhalten für alle Plattformen an, verweist aber auf Dokumentation, die diese Details abdeckt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes