Kann DeepSeek V4 Flash 284B wirklich mit 64 GB RAM ohne GPU laufen?

Ein Community-Projekt berichtet, DeepSeek V4 Flash 284B auf einem Linux-Rechner mit 64 GB RAM ausschließlich mit der CPU auszuführen. Das angegebene Setup verwendet llama-modchip, einen benutzerdefinierten Checkpoint mit etwa 1,71 Bit pro Gewicht und eine Desktop-CPU mit hoher Speicherbandbreite. Betrachten Sie dies als dokumentiertes Experiment mit einem bestimmten Build, nicht als allgemeine Empfehlung zur Dimensionierung für den offiziellen Checkpoint.

Das Ergebnis ist nützlich, weil es drei Fragen messbar macht, die normalerweise miteinander vermengt werden: Passt die Gewichtsdatei in den Speicher, kann der Prozess während der Generierung genügend Speicher freihalten, und bleibt die Ausgabe bei dieser Komprimierungsstufe brauchbar? Das Projekt wurde in einer Community-Diskussion am 8. November bekannt. Die folgenden Messwerte stammen aus dem Repository des llama-modchip-Maintainers, nicht aus unabhängigen Tests.

Um welches DeepSeek-Modell und welche Laufzeitumgebung geht es?

Das Projekt zielt auf DeepSeek V4 Flash ab, das in der Dokumentation mit insgesamt etwa 284B Parametern beschrieben wird, von denen pro Token etwa 13B aktiv sind. Bei einem Modell mit Expertenmischung wählt der Router für jedes Token Experten aus. Dadurch wird der Rechenaufwand pro Token begrenzt, während der gesamte Expertensatz weiterhin gespeichert und zugänglich gemacht werden muss. Den üblichen Bereitstellungskontext finden Sie in der Modellkarte des Entwicklers und in der Übersicht zu den Hardwareanforderungen.

Für das Experiment kommen ein spezialisiertes Transcoding-Verfahren und Patches für das ggml/llama.cpp-Ökosystem zum Einsatz. Selbst eine andere Datei, die dieselbe Modellfamilie bewirbt, kann ein anderes Tensorlayout oder eine andere Präzision haben. Eine Standard-llama.cpp-Binärdatei und ein herkömmliches GGUF sollten als separater Weg betrachtet werden. Der bestehende Leitfaden zum llama.cpp-Update behandelt den Upstream-Release-Weg.

Wie passen 284 Milliarden Parameter in 64 GB RAM?

Bei durchschnittlich 1.71 Bit pro Gewicht ergeben 284 Milliarden Gewichte etwa 61 GB gepackte Daten in Dezimaleinheiten. Das Projekt gibt eine Dateigröße von 56.56 GiB und einen Spitzenwert des residenten Prozessspeichers von 57.61 GiB in seiner 256K-Konfiguration an. GiB und GB bezeichnen unterschiedliche Einheiten. Prüfen Sie den tatsächlich verfügbaren Arbeitsspeicher des Hosts zum Testzeitpunkt, um den Spielraum einzuschätzen. Firmware-Reservierungen, integrierte Grafik und andere Prozesse können einen geringen verbleibenden Spielraum stark einschränken.

Arbeitsspeicherbedarf und Größe der Gewichtsdatei hängen zusammen, doch keine der beiden Messungen erfasst sämtliche Systemzuweisungen. Während des Ladens kann der Kernel den Dateisystem-Cache zurückgewinnen oder temporäre Puffer vorhalten. Beobachten Sie sowohl den Speicherbedarf des Runners als auch den verfügbaren Systemspeicher. Ein hoher residenter Speicherbedarf in einem einzelnen aufgezeichneten Test sagt außerdem nichts über alle Kontextlängen und Eingabetypen aus.

Warum unterscheiden sich Prompt- und Generierungsgeschwindigkeit?

Bei der Prompt-Verarbeitung werden bereits bekannte Eingaben verarbeitet, sodass die Laufzeit mehrere Tokens gleichzeitig bündeln kann. Die Generierung erfolgt sequenziell: Das nächste Token hängt von den zuvor generierten Tokens ab. Die CPU-Generierung eines MoE-Modells hängt davon ab, wie schnell der Rechner die ausgewählten Expertengewichte und den Zustand durch den Speicher bewegen kann. Taktfrequenz, Kanalanzahl, Speichertimings und Thread-Zuordnung können das Ergebnis beeinflussen.

Trennen Sie einen kurzen Prompt-Test von einem langen Repository-Prompt. Messen Sie die Zeit bis zum ersten Token und die anschließende Generierung unabhängig voneinander. Ein längerer Präfix kann die Gesamtverzögerung dominieren, selbst wenn der Stream nach dem Start reaktionsschnell wirkt. Halten Sie fest, ob die Laufzeit zwischengespeicherten Zustand wiederverwendet hat. Ein aufgewärmter Präfix und ein Kaltstart beantworten unterschiedliche Fragen. Die Dokumentation des Upstream-Benchmark-Tools erläutert die Messung von Prompt und Generierung.

Wie viel Qualität geht bei dieser Präzision verloren?

Bits pro Gewicht geben einen Überblick über den Speicherbedarf, nicht die Modellqualität. Verschiedenen Tensoren kann eine unterschiedliche Präzision zugewiesen werden, und zwei Konvertierungen ähnlicher Größe können sich unterschiedlich verhalten. Längeres Schlussfolgern, exakte Syntax, Tool-Argumente und ungewöhnliches Vokabular sind Bereiche, die sich gut überprüfen lassen. Eine verständliche Antwort auf eine Frage zeigt, dass die Generierung funktioniert. Sie belegt nicht, dass derselbe Build in einem Coding-Workflow zuverlässig ist.

Lege vor dem Testen einen kleinen Referenzdatensatz fest. Nimm eine Aufgabe mit exakt vorgegebenem Ausgabeformat, eine Funktion mit einem bekanntermaßen fehlschlagenden Test, eine Suche in langem Kontext und eine Anfrage auf, die das Modell vorsichtig behandeln sollte. Vergleiche die Ergebnisse mit einer höherpräzisen oder kleineren unterstützten Baseline anhand derselben Prompts. Halte die Testeingaben unverändert fest und protokolliere unvollständige Ausgaben, fehlerhafte Tool-Aufrufe und Zeitüberschreitungen. Fixiere die Modell- und Runtime-Revisionen, damit sich spätere Verbesserungen zuordnen lassen.

Wie würdest du das Ergebnis verantwortungsbewusst reproduzieren?

Beginne mit einer isolierten Linux-Testmaschine, ausreichend SSD-Speicherplatz und genau dem Checkpoint samt Revision des Maintainers. Lies die Build- und Schnellstartanleitung des Projekts, prüfe Skripte vor der Ausführung und notiere CPU, Speicherkonfiguration und Kernel. Ein kurzer Prompt ohne aktivierte Shell-Tools eignet sich als erster Test. Erhöhe den Kontext erst, wenn du weißt, dass der Host reaktionsfähig bleibt.

1. Miss den freien Speicher und die Swap-Aktivität vor dem Laden. Beende andere rechenintensive Experimente auf demselben Rechner.
2. Notiere die exakte Dateigröße und den Hash des Checkpoints, die Runner-Version sowie alle speziellen Einstellungen für Transkodierung oder Expert-Platzierung.
3. Erfasse den Spitzenwert des RSS-Speicherverbrauchs, die Zeit bis zum ersten Token, die Ausgabetokens pro Sekunde und ob Swap verwendet wurde. Führe den Test zweimal aus, um das Verhalten beim Kaltstart von Cache-Effekten zu trennen.
4. Vergleiche die Korrektheit der Ausgabe, bevor du das Modell für einen längeren Auftrag verwendest. Prüfe Datenzugriff und Dateisystemzugriff, falls du später einen Agenten verbindest.

Nutze für Aufgaben mit Repositories isolierte Git-Worktrees. Wenn der Host auch als Speicher für den Haushalt oder für Backups dient, führe das erste Experiment auf einem separaten Rechner für rechenintensive Aufgaben durch. Ein Inferenzprozess, der den gesamten RAM belegt, kann diese Dienste beeinträchtigen, lange bevor es zu einem Out-of-Memory-Abbruch kommt.

Wann solltest du dich stattdessen für ein kleineres Modell entscheiden?

Wähle einen kleineren Checkpoint, wenn du eine zuverlässige interaktive Geschwindigkeit, einfache Updates oder genügend Spielraum für mehrere Sitzungen brauchst. Das Community-Experiment ist besonders interessant, wenn du benutzerdefinierten Code, geringere Präzision und eine sorgfältige Reproduktion akzeptierst. Ein Alltagsmodell, das in einer unterstützten Runtime läuft, lässt sich möglicherweise einfacher warten und kann pro Stunde mehr nützliche Arbeit erledigen. Vergleiche beide anhand derselben Aufgabe, bevor du ein Produktions-Setup änderst.

FAQ

Wird dafür eine dedizierte GPU benötigt?

Der Maintainer berichtet von einem reinen CPU-Lauf mit dem angegebenen 284B-Checkpoint. Andere Konfigurationen im Repository umfassen GPU-unterstützte Varianten. Halte daher die Testprofile getrennt.

Erreicht jeder 64-GB-PC die angegebene Geschwindigkeit?

Allein aus dem installierten Speicher lässt sich keine allgemeine Geschwindigkeitsangabe ableiten. Die CPU-Generierung hängt von der Speicherbandbreite, den Kernels und der Thread-Platzierung ab; außerdem muss genügend RAM verfügbar sein.

Ist 44 Tok/s die Geschwindigkeit, die ich in einem Chat-Stream sehen werde?

Der Wert von etwa 44 Tok/s bezieht sich auf die Prompt-Verarbeitung im angegebenen Setup. Das Repository nennt für die autoregressive Generierung einen separaten, niedrigeren Bereich.

Ist ein Kontext von 256K die erste Einstellung, die ich ausprobieren sollte?

Beginne mit einem kürzeren Kontext und miss die Werte. Die Speicherangabe des Maintainers gilt für eine bestimmte Runner- und Checkpoint-Konfiguration.

Ersetzt das die veröffentlichte Hardwareanleitung?

Verwende für eine Standardbereitstellung die offizielle Modellanleitung. Betrachte llama-modchip als Community-Ansatz mit eigenen Einschränkungen bei Präzision, Kompatibilität und Leistung.

Fazit

Das interessante Ergebnis ist, dass sich ein bestimmtes CPU-Runtime-System und ein benutzerdefinierter Checkpoint mit geringer Bitbreite gemeinsam in ein unerwartet großes MoE-Modell bei knappem Speicherbudget einpassen lassen. Reproduziere exakt den Build, unterscheide zwischen Prefill und Decoding und prüfe die Ausgabequalität, bevor du dich darauf verlässt. Ein kleineres Modell bleibt ein nützlicher Vergleichswert, wenn du die Latenz im Alltag bewertest.