antirez/ds4: DwarfStar als schmale Inferenz-Engine für DeepSeek V4 Flash

Warum antirez/ds4 bewusst nur DeepSeek V4 und GLM 5.2 lädt

Das Repository antirez/ds4 trägt die Beschreibung einer lokalen Inferenz-Engine für DeepSeek 4 Flash und PRO mit Metal, CUDA und ROCm. Im README trägt die Software den Namen DwarfStar und wird als kleine native Engine bezeichnet, die zuerst für DeepSeek V4 Flash optimiert wurde. Dazu kommen GLM 5.2 sowie auf Maschinen mit sehr viel Speicher DeepSeek V4 PRO.

Die Engstelle ist Absicht. Das README formuliert, die Engine arbeite ausschließlich mit den dort aufgeführten DeepSeek-V4- und GLM-5.2-GGUF-Dateien und sei kein allgemeiner GGUF-Lader. Beliebige GGUF-Dateien brächten weder das erwartete Tensor-Layout noch die Quantisierungsmischung, die Metadaten oder den optionalen MTP-Zustand mit. Modellladen, Prompt-Rendering, Werkzeugaufrufe, KV-Zustand, HTTP-Server und der Programmieragent werden gemeinsam gebaut und geprüft.

Diese Verengung hat eine Konsequenz, die im README offen ausgesprochen wird: Die Modellunterstützung folgt opportunistisch den jeweils besten offenen Gewichten für sinnvolle lokale Maschinengrößen, und ein Modell kann entfernt werden, sobald ein besserer Ersatz erscheint. Als Hauptsprache ist C eingetragen, die Lizenz ist MIT. Zum Erhebungszeitpunkt weist GitHub 21.883 Sterne, 2.037 Forks und 544 offene Issues aus.

Asymmetrische 2-Bit-Quantisierung mit IQ2_XXS und Q2_K

Zum Kern der Engine gehört eine ungewöhnliche Quantisierungsstrategie. Die angebotenen 2-Bit-Quantisierungen sind laut README als tatsächlich hochwertig verifiziert, sie verhielten sich gut, arbeiteten unter Programmieragenten und riefen Werkzeuge zuverlässig auf.

Das Schema ist stark asymmetrisch. Quantisiert werden ausschließlich die gerouteten Mixture-of-Experts-Blöcke, und zwar up und gate mit IQ2_XXS sowie down mit Q2_K. Gemeinsame Experten, Projektionen und das Routing bleiben unangetastet. Die Begründung liegt laut README darin, dass DeepSeek V4 Flash und PRO sowie GLM 5.2 eine aggressive Quantisierung der gerouteten Experten vertragen, während der Rest des Modells davon stärker betroffen wäre.

Daneben gibt es ein MXFP4-GGUF, das die von DeepSeek veröffentlichten Gewichte der gerouteten Experten bewahrt, statt sie neu zu quantisieren. Es läuft auf Metal und CUDA, wobei Blackwell-Geräte unter CUDA native FP4-Matrixbefehle für gebündelte Expertenarbeit nutzen. Für GLM 5.2 gilt eine Einschränkung: Unterstützt werden nur bestimmte geprüfte GGUF-Layouts, andere Layouts bleiben außen vor, bis sie absichtlich ergänzt und bewertet werden.

Metal ab 96 GB, CUDA mit DGX Spark und ROCm auf Strix Halo

Bei den Backends setzt das Projekt auf drei Zielplattformen. Metal ist als primäres Ziel genannt und gilt für Macs mit 96 GB oder mehr, kleinere Maschinen können auf SSD-Streaming ausweichen. CUDA wird einschließlich Multi-GPU-Systemen und DGX Spark unterstützt. ROCm läuft auf Strix-Halo-Systemen, als Beispiel nennt das README den Framework Desktop.

Zu den Einsatzszenarien macht das README konkrete Angaben. Mit der CUDA-Multi-GPU-Unterstützung und der Mikrobatch-Verarbeitung von ds4-server lasse sich ein Server mit älteren CUDA-Karten der Ada-Lovelace-Architektur, die von vLLM für neue Modelle nicht mehr unterstützt werden, in einen Mehrbenutzer-Server verwandeln. Für einen Aufbau mit acht L40S-Karten und mehreren Sitzungen berichtet das README selbst von 120 Token pro Sekunde aggregierter Generierung und 2000 Token pro Sekunde beim Prefill. Das sind selbst berichtete Werte aus dem README, keine unabhängige Messung.

Über RDMA verbundene MacBooks der Bauart M5 Max oder M3 Ultra sollen 4-Bit-DeepSeek-Flash oder GLM 5.2 mit Tensor-Parallelität ausführen können. Als Zielgrößen für die Modellwahl nennt das README Laptops mit 128 GB und Workstations mit 512 GB.

SSD-Streaming mit --ssd-streaming-cache-experts bei knappem Speicher

Für Maschinen, auf denen das Modell nicht vollständig in den adressierbaren Speicher passt, beschreibt das README einen SSD-Streaming-Modus, verfügbar unter Metal und für GLM 5.2 auch unter ROCm. Der normale Metal-Pfad halte das Modell im GPU-adressierbaren Speicher und sei der schnellere Weg.

Im Streaming-Modus bleiben die nicht gerouteten Gewichte dauerhaft resident, während die gerouteten MoE-Experten in einem Cache im Hauptspeicher gehalten und bei Fehlgriffen aus der GGUF-Datei nachgeladen werden. Das README räumt ein, dass Streaming langsamer ist als ein vollständig im RAM liegendes Modell, hält den Weg aber für nützlich, weil die gerouteten Experten die Modellgröße dominieren und schnelle lokale SSDs die Fehlgriffe erträglich machten.

Die Dimensionierung lässt sich steuern. Das automatische Cache-Budget nimmt 80 Prozent des vom Backend empfohlenen Arbeitssatzes, zieht die nicht gerouteten Gewichte ab und wendet dann den Reserveanteil für geroutetes Prefill an. Wer es selbst festlegen will, setzt den Experten-Cache explizit über --ssd-streaming-cache-experts mit einer Größenangabe in Gigabyte, im README als NGB bezeichnet. Welche Werte auf welcher Maschine sinnvoll sind, bleibt eigener Prüfung überlassen, Angaben zu typischen Ergebnissen enthält das README an dieser Stelle nicht.

Pipeline- und Tensor-Parallelität bei DwarfStar über TCP und RDMA

Für Modelle, die auf eine einzelne Maschine nicht passen, bietet das README Pipeline-Parallelität. Dabei werden Transformer-Schichten auf mehrere Maschinen verteilt, das Hauptbeispiel ist eine vollständige 4-Bit-Flash-Quantisierung über zwei MacBooks mit je 128 GB. Jeder Prozess bildet nur seinen Schichtausschnitt ab, Aktivierungen werden über TCP übertragen, und der Koordinator behält das übliche Verhalten von Kommandozeile und Schnittstelle bei.

Die Grenzen dieses Modus sind deutlich beschrieben. Beim Prefill hilft Parallelität, weil mehrere Grafikeinheiten gleichzeitig verschiedene Mikrobatches bearbeiten. Die Generierung ist streng autoregressiv und zahlt pro Token mindestens einen Sprung der Aktivierungen über die Maschinengrenze, weshalb sie langsamer ist als ein einzelner lokaler Prozess. Hinzu kommt ein Sicherheitsvorbehalt: Das verteilte Protokoll nutzt Steuer- und Datenverbindungen über TCP, besitzt laut README keine Verschlüsselung und keine Authentifizierung und gilt nicht als release-stabil. Koordinator und Worker sollten aus demselben Commit gebaut und in vertrauenswürdigen Netzen betrieben werden.

Tensor-Parallelität funktioniert anders, indem ein einzelner Dekodierschritt auf zwei über ein Thunderbolt-5-Kabel verbundene Macs verteilt wird und beide gleichzeitig am selben Token arbeiten. Auf einem einzelnen Server teilt --cuda-tensor-parallel die Last auf eine gerade Anzahl von Grafikgeräten auf.

ds4-bench, ds4-eval mit 92 Punkten und ds4-server mit --batched-session N

Zum Lieferumfang gehören eigene Messwerkzeuge. ds4-bench bestimmt den momentanen Prefill- und Generierungsdurchsatz an Kontextgrenzen statt eines Durchschnitts über einen ganzen Lauf und stellt den KV-Zustand zwischen den Zeilen wieder her. ds4-eval wird als echte Modellintegrationsprüfung mit einem eingebetteten Satz von 92 Aufgaben beschrieben, zusammengesetzt aus GPQA Diamond, geprüftem SuperGPQA, AIME 2025 und COMPSEC. Das README warnt ausdrücklich davor, Ergebnisse daraus als offizielle Benchmark-Punktzahl zu melden.

Der mitgelieferte Agent führt die Inferenz innerhalb des Agenten selbst aus, also ohne Socket- oder Schnittstellengrenze, und legt Sitzungen unter ~/.ds4/kvcache ab. Bedient wird er über die Befehle /save, /list, /switch, /del und /strip. Der Server startet als lokaler, zu OpenAI und Anthropic kompatibler Dienst und nimmt mit --batched-session N mehrere residente KV-Sitzungen auf.

Zum Zustand der Software ist das README deutlich: Sie verändere sich derzeit sehr schnell, gelte als Beta-Qualität, und vor jeder Veröffentlichung werde ein großer QA-Lauf ausgeführt, Instabilitäten seien dennoch möglich. Das Projekt nennt außerdem offen, dass es mit starker Unterstützung durch Sprachmodelle entstanden ist, namentlich GPT 5.5, GPT 5.6 und Claude Fable, wobei Menschen Ideen, Tests und Fehlersuche führten. Einen Installationsbefehl enthält der hier ausgewertete README-Ausschnitt nicht, die nähere Anleitung liegt in den Unterdokumenten wie CONTRIBUTING.md und QA_BEFORE_RELEASES.md.

Abgrenzung zu llama.cpp als universellem GGUF-Lader

Der Vergleich mit llama.cpp liegt nahe, weil das README selbst betont, dass ds4.c nicht gegen GGML linkt, aber ohne die von llama.cpp und GGML eröffneten Wege nicht existieren würde. Teile des Quellcodes wurden unter der MIT-Lizenz übernommen oder angepasst, namentlich GGUF-Quantisierungslayouts und Tabellen, CPU-Quantisierungs- und Skalarprodukt-Logik sowie einzelne Kernel, weshalb der Urheberrechtshinweis der GGML-Autoren in der LICENSE-Datei erhalten bleibt.

Der praktische Unterschied liegt in der Breite. llama.cpp verfolgt den Ansatz, möglichst viele Modelle und Quantisierungsformate zu laden, und ist damit die Wahl für wechselnde Gewichte, eigene Feinabstimmungen und experimentelle Formate. DwarfStar verzichtet darauf und bündelt stattdessen für eine Handvoll Modelle alle Bestandteile von der Gewichtedatei über den Agenten bis zum Server aus einem Guss, was die Abstimmung von Quantisierung, KV-Cache und Werkzeugaufrufen erleichtert.

Wer zwischen beiden wählt, kann die Entscheidung an einer konkreten Beobachtung festmachen. Läuft das eigene Vorhaben ausschließlich auf DeepSeek V4 Flash, V4 PRO oder GLM 5.2 in einem der im README genannten GGUF-Layouts, ergibt die schmale Engine mit ihrem abgestimmten SSD-Streaming und den parallelen Betriebsarten Sinn. Sobald ein zusätzliches Modell oder ein abweichendes Layout ins Spiel kommt, endet die Unterstützung, und ein breiterer Lader ist die belastbarere Grundlage. Da das README den Beta-Zustand und mögliche Instabilitäten nennt, sollte ein Wechsel in jedem Fall mit einem Lauf von ds4-bench und einem Blick auf ds4-eval begleitet werden.

Redaktionelles Fazit

Geeignet ist das Projekt für Besitzer großer Maschinen, also Macs ab 96 GB, Workstations mit 512 GB oder Server mit mehreren CUDA-Karten, die genau eines der unterstützten Modelle lokal betreiben wollen und Abweichungen im Betrieb tolerieren. Nicht geeignet ist es für alle, die einen universellen GGUF-Lader suchen, denn beliebige GGUF-Dateien funktionieren nach README-Angabe nicht, und ebenso wenig für Umgebungen, die ein stabiles verteiltes Protokoll brauchen, da dieses ohne Verschlüsselung und Authentifizierung arbeitet. Vor dem Einsatz sollte geprüft werden, ob die eigene Hardware zu den drei Backends passt und ob unter Metal ausreichend Speicher für den residenten Pfad vorhanden ist, sonst bleibt nur das langsamere SSD-Streaming. Wer mehrere Modelle oder wechselnde Quantisierungen fahren will, ist mit einem breiteren Laufzeitwerk besser bedient.

Offizielle Quellen

1. Official README
2. Project repository