DeepInfer durchgesehen: zwei Stellen im Code entscheiden, ob es bei uns läuft

Am 20. Oktober 2026 um 04:09:42 UTC hat DeepSeek den Inhalt seines neuen Repositories DeepInfer als einen einzigen Commit hochgeladen (Commit-Verlauf auf GitHub). Apache-2.0, am Abend des 20. Oktober drei Commits. Gemeint ist die Inferenz-Engine hinter DeepSeek V4.1 Flash, also die Schicht, die bei uns vLLM und llama.cpp ausfüllen (wie wir Inferenz beschleunigen). Wir haben den Klon gelesen, nichts davon installiert oder gebaut.

DeepInfer ist die Inferenz-Engine, mit der DeepSeek nach eigener Angabe sein Modell V4.1 Flash im Produktivbetrieb ausliefert. Die offene Fassung unter Apache-2.0 enthält den Offline-Kern: eine Einstiegsklasse ohne Server, verteilte Ausführung, spekulative Decodierung und strukturierte Ausgaben. KV-Speicher und Lastverteiler fehlen, und das Modellregister kennt nur eine Architektur, DeepSeek V4.1 Flash.

Stand 5. November 2026: Die Aussagen über unsere Strecke gelten für den 20. Oktober. Seit dem 4. November testen wir auf unserem Produktionshost zusätzlich DeepSeek V4.1 Flash, aber mit der Engine Strata und nicht mit DeepInfer. Dort liegen damit DeepSeek-Gewichte, und das Gateway führt einen Namen mit deepseek. Am Befund zum Code ändert das nichts, DeepInfer lädt bei uns weiterhin nichts, weil die Hardwareprüfung die Karten ablehnt. Das Repository hat sich bewegt: am 5. November 25.434 Sterne und 3.108 Forks (GitHub-API), sechs Commits, zuletzt am 3. November mit der Meldung „update V4.1 Flash Q&A to v0.2“. Die Zitate unten stammen aus dieser aktuellen Fassung.

Am Abend des 20. Oktober stand das Repository bei rund 11.450 Sternen und 1.016 Forks, mit 95 Anträgen von 40 Autoren (unsere Ablesung vom 20. Oktober, 20:06 und 20:26 UTC) und ohne einen einzigen gemergten. Die Issue-Schaltfläche ist abgeschaltet. Gemergt wird inzwischen, etwa Antrag #157 am 21. Oktober. Zur Berichterstattung: Die Primärquellen sind die README und die Einsatz-Dokumentation im Repository, die Fachpresse zog nach, zum Beispiel TechNode am 21. Oktober. Eine Bloomberg-Meldung zu DeepInfer haben wir nicht gefunden und nennen sie deshalb nicht.

Was im Release steht und was nicht

Geliefert wird der Offline-Kern: eine Einstiegsklasse für Inferenz ohne Server, verteilte Ausführung, spekulative Decodierung, strukturierte Ausgaben. Einen HTTP-Server gibt es im Paket nicht, dazu keinen KV-Speicher und keinen Lastverteiler. Die Einsatz-Dokumentation sagt das selbst: Die Komponenten für KV-Cache-Verwaltung und Lastverteilung seien eng mit der internen Infrastruktur verknüpft und deshalb noch nicht vollständig offen.

Getestet wird im Repository durchaus. Unter tests/ liegen 19 Python-Dateien, darunter ein KL-Test, der schrittweise Decode-Logprobs gegen einen vollständigen Prefill vergleicht, ein Test auf Batch-Invarianz, eine Regressionsdatei offline_decode_ppl.json mit festgeschriebenen Perplexity-Werten und ein Test für unerlaubte CUDA-Synchronisationspunkte. Eine Pipeline zum Ausführen fehlt: Ein Ordner .github/ gibt es im Erstcommit nicht, und die Testmarker in pyproject.toml (ci, ci_npu, benchmark) verweisen auf Pipelines, die nicht mitgeliefert werden.

Wer so etwas in ein bestehendes Image setzt, sollte das Build-Skript lesen. build.sh installiert zum Schluss nvidia-nccl-cu13==2.32.3 zwangsweise neu, in einem laufenden Inferenz-Image also ein Austausch der Kommunikationsbibliothek unter der laufenden Engine.

Zwei Stellen im Code entscheiden

Die erste ist eine Hardwareprüfung. Die Funktion für die Obergrenze der Rechenleistung steht in deep_cluster/hardware/device.py und kennt zwei Fälle (hier gekürzt):

def get_bf16_tflops_limit() -> int:
    if accelerator_kind() == "ascend":
        return 432
    if is_sm_major_10():          # capability[0] == 10
        return 2500 if arm else 2250
    raise RuntimeError("unknown GPU type")

Aufgerufen wird sie in Zeile 304 von deepinfer/engine/llm_engine.py beim Bauen des Statistik-Loggers im Konstruktor der Engine. Die README nennt als unterstützte Plattformen „NVIDIA SM100 GPUs“ und Huawei Ascend 950. Unsere vier Karten melden Compute-Fähigkeit 12.0, Consumer-Blackwell an PCIe-Bussen, je 32.607 MiB (Abfrage am Produktionshost, 20. Oktober 2026). Auf dieser Hardware würde die Engine nach dem Code eine Ausnahme werfen, bevor das erste Token entsteht. Ausprobiert haben wir das nicht, es ist eine Lesart des Quellcodes.

Die zweite Stelle ist das Modellregister, und sie wiegt für uns schwerer. Die Tabelle _MODELS in deepinfer/model_executor/models/__init__.py enthält genau einen Eintrag, DeepseekV41ForCausalLM, und die README listet als unterstütztes Modell nur DeepSeek-V4.1-Flash. Dazu unsere Messung vom 20. Oktober am Produktionshost: In der Gateway-Konfiguration unseres LiteLLM-Hosts standen 16 Modellnamen, keiner davon enthielt deepseek, und alle zeigten auf eigene Karten. Der einzige laufende Inferenzprozess startete sein Modell mit --reasoning-parser qwen3 --tool-call-parser qwen3_xml, fuhr acht Folgen gleichzeitig und spekulativ mit drei Tokens. DeepSeek-Gewichte lagen auf der Maschine nicht, die offene Datei dieser Klasse wäre 510,3 GB groß. DeepInfer war damit kein Angebot für unsere Strecke, es lädt unser Modell nicht (unsere vLLM-Strecke im Betrieb).

Die Verfahren stecken seit Wochen in unserem Pin

DeepSeek verlinkt in seiner Dokumentation Anträge aus dem vLLM-Projekt. Wir haben am 20. Oktober mit einer git-Vorfahrenprüfung gemessen, was davon in unserem Stand v0.32.0 enthalten war (Pin seit 18. Oktober). Fünf der sechs namentlich genannten Verfahren sind drin. Die Merge-Daten haben wir am 5. November gegen die GitHub-API gegengelesen: die DSpark-Korrektur vom 17. September (#57432), das Encoder-Replay vom 18. September (#56227), die TopK-Auswahl vom 13. September (#56464), Mega-Attention mit NVFP4-komprimiertem KV-Cache vom 16. September (#56935) und der asynchrone Vorabzugriff auf die Engram-Tabelle vom 13. September (#56512). Der Decoder-Zweig (#56752) wurde ohne Merge geschlossen, im Sammelantrag #57448 steht er trotzdem abgehakt. Diese Abhakmechanik ist der nützlichste Fund hier, sie gilt für jede Checkliste, die wir Übernahme nennen. Einen neueren Stand gibt es inzwischen: vLLM hat am 2. November v0.33.0rc3 veröffentlicht (ein Release ohne Endversion v0.33.0, Stand 5. November), unsere Aussage bezieht sich auf v0.32.0.

Die zweite Rechnung gilt der Herkunft. Die README sagt selbst, DeepInfer sei ursprünglich vor allem auf vLLM aufgebaut worden, mit Anleihen bei SGLang und TensorRT-LLM. Den Vermerk über abgeleiteten Code tragen 23 von 270 Python-Dateien. Gegen v0.32.0 gerechnet blieben davon am 20. Oktober 748 von 6.817 Zeilen wörtlich gleich, das sind elf Prozent. Das ist unser Vergleich, das Skript dazu haben wir nicht veröffentlicht. DeepInfer ist damit eine eigene Engine auf einem älteren Gerüst. Wer sie betreibt, trägt Sicherheits- und Bugfix-Pflege ab Tag eins selbst.

Die publizierten Zahlen, nachgerechnet

DeepSeek nennt in der Einsatz-Dokumentation 155 Billionen Tokens pro Tag für einen Cluster und 38 US-Dollar Umsatz je GPU-Stunde zu Preisen der Nebenzeit, beides ohne Messprotokoll. Unsere Überschlagsrechnung dazu: Am günstigsten Punkt der publizierten Decode-Kurve, rund 26.300 Tokens pro Sekunde und GPU (am Diagramm abgelesen), ergeben 155 Billionen Tokens am Tag etwa 68.200 Karten. Mit dem Wert 13.730 aus der Messtabelle bei 60 Folgen je Rang sind es etwa 130.700. Das Dokument sagt nicht, ob die Tageszahl Eingabe-Tokens aus dem Cache mitzählt. Die Rechnung ist deshalb nur eine Größenordnung, eine Anlage im sechs- bis siebenstelligen Kartenbereich, und kein Befund.

Eine Spanne, die zu dem Thema die Runde machte, steht so nicht in der Dokumentation. Der Vorteil des breiten Expert-Parallelbetriebs (EP64) gegenüber acht Rängen (EP8) wird mit 25 bis 35 Prozent angegeben, und im Text der Dokumentation steht dazu nur der Hinweis auf ein Diagramm. Wir haben die Punkte im Diagramm der Dokumentation abgelesen, auf etwa einen Prozentpunkt genau: Bei 256 Anfragen je Rang sind es rund 6 Prozent, bei 128 rund 19, bei 64 rund 24, bei 32 rund 35, bei 16 rund 37 und bei 8 rund 39 Prozent. Die Spanne von 25 bis 35 Prozent liegt damit im Mittelteil der Kurve, und am Betriebspunkt von rund 60 Folgen je Rang, den DeepSeek selbst nennt, sind es etwa 24 Prozent. Die Ablesung ist von uns, nicht von DeepSeek, und die Kurve gilt für Kontext 131.072 mit festem Draft von drei Tokens.

Sauber belegt ist die spekulative Verifikation, alle Werte wörtlich aus der Messtabelle der Dokumentation:

Ebenfalls belegt, und in Meldungen oft verkürzt: Das begrenzte Wiederaufgreifen (SWA bounded replay) rechnet in den Decoder-Schichten nur die letzten 128 Tokens des Prompts neu, statt exakt die letzten 2.560 Tokens durch 20 Schichten zu schicken, und halbiert die Prefill-Rechnung damit nach DeepSeek beinahe. Kleiner als oft gelesen ist auch der Abstand der offenen Kernel zur internen Fassung: Die offene Version von FlashMLA ist im Decode-Kernel um 5 bis 10 Prozent langsamer, weil eine handoptimierte SASS-Optimierung fehlt, die Abweichung Ende-zu-Ende liegt laut Dokumentation bei höchstens 5 Prozent.

Was wir daraus machen

Am Gateway ändert sich wegen DeepInfer nichts, und das ist das Ergebnis. Zu kaufen gibt es für diesen Fall nichts, eine Anlage in dieser Baugröße ist bei uns nicht geplant, und unsere produktive Strecke lief am 20. Oktober mit einem Modellbetrieb, den diese Engine nicht lädt. Offen bleibt eine kostenlose Beobachtung: der Sammelantrag #57448 in vLLM, der am 5. November noch offen ist. Wir prüfen dort, ob weitere Verfahren in unseren nächsten Pin kommen.

Bleibt das Handwerk, und das ist übertragbar. Ein Abgleich von Decode-Logprobs gegen einen vollständigen Prefill, eine Regressionsdatei mit festgeschriebenen Perplexity-Werten und ein Test, der unerlaubte Synchronisationspunkte meldet, sind Muster für jede Strecke, unabhängig vom Modell. Unsere eigene Qualitätssicherung an der Lane kennt bisher keinen dieser drei Tests (unsere 27B-Strecke im Eigenbetrieb). Die Parallelität im Betrieb beschreibt DeepSeek selbst: Decode läuft mit EP64 bis 128 und DP64 bis 128, Tensor-Parallelismus setzt DeepSeek nicht ein, solange das Modell in den Speicher passt und die Latenz stimmt. Diese Breite braucht Decode-Gruppen mit 64 bis 128 GPUs und Last, die sie füllt. Vier Karten an PCIe bilden das nicht ab (zwei DGX Spark im Eigenversuch).

Einen anderen Blick auf dieselbe Modellfamilie wirft DeepSeek 1017: Dort geht es um die ausgetauschten Gewichte und ihre Kosten je Aufgabe laut Artificial Analysis, hier um den veröffentlichten Engine-Code und die Frage, ob er bei uns läuft. Alle Beiträge zum Betrieb eigener Modelle bündelt das Thema KI im Betrieb. Wenn Sie vor der Frage stehen, welche Engine für Ihre Hardware und Ihr Modell trägt, ist das der Kern unserer Arbeit an firmeneigenen Sprachmodellen.

Weiterführende Quellen

Eigene Messungen (Produktionshost, Quellcode-Lesung, vLLM-Vergleich) sind im Text als solche gekennzeichnet. Ein Video liegt dem Beitrag nicht zugrunde.

• Repository deepseek-ai/DeepInfer
• Commit-Verlauf, Erstcommit vom 20. Oktober 2026, 04:09:42 UTC
• Einsatz-Dokumentation im Repository, Quelle aller zitierten DeepSeek-Zahlen
• README mit unterstützten Plattformen und Herkunft aus vLLM
• TechNode, 21. Oktober 2026: DeepSeek open-sources inference framework
• Sammelantrag #57448 in vLLM mit der Abhakliste der Verfahren
• Antrag #56752 in vLLM, ohne Merge geschlossen