DeepSeek V3.2 im Eigenbetrieb: GPT-5-Klasse-KI auf dem eigenen Server

Frontier-Reasoning ist bislang das Reich einer Handvoll geschlossener US-APIs – und damit für den datensensiblen deutschen Mittelstand faktisch tabu. Mit DeepSeek V3.2 kippt diese Rechnung. Das Modell erreicht in seiner High-Compute-Ausbaustufe laut Paper GPT-5-Niveau, ist unter MIT-Lizenz frei verfügbar und lässt sich vollständig im eigenen Rechenzentrum betreiben. Der technische Hebel dahinter heißt DeepSeek Sparse Attention (DSA) – und er macht genau die teuren Langkontext-Workloads bezahlbar, an denen Cloud-APIs ihr Geld verdienen.

Dieser Artikel ordnet ein, was V3.2 von V4 und geschlossenen Modellen unterscheidet, erklärt Sparse Attention verständlich, liefert eine ehrliche Hardware-Staffel für den Eigenbetrieb, rechnet die Kosten gegen die aktuelle API-Referenz und zeigt den Deployment-Weg über vLLM und TensorRT-LLM bis zum internen API-Endpunkt.

Was DeepSeek V3.2 von V4 und geschlossenen Modellen unterscheidet

DeepSeek V3.2 ist kein monolithisches Riesenmodell, das bei jeder Anfrage vollständig rechnet. Es folgt der Mixture-of-Experts-Architektur: Von den 671 Mrd. Parametern des Hauptmodells werden pro Token nur rund 37 Mrd. aktiv geschaltet – acht von 256 geroutete Experten plus ein geteilter Experte. Das entkoppelt die Modellkapazität von der Rechenlast: Sie erhalten das Weltwissen eines sehr großen Netzes, zahlen bei der Inferenz aber nur für einen kleinen aktiven Ausschnitt.

Ein Detail, das für Verwirrung sorgt: Der Checkpoint auf Hugging Face weist 685 Mrd. Parameter aus, nicht 671. Der Unterschied ist ein aufgesetztes 14-Mrd.-Parameter-Modul für Multi-Token-Prediction (MTP), das die Generierung beschleunigt. Beide Zahlen sind korrekt – je nachdem, ob das MTP-Modul mitgezählt wird. Für die Kapazität des eigentlichen Sprachmodells gilt: 671 Mrd. total, 37 Mrd. aktiv.

Die Abgrenzung nach oben: V4

DeepSeek V4 existiert seit Frühjahr 2026 und hat V3.2 in der offiziellen API abgelöst. V4-Pro liefert die maximale Frontier-Leistung, verlangt dafür aber einen deutlich schwereren Server – in der Größenordnung von acht H200-GPUs. V3.2 ist damit nicht das „alte" Modell, sondern die kosteneffiziente, leichter self-hostbare Ausbaustufe. Für einen sehr großen Teil der Mittelstands-Workloads ist genau das die richtige Wahl: frontier-nahe Qualität, ohne einen ganzen Cluster zu betreiben.

Die Abgrenzung nach außen: geschlossene APIs

Gegen GPT-5, Gemini oder Claude verliert V3.2 im Datenschutz-Vergleich nicht – es gewinnt. Geschlossene Modelle sind nur als Cloud-API zugänglich; jede Anfrage verlässt Ihr Unternehmen und landet bei einem US-Anbieter als Auftragsverarbeiter. V3.2 dagegen läuft auf Ihrer Hardware. Die High-Compute-Variante V3.2-Speciale übertrifft laut dem zugehörigen Paper (arXiv:2512.02556, Dezember 2025) sogar GPT-5 und erreichte Gold-Niveau bei der IMO 2025 (35 von 42 Punkten) sowie bei der IOI 2025 sowie den zweiten Platz beim ICPC World Finals 2025.

Hinweis: Der gehostete Speciale-API-Endpunkt wurde am 15. Dezember 2025 abgeschaltet. Weil die Gewichte offen und MIT-lizenziert sind, bleibt das Self-Hosting davon unberührt – Sie betreiben das Modell schlicht selbst.

DeepSeek Sparse Attention erklärt: Warum lange Kontexte plötzlich bezahlbar sind

Der teuerste Teil eines Transformers bei langem Kontext ist die Attention. Klassische „Full Attention" vergleicht jedes Token mit jedem anderen – die Rechenlast wächst quadratisch mit der Sequenzlänge. Verdoppeln Sie den Kontext, vervierfachen sich die Attention-Kosten. Genau deshalb sind Dokumentenanalyse, große RAG-Kontexte oder lange Chatverläufe in der Cloud so teuer.

DeepSeek Sparse Attention bricht diese Quadratik auf. Statt alle Token-Paare zu berechnen, schaltet DSA einen leichtgewichtigen Lightning Indexer vor: ein FP8-Modul, das für jedes Token bewertet, welche vorangegangenen Kontextabschnitte überhaupt relevant sind. Ein feingranularer Top-k-Selektor wählt daraus die wichtigsten Blöcke aus. Erst diese Auswahl wird von der eigentlichen Attention verarbeitet.

Der Effekt: Die Komplexität sinkt von O(L²) auf O(k·L) – statt „jedes mit jedem" nur „jedes mit den k relevantesten". Bei langem Kontext halbiert das die Inferenzkosten in etwa. In der DeepSeek-API schlug sich das direkt nieder: Der Preis fiel gegenüber der Vorgängerversion V3.1-Terminus um rund 50 %.

Hardware-Sizing: Welche GPUs V3.2 im eigenen Rack braucht

Hier trennt sich Marketing von Realität, deshalb die ehrliche Ansage vorweg: Ein 671-Mrd.-Parameter-Modell ist auch quantisiert kein Ein-Karten-Projekt. Entscheidend ist die Quantisierung. NVIDIA und DeepSeek liefern einen fertigen NVFP4-Checkpoint (nvidia/DeepSeek-V3.2-NVFP4) mit TensorRT-LLM-Support; FP8- und BF16-Varianten existieren ebenfalls.

NVFP4 nutzt 4 Bit pro Gewicht statt 8 Bit bei FP8 – der reine Gewichts-Speicher halbiert sich also. Wichtig für die Planung: Die reale GPU-Speicherreduktion liegt bei rund dem 1,6-fachen, nicht bei glatt 2x, weil der KV-Cache aus Stabilitätsgründen in FP8 bleibt und weiterer Overhead hinzukommt. Der Genauigkeitsverlust von NVFP4 bleibt dabei typischerweise unter 1 %.

Konkret bedeutet das: Die rund 685 Mrd. Gewichte belegen in NVFP4 etwa 340–360 GB VRAM. Das erfordert einen Multi-GPU-Knoten. Blackwell spielt hier seine Stärke aus – die zweite Generation der Transformer Engine liefert dichte NVFP4-Leistung im Bereich von ~10 PFLOPS (rund das Fünffache von FP8 auf H200) bei 186 GB HBM3e pro GPU.

Konfiguration	Format	Eignung
Blackwell-Node (z. B. 8× B200 / GB200)	NVFP4	Produktiv, hoher Durchsatz
8× H200 / H100	FP8	Bestandshardware, bewährt
RTX PRO 6000 (96 GB), Mehrkarten-Setup	NVFP4	Kosteneffizienter Einstieg

Der entscheidende Vorteil von MoE beim Sizing: Sie brauchen viel VRAM für die Gewichte, aber die Rechenlast pro Token bleibt moderat, weil nur 37 Mrd. Parameter aktiv sind. Das hält die laufende Energie- und Rechenkosten im Rahmen und macht den Dauerbetrieb wirtschaftlich – anders als bei einem gleich großen Dense-Modell.

Kostenvergleich: Eigenbetrieb gegen 0,28 USD pro Million Token

Die DeepSeek-API dient als saubere Preisreferenz. Nach dem DSA-Sprung liegen die aktuellen Sätze bei rund 0,28 USD pro Million Input-Token (Cache-Miss), 0,028 USD bei Cache-Hit und 0,42 USD pro Million Output-Token. Das ist günstig – aber es ist eine variable Rechnung, die mit jedem Token weiterläuft und bei der jedes Token Ihr Haus verlässt.

Aspekt	Cloud-API	On-Premise V3.2
Kostenmodell	Variabel je Token (~0,28 USD/Mio. Input)	Fixe CAPEX + Strom/Wartung
Datenschutz	Drittlandtransfer, AVV, DSFA nötig	Kein Datenabfluss
Skalierung	Sofort, aber laufend teurer	Fixe Kapazität, planbar
Break-even	—	Bei hoher, planbarer Auslastung

Die Break-even-Logik ist einfach: Solange die Auslastung niedrig und unregelmäßig ist, gewinnt die API. Sobald Sie sensible Daten dauerhaft und in Volumen verarbeiten, kippt die Rechnung Richtung Eigenbetrieb. Die fixe CAPEX eines Servers amortisiert sich gegen eine variable Token-Rechnung, die nie aufhört zu laufen. Hinzu kommt eine oft unterschätzte Position: die Datenschutz-Ersparnis. Kein Drittlandtransfer, kein Auftragsverarbeiter, in vielen Fällen keine gesonderte Datenschutz-Folgenabschätzung für eine Cloud-API – das spart nicht nur Geld, sondern Monate an Compliance-Aufwand. Für eine belastbare Gesamtrechnung nutzen Sie unseren TCO-Rechner Cloud vs. On-Premise.

Deployment: V3.2 mit vLLM oder TensorRT-LLM produktiv ausrollen

Der Weg vom offenen Gewicht zum internen Endpunkt ist überraschend geradlinig – und vor allem reproduzierbar und auditierbar, weil jeder Schritt in Ihrem Netz stattfindet.

Schritt 1: Modell beziehen

Sie laden den passenden Checkpoint von Hugging Face – NVFP4 für Blackwell, FP8 für H200/H100-Bestand. Für Blackwell existiert zusätzlich eine NVIDIA-Dynamo-Recipe, die die Verteilung über mehrere GPUs vorkonfiguriert.

Schritt 2: Serving-Engine wählen

vLLM bietet frühe NVFP4-Unterstützung und ist der pragmatische Weg für flexible Deployments. TensorRT-LLM holt auf Blackwell das Maximum an Durchsatz heraus und ist der Pfad, wenn Sie die Hardware voll ausreizen wollen. Beide werden offiziell unterstützt.

Schritt 3: OpenAI-kompatibler Endpunkt

Beide Engines exponieren einen OpenAI-kompatiblen API-Endpunkt. Das ist der eigentliche Integrations-Hebel: Bestehende Anwendungen, die heute gegen eine Cloud-API sprechen, ändern nur die Base-URL – Ihr interner Server ersetzt den externen Anbieter, ohne dass eine Zeile Anwendungslogik angefasst werden muss. Unsere KIS:UI Chat-Plattform setzt genau auf diesem Prinzip auf.

Schritt 4: Durchsatz tunen

Für hohen Durchsatz sind zwei Stellschrauben entscheidend: Continuous Batching bündelt gleichzeitige Anfragen effizient, und KV-Cache-Tuning bestimmt, wie viele lange Kontexte parallel Platz finden. Der große Nebeneffekt des Eigenbetriebs: Vollständige Logs und Traces bleiben im eigenen Netz – die Grundlage für Governance, Debugging und Nachvollziehbarkeit, ohne dass Prompt-Inhalte an Dritte gehen.

Anwendungsfälle im Mittelstand: Reasoning ohne Datenabfluss

Der Wert von V3.2 im Eigenbetrieb zeigt sich überall dort, wo starke Reasoning-Fähigkeit auf vertrauliche Daten trifft – also genau da, wo eine Cloud-API ausscheidet:

• Vertrags- und Dokumentenanalyse: Klauseln prüfen, Abweichungen markieren, Zusammenfassungen erstellen – mit vertraulichen Mandanten- oder Lieferantendaten, die das Haus nicht verlassen dürfen. DSA macht dabei die typisch langen Kontexte bezahlbar.
• Coding-Assistent: Ein Modell, das Quellcode versteht und generiert, ohne dass eine einzige Zeile proprietärer Code an einen externen Anbieter geht. Für Unternehmen mit schützenswerter Software-IP ist das oft die einzige gangbare Option.
• RAG-Wissensassistent: Auf internen Handbüchern, Richtlinien und technischer Dokumentation. In Kombination mit einer lokalen Vektordatenbank entsteht ein befragbarer Wissensspeicher, dessen gesamter Datenfluss on-premise bleibt.
• Mathematisch-logische Aufgaben: Hier zahlt sich die Reasoning-Stärke der Speciale-Linie aus – von komplexen Kalkulationen über Konstruktionslogik bis zu strukturierten Entscheidungsbäumen.

Grenzen, Wartung und die Brücke zu V4

Eigenbetrieb heißt Eigenverantwortung – das gehört zur ehrlichen Bilanz. Wer V3.2 selbst hostet, übernimmt Aufgaben, die bei einer API der Anbieter trägt:

• Modellpflege: Updates und Sicherheits-Patches – für Serving-Engine, Treiber und Modell-Revisionen – spielen Sie selbst ein. Das ist überschaubar, aber es ist ein laufender Prozess.
• Eval-Pipeline: Nach jedem Update brauchen Sie eine automatisierte Bewertung, die die Antwortqualität gegen einen festen Testsatz prüft. Ohne diese Absicherung merken Sie Qualitätsregressionen erst im Produktivbetrieb.
• Governance-Pflichten: Dokumentation, Zugriffskontrolle und Audit-Logging bleiben Ihre Verantwortung. Der Vorteil: Alle dafür nötigen Daten liegen ohnehin bei Ihnen.

Der Upgrade-Pfad

V3.2 ist kein Endpunkt, sondern ein sinnvoller Einstieg. Steigen die Anforderungen – mehr Durchsatz, noch mehr Reasoning-Tiefe – führt der Weg zu V4-Flash oder V4-Pro. Weil beide derselben offenen DeepSeek-Linie folgen, bleibt das Deployment-Muster über vLLM oder TensorRT-LLM identisch; im Wesentlichen tauschen Sie Checkpoint und Hardware-Dimension. Sie investieren also nicht in eine Sackgasse, sondern in eine Architektur, die mitwächst. Mehr dazu im weiterführenden Beitrag zu DeepSeek V4 On-Premise.

Für die grundlegende Standortbestimmung – lohnt sich der Eigenbetrieb für Ihren Anwendungsfall überhaupt? – ist unser KI-Schnellcheck der schnellste Einstieg.

Häufig gestellte Fragen zu DeepSeek V3.2 im Eigenbetrieb

Ist DeepSeek V3.2 wirklich DSGVO-konform betreibbar?

Ja, wenn Sie es selbst hosten. Da die Gewichte offen sind, läuft das Modell vollständig auf Ihrer eigenen Hardware – es gibt keinen Drittlandtransfer, keinen Cloud-Anbieter als Auftragsverarbeiter und keinen externen Datenzugriff. Damit entfällt die größte DSGVO-Hürde geschlossener US-APIs.

Welche Hardware brauche ich mindestens für V3.2?

Dank Mixture-of-Experts sind nur 37 Mrd. Parameter pro Token aktiv. Mit NVFP4-Quantisierung auf Blackwell-GPUs (z. B. RTX PRO 6000 mit 96 GB) lässt sich das Modell auf deutlich kleinerer Hardware betreiben als das schwere V4-Pro, das rund acht H200 benötigt.

Was bringt DeepSeek Sparse Attention konkret?

DSA reduziert die Inferenzkosten bei langem Kontext um rund die Hälfte, indem der Lightning Indexer nur relevante Kontextabschnitte attendiert. Das macht Dokumentenanalyse und RAG mit großen Eingaben deutlich günstiger und schneller.

Ist V3.2 gegenüber V4 nicht veraltet?

V3.2 ist die kosteneffiziente, leichter self-hostbare Option. Für viele Mittelstands-Workloads liefert es GPT-5-nahe Reasoning-Qualität bei geringerem Hardwarebedarf. Wer maximale Frontier-Leistung braucht, kann später auf V4-Flash oder V4-Pro upgraden.