DeepInfer ist ein leistungsfähiges Framework für die Inference von Großmodellen, das trainierte Modelle in servicebasierte, skalierbare Inference-Dienste verwandelt.

Warum hat DeepSeek DeepInfer offengelegt?

DeepSeek hat DeepInfer offengelegt, um es für großangelegte Produktionsdienste zu verwenden und es der Öffentlichkeit zugänglich zu machen.

Was ist die Diskussion auf Hacker News über DeepInfer?

Die Diskussionen konzentrieren sich hauptsächlich darauf, ob die Offenlegung ein einmaliger Code-Dump ist oder der Beginn einer langfristigen Wartung, ob die Produktionsstrategie direkt angewendet werden kann und was es für DeepSeek’s eigene Ökologie bedeutet.

Technische Analyse 034 | DeepSeek – offene Produktions- und Reasoning-Framework DeepInfer

Tech Teardown: Analyse der AI-Technik-Frameworks, Erklärung, Analyse, Beurteilung. Autor: Yongliang Datum: 2026-10-21 | Version v1 (Repository-Daten vom 10-20)

Cover Platzhalter

Cover: Platzhalter

Vorwand

Am 16. Oktober hat DeepSeek auf GitHub deepseek-ai/DeepInfer offengelegt. In der README-Erklärung des Repositories heißt es: „Die Inference-Framework, die von DeepSeek für großangelegte Produktionsdienste verwendet wird“ (Apache License 2.0).

Nach den Daten der Hot Tracking-Daten von Dritten beträgt die Anzahl der Sterne für dieses Repository bis zum 20. Oktober etwa 10.863 und es gibt 959 Fork-Versionen; Daten von Upstar zeigen, dass es diese Woche etwa 7.600 neue Sterne hinzugewonnen hat und zeitweise an der Spitze der allgemeinen Liste stand. Auf Hacker News gibt es den entsprechenden Diskussionspost 50163277 mit etwa 2075 Likes und 812 Kommentaren (Daten vom 10-21). Auf der Codeebene sind jedoch momentan nur 3 sichtbare Commits verfügbar; PithWire bewertet dies als: „3 Commits, Tausende von Sternen: Das ist ein Dump, kein Entwicklungsprozess.“

Die Diskussionen auf Hacker News konzentrieren sich hauptsächlich auf drei Aspekte: Ist diese Offenlegung eher ein einmaliger Code-Dump oder der Beginn einer langfristigen Wartung; kann die in der README beschriebene Produktionsstrategie direkt auf externe Nutzer angewandt werden; und was bedeutet dies für DeepSeek’s eigene Ökologie. Diese Kontroverse zeigt auch, dass die Marktforderungen nach jeder Offenlegung von DeepSeek nicht niedrig sind. Wenn die Erbringung nicht mit den Erwartungen übereinstimmt, wird der Unterschied vergrößert.

Was ist es

DeepInfer ist ein leistungsfähiges Framework für die Inference von Großmodellen, das standardmäßig auf der DeepSeek-V4.1-Flash-Serie basiert und den Standard-Checkpoint deepseek-ai/DeepSeek-V4.1-Flash-1017 verwendet. Es handelt sich nicht um Modelgewichte oder Trainingscode, sondern um ein Engineering-System, das trainiertes Modell in servicebasierten, skalierbaren Inference-Diensten verwandelt.

Laut der Repository-Erklärung unterstützt DeepInfer DeepSeek’s eigene Online-Produktionsdienste. Es packt Operatoren, Parallelstrategien, Scheduler und Ausgabeeinschränkungen zusammen, um bei großangelegter Bereitstellung eine geringe Latenzzeit und hohe Durchsatzkapazität zu gewährleisten. Das offene Repository ist jedoch eher eine geordnete Version des Produktionscodes: Die vollständige Git-Historie wurde nicht veröffentlicht, extern kann man nur 3 Commits sehen. Diese Art von „einmaligem Dump“ ist bei Open-Sourcing großer Unternehmen nicht ungewöhnlich. Der Vorteil ist, dass der Code vollständig lesbar ist, der Nachteil ist, dass es für Außenstehende schwierig ist, den Unterschied zwischen diesem Code und der aktuellen Online-Version zu erkennen sowie den Entwicklungsverlauf nachzuvollziehen.

In Bezug auf die Abhängigkeiten wird in der README vLLM als Hauptgrund angegeben, wobei SGLang und TensorRT-LLM berücksichtigt wurden. Das bedeutet, dass DeepInfer auf der bereits vorhandenen Open-Source-Ökologie basiert und nicht von Grund auf neu entwickelt wird. Für Entwickler, die bereits mit vLLM vertraut sind, ist der Einstieg in DeepInfer „welche DeepSeek-basierten Optimierungen auf vLLM aufgesetzt wurden“. Für externe Beobachter ist es genauer, DeepInfer als „Inference-Engineering-Auftritt von DeepSeek“ zu verstehen, als „einen direkt wiederverwendbaren Open-Source-Dienst“.

Welche Probleme löst das Projekt?

Produktionsniveau-Modellgrößen müssen gleichzeitig niedrige Latenzzeiten, hohe Durchsatzraten, stabile Ergebnisse und Hardwarekompatibilität bieten. DeepInfer versucht, eine umfassende Lösung in diesen Bereichen anzubieten.

Erstens ist es die Latenzzeit pro Anfrage. In der Modellgrößenberechnung machen die Attention-Computation und Matrizenmultiplikation den größten Teil der Zeitverwendung aus. Wenn das Kernel-Toolkit nicht gut auf die Hardware abgestimmt ist, kann dies dazu führen, dass die GPU nicht vollständig genutzt wird. Zweitens ist es der Durchsatz. Online-Dienste führen Anfragen normalerweise in Batches durch. Wie die Batches organisiert, wie sie verwaltet werden und wie man verhindert, dass die Ergebnisse nach der Organisation unterschiedlich sind, sind wichtige Probleme. Drittens ist es die Stabilität der Ergebnisse. Im Produktionsumfeld wird erwartet, dass dieselben Eingaben in verschiedenen Batches konsistente Ergebnisse liefern, und auch dass der Sampling-Prozess reproduzierbar ist. Viertens sind es die Ausgabebeschränkungen. In der Praxis muss das Modell oft in JSON-Schema-, Regular- oder EBNF-Format ausgegeben werden, anstatt freier Text. Fünftens ist es die Hardware-Heterogenität. DeepSeek hat in seinem README zwei Plattformen aufgelistet: NVIDIA SM100-GPUs und Huawei Ascend 950-NPUs, um einen Übergang zur Berechnung über verschiedene Hardwaretypen zu bieten.

Diese Probleme sind nicht nur bei DeepInfer vorhanden, aber das Projekt sammelt die Lösungen in einem einzigen Repository und betont ausdrücklich, dass sie aus den eigenen Produktionsdiensten stammen. Für Teams, die die technischen Entscheidungen von DeepSeek übernehmen möchten, ist dies viel konkreter als das Erforschen des vLLM-Quellcodes von Grund auf. Mit anderen Worten, der Wert von DeepInfer liegt nicht nur im Code selbst, sondern auch darin, dass es zeigt, welche Optimierungen für die Produktionsberechnung am wichtigsten sind. Für viele Unternehmen sind diese Probleme in verschiedenen Tools verteilt, während DeepInfer versucht, sie in einem einheitlichen Rahmen zu vereinen.

Wie wird das Projekt umgesetzt?

Die Umsetzung von DeepInfer konzentriert sich auf fünf Aspekte: Kernel, Parallelität, Scheduling, Sampling und Ausgabeformat.

Das Kernel-Toolkit ist der größte Glanzpunkt. Das Repository listet FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect und TileLang-Kerne auf. FlashMLA sorgt dafür, dass die Attention-Computation nahe an den Hardwaregrenzen liegt. Der Name MLA deutet darauf hin, dass es das Kompressionstoolkit von Multi-head Latent Attention verwendet, um den Speicherbedarf für die Schlüssel-Wert-Speicher zu reduzieren. DeepGEMM ist eine tiefgehende Anpassung der allgemeinen Matrizenmultiplikation. DeepEP adressiert die Kommunikationskosten in der Expert-Parallelisierung. TileKernels und TileLang vereinfachen die häufigen tile-basierten Berechnungen zu wieder verwendbaren Modulen. Die Namen dieser Kerne zeigen auch, dass DeepInfer keine einfache Verpackung bestehender Frameworks ist, sondern die von DeepSeek selbst getesteten Operatoren direkt nutzt.

Auf der parallelen Ebene unterstützt DeepInfer Attention DP und balanced CP sowie EP und EPLB in den MoE-Szenarien. DP verteilt verschiedene Anfragen auf unterschiedliche Geräte, CP teilt lange Sequenzen nach Kontext auf, während EP und EPLB die Lastverteilung der Expertenmodule im MoE-Modell verarbeiten. Für ein Großmodell-Framework hat die Wahl der Parallelstrategie direkten Einfluss darauf, ob die Nutzung mehrerer Karten vollständig ausgeschöpft werden kann. Wenn die Lastverteilung nicht gut gemacht wird, werden bestimmte Experten übermäßig genutzt, was dazu führt, dass einige Karten voll belastet sind und andere ungenutzt bleiben.

Auf der Scheduling-Ebene gibt es zwei Besonderheiten. Erstens ein asynchroner, kostengünstiger Batch-Scheduler, dessen Ziel es ist, bei unterschiedlichen Anfragetypen und Ankunftstimen einen hohen Durchsatz zu gewährleisten. Zweitens die batch-invariant Inference, also die Konstanz der Ausgabeergebnisse unabhängig davon, wie die Anfragen in Batches zusammengesetzt werden. Letzteres ist besonders wichtig für die Produktionsumgebung, da es das Risiko vermeidet, dass „dasselbe Problem auf eine andere Weise gestellt, unterschiedliche Ergebnisse erzielt“. Für Ingenieurteams, die reproduzierbare Ergebnisse benötigen, ist batch-invariant eine wichtige Eigenschaft, um die Fehlerbehebung zu reduzieren.

Bei der Decodierungsschrittgeschwindigkeit führt DeepInfer DSpark und confidence-scheduled Verification ein. Einfach gesagt: Zuerst werden mit dem Draft-Token schnell Kandidaten erstellt, anschließend wird die Verifizierungsphase mit konfidenzbasierter Planung durchgeführt, um zu vermeiden, dass jeder Schritt mit voller Genauigkeit neu berechnet wird. Gleichzeitig speichert SWA bounded replay nur begrenzte Teile des Kontexts, anstatt den gesamten Kontext neu vorzufüllen, wodurch die Menge der Vorberechnungen reduziert wird. Beide Maßnahmen dienen dazu, die Kosten für die Decodierung langer Kontexte zu senken.

Bei der Ausgabekontrolle unterstützt das Framework sicheres Sampling und strukturierte Ausgaben. Sicheres Sampling gewährleistet, dass Ergebnisse bei gleichen Eingaben und Parametern reproduzierbar sind; strukturierte Ausgaben unterstützen regex, JSON-Schemas und EBNF, was es dem Business Layer ermöglicht, die Modelle direkt zu verwenden. Strukturierte Ausgaben erfordern keine Formatprüfung nach der Modellgenerierung, was auch die Komplexität der API-Ebene reduziert.

Was die Hardware- und Konstruktionsanforderungen betrifft, so weist das README darauf hin, dass für die NVIDIA-Seite SM100-GPUs und CUDA 13 erforderlich sind, während Huawei-Seite Ascend 950 NPUs und CANN 9.2 benötigt. Die Konstruktionsumgebung erfordert Linux, GCC nicht unter 13.0 und Python 3.12. In Bezug auf die Abhängigkeiten dankt das README vLLM als Hauptgrundlage und berücksichtigt außerdem SGLang und TensorRT-LLM.

Verifizierung/Ergebnisse

Die aktuelle Verifizierung von DeepInfer stammt hauptsächlich aus dem Repository-自述 und Hot-Tracking-Daten, es fehlen noch unabhängige Bewertungen durch Dritte.

Aus Sicht der Popularität zeigt die etwa am 20. Oktober erzielte 10.900 Stimmen und 2000 Likes in HN, dass die Community sehr sensibel auf das Thema „DeepSeek’s offene Produktions-Framework“ reagiert. Die Diskussionen konzentrieren sich auf drei Aspekte: Ob es sich um einen Code-Dump oder eine echte kontinuierliche Open-Source-Entwicklung handelt; ob die in der README beschriebenen Produktionsanforderungen direkt auf externe Nutzer angewandt werden können; und welche Bedeutung dies für die DeepSeek-Ökologie hat. PithWire’s Kommentar ist der repräsentativste Kritikpunkt, da er beanstandet, dass die Anzahl der Likes und Commitments stark unterschiedlich sind.

Aus Sicht der Funktionsfähigkeit sind die von README aufgelisteten Anwendungsbereiche eher für großflächige Offline-Inferenz geeignet. Für ein vollständiges Online-Dienstesystem fehlen ihm noch wichtige Komponenten wie KV-Cache-Verwaltung, VE/Prefill/Decode-Analyse sowie Lastverteilung. Mit anderen Worten, DeepInfer ist eher ein „Inferenzmotor“ als eine „Inferenzdienstplattform“. Es gibt derzeit keine öffentlichen Vergleichsdaten von Drittanbietern, um seine Vorteile in Bezug auf Verzögerung und Durchsatz quantitativ zu bewerten. Man muss also warten, bis die Community oder DeepSeek weitere Testdaten veröffentlicht.

Schwächen und Grenzen

Erstens ist die Codeform nur eine Zusammenstellung von Daten („dump“) statt einer vollständigen Entwicklungsgeschichte. Die drei Commits zeigen nicht den Design-Wandel, und es ist schwierig zu erkennen, welche Module noch ständig aktualisiert werden. Für externe Entwickler, die langfristig folgen und Code beitragen möchten, ist dies keine ideale Möglichkeit.

Zweitens kann die Produktionsqualität nicht einfach übertragen werden. Im Repository heißt es, dass DeepInfer die Produktionsdienste von DeepSeek unterstützt, doch die Online-Umgebung von DeepSeek enthält sicherlich nicht öffentlich zugängliche Komponenten wie Scheduling, Monitoring, Fehlerbehebung und Lastverteilung. Wenn externe Nutzer DeepInfer als fertiges Produkt verwenden, unterschätzen sie die Anschlusskosten.

Drittens ist der Hardwareaufwand nicht gering. SM100 GPUs und CUDA 13 gehören zu der neuen NVIDIA-Plattform, während Ascend 950 und CANN 9.2 spezielle Hardwarestacks sind. Normalerweise verfügen Entwickler nicht über diese Geräte, was die Validierungskosten erhöht.

Viertens sind fehlende Komponenten explizit aufgelistet. Module wie KV-Cache, VE/Prefill/Decode-Analyse und Lastverteilung tauchen noch nicht in dem öffentlichen Repository auf, wie das README zugibt. Dies bedeutet, dass DeepInfer momentan eher als Ausgangspunkt für Forschung oder Offline-Batch-Verarbeitung geeignet ist, nicht als Endpunkt für direkte Online-Dienste.

Fünftens sind Anzahl der Sterne und Fork-Namen eher Indikatoren für Popularität als für die Praxistauber. 10.900 Sterne zeigen nur, dass die Community Interesse hat, aber nicht, wie viele echte Anwendungen auf DeepInfer laufen. Bei der Bewertung, ob es eingeführt wird, muss zwischen Popularität und Reife unterschieden werden.

Sechstens bedeutet vLLM als Hauptbasis, dass das Upgrades-Tempo von den Quellen abhängt. Wenn es wesentliche Änderungen an den APIs von vLLM gibt, muss DeepInfer diese entsprechend anpassen. Die Unterstützung durch Huawei Ascend 950 und CANN 9.2 hängt von der Reife des Huawei-Softwarestacks ab. Im Vergleich zum NVIDIA-Kurs gibt es weniger verifizierte Beispiele in der Community, und die tatsächliche Verwendbarkeit muss separat getestet werden.

Schlussfolgerung

DeepInfer ist ein Versuch von DeepSeek, seine eigene Erfahrung in der Produktionsinferenz zu veröffentlichen. Es integriert Optimierung des Kerns, parallele Strategien, Scheduling-Logik und Ausgabeeinschränkungen in einem Rahmen, was für diejenigen, die sich mit dem Inferenzengineering von LLMs beschäftigen, eine hochinformative Referenzlösung darstellt. Die öffentliche Version ist jedoch eher wie eine Codeversion ohne die notwendigen Komponenten für einen vollständigen Dienst und in Form eines „einmaligen Dumps“, was es für externe Entwickler schwer macht, den Fortschritt zu verfolgen.

Für Forscher und Technikteams liegt der Wert von DeepInfer darin, dass es zeigt, welche Probleme ein Large-Scale Produktions-Reasoning-Framework berücksichtigen sollte und wo man optimieren kann. Für diejenigen, die direkt in die Praxis umsetzen möchten, ist eine pragmatischere Vorgehensweise es, es als Ausgangspunkt für Offline-Reasoning oder interne Prototypen zu verwenden, anstatt einen bestehenden, etablierten Servicestack zu ersetzen. Es kann nicht direkt in die Produktionsumgebung eingeführt werden, aber es macht die ingenieurtechnischen Entscheidungen von DeepSeek im Bereich des Reasoning der Community zugänglich. Was später beobachtet werden sollte, ist, wann die entsprechenden Komponenten vollständig verfügbar sind und wann externe Beispiele für den tatsächlichen Einsatz auftauchen.

Wenn DeepSeek in Zukunft den Commit-Historien kontinuierlich aktualisieren, fehlende Servicekomponenten ergänzen und Vergleichsdaten mit Frameworks wie vLLM und SGLang veröffentlichen kann, könnte DeepInfer von einer beliebten Version zu einem langfristig abhängigen technischen Referenz werden. Bis dahin ist es am sichersten, die Entwicklung zu verfolgen, aber nicht übermäßig zu verehren.