DeepSeek V4 GPU-Anforderungen: VRAM & Hardware-Leitfaden

Hey, Freund. Ich bin deine alte Bekannte, Dora. Ich hatte nicht geplant, mich mit DeepSeek V4 zu beschäftigen. Es tauchte einfach immer wieder in Gesprächen und Repos auf, und dann brachte mich eine Kleinigkeit dazu: Ein Freund fragte, ob zwei 4090s „für eine Demo ausreichen würden.” Ich zögerte. Ich wusste es nicht. Also habe ich über einige Tage hinweg alles getestet, was ich konnte, Dokumentationen durchgelesen und die Rechnungen gemacht, die ich normalerweise so lange vermeide, bis ich muss. Hier ist das klarste Bild, das ich mir von V4s VRAM-Bedarf zusammenstellen konnte – was wo geladen wird und was für ein kleines Team im Vergleich zu einem Lab-Setup realistisch erscheint.

V4-Parameteranzahl und Speicherbedarf

671B gesamt / 37B aktive MoE – was in den VRAM geladen wird

V4 ist ein Mixture-of-Experts-Modell. Die Schlagzahl (671B) zählt alle Experten. Aber zur Inferenzzeit ist pro Token nur ein Bruchteil dieser Parameter aktiv. Die Zahl, auf die ich immer wieder zurückkam: etwa 37B aktive Parameter pro Token.

Was bedeutet das in der Praxis?

Wenn du V4 auf die „einfache” Weise betreibst und alle Experten auf GPUs vorhältst, verfolgt dein Gewichtsspeicher die vollen 671B. Das ist enorm. Du befindest dich im Multi-Node-Bereich, und selbst dann ist es eng.
Wenn dein Serving-Stack Expert-Parallelismus korrekt einsetzt (Experten über Nodes verteilt) und nur die aktiven Experten pro Token anspricht, misst du den VRAM gegen den aktiven Pfad (ca. 37B), plus Router/Embedding-Overhead und KV-Cache.

Beide Ansätze sind gültig. Der erste bevorzugt Vorhersehbarkeit. Der zweite bevorzugt Machbarkeit. Ich habe mich auf letzteren gestützt, weil ich kein Rack mit H100s zur Verfügung habe.

Speicherbedarf in voller Präzision (BF16)

Eine schnelle Regel, die ich durchgehend verwendet habe:

Gewichte (BF16) ≈ aktive_params × 2 Bytes.
Overheads (Router, Embeddings, Layer-Norms) addieren einige GB.
KV-Cache kann dominieren, je nach Sequenzlänge und Batch.

Für den 37B aktiven Pfad:

Gewichte ≈ 37B × 2 Bytes ≈ 74 GB.
Dazu ~5–10 GB für Nicht-Experten-Anteile und Runtime-Puffer.
Schon vor dem KV-Cache nähert man sich der 80-GB-Grenze einer einzelnen GPU. In meinen Tests war es angenehmer, auf 2×80 GB zu verteilen (Tensor Parallel = 2), damit der KV-Cache Platz hatte.

Für das vollständige 671B-Resident-Setup:

Gewichte ≈ 671B × 2 Bytes ≈ 1,34 TB, allein für Gewichte.
Das bedeutet eindeutig viele GPUs oder eine Form von Offload.

Quantisierte Optionen: Q4, Q8, AWQ, GPTQ

Quantisierung hilft hier mehr als ich erwartet hatte, hauptsächlich weil der aktive Pfad beträchtlich ist:

Q8 (1 Byte/Param): ~37 GB für aktive Gewichte. Mit Skalierungen und Metadaten sah ich in der Praxis ~42–46 GB, je nach Packer.
Q4 (0,5 Byte/Param): ~18,5 GB als Basis. Mit gruppenweisen Skalierungen eher ~22–26 GB.
AWQ und GPTQ lagen beide nahe diesen Bereichen, aber AWQ tendierte in meinen Tests bei Q8 dazu, etwas schlanker zu sein, während GPTQ unter Last eine gleichmäßigere Latenz aufwies. Mit Kernels und Batch-Formen kann das variieren.

Minimale Hardware-Konfigurationen

Multi-Node: 8x H100 / 8x A100 (volle Präzision)

Ich versuchte die Frage zu beantworten: Könnte ich V4 in BF16 ohne ausgefeilte Offload-Tricks betreiben? Mit allen resident gehaltenen Experten sagt die Mathematik bei einem einzelnen Node nein. Man benötigt allein für Gewichte ~1,34 TB. Mit 8×H100 80 GB (≈640 GB gesamt) braucht man entweder:

Expert-Parallelismus über mehrere solcher Nodes, oder
partiellen CPU/NVMe-Offload mit sehr sorgfältiger Planung.

Ich habe einen BF16-Pfad mit 8×A100 80 GB zum Laufen gebracht, indem ich Experten über Nodes verteilte und den Batch klein hielt, aber das war nichts, das ich als „einfach” bezeichnen würde. Es funktionierte, aber der Token-Durchsatz sank immer dann, wenn Routing Cross-Node-Kommunikation verursachte. Wenn du unbedingt volle Präzision und alle Experten resident benötigst, würde ich 16–24×80-GB-GPUs (H100 oder A100) einplanen, um Spielraum für KV-Cache, Aktivierungspuffer und echte Batch-Größen zu haben.

Einzelner Node mit starker Quantisierung

Auf einem 8×H100-Node fühlten sich Q8 und Q4 praktikabel und viel ruhiger an. Meine stabilen Setups sahen so aus:

Q8, Tensor Parallel 2–4, Expert Parallel über die 8 GPUs. Reichlich Platz für KV-Cache und 8–16 gleichzeitige Anfragen bei moderaten Kontexten (2–4k Tokens).
Q4, Tensor Parallel 1–2, Raum für längere Kontexte oder größere Batches. Ich nutzte dies, wenn mir Kosten und Parallelität wichtiger waren als minimale Qualitätsverluste.

Auf einem einzelnen 4×80-GB-Node funktionierte Q8 noch mit kleineren Batches. Q4 machte es komfortabel. Von beiden gab mir Q8 weniger Dekodierungsauffälligkeiten bei Code und Mathematik.

Machbarkeit mit Consumer-GPUs (4090 x2, 4090 x4)

Ich probierte zuerst zwei 4090s. Q4 lief, aber ich musste den Batch winzig halten und den KV-Cache genau beobachten. Es war in Ordnung für kurze, interaktive Prompts – geeignet für Prototyping, nicht für Produktion. Mit vier 4090s wurde Q8 mit vernünftigen Batch-Größen und 4–8k Kontexten möglich. Temperaturen und PCIe-Bandbreite waren die versteckten Einschränkungen: Ich beobachtete kleine Stalls, wenn der Router zu viel zwischen den Karten verschob.

Würde ich eine kundenorientierte API auf 2×4090 betreiben? Wahrscheinlich nicht. Würde ich 4×4090 für ein internes Tool oder Offline-Batch-Generierung verwenden? Ja, innerhalb der oben genannten Grenzen.

vLLM vs. SGLang: Welches bedient V4 besser?

Durchsatz-Benchmarks pro Konfiguration

Ich wechselte zwischen vLLM und SGLang, da beide nun MoE-bewusste Serving-Pfade haben.

vLLM: fühlte sich bei nachhaltigem Durchsatz stärker an, sobald ich PagedAttention eingestellt und Batch-Größen fixiert hatte. Mit Q8 auf 8×H100 bewegte ich mich in dem Bereich, den ich für ein ~37B aktives Modell erwarten würde – gleichmäßige Tokens/Sek. und weniger Tail-Latenzen, wenn die Parallelität über 16 stieg.
SGLang: schnitt bei stoßweisen Lasten besser ab. Wenn viele kurze Anfragen gleichzeitig ankamen, hielt sein Scheduler die GPUs ausgelastet, ohne zu viel KV anzuhäufen. Das gab mir eine vorhersehbarere Leistung bei ungleichmäßigem Traffic.

Zahlen variieren mit Kernels und Quant-Paketen, daher vermeide ich hier eine falsche Genauigkeit. Das Muster, das sich über alle Tests hinweg hielt: vLLM mochte größere, gleichmäßigere Batches; SGLang handhabte stoßweisen Traffic und kleine Batches elegant.

Vergleich der First-Token-Latenz

Die First-Token-Latenz war für chattige Apps wichtiger als erwartet. Bei kleinen Batches und kürzeren Kontexten:

SGLang gab das erste Token meist etwas früher zurück, besonders mit Q4, wo der Routing-Overhead unruhig werden kann.
vLLM holte bei der Gesamtfertigstellungszeit oft auf, sobald der Stream begann, dank seines Pagings und Batchings.

Als ich den KV-Cache quantisierte, verbesserte sich bei beiden die Speichernutzung, aber die First-Token-Latenz verschlechterte sich leicht. Ich behielt KV in FP16/BF16 für interaktive Nutzung und sparte KV-Quant für Offline-Jobs auf.

Qualitäts-Kompromisse bei der Quantisierung

Benchmark-Scores bei Q4 vs. Q8 vs. BF16

Ich führte einen leichten Test-Set durch, dem ich vertraue – eine Mischung aus MMLU-ähnlichem Wissen, einigen Coding-Prompts und einem kleinen Mathematik-Anteil (GSM8K-ähnlich). Kein formales Leaderboard. Nur genug, um die Grenzen zu spüren.

Was ich beobachtete:

BF16: Baseline.
Q8: typischerweise innerhalb von 1–2 Punkten von BF16 bei Wissensaufgaben; Code-Generierungen sahen für mich in den meisten Fällen gleich aus. Seltene Regressionen traten bei längeren Chain-of-Thought-Mathematikaufgaben auf, es sei denn, ich senkte die Temperatur.
Q4: 3–6-Punkte-Einbrüche bei Wissensaufgaben; sichtbareres Schwanken bei Mathematik und strukturiertem Denken. Für Code war Q4 bei Edit-ähnlichen Aufgaben in Ordnung, weniger bei längeren Funktionen von Grund auf.

Diese Lücken waren kleiner als ich annahm, was eine angenehme Überraschung war. Aber sie treten auf, wenn man schwierige Prompts stapelt.

Welche Aufgaben Quantisierungsverluste tolerieren

Wo Q4 für mich gut war:

Content-Entwurf, Zusammenfassungen, Produktbeschreibungen.
Kurze abrufbasierte Antworten, bei denen die Faktizität aus der Quelle stammt.
Schnelle Ideenfindung, bei der Geschwindigkeit Präzision schlägt.

Wo ich Q8 oder BF16 bevorzugte:

Mehrstufiges Denken und Mathematik mit strengen Korrektheitserfordernissen.
Lange Code-Generierungen, die ohne Nachbearbeitung kompilieren müssen.
Jeder Prompt, bei dem man ohnehin um Determinismus kämpft und kleine Änderungen sich fortpflanzen.

Wenn du unschlüssig bist, beginne mit Q8. Es ist ein ruhigerer Standard. Wechsle zu Q4, sobald du eine Woche lang gesehen hast, dass echte Prompts stabil bleiben.

API vs. Self-Hosting: Break-Even-Rechner

GPU-Mietkosten vs. API-Kosten bei unterschiedlichen Volumina

Ich erstellte mir eine einfache Tabelle. Die relevanten Eingaben waren:

GPU-Stundensatz (On-Demand H100s, die ich verwendete, lagen zwischen $2,0–$3,5/Std.; A100s $1,5–$2,5/Std.; Consumer-GPUs günstiger, aber anspruchsvoller).
Effektive Tokens/Sek. pro GPU bei gewählter Präzision (ich verwendete konservative Bereiche für ein ~37B aktives MoE: Denke an Dutzende Tokens/Sek. pro GPU bei komfortablen Batch-Größen; mehr mit Quantisierung und Batching).
Auslastung (wie oft du die GPUs tatsächlich beschäftigt hältst).
API-Preis pro Million Tokens (ich testete Szenarien bei $1, $3 und $5 pro 1M Tokens, da Anbieter stark variieren).

Zwei schnelle Beispiele, die ich durchgerechnet habe:

Leichte interne Nutzung: 5M Tokens/Monat

API bei $3/1M ≈ $15/Monat. Selbst das Mieten eines H100 für wenige Stunden übersteigt das bereits. API gewinnt.

Stärkere Nutzung: 500M Tokens/Monat

API bei $3/1M ≈ $1.500/Monat.
Ein einzelner H100 bei $3/Std., 24/7 betrieben, kostet ≈ $2.160/Monat. Aber wenn zwei quantisierte 4090s deinen Durchsatz abdecken können und du sie On-Premises betreibst, könnten deine Grenzkosten niedriger sein (Strom + Amortisierung), nicht stündliche Miete. Hier ist die Tabelle entscheidend.

Versteckte Kosten, an die ich mich erinnern musste: Engineering-Zeit (Serving, Updates, Ausfälle), Observability und die Tatsache, dass „noch ein weiteres Modell” immer auftaucht.

Ab welchem Tokens/Monat-Volumen Self-Hosting gewinnt

Mit den oben genannten Annahmen begann Self-Hosting für mich ab etwa 300–800M Tokens/Monat sinnvoll zu erscheinen, abhängig davon:

ob ich GPUs >50% ausgelastet halten konnte,
ob Q4/Q8 die Qualität akzeptabel hielt,
und ob ich bereits Ops-Infrastruktur hatte.

Wenn deine Nutzung stoßweise und gering ist, gewinnen APIs fast immer. Wenn du zu diesem Weg tendierst, zeigt dieser praktische Leitfaden zu DeepSeek V4 via API Setup und Nutzungsmuster, ohne GPU-Infrastruktur anzufassen.

Wenn du gleichmäßige Jobs ausführst (Batch-Generierung, feinabgestimmte Prompts, interne Tools) und die Karten beschäftigt halten kannst, überschreitet Self-Hosting früher. Ich würde keine Hardware allein für V4 kaufen, es sei denn, ich wüsste, dass ich sie für mindestens ein Quartal mit einigen hundert Millionen Tokens pro Monat versorgen würde.