Ein 284-Milliarden-Parameter-LLM mit reinem C auf einem Laptop mit nur 3,2 GB RAM ausführen

Ich habe es geschafft, ein Sprachmodell mit 284 Milliarden Parametern auf einem Laptop mit nur 3,2 GB RAM laufen zu lassen – und zwar ausschließlich mit reinem C99 und einer NVMe-Festplatte. Der Trick bestand darin, die Expertengewichte des Modells zu streamen, anstatt den gesamten 160 GB großen Checkpoint in den Arbeitsspeicher zu laden. Damit wurde bewiesen, dass selbst die größten Mixture-of-Experts (MoE)-Modelle auf Consumer-Hardware Platz finden können.

Warum das wichtig ist

Große Sprachmodelle (LLMs) treiben die Codegenerierung, Forschungsunterstützung und vieles mehr voran, aber ihre Größe zwingt Nutzer meist auf kostspielige Multi-GPU-Server oder zu einer starken Quantisierung, die die Qualität beeinträchtigt. Zu zeigen, dass ein MoE-Modell mit 284 Mrd. Parametern mit nur wenigen Gigabyte RAM laufen kann, öffnet Hobbyisten, kleinen Startups und budgetbeschränkten Forschern die Tür, um mit modernsten Modellen zu experimentieren, ohne dabei an Genauigkeit einzubüßen.

Das Modell und der Hardware-Engpass

DeepSeek-V4-Flash speichert 284 Mrd. Parameter über 256 Experten pro Transformer-Layer. Der rohe Checkpoint belegt etwa 160 GB auf der Festplatte – eine Größe, die die 3,2 GB RAM eines typischen Laptops bei weitem übertrifft. Traditionelle Inference-Pipelines versuchen, den gesamten Checkpoint in den Speicher abzubilden, was das RAM-Budget schnell erschöpft und zum Absturz führt.

Streaming der Expertengewichte: Die Kernidee

MoE-Architekturen aktivieren für jedes Token nur eine winzige Teilmenge an Experten. In DeepSeek-V4-Flash wählt der Router sechs von 256 Experten pro Layer aus. Da die Berechnung die inaktiven Experten nie berührt, kann die Inference-Engine das Laden dieser überspringen.

Die Implementierung behandelt den Checkpoint als Streaming-Quelle. Sobald der Router entscheidet, welche Experten für das aktuelle Token benötigt werden, zieht die Engine diese Gewichtungsblöcke von der NVMe-Festplatte in einen LRU-Cache (least-recently-used), der im RAM liegt. Ist der Cache groß genug, werden dieselben Experten für aufeinanderfolgende Token wiederverwendet, was zu Cache-Hits führt; ist der Cache zu klein, liest die Engine häufiger von der Festplatte. Das Ergebnis ist ein maximaler Speicherverbrauch von 3,23 GB, was weit innerhalb der Limits des Laptops liegt, während die Gewichte in voller Präzision erhalten bleiben und keine GPU-Beschleunigung erforderlich ist.

Mühsam gewonnene Erkenntnisse aus der Implementierung

1. Ein flüssiger Output ist kein Beweis für Korrektheit Ein fehlerhafter Kernel kann immer noch plausibel klingende Sätze erzeugen, besonders wenn die Sprachmuster des Modells numerische Fehler maskieren. Ich habe jede der 14 kritischen Operationen gegen eine frische PyTorch-Referenz validiert und sichergestellt, dass die numerische Differenz innerhalb einer minimalen Toleranz blieb. Das Überspringen dieses Schritts hätte subtile Abweichungen unbemerkt lassen können.

2. Gemeinsame Fehlerquellen können Tests täuschen Ein Bug bei der Speicherbeschädigung führte dazu, dass die Routing-Entscheidungen auf eine Handvoll Experten reduziert wurden, was die Cache-Hit-Rate von 52 % auf 95 % aufblähte und die Illusion einer massiven Beschleunigung erzeugte. Da die Testsuite zwei Versionen desselben fehlerhaften Codes verglich, wurde das Problem nicht erkannt. Die Lösung besteht darin, einen unabhängigen Referenzpfad hinzuzufügen – Code, der keine Logik mit der primären Implementierung teilt –, damit ein gemeinsamer Fehler nicht unbemerkt bleibt.

3. Messen, bevor man optimiert Ich ging davon aus, dass eine Speicherbereinigung (Memory Copy) 1 ms dauert, und verbrachte Zeit damit, sie zu optimieren. Das Profiling zeigte, dass die Operation tatsächlich 3,6 ms beanspruchte, also 22 % der gesamten Inference-Zeit. Die Lehre daraus: Verlassen Sie sich bei leistungskritischen Abschnitten niemals auf Ihre Intuition; präzise Messungen sind der einzige zuverlässige Wegweiser.

4. Thermische Bedingungen beeinflussen den Durchsatz drastisch Das Ausführen der Benchmarks auf einem „aufgeheizten“ Laptop führte zu Laufzeiten, die bis zu dreimal langsamer waren als auf einem kalten Gerät. Erhöhte Temperaturen drosselten den Durchsatz der NVMe-Festplatte und verlangsamten die CPU, was die Ergebnisse verfälschte. Dokumentieren Sie stets den thermischen Zustand des Systems, wenn Sie Leistungsdaten veröffentlichen.

So sehen die Zahlen aus

• Modellgröße auf der Festplatte: ~160 GB
• Maximaler RAM-Verbrauch: 3,23 GB
• Experten pro Token: 6 (von 256)
• Cache-Hit-Rate: variiert je nach RAM; bei 3,2 GB schwankt sie.
• Keine Quantisierung: Gewichte in voller Präzision werden gestreamt, wodurch die Modellqualität erhalten bleibt.

Wenn das RAM-Budget unter etwa 3,21 GB fällt, füllt sich der Cache nie, und die Engine streamt bei jedem Token, was zu einem drastischen Leistungsabfall führt.

Der Quellcode ist öffentlich unter github.com/ronak-create/deepseek-v4-in-c verfügbar. Ein Community-Diskussionskanal unter t.me/GyaanSetuAi steht für alle zur Verfügung, die das Experiment replizieren oder erweitern möchten.

Fazit

Das Streaming nur der Experten, die ein MoE-Modell tatsächlich nutzt, ermöglicht es einem LLM mit 284 Mrd. Parametern, auf einem bescheidenen Laptop ohne Quantisierung oder GPU-Beschleunigung zu laufen. Das Experiment zeigt, dass geschickte Datenbewegung, rigorose Validierung und disziplinierte Messung Hardwarebeschränkungen umgehen können, die viele für unumstößlich halten.