Quelle: GitHub: JustVugg/colibri

Manchmal ist ein Projekt nicht deshalb spannend, weil es sofort praktisch ist. Sondern weil es zeigt, dass eine scheinbar feste Grenze nicht so fest ist, wie wir dachten.

Colibri ist so ein Projekt.

Ein Solo-Entwickler baut eine winzige Runtime, die das riesige GLM-5.2 MoE-Modell mit 744 Milliarden Parametern auf Consumer-Hardware zum Laufen bringt. Nicht auf einem Cluster. Nicht zwingend auf einer GPU-Maschine mit hunderten Gigabyte VRAM. Sondern im Extremfall auf einer Maschine mit ungefähr 25 GB RAM und einer schnellen NVMe-SSD.

Das Ganze ist in purem C geschrieben, ohne klassische Runtime-Abhängigkeiten. Eine kleine Hummingbird-Engine für einen Frontier-Giganten.

Die Idee: Nicht alles muss im Speicher liegen

Der klassische Reflex bei großen Modellen lautet: Das Modell muss in den schnellen Speicher passen. Bei 744B Parametern ist das für normale Hardware absurd.

Colibri dreht die Frage um:

Was muss wirklich dauerhaft im Speicher liegen — und was kann genau dann geladen werden, wenn es gebraucht wird?

GLM-5.2 ist ein Mixture-of-Experts-Modell. Pro Token ist nur ein Teil des Modells aktiv. Genau das nutzt Colibri aus.

Laut README bleiben die dichten und gemeinsam genutzten Teile resident:

  • Attention,
  • Shared Experts,
  • Embeddings,
  • insgesamt rund 17B Parameter,
  • in int4 etwa 9,9 GB RAM.

Die routed Experts liegen dagegen auf der SSD. Das README nennt aktuell 19.456 routed Experts, zusammen ungefähr 370 GB im int4-Container. Diese Experten werden bei Bedarf gestreamt.

Nicht das gesamte Modell ist also „geladen“. Es wird platziert.

Die Runtime denkt wie ein Cache-System

Colibri behandelt VRAM, RAM und SSD nicht als getrennte Welten, sondern als Speicherhierarchie.

Das Projekt nutzt dafür mehrere Ideen, die man eher aus Betriebssystemen, Datenbanken oder JIT-Compilern kennt:

  • LRU-Cache pro Layer: Experten, die kürzlich gebraucht wurden, bleiben näher am schnellen Speicher.
  • Async Prefetching: Die Runtime versucht vorauszuladen, was der nächste Layer wahrscheinlich brauchen wird.
  • Learning Cache: Colibri merkt sich, welche Experten bei deiner Workload häufig auftauchen, und pinnt heiße Experten automatisch.
  • Optionale VRAM-Tier: Wenn GPU-Speicher vorhanden ist, können wichtige Experten dort landen.
  • Dual-SSD-Modus: Zwei Modellkopien können genutzt werden, um Lesebandbreite zu erhöhen.

Das fühlt sich fast wie ein JIT für Modellgewichte an. Ein Compiler kompiliert auch nicht das gesamte Programm im Voraus, sondern optimiert heiße Pfade. Colibri macht etwas Ähnliches mit Expertengewichten.

Warum es trotzdem langsam ist

Der wichtige Teil: Das ist kein magischer Speed-Hack.

Auf einer normalen Maschine mit ca. 25 GB RAM und NVMe ist Colibri laut Projektangaben kalt bei ungefähr 0,05 bis 0,1 Tokens pro Sekunde. Das ist extrem langsam. Ein einzelner Satz kann Minuten dauern.

Der Grund ist simpel: Wenn die benötigten Experten nicht im Cache sind, muss pro Token sehr viel von der SSD gelesen werden. In der README ist von ungefähr 11 GB wechselnden routed Experts pro Token die Rede. Das ist kein Rechenproblem, sondern ein I/O-Problem.

Auf stärkeren Systemen wird es interessanter:

  • große CPU-only-Maschinen mit 128 GB RAM schaffen warm laut README etwa 1,8 tok/s,
  • laptopartige GPU-Systeme mit residenter Pipeline liegen bei rund 1 tok/s,
  • voll residente Multi-GPU-Setups erreichen deutlich höhere Werte.

Aber für normale Hardware bleibt die ehrliche Einordnung:

Colibri ist derzeit kein Alltagstool. Es ist ein radikales Proof-of-Concept.

Und genau deshalb ist es wichtig.

Speculative Decoding: Mehr Tokens pro Forward-Pass

Colibri implementiert auch das native MTP Speculative Decoding von GLM-5.2.

Die Idee: Ein kleiner Draft-Head schlägt mehrere Tokens vor, das Hauptmodell prüft sie in einem gebatchten Forward-Pass. Wenn die Vorschläge passen, gewinnt man Durchsatz. Laut README werden dabei ungefähr 2,2 bis 2,8 Tokens pro Forward-Pass erreicht, wenn der Cache-Zustand und die Akzeptanzrate mitspielen.

Auch hier gilt: Das löst nicht die Memory Wall alleine. Aber es zeigt, dass Colibri nicht nur ein naiver Disk-Streamer ist, sondern eine ernsthafte Inferenz-Engine mit vielen kleinen Optimierungen.

Warum das Projekt so wichtig ist

Bei lokalen LLMs reden wir oft über Quantisierung, kleinere Modelle oder mehr VRAM. Colibri zeigt eine andere Richtung:

Vielleicht muss ein Frontier-Modell nicht vollständig in schnellem Speicher wohnen, um lokal ausführbar zu sein.

Das ist konzeptionell stark.

Denn MoE-Modelle haben Struktur. Router wählen Experten. Workloads haben Muster. Manche Experten werden häufiger gebraucht als andere. Wenn diese Struktur messbar ist, kann man sie cachen, vorhersagen und platzieren.

Das ist die eigentliche Botschaft:

  • Die Memory Wall ist real.
  • Aber sie ist nicht nur eine Hardware-Grenze.
  • Sie ist auch ein Scheduling-, Caching- und Laufzeitproblem.

Colibri beweist, dass man an dieser Wand arbeiten kann.

Was ich daran besonders mag

Das Projekt ist klein genug, um verstanden zu werden.

Kein riesiger Python-Stack. Keine undurchsichtige Serving-Plattform. Keine zehn Microservices. Die Kernidee steckt in einer bewusst kleinen Engine. Genau dadurch wird das Projekt lehrreich: Man kann sehen, wie Expert-Streaming, Placement und Cache-Strategien zusammenspielen.

Für mich ist Colibri deshalb weniger „Tool zum Benutzen“ und mehr „Labor zum Denken“.

Es macht sichtbar, wo zukünftige lokale Frontier-Runtimes hingehen könnten:

  • bessere Router-Vorhersage,
  • workload-spezifische Expert-Pinning-Strategien,
  • hybride RAM/VRAM/NVMe-Layouts,
  • mehr Parallelität über mehrere SSDs,
  • intelligente Warmup-Profile,
  • vielleicht irgendwann Consumer-Setups, die heute noch absurd wirken.

Fazit

Colibri ist langsam. Sehr langsam, wenn man es auf Minimal-Hardware startet.

Aber das ist nicht der Punkt.

Der Punkt ist: Ein 744B-Parameter-MoE-Modell läuft überhaupt auf einer Consumer-Maschine mit ca. 25 GB RAM. Nicht elegant, nicht schnell, aber korrekt genug, um die Grenze zu verschieben.

Das ist ein Meilenstein für lokale Frontier-Modelle.

Nicht weil morgen alle GLM-5.2 auf dem Laptop nutzen werden. Sondern weil Colibri zeigt, dass die nächste Generation lokaler Inferenz-Engines nicht nur kleinere Modelle braucht, sondern bessere Speicherintelligenz.

Und manchmal beginnt ein echter Durchbruch genau so: mit einer winzigen C-Engine, die einen Giganten von der SSD atmen lässt.