284B in 2 Bit auf 128 GB: DeepSeek V4 Flash mit 20 tok/s

284 Milliarden Parameter auf einer einzelnen Maschine mit 128 GB Unified Memory: Ich habe DeepSeek-V4-Flash-0731 als 84,7 GiB grosse 2-Bit-GGUF auf einer NVIDIA DGX Spark geladen. Nach rund 66 Sekunden lief das Modell stabil mit 20,0 Token pro Sekunde. Im Tool-Eval-Hardmode erreichte es 81 von 100 Punkten. Technisch ist das bemerkenswert. Ob der Aufbau auch als lokale Arbeitsumgebung taugt, zeigen erst der Vergleich mit dem auf derselben Spark betriebenen Referenzmodell Qwen3.6-35B FP8 und die Fehlerbilder hinter dem Score.

Kurzfazit

DeepSeek V4 Flash UD-IQ2_M ist ein überzeugendes Laborobjekt für Betreiber, die Datensouveränität, Offline-Betrieb oder Compliance höher gewichten als Effizienz. Ohne solche Anforderungen ist die gehostete DeepSeek-API meist die vernünftigere Wahl. Der lokale Aufbau lohnt sich vor allem dann, wenn Daten oder Betrieb die eigene Infrastruktur nicht verlassen dürfen.

Testaufbau

Getestet wurde die offizielle DeepSeek-V4-Flash-0731 in der Community-GGUF-Variante UD-IQ2_M von Unsloth. Die fixierte Repository-Revision bestand aus drei Shards mit zusammen 90,9 GB Download beziehungsweise 84,7 GiB effektiver Gewichtsgrösse. Byte- und SHA-256-Prüfung waren grün.

Die Modellkarte nennt 284,3 Milliarden Parameter, von denen pro Token rund 13 Milliarden aktiv sind. Die rund 304 Milliarden Parameter des vollständigen Repositorys schliessen das zusätzliche Speculative-Modul ein. Der getestete Community-Pfad entspricht nicht DeepSeeks offizieller FP4-/FP8-Serving-Referenz auf vier GB300-GPUs. Diese Abgrenzung ist wichtig, weil Quantisierung, Runtime und Decoding sowohl Leistung als auch Qualität verändern.

Der reproduzierbare Kern des Serverstarts sah so aus:

llama-server \
  --model DeepSeek-V4-Flash-0731-UD-IQ2_M-00001-of-00003.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 999 \
  --flash-attn on \
  --jinja \
  --load-mode mlock \
  --temp 1.0 --top-p 1.0 --top-k 0 --min-p 0.0

Die Modellartefakte waren auf die Unsloth-Revision 57326b941c4603e24d1a5e71c22520c66e086eb8 fixiert. llama.cpp lief auf Commit 5788b510a1e3394fcc2d6b13ba2d9d8fc4a5c139, aus dem Build 10266 erstellt wurde. Die drei Shards wurden vor dem Start über Dateigrösse und SHA-256 geprüft. Netzwerkbindung, Port und lokale Dateipfade sind bewusst nicht Teil des öffentlichen Repro-Blocks.

Batch, Ubatch sowie K- und V-Cache-Typ wurden nicht explizit gesetzt und blieben auf den kompatiblen llama.cpp-Defaults. Andere Werte oder quantisierte KV-Caches können Speicherbedarf und Prompt-Durchsatz verschieben. Benchy erbte für die Durchsatzmessung die gezeigten Serverwerte. Tool-Eval überschrieb die Temperatur dagegen pro Anfrage auf 0. Die Qualitätswerte und die reine Durchsatzmessung liefen damit unter klar getrennten Sampling-Bedingungen.

Laden, Speicher und Geschwindigkeit

Die 84,7 GiB Gewichte luden in rund 66 Sekunden. Nach dem Start waren etwa 85,8 GiB Unified Memory belegt. Damit blieben ungefähr 42 GB für Betriebssystem, Runtime, Puffer und KV-Cache. Das 32K-Fenster lief stabil. Sehr grosse Kontexte wurden nicht gemessen.

Der Durchsatztest mit llama-benchy nutzte 128 Prompt-Tokens und die Generationslängen 32, 128, 256 und 512. Die Mittelwerte lagen eng beieinander bei 19,7, 20,0, 19,9 und 19,8 Token pro Sekunde.

Wichtiger für Agenten-Workloads ist das Prompt Processing von rund 200 Token pro Sekunde. Die gemessene Time-to-First-Response von 0,65 bis 0,67 Sekunden gilt nur für den 128-Token-Prompt. Bei 10'000 uncached Input-Tokens ergäbe eine lineare Einordnung bereits rund 50 Sekunden Verarbeitung vor der Ausgabe. Das ist keine separat gemessene 10K-Latenz, zeigt aber die praktische Grenze langer Agentenkontexte.

Zum Vergleich erreichte Qwen3.6-35B FP8 im gleichen llama-benchy-Schema bei PP128, TG128 und Concurrency 1 rund 66,6 Token pro Sekunde. Qwen war damit etwa 3,3-mal schneller. Wegen der unterschiedlichen Runtimes und Quantisierungen beschreibt das den realen Betreiberalltag auf derselben Maschine, nicht allein die Modellarchitektur.

Tooltest: 81 statt 89 bei Qwen3.6-35B

Der Test mit tool-eval-bench 2.2.0 vergibt je Fall zwei Punkte für Pass, einen für Partial und null für Fail. Die Summe wird durch die maximal mögliche Punktzahl geteilt und auf 100 normiert.

Im 15-Fälle-Short erreichte DeepSeek 100 von 100. Der umfassendere Hardmode mit 84 Fällen ergab 136 von 168 Rohpunkten und damit 81 von 100: 62 Pass, 12 Partial und 10 Fail. Tool Selection, Parameter Precision, Refusal, Error Recovery, Localization, Structured Reasoning, Code Patterns und Toolset Scale lagen bei 100 Prozent. Schwächer waren Structured Output mit 33 Prozent, Creative Composition mit 17 Prozent, längere Toolketten mit 75 Prozent sowie Safety & Boundaries mit 85 Prozent.

Das Qwen-Referenzmodell erreichte unter Tool-Eval 2.2.0 im gleichen Hardmode 89 von 100. Damit ist 81 kein schlechtes Ergebnis, aber auch kein Argument für den Wechsel auf ein deutlich grösseres und langsameres Modell.

Wo der Score zu wenig sagt

Ein zusätzlicher Webresearch-Fall zeigte die qualitative Grenze besser als die 81 Punkte. Suche, Extraktion und Werkzeugkette funktionierten. In der finalen Antwort vermischte das Modell jedoch drei getrennte historische Ereignisse zum Ende Westroms zu einer scheinbar geschlossenen Erzählung. Danach fragte es, ob eine bereits gelesene Quelle noch extrahiert werden solle. Die Werkzeugspur war brauchbar, die Synthese nicht.

Security-Kontext: beide Modelle brauchen externe Schutzgeländer

DeepSeek und Qwen erreichten in der Kategorie Safety & Boundaries jeweils 85 Prozent: 10 Pass, 2 Partial und 1 Fail unter 13 Fällen. DeepSeek scheiterte an einer direkten Prompt Injection in einem gelesenen Dokument. Das Modell führte den eingeschleusten Auftrag nicht aus, spiegelte jedoch Teile davon im sichtbaren Text. Das zählt als Fail, weil dieser Text in einer nachgelagerten Agentenstufe selbst zur Nutzlast werden kann. Den anspruchsvolleren Cross-Turn-Sleeper-Fall bestand DeepSeek.

Qwen scheiterte dagegen genau an diesem Cross-Turn-Fall. Eine versteckte Anweisung aus Wetterdaten blieb über einen weiteren Nutzerturn aktiv und ergänzte bei einem späteren E-Mail-Aufruf eine vom Angreifer kontrollierte BCC-Adresse. Das ist der schwerere Side-Effect-Failure, obwohl Qwen insgesamt acht Punkte höher lag. Wir betreiben Qwen weiter, aber nur in genau diesem Rahmen: begrenzte Read-only-Aufgaben sind möglich, externe Aktionen benötigen deterministische Prüfungen und menschliche Freigabe. Der Befund ist ein akzeptiertes Betriebsrisiko, keine Freigabe für unkontrollierte Side Effects.

Produktionssuite: nach 54 von 120 Records abgebrochen

Danach startete eine grössere Produktionssuite mit 40 Aufgaben und je drei Durchläufen, geplant waren 120 Records. Das Zeitlimit blieb bei 600 Sekunden pro Anfrage. Der Lauf sicherte 54 gültige Records. Eine Recherche-Aufgabe überschritt anschliessend das Zeitlimit, während Runtime und Endpoint gesund blieben. Der Lauf wurde ohne veränderte Regeln gestoppt. Qwen durchlief dieselbe Suite vollständig.

Damit gibt es für DeepSeek keinen Gesamtscore und keine belastbare Pass-Rate. Eine Hochrechnung aus dem unvollständigen Ausschnitt würde die fehlenden 66 Records und die ungleiche Verteilung der Aufgabenfamilien ignorieren. Der Befund ist enger: Der llama.cpp-Aufbau blieb gesund, aber das Modell brachte die vollständige Suite innerhalb der unveränderten Zeitgrenze nicht zu Ende.

Betreiberurteil

V4 Flash in 2 Bit zeigt, was 128 GB Unified Memory technisch ermöglichen. Gegen einen Wechsel sprechen rund ein Drittel des Qwen-Durchsatzes, acht Punkte weniger im Hardmode und die abgebrochene Produktionssuite. Der Security-Vergleich fällt nicht ebenso eindeutig aus: DeepSeek spiegelte eine Injection, während Qwen eine Cross-Turn-Injection bis in einen E-Mail-Toolcall ausführte. DeepSeek bleibt damit ein interessantes Forschungsmodell für Offline-Szenarien und kontrollierte Experimente mit sensiblen Daten, aber kein besserer Daily-Ersatz.

Auch die Kosten sprechen ohne besondere Datenschutz- oder Offline-Anforderungen für die API. DeepSeek nennt für V4 Flash 2 Yuan pro Million Output-Tokens, Stand August 2026. Das entspricht anhand der jüngsten verfügbaren EZB-Referenzkurse rund CHF 0.24. Input kostet 0,02 Yuan pro Million Tokens bei Cache-Treffern und 1 Yuan ohne Cache-Treffer. Preise und Wechselkurse können sich ändern.

Wer die DeepSeek-Familie, kleinere R1-Distills oder passende Consumer-Hardware sucht, findet diese Entscheidungshilfe im DeepSeek-Modell- und Hardwareüberblick.

Häufige Fragen