10 Gigabyte RAM für 744 Milliarden Parameter: Wie SSD-Streaming GPUs überflüssig macht

744 Milliarden Parameter, gepresst auf einen Laptop mit 25 Gigabyte RAM. Das Modell ist 15 Mal größer als der Arbeitsspeicher, in dem es ausgeführt wird. Der Mechanismus, der das ermöglicht, hebelt die bisherigen Regeln der KI-Hardware vollständig aus.

Key Takeaways (TL;DR)

• SSD als Speicher-Tier nutzen: Betrachte die Festplatte bei großen Modellen als aktiven Teil der Architektur, nicht nur als statische Ablage.
• Routing-Vorhersagen priorisieren: Nutze die Vorhersagbarkeit im Datenfluss von MoE-Modellen, um Ladezeiten asynchron im Hintergrund zu verstecken.
• Anwendungsfälle entkoppeln: Trenne synchrone Live-Chats von asynchronen Qualitäts-Workloads für die Nacht.

Basiert auf einem Video zur Colibri-Engine. Das Original findest du hier: https://www.youtube.com/watch?v=19xCOJxWU0A

Normalerweise erfordert ein offenes Modell wie GLM 5.2, das in Benchmarks sogar über Claude Opus steht, mit seinen 370 Gigabyte an 4-Bit-Gewichten ein halbes Rechenzentrum an GPUs. Wer das nicht hat, zahlt rund 40.000 Euro für einen Mac Studio mit 256 Gigabyte Unified Memory. Darunter weigert sich das Modell überhaupt zu laden. Der naheliegende Ausweg, das Modell einfach direkt von der SSD zu lesen, scheitert in der Praxis an der Architektur klassischer Netzwerke. Bei einem normalen Modell wird jeder einzelne Parameter für jeden einzelnen Token benötigt. Selbst auf der schnellsten Consumer-SSD bedeutet das fast eine halbe Minute Ladezeit pro generiertem Wort.

Die Illusion der permanenten Parameter

Dass die Engine namens Colibri dieses Problem umgeht, liegt an der Architektur von GLM 5.2. Es handelt sich um ein Mixture-of-Experts-Modell (MoE). Anstelle eines gigantischen Blocks von Neuronen arbeiten in jeder Schicht 256 kleinere Experten. Davor sitzt ein Router. Dieser bewertet für jeden eintreffenden Token alle 256 Experten und wählt exakt die acht aus, die für dieses Wort auf dieser Schicht am besten geeignet sind. Die restlichen 248 Experten bleiben inaktiv.

Experten sind dabei keine sauber getrennten Fachbereiche für Code, Mathematik oder Poesie. Es sind unbeschriftete Blöcke von gelernten Gewichten mit überlappenden Zuständigkeiten. Das exakt selbe Wort erhält in einem anderen Satz völlig andere Experten zugewiesen. Zusammengerechnet verrichten von den 744 Milliarden Parametern pro Token nur etwa 40 Milliarden tatsächlich Arbeit. Das sind rund fünf Prozent. Die restlichen 95 Prozent des Modells sind in diesem spezifischen Moment toter Code. Und totes Gewicht muss nicht im Arbeitsspeicher liegen.

SSD-Streaming schlägt blindes Memory Mapping

Colibri, geschrieben in 1.300 Zeilen purem C, macht sich exakt diesen Umstand zunutze. Die Engine teilt das Modell auf. Der feste Kern, der bei jedem Token angesprochen wird, umfasst die Attention-Layer, die Embeddings und einen geteilten Experten. Diese knapp 10 Gigabyte bleiben permanent im RAM verankert. Die restlichen 21.500 Experten liegen als 370 Gigabyte große Datei auf der SSD. Sobald der Router die acht benötigten Experten für eine Schicht benennt, prüft Colibri einen kleinen Cache im RAM. Fehlt ein Experte, wird genau dieser 19-Megabyte-Block via Byte-Offset von der SSD gestreamt.

Das stärkste Gegenargument lautet oft, dass Llama.cpp bereits seit langer Zeit das Memory Mapping von Modellen unterstützt, die größer als der RAM sind. Das ist faktisch richtig. Doch Memory Mapping bedeutet, dass das Betriebssystem blind rät. Es lädt Seiten nacheinander in den Speicher und blockiert den Thread, während es wartet. Es weiß nicht, welche Gewichte als Nächstes wichtig sind. Colibri hingegen weiß das. Im Moment der Router-Entscheidung fordert die Engine alle acht Experten gleichzeitig und asynchron von der Festplatte an, während die CPU bereits rechnet. Ein Page-Fault des Betriebssystems kann nicht in die Zukunft sehen. Ein Router schon. Die Trefferquote für den Experten der nächsten Schicht liegt bei Colibri bereits bei 72 Prozent.

SSD-Verschleiß und Ladezeiten

Der Ansatz wirft sofort die Frage nach der Lebensdauer der Festplatte auf. Streaming bedeutet jedoch reine Lesezugriffe, und Lesezugriffe zerstören keinen Flash-Speicher. Das Problem bei günstigen Laufwerken ist höchstens thermisches Throttling nach stundenlanger Dauerlast.

Natürlich gibt es einen massiven Performance-Einschnitt. Auf einem Standard-Laptop liefert dieser Ansatz etwa ein Zehntel Token pro Sekunde. Eine Antwort mit 500 Token benötigt anderthalb Stunden. Eine teure PCIe-5-SSD steigert das auf 0,28 Token, ein 128-Gigabyte-Framework-Laptop auf 0,37 Token und ein M5 Max erreicht die Obergrenze von einem Token pro Sekunde.

Ein Zehntel Token pro Sekunde klingt nach einem schlechten Witz. Es sind aber auch 8.000 Token am Tag. Das reicht für mehrere tiefgreifende Architektur-Analysen auf Frontier-Niveau, komplett lokal und auf einem Rechner ohne Internetverbindung. Die Geschwindigkeit spielt keine Rolle, weil niemand auf den Bildschirm starrt. Colibri ist für Jobs gedacht, bei denen Qualität die Ausführungszeit übertrumpft: Übernacht-Refactorings oder strikt isolierte Umgebungen.

Die Industrie reagiert bereits. Antirez, der Entwickler von Redis, hat mit DS4 eine eigene Engine veröffentlicht, die DeepSeek-Experten von einer MacBook-SSD streamt. Auch bei vLLM und Llama.cpp gibt es konkrete Vorschläge für exakt solche Experten-Caches. Wenn Ladezeiten durch Vorhersage der Expertenwahl zunehmend in den Hintergrund verschwinden, wird die SSD faktisch zu einem Arbeitsspeicher-Tier.

3 Schritte zur Umsetzung

1. Workloads klassifizieren: Trenne Aufgaben, die sofortige Antworten benötigen (Live-Chat), von solchen, bei denen die Qualität der Analyse die Dauer überwiegt (Code-Reviews).
2. Speicherarchitektur neu denken: Optimiere Systeme für asynchrone SSD-Lesezugriffe, wenn große MoE-Modelle lokal betrieben werden sollen.
3. Air-Gapped-Systeme aufbauen: Nutze die neue Machbarkeit lokaler Riesenmodelle für Code, der das Unternehmensnetzwerk aus Compliance-Gründen rechtlich nicht verlassen darf.

Für den Preis eines simplen Lüfters für eine H100-GPU steht die Leistung eines Rechenzentrums jetzt unter dem Schreibtisch.