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

Ja, Colibri kann GLM-5.2 auf einem Rechner mit rund 25 GB RAM ausführen. Nein, daraus wird kein lokaler Claude-Ersatz. Der Entwickler misst im kalten Zustand 0,05 bis 0,1 Token pro Sekunde: ein Token alle 10 bis 20 Sekunden, Prompt-Verarbeitung nicht eingerechnet. Eine knappe Antwort mit 100 Tokens dauert ungefähr 17 bis 33 Minuten.

Die technische Leistung ist trotzdem real. Colibri führt ein Mixture-of-Experts-Modell mit 744 Milliarden Parametern auf Hardware aus, die nur einen Bruchteil davon in RAM oder VRAM halten kann. NVMe, Arbeitsspeicher und optionaler Grafikspeicher werden zu Stufen einer Speicherhierarchie. Die Rechnung ist brutal einfach: Die Kapazität kommt von Disk, die Latenz wird mit Disk-Reads bezahlt.

Dieser Test bildet den Stand vom 14. Juli 2026 ab. Das Projekt entwickelt sich schnell; Messwerte, Schätzungen und Ziele werden hier getrennt.

Was ist Colibri?

Colibri, vom Projekt als Colibrì geschrieben, ist eine überwiegend in C entwickelte Inference Runtime für sehr große sparse MoE-Modelle über Storage, RAM und optional VRAM. Upstream zielt derzeit auf GLM-5.2s spezifische glm_moe_dsa-Architektur. Eine OLMoE-Engine dient kleineren Validierungs- und Quantisierungstests; sie macht Colibri nicht zum universellen Frontier-Model-Loader. Enthalten sind CLI, lokales Web-UI, Converter, Benchmarks, OpenAI-kompatible Text-API und experimentelle CPU-, CUDA- und Metal-Pfade.

Die Runtime steht unter Apache 2.0, GLM-5.2s Gewichte unter MIT. Kommerzielle Nutzung ist damit permissiv. Präziser als „Open Source“ ist für das Modell trotzdem Open Weight: Gewichte und Lizenz sind öffentlich, Trainingsdaten und kompletter Trainingsprozess nicht reproduzierbar.

Das Modell wird nicht auf 25 GB komprimiert. Der vollständige int4-Checkpoint bleibt auf Disk. Colibri hält immer benötigte Teile im Speicher und lädt geroutete Experten bei Bedarf. Das ist das gesamte Prinzip.

Warum GLM-5.2?

Z.ai beschreibt GLM-5.2 als 744B-A40B: rund 744 Milliarden Parameter insgesamt, etwa 40 Milliarden aktiv pro Token. Offiziell werden ein Kontext von einer Million Tokens, 81,0 auf Terminal-Bench 2.1 und 62,1 auf SWE-bench Pro genannt. Das sind Vendor-Zahlen, keine neutrale Bestätigung. Artificial Analysis führte GLM-5.2 zum Launch als stärkstes Open-Weight-Modell. „Frontier-class Open Weight“ ist damit vertretbar; universelle Überlegenheit ist es nicht.

Übertrage Hosted- oder Full-Precision-Benchmarks nicht auf Colibris int4-Build. Ein erster kleiner Colibri-Test kam bei je nur 40 Fragen aus HellaSwag, ARC und MMLU auf 62,5 % mittlere normalisierte Accuracy. Sample, Protokoll und fehlender FP-vs-int4-A/B machen das Ergebnis nicht belastbar. Colibri beweist Ausführbarkeit deutlich stärker als Qualitätserhalt.

Wie passen 744B Parameter in 25 GB RAM?

1. Dichte Layer bleiben resident: Attention, Embeddings, Shared Experts und andere ständig genutzte Gewichte belegen int4 etwa 9,9 GB.
2. Geroutete Experten bleiben auf NVMe: 21.504 Expert-Blöcke über MoE-Layer und MTP-Head, jeweils rund 19 MB.
3. Der Router wählt pro Token: acht geroutete Experten je MoE-Layer.
4. Cache-Hits ersetzen Reads: Layer-LRU, gelernter Pin-Store, OS Page Cache und optional VRAM halten heiße Experten.
5. Reads und Compute überlappen: Cold Experts werden vorab geladen, soweit Abhängigkeiten es erlauben.

Die Mathematik erklärt die Geschwindigkeit: 75 MoE-Layer × acht Experten × etwa 19 MB ergeben rund 11,4 GB Expertendaten pro Token. Bei ungefähr 1 GB/s braucht allein die Disk etwa elf Sekunden. Die theoretische Obergrenze um 0,09 tok/s liegt genau im gemessenen Bereich.

Wie schnell ist Colibri wirklich?

Die folgenden Werte stammen aus der Community-Tabelle des Projekts; wir haben sie nicht selbst reproduziert. Die 100-Token-Zeit ist 100 / tok_s und enthält weder Prefill noch Queueing.

Time to First Token kann bei kaltem Cache und langem Prompt weit schlechter sein. Sechs RTX 5090 beweisen keine 6 tok/s auf einer Gaming-GPU. Ein sauber wiederholter Single-5090-Test zeigte ungefähr keinen Gewinn, weil CPU-Expert-Matmul bereits mithielt und Storage limitierte. Als Gesprächsziel sind 20-30 tok/s üblich; selbst Colibris stärkstes veröffentlichtes Single-Request-Ergebnis bleibt darunter.

Was bestimmt die Performance?

RAM und Cache-Hit-Rate

Bei 24-32 GB bleibt nach dichten Gewichten, KV-State, Scratch und Betriebssystem kaum Expert-Cache. Ein 24-GB-Test erreichte trotz 2,74 GB/s Direct-Read nur 3-4 % Hits und 0,07 tok/s. Mit 128 GB können Dutzende Gigabyte gelernte Hot Experts pinnen. Wiederkehrende Workloads profitieren stärker als zufällige Fragen; ein Code-Cache muss für juristische Prompts nicht heiß sein.

Echte Random-Read-Leistung

Relevant sind parallele, verteilte Reads von etwa 19-MB-Blöcken über 370 GB, nicht die sequentielle Zahl auf der SSD-Packung. Auf demselben Ryzen-System stieg Storage von 1,51 auf 8,81 GB/s, Token-Speed aber nur von 0,10 auf 0,28 tok/s: 5,8× mehr Disk brachte 2,9× mehr Output, weil Compute zum nächsten Bottleneck wurde.

CPU, Memory Bandwidth und Speculation

Bei Cache-Hits zählen quantisierte Matrixmultiplikation und RAM-Bandbreite. Mehr Kerne helfen nur bis zur Channel-Sättigung. Das korrekte int8-MTP-Head erreicht laut Projekt 39-59 % Draft Acceptance und 2,2-2,8 Tokens pro Forward; der ältere int4-Mirror nahm fast nichts an. Auf kaltem Cache kann Speculation langsamer werden, weil Expert Loads von etwa 660 auf 1.100 pro Token steigen. --topp 0.7 reduziert Reads, verändert aber das Routing verlustbehaftet und verlangt neue Quality-Evals.

Verschleißt Colibri die SSD?

Normale Inference sollte SSD-TBW kaum verbrauchen. Die 11 GB pro Token sind Reads. TBW und DWPD bewerten Flash-Verschleiß durch Program/Erase-Zyklen; Micron beschreibt Wear durch Reads als vernachlässigbar. Expert-Streaming ist read-only.

• Setup schreibt einmal viel: etwa 370 GB beim Download; eine Konvertierung aus 756 GB FP8 erzeugt über Download, temporäre Shards und Output mehr als ein Terabyte Host-Writes.
• Swap ist das echte Risiko: RAM-Mangel erzeugt viele Writes und zerstört gleichzeitig die Performance.
• KV-Persistenz schreibt etwas: etwa 182 KB pro Token plus Usage-Historie, klein gegenüber den Reads.
• Dauerlast erzeugt Hitze: Samsung dokumentiert Thermal Throttling. Kühlkörper, Airflow und SMART-Monitoring sind sinnvoll.

Eine lokale 1-TB-NVMe mit Kühlung und ausreichend freiem Platz ist komfortabler als ein 370-GB-Modell neben OS und Swap auf 500 GB. RAID 0 kann Bandbreite erhöhen, erhöht aber auch die Ausfallfläche; verwende es nur für reproduzierbare Artefakte.

Macht eine GPU Colibri schnell?

Manchmal. Colibri kann heiße Experten in NVIDIA-VRAM pinnen, Dense Work über CUDA ausführen oder Metal auf Apple Silicon nutzen. Eine einzelne 16-32-GB-GPU hält aber nur einen kleinen Teil von 370 GB. Sie hilft bei hoher Hot-Tier-Hit-Rate und CPU-Matmul-Bottleneck; bei Disk-Limit kaum. Multi-GPU nutzt derzeit unabhängige Kontexte und Host-staged Copies, ohne P2P/NCCL, Expert Sharding oder reife Tensor-Core-Libraries. Kaufe für Colibri keine GPU, bevor Profiling Compute statt Disk oder RAM als Engpass zeigt.

Kann Colibri Qwen, DeepSeek, Kimi oder andere Modelle laden?

Nicht als Modellwechsel. Upstream ist keine generische GGUF-Runtime. Tokenizer, Multi-head Latent Attention, DeepSeek Sparse Attention, Router, Tensorlayout, MTP und Container sind GLM-5.2-spezifisch. Andere Architekturen brauchen Code, Converter und Validierung.

Der Colibri-Hy3-Fork überträgt das Prinzip auf Tencents 295B-Hy3 mit eigener C-Engine, GQA, Router und Converter für einen rund 142 GB großen int4-Container. Das beweist Portabilität – und den nötigen Implementierungsaufwand. Dichte Modelle profitieren weniger, weil fast jeder Parameter für jeden Token benötigt wird.

Was ist mit einer Million Kontext-Tokens?

GLM-5.2 unterstützt laut Z.ai eine Million Tokens. Das ist auf 25 GB nicht praktisch. Colibris Server startet mit 4.096 Tokens; die komprimierte KV-Persistenz benötigt rund 182 KB pro Token. Eine Million Tokens wären allein etwa 182 GB KV-State, noch vor Gewichten, Scratch und Cache. Model Capability und System Capacity sind nicht dasselbe.

Ist die OpenAI-kompatible API production-ready?

Sie ist nützlich für Integrationstests: Model Discovery, Chat/Legacy Completions, SSE-Streaming, Usage und Basis-Sampling. Production vLLM oder SGLang ersetzt sie nicht. Version eins ist text-only; Tools, Bild/Audio, Custom Stops, Logprobs und Penalties liefern Fehler. Requests warten, weil eine Sequenz gleichzeitig ausgeführt wird. Bis zu 16 getrennte KV-Slots isolieren Dialogzustand, schaffen aber kein Continuous Batching. Authentifizierung ist ein gemeinsamer lokaler API-Key, keine Tenancy- oder Policy-Schicht.

Für ein Lab reicht das. Für Kundenbetrieb brauchst du Load-Tests, Isolation, Rate Limits, Observability, Security Review, Recovery, Checksums, Update Policy, Eval Gates und API-Fallback. Unser Break-even-Modell für lokale LLMs und APIs rechnet die Betriebsseite durch; Colibris Single-Sequence-Durchsatz macht die Hürde heute besonders hoch.

Für wen lohnt sich Colibri heute?

Der kommerzielle Wert liegt heute in der Machbarkeitsprüfung: Besteht GLM-5.2 deinen privaten Workload? Hält int4 die Qualität? Welche Experten werden heiß? Welches Hardware-Tier beseitigt den gemessenen Engpass?

So testest du Colibri vor einem Hardware-Kauf

1. Baue 30-100 repräsentative Prompts und eine Akzeptanzrubrik.
2. Nutze den vorkonvertierten Checkpoint mit int8-MTP-Heads und prüfe Dateigrößen.
3. Führe coli doctor und coli plan aus.
4. Teste Cold Storage mit dem enthaltenen Direct-I/O-Benchmark, nicht mit Herstellerwerten.
5. Miss Time to First Token, tok/s, Expert Hit Rate, Peak RSS, Qualität und gesamte Task-Zeit.
6. Berichte kalte und warme Wiederholungen getrennt.
7. Ändere RAM, NVMe, VRAM-Budget und CPU-Flags jeweils einzeln.
8. Vergleiche Hardware, Strom und Engineer-Zeit mit einem Hosted Endpoint pro erfolgreicher Aufgabe.

Wenn der Test das Lab verlässt, ergänze Eval Gate und Fallback. Dieselbe Disziplin zeigen unsere Twinsoft-AI-Case-Study und der Guide zur Technologieauswahl: Architektur folgt gemessenen Constraints, nicht Neuigkeitswert.

Quellen und Methodik

Runtime, Anforderungen, Feature-Status und Speed stammen aus dem Colibri-Repository und verlinkten Issues. Modell, Lizenz, Kontext und Launch-Benchmarks stammen von Z.ai und der offiziellen Model Card. Artificial Analysis dient nur als unabhängiges Capability-Signal. Alle Fakten wurden am 14. Juli 2026 geprüft.