DeepSeek veröffentlicht Inference-Framework DeepInfer als Open Source

DeepSeek hat am 20. Oktober 2026 sein internes Inference-Framework DeepInfer als Open Source unter der Apache License 2.0 veröffentlicht. Es ist die Software, mit der DeepSeek das Modell DeepSeek-V4.1-Flash im eigenen Rechenzentrum ausliefert. Relevant ist das für Betreiber großer GPU-Cluster und für Teams, die DeepSeek-Modelle selbst hosten wollen. Für typische Unternehmensumgebungen mit einzelnen GPU-Servern ändert sich vorerst wenig: Die unterstützte Hardware ist eng gefasst, und zentrale Bausteine eines Produktivdienstes fehlen im Release. Akuter Handlungsbedarf besteht nicht, wohl aber Grund zur Planung für alle, die eigene Inference-Infrastruktur aufbauen.

Was ist neu?

DeepSeek kündigte DeepInfer am 20. Oktober um 09:30 UTC auf X als „in-house inference framework, now fully open source“ an. Das GitHub-Repository deepseek-ai/DeepInfer enthält einen ersten Commit vom selben Tag. Laut README handelt es sich um das Framework hinter den großen Produktivdiensten von DeepSeek, in dieser Fassung zunächst für Offline-Inferenz. Es entstand laut den Entwicklern ursprünglich auf Basis von vLLM, mit Anleihen bei SGLang und TensorRT-LLM.

Parallel veröffentlicht DeepSeek deepseek-recipe. Die Rust-Bibliothek mit Python-Anbindung übersetzt Anfragen in den Formaten Messages, Chat Completions und Responses in Prompts und Token für DeepSeek-V4- und V4.1-Modelle und wandelt die Ausgabe zurück. Laut DeepSeek ist die Verarbeitung an die offizielle API angeglichen, sodass eigene Installationen dasselbe Verhalten zeigen sollen. Inference-Code für künftige Modelle soll ebenfalls in DeepInfer erscheinen.

Was DeepInfer mitbringt

Das README listet unter anderem folgende Funktionen:

• optimierte Kernel aus FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect und eigenen TileLang-Kerneln
• Attention-Datenparallelität, Kontext-Parallelität sowie Expert-Parallelität für MoE mit Lastausgleich (EPLB)
• spekulatives Dekodieren mit Draft-Tokens (DSpark) und konfidenzgesteuerter Verifikation
• asynchrones Scheduling, das CPU-Planung und GPU-Ausführung überlappt
• batch-invariante Inferenz und deterministisches Sampling, beides nur auf NVIDIA
• strukturierte Ausgaben über Regex, JSON-Schema oder EBNF-Grammatik

Laut der begleitenden Deployment-Dokumentation bedient ein einzelner Cluster derzeit 155 Billionen Token pro Tag.

Für wen ist das relevant?

Die Voraussetzungen sind hoch. Unterstützt werden ausschließlich NVIDIA-GPUs der Generation SM100 und Huawei Ascend 950. Gefordert sind Linux, GCC ab 13, Python 3.12 sowie CUDA 13 beziehungsweise CANN 9.2. Als Modell ist bisher nur DeepSeek-V4.1-Flash unterstützt, standardmäßig der Checkpoint DeepSeek-V4.1-Flash-1017 von Hugging Face. Die Benchmarks im README wurden auf 4 GPUs für Prefill und 64 GPUs für Decode gemessen.

Die Deployment-Dokumentation nennt als kleinste effiziente Einheit 64 GPUs für Prefill plus 64 GPUs für Decode, lauffähig sei bereits eine Instanz pro Stufe. Damit richtet sich DeepInfer an Cloud-Anbieter, Rechenzentren und große Forschungseinrichtungen. Wer lokal mit Ollama oder einem einzelnen vLLM-Server arbeitet, bleibt vorerst bei diesen Werkzeugen.

Was im Release fehlt

DeepSeek benennt im README selbst, welche Teile für einen vollständigen Inference-Dienst nötig, aber nicht enthalten sind:

• ein KV-Cache-System zur Wiederverwendung bereits berechneter Kontexte
• die Trennung von Vision Encoder, Prefill und Decode auf eigene Instanzen, deren Engine-Funktionen laut DeepSeek größtenteils schon implementiert sind
• Lastverteilung über datenparallele Replikate für Prefill und Decode

Begründung laut Dokumentation: KV-Cache-Verwaltung und Load Balancing seien eng mit der internen Infrastruktur verzahnt. Das Design beschreibt DeepSeek in einem Blogbeitrag, den Code jedoch nicht. Wer DeepInfer produktiv nutzen will, muss diese Schichten selbst bauen oder aus anderen Projekten übernehmen.

Was Admins jetzt tun sollten

• Bestand prüfen: Welche GPU-Generationen stehen zur Verfügung? Ohne SM100 oder Ascend 950 ist DeepInfer derzeit keine Option.
• Modellbezeichnungen in eigenen Anwendungen kontrollieren. DeepInfer arbeitet mit DeepSeek-V4.1-Flash-1017, die alten Flash-Namen der API werden laut DeepSeek nur noch weitergeleitet.
• deepseek-recipe unabhängig von DeepInfer bewerten: Wer DeepSeek-Modelle hinter einem eigenen Gateway betreibt, kann damit Tokenisierung und API-Verhalten an die offizielle API angleichen.
• Für Pilotprojekte fehlende Bausteine einplanen, insbesondere KV-Cache-Speicher und Load Balancer.
• Abhängigkeiten prüfen: Die NVIDIA-Variante setzt auf PyTorch 2.13 mit CUDA 13.2 und Vorabversionen von FlashAttention 4.

Einordnung

Mit DeepInfer legt DeepSeek nach Kernel-Bibliotheken nun auch die Engine darüber offen. Für den Mittelstand ist das vor allem ein Signal: Leistungsfähige Inference-Software wird freier verfügbar, die Hardwarehürde bleibt aber hoch. Mittelfristig dürften Verbesserungen über vLLM und andere Projekte auch bei kleineren Installationen ankommen. Bis dahin sind die bisherigen Werkzeuge für lokale Modelle die realistische Wahl. Wer die Umstellung der Flash-Modell-IDs noch vor sich hat, findet die Details im Beitrag zur Modell-ID-Migration auf DeepSeek-V4.1-Flash-1017.

Passende Anleitungen auf S-EDV

• vLLM 0.32 mit neuem KV-Cache-System: die Basis, auf der DeepInfer ursprünglich aufbaut.
• Strukturierte JSON-Ausgaben mit lokalen LLMs: dieselbe Technik, die DeepInfer per Regex, JSON-Schema und EBNF anbietet.

Quellen

• GitHub: deepseek-ai/DeepInfer (README, Lizenz, Voraussetzungen)
• DeepInfer: DeepSeek V4.1 Flash Inference Deployment Q&A
• GitHub: deepseek-ai/deepseek-recipe
• DeepSeek auf X: Ankündigung von DeepInfer (20.10.2026)
• THE DECODER: DeepInfer, Deepseek gibt die Betriebssoftware hinter seinem schnellen KI-Modell frei