Werkzeug · Lokal & Self-Hosting

colibrì

von Vincenzo Fornaro („JustVugg“), quelloffen

Inferenz-Engine in reinem C ohne Abhängigkeiten, die ein 744-Mrd.-MoE-Modell (GLM-5.2) auf Consumer-Hardware lauffähig macht: Die dichten Anteile bleiben im RAM (~9,9 GB in int4), die Experten werden bedarfsweise von der SSD gestreamt. Läuft – langsam, aber korrekt – auf Maschinen, für die das Modell eigentlich viel zu groß ist.

Open SourceLinuxmacOSCLI

Einschätzung

Machbarkeitsnachweis für lokale MoE-Inferenz, kein Alltagswerkzeug

Technisch bemerkenswert und sauber dokumentiert: ein 744-Mrd.-Modell antwortet korrekt auf Maschinen, auf die es nicht passt. Produktiv nutzbar ist das aber nur am oberen Ende der Tabelle – auf der 25-GB-Referenzmaschine sind 0,05–0,1 Token/s rund ein Wort alle zehn bis zwanzig Sekunden. Der eigentliche Erkenntniswert liegt in der Kostenstelle: Nicht die GPU begrenzt, sondern Arbeitsspeicher und Plattendurchsatz. Wer die Hardware hat, auf der es flott läuft (Multi-GPU-Rig oder Server mit sehr viel RAM), hätte auch andere Wege.

colibrì setzt an der Eigenschaft von Mixture-of-Experts-Modellen an, dass je Token nur ein Bruchteil der Gewichte gebraucht wird – beim 744 Mrd. Parameter großen GLM-5.2 laut Projektangabe rund 5,4 Prozent. Die dauerhaft benötigten dichten Teile (Attention-Schichten, geteilte Experten, Embeddings) hält die Engine in int4-Quantisierung mit rund 9,9 GB dauerhaft im Arbeitsspeicher; die 19.456 gerouteten Experten liegen auf der Platte (int4-Container rund 372 GB) und werden beim Bedarf gestreamt und zwischengespeichert. Dazu kommen ein lernender Cache, der die am häufigsten angesteuerten Experten beim Start in freies RAM pinnt, spekulatives Dekodieren über den nativen Multi-Token-Kopf des Modells und eine MLA-Attention, die den KV-Cache laut Projekt um den Faktor 57 verkleinert.

Die Engine ist in reinem C ohne externe Abhängigkeiten geschrieben und steht unter Apache-2.0-Lizenz; eine Python-Laufzeit wird nicht gebraucht. Über GLM-5.2 hinaus läuft nach Projektangabe bereits OLMoE, auf der Roadmap stehen Kimi K2, Qwen3-MoE und MiniMax. Ausdrücklich zugesichert wird, dass bei knappem schnellen Speicher die Geschwindigkeit sinkt, aber nicht stillschweigend die Präzision: „Insufficient fast memory may reduce speed, but the default policy never silently changes model precision.“

Die veröffentlichte Messtabelle beschreibt die Bandbreite ehrlich: 5,8–6,8 Token/s auf sechs RTX 5090 mit voller Experten-Residenz, rund 1,8 Token/s warm auf einem reinen CPU-Rechner mit 128 GB RAM, 1,07 Token/s auf einem Laptop mit RTX 5070 Ti – und 0,05–0,1 Token/s auf der 25-GB-Referenzmaschine. Ein unabhängiger Nachbau (Better Stack, Tier C) bestätigt die Größenordnung und liefert die Erklärung mit: Auf einem MacBook M2 Max mit 32 GB RAM und externer USB-SSD entfielen von 158 Sekunden Antwortzeit rund 145 auf Warten auf die Platte und nur etwa 7 auf Rechenzeit; auf einer Workstation mit 64 GB RAM und interner SSD sank der Warteanteil auf rund 48 Prozent und die Ausgabe stieg auf rund 0,8 Token/s. Nicht die Grafikkarte entscheidet also, sondern wie viel des Modells im Arbeitsspeicher bleibt.

Wofür es gut ist

Ein Open-Weight-Frontier-Modell auf eigener Hardware überhaupt ausführbar machen, wo VRAM und RAM dafür nicht reichen
Datenhoheit ohne Cloud-Inferenz, wenn Latenz und Durchsatz keine Rolle spielen (Batch, Prüfläufe, Experimente)
Verstehen und messen, woran lokale MoE-Inferenz tatsächlich hängt – die Engine weist Warte- gegen Rechenzeit getrennt aus

Stärken

Reines C ohne Abhängigkeiten, Apache-2.0 – klein, prüfbar, ohne Python-Laufzeit
Kein stiller Qualitätsverlust: Der Forward-Pass ist laut Projekt token-exakt gegen eine Transformers-Referenz validiert, knapper Speicher kostet Geschwindigkeit statt Präzision
Transparente Profilierung (Warte- vs. Rechenzeit) und eine Messtabelle, die die schwachen Konfigurationen mitnennt

Schwächen

Auf der beworbenen 25-GB-Maschine praktisch unbenutzbar langsam (0,05–0,1 Token/s laut eigener Tabelle)
Rund 372 GB Plattenplatz allein für den GLM-5.2-Container – die erste Hürde ist oft der Speicherplatz, nicht die Rechenleistung
Ein-Personen-Projekt in schneller Bewegung; Modellauswahl bislang schmal (GLM-5.2, OLMoE), Kimi K2/Qwen3-MoE/MiniMax nur angekündigt

Im Vergleich

Wofür dieses Werkzeug die bessere Wahl ist – und wann ein direkter Konkurrent.

Wo Ollama und LM Studio Modelle bedienen, die ganz in den Speicher passen, geht colibrì den umgekehrten Weg: Es nimmt bewusst in Kauf, dass das Modell nicht passt, und behandelt VRAM, RAM und SSD als eine Speicherhierarchie. Das verschiebt den Flaschenhals von der Modellgröße zum Plattendurchsatz.

Stimmen aus der Community

Subjektive Einschätzungen Dritter – keine belegten Fakten, jeweils verlinkt.

gemischtUnabhängiger Nachbau auf zwei Maschinen bestätigt Funktion und Größenordnung, aber auch die Grenze: „can you run a 744 billion parameter Frontier model on consumer hardware? Yes, full stop“ – zugleich sei „running it and running it well … two very different things“. Der Befund aus dem eigenen Profiling: Nicht die RTX 5090 entscheide, sondern der Arbeitsspeicher.Better Stack – „This Tiny Engine Runs Impossibly Big AI Models Locally! (colibrì)“ (YouTube) · Community, Juli 2026

Direkt ausprobieren

github.com/JustVugg/colibri

Zur offiziellen Seite ↗

ℹ️ Über den Dev-/Vendor-Kanal Better Stack (C58, Tier C) aufgekommen; Existenz, Architektur, Lizenz und sämtliche Kennzahlen an der Primärquelle (GitHub-Repo) geprüft, nicht am Video. Abweichung nicht aufgelöst und deshalb nicht übernommen: Das Video nennt GLM-5.2 mit 744 Mrd. Parametern und ~357 GB, unser Katalog führt GLM-5.2 mit 753 Mrd.; die Größenangaben hier stammen sämtlich aus dem Repo. Kursierende Stern- und Zeilenzahlen der Sekundärberichte widersprechen einander (14,7k/19,2k Sterne, 1.300/2.400 Zeilen) und sind hier weggelassen. Juli 2026 erschienen – evergreen Tooling, keine dated Depesche.

Wofür es gut ist

Stärken

Schwächen

Im Vergleich

Stimmen aus der Community

Verwandte Werkzeuge