DeepSeek 284B läuft auf einer CPU mit 64 GB RAM
llama-modchipDeepSeek-V4-FlashCPU-инференс
Wie 284B Parameter in gewöhnlichen Arbeitsspeicher passen
Das zentrale Ergebnis lautet: llama-modchip beansprucht, DeepSeek-V4-Flash mit 284,33B Parametern auf einem 16-Kern-AMD-Ryzen-9-9955HX, 64 GB DDR5 und ganz ohne GPU auszuführen. Im Projekt-Repository und in der Benchmark-Tabelle wird eine Modellgröße von 56,56 GiB genannt; der Spitzenverbrauch liegt bei einem 256K-Kontext bei etwa 57,6–58,9 GiB.
Der Kern der Sache ist nicht, dass ein dichtes 284B-Modell plötzlich günstig auf einer CPU berechnet werden kann. DeepSeek-V4-Flash verwendet Mixture-of-Experts: Insgesamt gibt es viele Parameter, pro Token sind aber nur rund 13,17B aktiv. Der vollständige Expertensatz muss weiterhin im Speicher liegen, doch der Rechenaufwand pro Token sinkt deutlich.
Der zweite Bestandteil ist aggressive Quantisierung in Verbindung mit einem spezialisierten GGUF-Format. Die llama-modchip-Dokumentation führt außerdem eine Einsparung von 20,31 GiB auf die SwiGLU-H2-Implementierung zurück. Zusammen mit Memory Mapping und strenger Kontrolle der Speicherzuweisungen bleibt Platz für Runtime-Zustand und KV-Cache, auch wenn die Reserve auf einem nominellen 64-GB-System äußerst knapp bleibt.
Die veröffentlichten Ergebnisse zeigen 43,16–44,36 Token pro Sekunde bei der Prompt-Verarbeitung und 9,06–10,74 bei normaler Generierung. Mit Stockfish-PVS-Konfigurationen für spekulatives Decoding meldet das Projekt 11,50–14,69 Token pro Sekunde sowie etwa 94,5 % Akzeptanz für Entwurfs-Token. Das sind projektinterne Werte zum Zeitpunkt der Veröffentlichung, keine unabhängige Reproduktion.
GPUs werden nicht überflüssig, aber die Lage verändert sich
Dies ist kein Ersatz für Beschleuniger beim Training oder bei hochvolumigem Serving. Es ist jedoch ein realistischer Weg zur lokalen Inferenz eines großen MoE-Modells. Besonders interessant ist er dort, wo Autonomie, ein großer verfügbarer Gewichtssatz und keine separate VRAM-Anforderung wichtiger sind als maximaler Durchsatz.
Zuerst wären die Qualität nach der Quantisierung, die Stabilität bei langen Kontexten und die Empfindlichkeit der Geschwindigkeit gegenüber dem Speicher zu prüfen. Bei dieser Art der Inferenz ist oft nicht die CPU-Arithmetik der Engpass, sondern RAM-Bandbreite, Thread-Platzierung und das Bewegen von Dutzenden Gigabyte Gewichten. Ergebnisse lassen sich deshalb keineswegs automatisch auf andere Prozessoren oder langsamere Speicherkonfigurationen übertragen.
Ein konkreter Hacker-News-Thread lässt sich anhand der verfügbaren Materialien nicht zuverlässig bestätigen, daher sollten Schlussfolgerungen von Community-Diskussionen getrennt werden. Das Experiment bleibt dennoch bemerkenswert: Die Parameterzahl beschreibt die tatsächlichen Inferenzkosten immer schlechter, wenn die Architektur sparsam aktiviert wird und die Runtime zusammen mit dem Gewichtsformat optimiert ist. Die wichtigste Frage lautet nicht mehr, ob das Modell läuft, sondern wie gut diese komprimierte Variante ihre ursprüngliche Qualität bewahrt.