Was ist DeepInfer? DeepSeeks Inferenz-Engine und die Teile, die nicht mit ausgeliefert wurden

DeepInfer ist das Inferenz-Framework, das DeepSeek am 16. Oktober 2026 unter Apache-2.0 veröffentlichte, und es bedient genau ein Modell: DeepSeek-V4.1-Flash, mit DeepSeek-V4.1-Flash-1017 als Standard-Checkpoint. Diese Beschränkung auf ein einziges Modell ist das Erste, was man verstehen muss, denn sie erklärt fast alles andere im Repository. Dies ist kein allgemeines Serving-Framework, das zufällig eine DeepSeek-Konfiguration enthält. Es ist der Codepfad, den DeepSeek in der Produktion ausführt, heruntergekürzt auf die Teile, die sich verallgemeinern lassen, und es ist ehrlich bezüglich der Kürzung: Die eigene Liste der README dessen, was ein vollständiger Inferenzdienst benötigt und was dieses Release nicht enthält, nennt ein KV-Cache-System, VE/Prefill/Decode-Disaggregation und Lastverteilung über datenparallele Replikate. Was man erhält, ist der Rechenpfad – Kernel, Parallelität, spekulative Dekodierung, Scheduling, strukturierte Ausgabe. Was man nicht erhält, ist die Speicher- und Routing-Schicht, die den Rechenpfad im großen Maßstab kostengünstig zu betreiben macht. DeepSeek nennt den Grund: Diese Komponenten sind eng an die interne Infrastruktur gekoppelt, daher wird das Design in einem veröffentlichten Write-up beschrieben, während der Code intern bleibt.

Was ist eigentlich im Repository?

Die veröffentlichte Funktionsliste liest sich wie ein Rundgang durch die Engpässe beim Ausliefern eines großen Mixture-of-Experts-Modells. Da sind die Kernel-Bibliotheken, die DeepSeek zuvor veröffentlicht hat – FlashMLA für Attention, DeepGEMM für die Matrixmultiplikationen, DeepEP für expertenparallele Kommunikation, plus TileKernels und DeepSelect. Da ist das Parallelisierungsschema: Attention läuft als Datenparallelismus mit ausgewogenem Kontextparallelismus, die MoE-Hälfte läuft als Expertenparallelismus mit einem expertenparallelen Load Balancer. Da ist DSpark, der Stack für spekulative Dekodierung, mit Verifikationslängen, die geplant statt fest vorgegeben sind. Da ist SWA Bounded Replay, der Mechanismus, der verhindert, dass ein Sliding-Window-Attention-Cache bei jedem Cache-Miss eine vollständige Neuberechnung erzwingt. Da sind asynchrone Batch-Planung, batchinvariante Inferenz mit deterministischem Sampling und strukturierte Ausgaben, die durch reguläre Ausdrücke, JSON-Schema oder EBNF eingeschränkt sind.

Der Einstiegspunkt ist bewusst klein gehalten. Nachdem DEEPINFER_ACCELERATOR auf nvidia oder das Ascend-Äquivalent gesetzt und build.sh ausgeführt wurde, enthält das Repository examples/offline_inference.py, das den Standard-Checkpoint von Anfang bis Ende ausführt. DEEPINFER_HF_MODEL_DIR verweist es auf ein anderes Verzeichnis mit Gewichten. Die veröffentlichten Benchmarks wurden auf vier SM100-GPUs für Prefill und 64 SM100-GPUs für Decode gemessen; das entspricht der Form der Bereitstellung, für die die Engine geschrieben wurde, und nicht einer Demo im Laptop-Format.

Die README sagt auch, woher der Code stammt, was man vor der Lektüre wissen sollte. Die Engine wurde ursprünglich hauptsächlich auf vLLM aufgebaut, wobei die Designinspiration von SGLang und TensorRT-LLM kam. Diese Abstammung zeigt sich in der Struktur – der Scheduler, die Paged-Attention-Schnittstelle und der Sampling-Pfad werden jedem bekannt vorkommen, der diese Projekte gelesen hat – und sie erklärt, warum die Veröffentlichung ein Fork eines Serving-Stacks und keine von Grund auf geschriebene Architektur ist. Was DeepSeek hinzugefügt hat, ist der Teil, der spezifisch für sein eigenes Modell ist: das disaggregierte Deployment, die breite Expertenparallelität mit ihrem Balancer, das Sliding-Window-Replay und DSpark.

Was es nicht enthält – und warum das wichtiger ist

Die drei fehlenden Teile sind keine kleinen Auslassungen. Jedes davon ist ein System, das existieren muss, bevor die Engine Produktionsverkehr bedient, und jedes ist auf eine andere Weise teuer.

• Das KV-Cache-System.Prefix-Wiederverwendung ist der Punkt, an dem in einer Chat-Workload das meiste Geld steckt, denn ein Cache-Treffer ersetzt einen Prefill. Ohne einen Cache-Speicher berechnet jede Anfrage ihren Prompt neu. DeepSeeks eigene Ausführungen beschreiben den verwendeten Speicher: ein dedizierter 3FS-Cluster statt lokalem Host-Speicher, gerade damit jede Prefill-Maschine jeden Prefix treffen kann und die Cache-Kapazität unabhängig von der Rechenleistung skaliert werden kann.

• VE/Prefill/Decode-Disaggregation. Die README merkt an, dass der Großteil der Engine-seitigen Funktionalität bereits im Release vorhanden ist; was fehlt, ist das Deployment. Die Disaggregation von Vision-Encoder, Prefill und Decode ermöglicht es, jede Stufe an ihrem eigenen Engpass auszurichten und die Zeit bis zum ersten Token getrennt von der Zeit zwischen den Token zu steuern. Das ist eine Infrastrukturentscheidung, kein Flag.

• Lastverteilung über datenparallele Replikate hinweg. DeepSeek betreibt vier Balancer – Prefill, Decode, Vision-Encoder und Expert-Parallel – und beschreibt alle vier in der Dokumentation. Keine der Routing-Logik wird mitgeliefert. Ohne sie ist ein Replikat-Verbund nur so gut wie der Router, den man ihm voranstellt, und ein naiver Round-Robin-Router zerstört die Cache-Trefferquote, zu deren Schutz der Store gebaut wurde.

Im Zusammenhang gelesen verrät die Auslassung, um welche Art von Artefakt es sich handelt. DeepInfer ist eine Referenzimplementierung des Berechnungspfads, veröffentlicht, damit die Arbeit an Kernel und Scheduling eingesehen und wiederverwendet werden kann – keine Distribution, die man installiert und auf die man Traffic lenkt.

Das Hardware-Gate ist der eigentliche Filter

DeepInfer richtet sich an NVIDIA SM100 und Huawei Ascend 950. Es gibt keinen Ampere-Pfad und keinen Hopper-Pfad, was die meisten GPUs in den meisten Clustern heutzutage ausschließt. Der Rest der Toolchain ist ebenso spezifisch: nur Linux, GCC 13 oder neuer, Python 3.12, CUDA 13 für NVIDIA oder CANN 9.2 für Ascend. Und es gibt überhaupt keine Releases – das Repository hatte null veröffentlichte Releases, als es am 21. Oktober 2026 gelesen wurde, es gibt also nichts zum Herunterladen und nichts zum Pinnen. Man klont es und baut es gegen die eigene Toolchain.

Diese Kombination ist ungewöhnlich für eine Open-Source-Veröffentlichung mit so viel Aufmerksamkeit, und man sollte sie am besten als präzise Aussage zum Umfang lesen und nicht als Versehen. Die Kernel im Repository sind für einen bestimmten Befehlssatz und einen bestimmten Interconnect geschrieben; die Zahlen in der README stammen von dieser Hardware. Den Berechnungspfad eine Generation nach unten zu portieren, ist genau die Art von Arbeit, die eine Community schnell erledigt und die eine Engineering-Organisation nicht zusagen kann. Innerhalb von Tagen nach der Veröffentlichung erschien auf GitHub ein Drittanbieter-Port für ältere NVIDIA-Komponenten, was ein nützliches Signal für die Nachfrage ist und keinerlei Signal dafür, ob die veröffentlichten Durchsatzwerte den Port überstehen.

Die Deployment-Form, die DeepSeek tatsächlich betreibt

Die Architekturbeschreibung ist der Ort, an dem die Annahmen des Repositorys erkennbar werden. Das System ist in einen Vision-Encoder, Prefill und Decode sowie dedizierte Storage-Knoten aufgeteilt. Prefill verwendet Experten-Parallelität von 2 bis 8 mit passender Daten-Parallelität und wählt die kleinste Konfiguration, die HBM zulässt. Decode geht den entgegengesetzten Weg: Experten-Parallelität und Daten-Parallelität von 64 bis 128, was DeepSeek als Wide-EP bezeichnet, wobei die größte Konfiguration verwendet wird, die die verfügbaren GPUs zulassen. Tensor-Parallelität und Kontext-Parallelität werden überhaupt nicht verwendet. Der Vision-Encoder läuft mit einer GPU pro Instanz, wobei günstigere GPUs empfohlen werden, weil der Encoder nicht der Kostentreiber ist.

Die kleinste sinnvolle Bereitstellung ergibt sich aus diesen Zahlen. Eine Prefill-GPU und eine Decode-GPU werden laufen, und in der Praxis ist das Verhältnis zwischen den beiden Pools ungefähr eins zu eins. Da Decode jedoch 64 GPUs oder mehr benötigt, um den Expert-Parallel-Vorteil zu erzielen, ist die kleinste effiziente Einheit 64 Prefill-GPUs plus 64 Decode-GPUs. Diese Zahl sollte man sich merken, wenn man eine Aussage über die Effizienz von DeepInfer liest: Die Werte beschreiben eine Bereitstellung mit 128 GPUs, und die Hälfte davon ist eine Stufe.

Die Aufteilung von Prefill und Decode auf verschiedene Rechenzentren ist technisch möglich, weil DeepSeek-V4.1-Flash seinen KV-Cache erheblich komprimiert, und DeepSeeks eigene Bereitstellung platziert Inferenzknoten tatsächlich in verschiedenen, aber benachbarten Rechenzentren. Das Budget liegt bei etwa 400 Gbit/s Interconnect pro acht GPUs, und der Bericht ist offen hinsichtlich der Zuverlässigkeitskosten – Glasfaserkabel zwischen Gebäuden lassen sich leicht durchtrennen.

Warum ist die Dekodierung so weit verbreitet?

Breite Expertenparallelität ist die folgenreichste Entscheidung im Design, und sie wird leicht als Skalierungstrick missverstanden. In einer Mixture-of-Experts-Schicht berührt jedes Token nur eine kleine Anzahl von Experten, daher werden die Kosten eines Decode-Schritts vom Verschieben von Expertengewichten und -aktivierungen dominiert und nicht von der arithmetischen Intensität. Die Verteilung der Experten auf 64 oder 128 GPUs reduziert den Speicherverkehr pro Schritt, den jede GPU beisteuert, was die Tokens pro Sekunde erhöht, wenn – und das ist die Bedingung – die Last über die Experten hinweg gleichmäßig bleibt. Dafür ist der Load Balancer für Expertenparallelität da.

DeepSeeks Einstellungen sind konkret genug, um sie zu kopieren. Für Prefill hält jede GPU vier redundante Experten zusätzlich zu den eigenen, die Statistiken werden über ein Fenster von 100 Schritten gesammelt und die Experten alle 1.000 Schritte neu zugewiesen, wobei die Gewichte innerhalb der Gruppe über den gemeinsam genutzten NVLink-Speicher gemischt werden. Die gemessene Ungleichverteilung – langsamster Rank geteilt durch den Mittelwert – ergab 1,074 für eine EP4/DP4-Konfiguration und 1,045 für EP2/DP2. Beim Decode ziehen sich die Einstellungen: ein redundanter Experte pro GPU, ein Statistikfenster von 1.000 Schritten, Neuzuweisung alle 10.000 Schritte und eine gemessene Ungleichverteilung von 1,090. Der Unterschied zwischen beiden ist der Punkt. Prefill sieht stoßartige, heterogene Arbeit und braucht schnelles Rebalancing; Decode sieht einen gleichmäßigen Strom und kann sich ein langes Fenster leisten, daher wird selten rebalanciert und für dieses Privileg fast nichts bezahlt.

Die Routing-Seite hat denselben Charakter. Prefill-Anfragen werden nach der Gesamtkontextlänge in vier Stufen eingeteilt – unter 16K, 16 bis 64K, 64 bis 256K und 256K und mehr –, und Engines werden den Stufen entsprechend ihrem Anteil am Rechenbedarf in der vorherigen Runde zugewiesen. Innerhalb einer GPU ist die Chunk-Größe für jeden Prefill-Schritt nicht fest: Ein angepasstes quadratisches Kostenmodell sagt voraus, wie lange ein Schritt dauern wird, gegeben die Anzahl der Sequenztokens und den bereits berechneten Prefix, und der Scheduler sucht die größte Chunk-Größe, die in ein Budget von 32.768 Tokens innerhalb der verbleibenden Zeit passt. Der Decode-Balancer gleicht zwei Dimensionen gleichzeitig aus, Anfrageanzahl und gesamte KV-Cache-Länge, und schickt kurze Anfragen an GPUs mit geringer Nebenläufigkeit und langem Cache sowie lange Anfragen an GPUs mit kleinem Cache. DeepSeeks eigene Zusammenfassung, wie viel all das bringt: etwa 80 Prozent eines perfekt ausbalancierten Offline-Benchmarks.

Der Cache und die Drei-Tage-Frage

Der KV-Cache liegt auf einem dedizierten 3FS-Cluster und nicht im lokalen Hostspeicher; diese Entscheidung bestimmt den Rest des Speicherdesigns. Die Daten werden mit 10+2-Erasure-Coding gespeichert, sodass jede Coding-Gruppe zwei gleichzeitige Knotenausfälle übersteht; bei einem Lesevorgang werden Anfragen an alle 11 Knoten der Gruppe gesendet, und beliebige 10 Antworten reichen zum Dekodieren aus. Auf jedem Speicherknoten läuft ein Garbage-Collection-Worker, der bei Überschreiten einer Watermark nach LRU verdrängt. Der empfohlene Server verfügt über 20 Solid-State-Drives mit jeweils 30,73 TB und erreicht mindestens 40 GB/s Lese- und 5 GB/s Schreibdurchsatz; er ist so dimensioniert, dass pro Server etwa 24 Stunden Daten vorgehalten werden. In der Praxis bietet der Cluster etwa 14,4 TB logischen Cache pro online befindlicher GPU, wobei die physische Kapazität darüber liegt.

Die Verweildauer ist der Punkt, an dem der Trade-off sichtbar wird. Auf der Cache-Seite gibt es keine Ablauflogik; die TTL wird auf der Speicherseite festgelegt – auf drei Tage für Agenten-Traffic und sieben Tage für Chatbot-Traffic, in einem Cluster mit rund 100 Petabyte Solid-State-Speicher. Die Aufteilung existiert, weil Chatbot-Traffic einen viel schwereren langen Tail an Hits hat – ein kleiner Teil des Caches wird viele Male gelesen, sodass sein Verlust die Gesamt-Hit-Rate stärker kostet, als das Volumen vermuten lässt. DeepSeeks gemessene Kosten dafür, die Chatbot-Aufbewahrung auf drei Tage zu kürzen, betragen 0,5 bis 1 Prozent der Cache-Hit-Rate. Das ist eine kleine Zahl, die zufällig eine große Menge neu berechneten Prefills repräsentiert.

Sliding-Window-Attention erhält einen separaten Cache mit anderen Regeln. Der SWA-Cache gelangt nicht in die Paged Blocks; jede Sequenz belegt einen Slot fester Größe im Hostspeicher, und bei DeepSeek-V4.1-Flash sind die gespeicherten Layer die ersten 20. Nur dieser Bereich bleibt erhalten — 20 Layer × 134 Token × 528 Byte, also 1.415.040 Byte pro Sequenz in einem MXFP8-Format. Nichts geht an den Storage-Cluster; es bleibt im Speicher der Maschine, die es erzeugt hat, wobei ein In-Memory-Verzeichnis festhält, welche Maschine was hält, und ein maschinenübergreifender Treffer es über ein 400-Gbps-VLAN zurückholt.

Die beiden Mechanismen, die die Schlagzeilenwerte erzeugen

Bounded Replay ist die interessantere der beiden Varianten, weil es unbegrenzte Kosten in konstante Kosten verwandelt. Normalerweise bedeutet ein Sliding-Window-Cache-Miss, dass das Fenster von Anfang an neu berechnet werden muss, und die Kosten wachsen mit der Kontextlänge und der Anzahl der Layer. DeepSeek berechnet stattdessen nur die jüngsten 128 Token neu und schneidet das Attention-Fenster auf dieses Segment zu, wodurch ein approximierter SWA-Cache zu einem festen Preis entsteht. Auf der Encoder-Seite entkoppelt dies die Trefferlänge des Prefix-Cache vollständig vom SWA-Cache: Fehlt der SWA-Cache, werden die letzten 128 Token des Treffer-Präfixes erneut abgespielt, während der Block-Cache unberührt wiederverwendet wird.

Auf der Decoder-Seite ist die Einsparung groß. In dieser Architektur wird der Block-Cache der Decoder-Schichten aus dem Hidden State der letzten Encoder-Schicht projiziert, sodass pro Schicht nur der SWA-Cache des Decoders berechnet werden muss – und ihn exakt zu rekonstruieren würde bedeuten, bei jedem Prefill die letzten 2.560 Tokens durch 20 Decoder-Schichten zu schicken. Stattdessen 128 Tokens erneut abzuspielen und das Ergebnis nur für die Dekodierung zu verwenden, anstatt es in den Prefix-Cache gelangen zu lassen, halbiert die gesamte Prefill-Berechnung nahezu. Diese eine Änderung ist mehr wert als die meisten Kernel-Optimierungen, und sie ist die Art von Sache, die nur ein Team tun kann, das die Modellarchitektur besitzt.

Der Beitrag von DSpark ist kleiner und konventioneller. Draft-Token haben je nach Anfrage und Position unterschiedliche Akzeptanzwahrscheinlichkeiten, daher verschwendet die Verifizierung von fest fünf Drafts pro Schritt Rechenleistung für Token, die abgelehnt werden. Ein Confidence-Head sagt die Akzeptanzrate jedes Draft-Tokens voraus, und der Scheduler sortiert die Drafts nach erwartetem Ertrag und verifiziert nur das Präfix, das den Durchsatz maximiert. Im Produktivbetrieb erzeugt das Draft-Modell weiterhin fünf Token pro Schritt; die verifizierte Anzahl sinkt von 5,00 auf zwischen 3,2 und 4,4 – eine Reduktion um etwa 30 Prozent –, während sich die akzeptierte Länge kaum ändert: 3,29 gegenüber 3,20. Aus EP64/DP64-Benchmark-Daten abgelesen ergibt das 4 bis 7 Prozent mehr Durchsatz bei rund 60 gleichzeitigen Sequenzen pro Rank. Bei genau 60 steigt der Durchsatz pro Rank von 13.730 auf 14.466 Token pro Sekunde. Unter etwa 16 gleichzeitigen Sequenzen ist die Technik ein kleiner Nettoverlust, was man wissen sollte, bevor man sie für ein Deployment mit geringem Traffic einsetzt.

Was die Zahl von 155 Billionen bedeutet

Die am häufigsten zitierte Zahl zu diesem Release ist ein einzelner Cluster, der 155 Billionen Tokens pro Tag bei einem Gesamtumsatz von 38 US-Dollar pro GPU-Stunde zu Valley-Preisen bedient. Beide Hälften sind vom Anbieter gemeldet, und keine davon ist ein Benchmark, den man reproduzieren kann, was sie nicht uninteressant macht – eine Umsatzzahl pro GPU-Stunde ist eine genuin andere Art von Aussage als eine Durchsatzzahl, weil sie Auslastung, Preisgestaltung und Cache-Trefferquote in einer Zeile zusammenfasst. Sie ist auch die Zahl, die am wahrscheinlichsten ohne ihre Qualifikatoren zitiert wird, daher sollten die Qualifikatoren festgehalten werden: ein Cluster, Valley-Preise, Umsatz statt Kosten und aggregiert über Prefill, Decode und Vision-Encoder.

Zwei kleinere Offenlegungen sind unmittelbar nützlicher. Dem FlashMLA-Decoding-Kernel im öffentlichen Repository fehlt eine handoptimierte Assembly-Optimierung, die die interne Version besitzt, wodurch er isoliert betrachtet 5 bis 10 Prozent langsamer ist; DeepSeek gibt an, dass die End-to-End-Leistung höchstens 5 Prozent abweicht. Und das interne Draft-Modell für spekulatives Decoding ist neuer als das veröffentlichte, wobei der Leistungsunterschied als gering beschrieben wird. Beide Aussagen begründen eine Erwartung dazu, wie viel der veröffentlichten Leistung ein Dritter durch Kopieren des Codes erreichen kann, und die Antwort lautet: das Meiste, sofern die Hardware übereinstimmt.

Das Repository in seinem aktuellen Zustand

Die obige Aufnahme wurde am 21. Oktober 2026 erstellt und zeigt die Seite mit 16,3k Sternen. Die am selben Tag abgefragte GitHub-API lieferte 16.590 Sterne, 1.649 Forks und 176 offene Issues; Issues waren deaktiviert und Diskussionen wurden stattdessen an GitHub Discussions weitergeleitet. Die Zahl der Sterne ist seitdem weiter gestiegen, daher sollte jede hier genannte Zahl als Zeitstempel und nicht als Eigenschaft des Codes gelesen werden. Ein solcher Andrang in weniger als einer Woche sagt mehr über das Interesse am Serving-Stack von DeepSeek aus als über die Reife des Codes, und die Zahl der Null-Releases sagt den Rest.

Wenn Sie daran denken, es selbst auszuführen

Die ehrliche Zusammenfassung lautet: DeepInfer ist es wert, genau studiert zu werden, und zugleich schwer zu betreiben. Vier Fragen zeigen Ihnen, ob es zu Ihnen passt.

• Haben Sie SM100 oder Ascend 950? Alles andere in der Toolchain ergibt sich daraus. Ohne den richtigen Beschleuniger lassen sich die veröffentlichten Zahlen nicht übertragen, und die Community-Ports sind im Produktionsmaßstab nicht validiert.

• Können Sie 64 Decode-GPUs in einer Kommunikationsdomäne betreiben? Breite Expertenparallelität ist keine Optimierung, die man überspringen kann; sie ist die Konfiguration, für die der Decode-Pfad ausgelegt wurde. Unterhalb dieser Skala betreiben Sie ein anderes System mit demselben Namen.

• Verfügen Sie bereits über einen Prefix-Cache? Wenn nicht, vergleichen Sie den Compute-Pfad von DeepInfer mit einem konkurrierenden Stack, der bereits einen enthält, und der Vergleich wird schlechter ausfallen, als es das Design verdient.

• Können Sie es sich leisten, die Routing-Schicht zu schreiben? Prefill-Bucketing, Decode-Balancing und Experten-Neuzuweisung sind gut genug beschrieben, um sie nachzubauen, und sie nachzubauen ist wochenlange Arbeit, die das Repository nicht für Sie übernimmt.

Wenn Sie lieber nichts von den oben Genannten besitzen möchten

Für die meisten Teams lautet die praktische Frage nicht, wie DeepSeek-V4.1-Flash bereitgestellt wird, sondern wo man es aufruft. Das Modell ist über eine kompatible API verfügbar, ohne einen 128-GPU-Cluster aufzubauen oder einen Load Balancer neu zu implementieren, und es ist dasselbe Modell, dessen Architektur in diesem Artikel beschrieben wurde – dieselbe Kontextverarbeitung, dasselbe Verhalten bei strukturierter Ausgabe, ohne die Disaggregationsarbeit.

Der anzustellende Vergleich ist nicht der, welcher Motor abstrakt schneller ist, denn die veröffentlichten Zahlen sind vom Anbieter gemeldete Messungen auf Hardware, über die die meisten Leser nicht verfügen. Er besteht darin, ob die Arbeitslast eine ist, bei der eine Cache-TTL von 3 Tagen und ein Decode-Pool mit 64 GPUs den Preis ändern, oder eine, bei der eine Anfrage alle paar Sekunden über eine API einfach günstiger ist als jede der oben beschriebenen Operationen. Für den zweiten Fall – der die meisten Fälle umfasst – ist die richtige Menge DeepInfer, die man einsetzen sollte, keine, und die richtige Menge, die man lesen sollte, alles davon. Beginnen Sie mit der Modellseite DeepSeek V4.1 Flash, wenn Sie den Endpunkt möchten; beginnen Sie mit der README des Repositorys, wenn Sie wissen möchten, was der Endpunkt tut.