Colibri führt GLM-5.2 auf Consumer-Hardware aus. Der Haken.

Zurück

Kevin Riedl

19 min Lesezeit · 14. Juli 2026
Zuletzt geprüft 4. November 2026

Weiter

Colibri kann GLM-5.2 weiterhin mit ungefähr 25 GB RAM ausführen. Das ist ein Fortschritt bei der benötigten Speicherkapazität, aber kein Versprechen für schnelle Chats. Die ursprüngliche Entwicklermessung lag bei kaltem Cache bei 0,05-0,1 erzeugten Token pro Sekunde. 100 Ausgabe-Token benötigen damit rechnerisch etwa 17-33 Minuten, ohne Prompt-Verarbeitung. Spätere Messungen mit bestimmten Modellcontainern sind schneller. Der alte Wert ist deshalb keine allgemeine Obergrenze für ein RAM-Budget von 25 GB.

Quellenprüfung am 4. November 2026. Die neueste verifizierte Version ist Colibri v2.1.0 vom 31. Oktober. Sie ergänzt GGUF-Import, breitere Vulkan-/CUDA-Pfade und neue Modelle. Die alte Brio-Route wurde entfernt: Aktuelle Integrationen verwenden POST /v1/systemone. Die September-Releases v1.12.0 und v1.11.0 bleiben historische Einordnung, keine aktuelle Funktionsgrenze.

Der Schwerpunkt dieses Artikels bleibt erhalten: Was leistet Colibri auf deiner Hardware tatsächlich, welche Kosten entstehen durch Latenz und Speicherbedarf, und wie testest du das, ohne einen erfolgreichen Start mit einer produktiven Bereitstellung zu verwechseln? Sämtliche Geschwindigkeiten stammen aus den verlinkten Projektmessungen, nicht aus Wavect-Benchmarks.

Was ist Colibri, und was hat sich seit unserem letzten Review geändert?

Colibri, vom Projekt als Colibrì geschrieben, ist eine unter Apache 2.0 veröffentlichte Inferenzlaufzeit. Sie verteilt Modellgewichte auf NVMe-Speicher, Arbeitsspeicher und optionalen Grafikspeicher. Dabei wird kein Modell mit 744 Milliarden Parametern in 25 GB gepresst. Der Checkpoint bleibt auf dem Datenträger; nur die gerade benötigten Teile müssen in schnellerem Speicher liegen. Die README der geprüften Version unterscheidet zwischen der abhängigkeitsfreien C-Inferenzengine und dem Python-Launcher samt HTTP-Gateway. „Kein Python zur Laufzeit“ ist für den üblichen coli-Workflow deshalb irreführend.

Der Colibri-Container für GLM-5.3 umfasst ungefähr 419 GB und verwendet dieselbe Engine-Familie wie GLM-5.2. Anders als der empfohlene 5.2-Container enthält er keinen MTP-Head. Dieser Pfad für spekulatives Decoding bleibt daher ausgeschaltet. Es handelt sich um einen anderen Checkpoint, nicht um ein automatisches Upgrade vorhandener 5.2-Gewichte.

Was änderte sich nach der September-Basis?

Die README von v2.1.0 nennt zusätzliche MiMo-, Flint-, Mistral-Large-4- und LFM3-Pfade. GPU-Unterstützung bleibt engineabhängig; ein Vulkan-Treiber garantiert nicht für jede Operation Beschleunigung. Der aktuelle Inkling-Download umfasst vor der dokumentierten Konvertierung dichter Gewichte etwa 514 GB statt der alten Zusammenfassung mit 469 GB.

Beim GGUF-Import erzeugt ./coli import model.gguf Metadaten für eine unterstützte Architektur. Link-Modus liest bestehende Dateien; Copy-Modus kann zusätzlichen Plattenplatz benötigen. Alle Split-Shards müssen verfügbar bleiben. Das Release nennt eine GLM-5.2-Datei UD-IQ1_S mit 202 GB und 0,633-0,658 tok/s auf seinem Vulkan-Testrechner. Das ist eine andere Quantisierung und Maschine als die gruppierte-int4-Basis mit 429 GB, kein qualitätsgleiches Tempo-Upgrade für einen 25-GB-Laptop.

Wie läuft ein 744B-Modell mit 25 GB RAM?

GLM-5.2 ist ein Mixture-of-Experts-Modell: Pro Token sind ungefähr 40B der rund 744B Parameter aktiv. Die offizielle Modellkarte beschreibt das Modell. Ihre Leistungsangaben belegen jedoch nicht automatisch die Qualität einer bestimmten Colibri-Quantisierung. Colibri hält ungefähr 9,9 GB dichter Gewichte im RAM und lädt ausgewählte geroutete Experten vom Datenträger. Das ursprüngliche Layout umfasst 19.456 Expertenblöcke über 75 MoE-Schichten und den MTP-Head.

Ein Cache pro Schicht, gelernte Priorisierung häufig verwendeter Experten, Betriebssystem-Caches und optionale GPU-Platzierung vermeiden einen Teil wiederholter Lesezugriffe. Für den ursprünglichen kalten Zustand werden etwa 11 GB gelesene Expertengewichte pro erzeugtem Token angegeben. Das ist eine Schätzung für ein bestimmtes Layout und eine bestimmte Last, keine Konstante für sämtliche Modelle, Checkpoints oder spekulativen Modi.

Zwei Dinge müssen getrennt werden: Quantisierung verändert die Darstellung der Gewichte; die Speicherhierarchie verändert deren Aufenthaltsort. Identische quantisierte Ergebnisse auf CPU und GPU beweisen nicht, dass die Quantisierung die Genauigkeit des ursprünglichen Modells erhalten hat. Umgekehrt kann eine korrekt rechnende Engine für deine Anwendung trotzdem zu langsam sein.

Welche Modelle unterstützt Colibri, und welche Hardware benötigen sie?

Das Familienregister von v1.12.0 hilft, eine Engine-Familie von einem Checkpoint-Namen zu unterscheiden. Neun Familien bedeuten nicht neun beliebig austauschbare Modellkennungen. Jede benötigt passende Implementierungen für Routing, Attention, Tensorformate und Chat-Verarbeitung. Dieses September-Register entstand vor dem GGUF-Import; v2.1.0 lädt die oben dokumentierten Architekturen.

Wichtige Korrektur zum Plattenbedarf: Die September-README von v1.12.0 bezeichnete den GLM-5.2-Container noch als 372 GB groß. Die Container-Modellkarte enthält abweichende Größenangaben; die aktuelle Dateiliste zeigt ungefähr 429 GB. Plane anhand der konkreten Revision und ausgewählten Dateien, nicht anhand der alten Schlagzeile. Dezimale GB und binäre GiB dürfen nicht vermischt werden. Ein kleinerer E8/IQ3-Container nennt etwa 289 GB, verändert aber die Gewichtsdarstellung und hat eigene Genauigkeits- und Decoding-Abwägungen. Die Verkleinerung ist nicht kostenlos.

Die Engine-Dokumentation für DeepSeek V4.1 Flash erklärt, warum die gesamte Checkpoint-Größe den Aufwand pro Token schlecht vorhersagt: Ungefähr 203 GB entfallen auf datenträgergestützten N-Gramm-Speicher. Die gerouteten Experten verursachen vor Cache-Treffern ungefähr 4,5 GB pro Token. Die Gewichte benötigen keine Konvertierung; die dokumentierte Einrichtung erzeugt jedoch eine kleine Begleitdatei namens dsv41_engram.json. „Keine Konvertierung“ bedeutet nicht „keine Vorbereitung“.

Auch bei Qwen3.8 widersprechen sich Dokumentationsstellen. Die September-README-Zusammenfassung nannte mindestens 16 GB und ausschließlich CPU-Betrieb. Die detaillierten Qwen3.8-Messungen zeigen bei einer kurzen Anfrage mit cap 32 ungefähr 16,5 GiB maximale RSS und empfehlen für dieses Setup praktisch 24 GB Gesamtspeicher, für einen größeren Cache 32 GB. v1.12.0 ergänzt CUDA trotz verbliebener Aussagen über ein fehlendes Backend. Maßgeblich sind die zur Version passende Implementierung und die gemessene Konfiguration, nicht eine isolierte Tabellenzeile.

Wie schnell ist Colibri auf Consumer-Hardware?

Die Benchmark-Sammlung des Projekts dokumentiert die folgenden GLM-5.2-Ergebnisse. Die Core-Ultra-9-Zeile mit begrenztem RAM stammt aus der oben verlinkten Container-Karte. Es sind historische Läufe mit unterschiedlichen Builds, Cache-Verläufen und Containern, kein kontrollierter Vergleich unter v1.12.0. Einige ältere Zeilen erfüllen die inzwischen strengeren Anforderungen an GPU-Korrektheitsnachweise nicht.

Das Ergebnis mit sechs GPUs ist keine Ausgangsbasis für einen Consumer-Laptop. Spätere Tests mit selektiver NUMA-Platzierung erreichten auf einem bestimmten Mehrsockel-Host ungefähr 9 tok/s. Auch die in den Release Notes genannte Qwen3.6-Steigerung von 12,8 auf 15,7 tok/s bei sinkendem residentem Speicher von 29 auf 17 GB gehört zu diesem Qwen-Workload. Sie macht GLM-5.2 auf 25 GB nicht zu einem Modell mit 15,7 tok/s.

Für einen realen Dienst zählt die vollständige Anfrage: Warteschlange, Prompt-Prefill, Generierung und mögliche Werkzeugaufrufe. Ein wiederverwendeter Prompt kann nahezu ohne Prefill auskommen, während ein neues Dokument langsam bleibt. Ein Dashboard-Screenshot mit warmem Cache belegt keine Latenz für neue Dokumente.

Was solltest du zuerst optimieren: RAM, NVMe oder GPU?

Beginne bei der Phase, die tatsächlich die Laufzeit verbraucht. Auf einem GLM-System mit wenig RAM können wiederholte Cache-Fehlzugriffe dominieren. Auf einem weitgehend residenten System können dagegen CPU-Matrixmultiplikation oder Speicherbandbreite begrenzen. Beim historischen SSD-Vergleich auf demselben Rechner stieg die gemessene Bandbreite von 1,51 auf 8,81 GB/s, die Generierung aber nur von 0,10 auf 0,28 tok/s, weil die Rechenarbeit wichtiger wurde.

Miss kalte, nicht zwischengespeicherte Shard-Lesezugriffe statt der beworbenen sequenziellen SSD-Höchstgeschwindigkeit. Unter macOS entfernt der dokumentierte F_NOCACHE-Test keine bereits vorhandenen Cache-Seiten. Vergleiche außerdem mehrere Prompts: Gelernte Pins können die Trainingslast des Caches bevorzugen. Ein größerer Cache oder mehr zugewiesener RAM ist nicht automatisch schneller, wenn dadurch Ressourcenkonkurrenz entsteht oder Systemreserven fehlen.

Eine GPU hilft, wenn ihr Backend den gemessenen Engpass reduziert. Ihre bloße Anwesenheit beseitigt keine Plattenzugriffe. Zu jedem CUDA-, HIP-, Metal- oder Vulkan-Zeitwert gehört ein Qualitätscheck. Das Projekt dokumentiert einen HIP-Fall mit ähnlicher Geschwindigkeit, aber erheblich schlechterer Perplexität. Die reine Geschwindigkeit hätte den Fehler verdeckt.

Auch MTP ist ein Experiment, kein kostenloser Beschleunigungsschalter. GLM-5.2 benötigt den richtigen int8-MTP-Head; zusätzliche spekulative Expertenzugriffe können bei kaltem Cache nachteilig sein. Die Router-Abkürzung --topp 0.7 verändert das Routing ausdrücklich verlustbehaftet. Sie ist nicht dasselbe wie gewöhnliches Sampling von Ausgabe-Token. Sobald sich die Modellsemantik ändert, muss die Qualität erneut geprüft werden.

Wie viel Qualität erhält die GLM-5.2-int4-Variante?

Die Evidenz trägt weiterhin keine pauschale Aussage wie „Frontier-Qualität auf dem Laptop“. Ein kleiner GLM-5.2-Test des Projekts meldet 62,5 % mittlere normalisierte Genauigkeit über HellaSwag, ARC und MMLU bei nur 40 Fragen pro Aufgabe. Ein separates OLMoE-Experiment maß 8,2 Prozentpunkte Quantisierungsverlust; gruppierte Skalierung holte davon ungefähr 63 % zurück. Das sagt etwas über die Methode, ist aber kein sauberer Vergleich zwischen unquantisiertem GLM-5.2 und int4.

Es gibt inzwischen auch direktere GLM-Evidenz: Die gruppierte-int4-Modellkarte nennt für HellaSwag 87,0 % gegenüber 83,5 % normalisierter Genauigkeit bei zeilenweiser int4-Quantisierung, mit 200 Fragen. Die E8-Karte vergleicht ebenfalls mit gruppiertem int4. Ihre kleinen Stichproben und das eingeschaltete cacheabhängige Routing isolieren den Quantisierungsfehler jedoch nicht. Das sind hilfreiche, begrenzte Tests, keine Gleichwertigkeit zum Originalmodell und kein Nachweis produktiver Reasoning-Qualität.

Halte bei eigenen Tests Checkpoint, Quantisierung, Prompt-Vorlage und erwartete Ergebnisse fest. Verwende schwierige Negativbeispiele, mehrsprachige Eingaben und Aufgaben, die zuvor Schleifen oder erschöpfte Ausgabelimits auslösten. Prüfe sowohl Antwortqualität als auch korrektes Beenden. Tokenidentische Implementierung und nützliche Geschäftsergebnisse sind unterschiedliche Prüffragen.

Verschleißt Experten-Streaming die SSD?

11 GB gelesene Daten sind nicht 11 GB Verbrauch eines Schreibbudgets. Kingstons Erklärung von TBW und DWPD bezieht diese Kennzahlen auf geschriebene Daten und Programmier-/Löschzyklen. Colibris Expertenpfad ist leseintensiv. Modelldownloads, Konvertierung, gespeicherter Zustand und Betriebssystem-Swap können dennoch Schreibzugriffe verursachen.

Beobachte bei einem langen repräsentativen Lauf Temperatur, SMART-Zustand und Swap-Aktivität. Lass RAM-Reserven, damit Caching nicht schreibintensive Auslagerung auslöst. Eine dedizierte 1-TB-NVMe ist für den ungefähr 429 GB großen Referenzdownload plus Betriebsreserve eine vernünftige Planungsgröße. Sie ist weder ein Softwareminimum noch eine Garantie, dass jede Konvertierung vom Quellmodell darauf passt. Temporären Speicherbedarf separat prüfen.

Von Brio zu System One: Wie migrieren bestehende Clients?

Der aktuelle System-One-Vertrag ersetzt /v1/brio, das bis v1.12.1 existierte. Sende state und ein Objekt typisierter questions: choice erhält Labels mit Beschreibungen, noul eine Ja-/Nein-Frage und score geordnete Stufen. Antworten stehen unter answers. Nur die URL zu ändern genügt nicht: Alte options- und schema-Formen passen nicht unverändert.

Bei Sprachmodell-Scoring ist normalize: "sum" jetzt Standard. Das optionale mean kann Vergleiche zwischen unterschiedlich langen Labels verzerren. Jede unabhängige Frage liest den Zustand; anders als beim alten sequenziellen Schema sehen spätere Fragen vorher gewählte Feldwerte nicht automatisch. Abhängige Entscheidungen müssen ausdrücklich verkettet werden.

Das ältere Brio-Vier-Felder-Ergebnis mit Qwen3.6, 103,8 statt 246,0 Sekunden, bleibt historische Evidenz, kein GLM-Benchmark und keine aktuelle System-One-Servicegarantie. Ohne freie Textgenerierung entstehen weiterhin Kosten für Prefill, Optionsbewertung und Cache-Verwaltung. Wahrscheinlichkeiten und Konfidenz sind keine kalibrierte Garantie geschäftlicher Korrektheit. Plane menschliche Prüfung und teste Labels, Fehlerkosten und Schwellenwerte anhand eigener Fälle.

Die separate Kategorie behandelt unser Review des Jev-Entscheidungsmodells. Protokollkompatibilität belegt weder gleiche Modellqualität noch eine Berechtigung.

Wie installierst und testest du Colibri v2.1.0?

Für einen reproduzierbaren Build auf einem unterstützten Unix-ähnlichen System solltest du die Version festlegen, statt einen unbekannten zukünftigen main-Stand zu laden. Python 3 und ein unterstützter C-Compiler mit OpenMP müssen vorhanden sein. Die folgenden Befehle laden keine Gewichte herunter: Unter /nvme/glm52_i4 muss bereits der oben verlinkte GLM-5.2-Referenzcontainer mit gruppiertem int4 und int8-MTP liegen. Für Windows oder andere Compiler und Backends gelten die jeweiligen Plattformanleitungen.

git clone --branch v2.1.0 --depth 1 https://github.com/JustVugg/colibri.git
cd colibri/c
./setup.sh
export COLI_MODEL=/nvme/glm52_i4
./coli doctor --deep
./coli plan
./coli chat

doctor --deep prüft die Modellbereitschaft; plan erklärt die Speicherplatzierung. Beide belegen weder Antwortqualität noch Dienstlatenz. Speichere den Plan zusammen mit der Checkpoint-Revision oder Prüfsummen im Benchmark-Protokoll. Dieselbe Engine-Familie lädt GLM-5.3, benötigt aber dessen eigenen Container. Erwarte nicht das MTP-Verhalten von GLM-5.2.

Starte zum Gateway-Test einen dauerhaften Server in einem Terminal. Ersetze den Platzhalter durch ein starkes lokales Geheimnis und behalte während der Evaluation die Loopback-Bindung bei:

export COLI_API_KEY='replace-with-a-long-random-local-secret'
COLI_MODEL=/nvme/glm52_i4 ./coli serve \
  --host 127.0.0.1 --port 8000 --model-id glm-5.2-colibri

Setze in einem zweiten Terminal COLI_API_KEY auf dasselbe Geheimnis und sende dieses synthetische System-One-Beispiel. Die Modellkennung muss mit dem Server übereinstimmen. Die Anfrage schlägt eine Prüfwarteschlange vor. Sie erstattet keine Zahlung und beweist nicht, dass tatsächlich doppelt abgebucht wurde.

curl --fail-with-body http://127.0.0.1:8000/v1/systemone \
  -H "Authorization: Bearer ${COLI_API_KEY:?Set the same key as the server}" \
  -H 'Content-Type: application/json' \
  --data-binary '{
  "model": "glm-5.2-colibri",
  "state": "The ticket reports two charges for one renewal. The payment ledger has not been checked.",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team should inspect the evidence?",
      "criteria": {
        "billing": "Inspect the payment ledger",
        "technical support": "Investigate a technical fault",
        "human review": "Insufficient evidence; ask a person"
      }
    }
  },
  "normalize": "sum"
}'

Das Beispiel basiert auf dem dokumentierten API-Vertrag, nicht auf einem für diesen Artikel durchgeführten Integrationstest. Ergänze in einer Anwendung ein zur gemessenen Prefill-Zeit passendes Timeout, Antwortvalidierung sowie Fehlerbehandlung für Warteschlangen-Ablehnung und Engine-Ausfälle. Mache den Listener nicht öffentlich, nur damit sich ein entfernter Editor verbinden kann.

Lässt sich die API mit Claude Code oder einer Geschäftsanwendung verwenden?

Die Gateway-Dokumentation beschreibt OpenAI-kompatible Chat-/Completion-Routen und eine Route /v1/messages im Anthropic-Protokoll. Protokollkompatibilität garantiert weder identisches Werkzeugverhalten noch dieselbe Coding-Qualität. Große Agenten-Systemprompts und Werkzeugkataloge können die Zeit bis zum ersten Token gegenüber einem kurzen manuellen Chat stark erhöhen.

Der normale Serving-Pfad führt weiterhin nur eine Generierung gleichzeitig aus. Er begrenzt die Aufnahme neuer Anfragen und antwortet bei abgewiesenen oder abgelaufenen Warteschlangen-Anfragen mit HTTP 429. Mehrere KV-Slots halten getrennte Kontexte, soweit die Engine das unterstützt. Sie sind kein Continuous Batching und nicht bei allen Engines gleich verfügbar. Lege Warteschlangen-Timeouts anhand gemessener Anfragedauern fest, nicht anhand optimistischer Tokenraten.

Vision, Logwahrscheinlichkeiten und Tools bleiben engine- und endpunktabhängig. System One bewertet Options-Logwahrscheinlichkeiten, schaltet aber nicht überall jeden API-Parameter, Bildblock oder Tool-Aufruf frei. Prüfe konkrete Engine und Anfrageform; nicht unterstützte Kombinationen sollen ausdrücklich scheitern, statt Daten still zu verwerfen.

Wo ergibt Colibri heute geschäftlich Sinn?

Unsere Einordnung ändert sich von einem pauschalen „nicht produktionsreif“ zu Workload und ausgewählte Engine getrennt bewerten. Das Projekt bietet konkrete Funktionen und Verbesserungen. Dieser Review belegt aber keinen produktiven Servicelevel. GLM-5.2 per Streaming auf einem 25-GB-Rechner bleibt für reaktionsschnelle, parallele Kundenchats eine schlechte Wahl.

Lokale Ausführung kann die Kontrolle über Modellverkehr verbessern. Sie löst nicht automatisch Zugriffsschutz, Aufbewahrung, Backups, Client-Telemetrie oder Berechtigungen. Für die Wirtschaftlichkeit nutzt du unseren Break-even-Leitfaden für lokale Modelle und APIs, statt nicht abgerechnete Token als kostenlos zu behandeln. Vor einem Hardwarekauf hilft unser llmfit-Hardwareleitfaden bei der Vorauswahl üblicher Modell-/Runtime-Kombinationen. Colibris Experten-Streaming-Cache simuliert er nicht.

Wie solltest du ein Upgrade vor dem verlässlichen Einsatz messen?

Verwende das reproduzierbare Benchmark-Protokoll des Projekts und bewahre Rohprotokolle auf. Beginne mit repräsentativen Aufgaben statt einer einzelnen Begrüßung. Erfasse Commit, Modellrevision, Konvertierungseinstellungen, Befehle, Kontextlänge, RAM-/VRAM-Platzierung und Datenträgerkonfiguration.

Trenne kalte, identisch wiederholte und wechselnde Prompts in einem laufenden Server. Berichte Erst-Token-Latenz, Gesamtzeit, akzeptierte Ausgabe, Decoding-Rate, Cache-Trefferrate, gelesene Bytes und maximalen Speicherverbrauch. Wiederhole Konfigurationen abwechselnd, damit Temperatur, Cache-Verlauf und Hintergrundlast das Ergebnis nicht bestimmen. Für System One gehören Optionsmenge, Normalisierung, Kosten falscher Zuordnungen und menschliche Prüfquote dazu.

Unsere Umsetzungsempfehlung beginnt im Schattenbetrieb: eine Entscheidung berechnen, ohne die Geschäftsaktion auszuführen, mit dem bisherigen Prozess vergleichen und erst nach Prüfung erweitern. Die Trennung zwischen überzeugender Demo und betreibbarem System zeigen auch unsere Twinsoft-AI-Fallstudie und unser Leitfaden zur Technologieauswahl. Wavects AI-Enablement-Service deckt Evaluation, Integration, Beobachtbarkeit und Rückfallmechanismen ab.

Quellen, Prüfdatum und Grenzen

Dies ist ein quellenbasierter technischer Review, aktualisiert am 4. November 2026 anhand von v2.1.0. Primärquellen stehen bei den zugehörigen Aussagen. Soweit verfügbar, verwenden wir Code und Dokumentation des Release-Tags. Modell-Repositories können sich weiter ändern. Das ursprüngliche Veröffentlichungsdatum bleibt 14. Juli 2026.

Wir haben die großen Checkpoints für dieses Update weder heruntergeladen noch ausgeführt, keine Community-Benchmarks reproduziert und keine laufende System-One-Installation getestet. Die Zeitumrechnung nutzt Sekunden = Ausgabe-Token / Token_pro_Sekunde, ohne Prefill und Warteschlange. Der Brio-Vergleich verwendet 246.0 / 103.8. Vorgeschlagene Abnahmekriterien und geschäftliche Eignung sind unsere Analyse, keine Garantien des Projekts. Dokumentationswidersprüche werden benannt und nicht in scheinbar sichere allgemeine Aussagen umgewandelt.

Du brauchst aus diesen Tests eine belastbare Deployment-Entscheidung? Eine messbare lokale KI-Evaluation mit Wavect besprechen.