Wat is DeepInfer? De inferentie-engine van DeepSeek, en de onderdelen die niet zijn meegeleverd

DeepInfer is het inferentieframework dat DeepSeek op 16 oktober 2026 onder Apache-2.0 heeft gepubliceerd, en het serveert precies één model: DeepSeek-V4.1-Flash, met DeepSeek-V4.1-Flash-1017 als standaardcheckpoint. Dat het om één model gaat, is het eerste dat je moet begrijpen, want dat verklaart bijna al het overige in de repository. Dit is geen algemeen servingframework dat toevallig een DeepSeek-configuratie bevat. Het is het codepad dat DeepSeek in productie draait, teruggebracht tot de onderdelen die generaliseren, en het is eerlijk over die inkorting: de eigen lijst in de README van wat een complete inferentiedienst nodig heeft, en wat deze release niet bevat, noemt een KV-cachesysteem, VE/Prefill/Decode-disaggregatie en load balancing over data-parallelle replica's. Wat je krijgt, is het compute-pad — kernels, parallelverwerking, speculatieve decoding, scheduling en gestructureerde output. Wat je niet krijgt, is de opslag- en routeringslaag die het compute-pad goedkoop op schaal laat draaien. DeepSeek zegt waarom: die componenten zijn nauw verweven met de interne infrastructuur, dus het ontwerp wordt beschreven in een gepubliceerde write-up, terwijl de code intern blijft.

Wat zit er eigenlijk in de repository?

De gepubliceerde functielijst leest als een rondleiding langs de knelpunten bij het serveren van een groot mixture-of-expertsmodel. Er zijn de kernbibliotheken die DeepSeek eerder heeft uitgebracht: FlashMLA voor attention, DeepGEMM voor de matrixvermenigvuldigingen, DeepEP voor expert-parallelle communicatie, plus TileKernels en DeepSelect. Er is het parallellismeschema: attention draait als dataparallellisme met gebalanceerd contextparallellisme, de MoE-helft draait als expertparallellisme met een expert-parallelle load balancer. Er is DSpark, de speculative-decodingstack, met verificatielengtes die worden gepland in plaats van vastgelegd. Er is SWA bounded replay, het mechanisme dat voorkomt dat een sliding-window-attentioncache bij elke cachemiss een volledige herberekening afdwingt. Er is asynchrone batchplanning, batch-invariante inferentie met deterministische sampling, en gestructureerde uitvoer die wordt beperkt door regex, JSON-schema of EBNF.

Het toegangspunt is bewust klein. Na het instellen van DEEPINFER_ACCELERATOR op nvidia of het Ascend-equivalent en het uitvoeren van build.sh levert de repository examples/offline_inference.py, dat het standaardcheckpoint end-to-end uitvoert. DEEPINFER_HF_MODEL_DIR wijst het naar een andere map met gewichten. De gepubliceerde benchmarks zijn gemeten op vier SM100-GPU's voor prefill en 64 SM100-GPU's voor decode, wat de vorm is van de deployment waarvoor de engine is geschreven en niet een demo in laptopvorm.

De README vermeldt ook waar de code vandaan komt, wat het weten waard is voordat je hem leest. De engine was oorspronkelijk voornamelijk gebouwd op vLLM, met ontwerpinspiratie uit SGLang en TensorRT-LLM. Die afkomst is zichtbaar in de structuur — de scheduler, de paged-attention-interface en het sampling-pad zullen bekend voorkomen bij iedereen die die projecten heeft gelezen — en verklaart waarom de release een fork is van een serving-stack in plaats van een architectuur die vanaf nul is geschreven. Wat DeepSeek heeft toegevoegd, is het deel dat specifiek is voor zijn eigen model: de gedisaggregeerde deployment, het brede expert-parallellisme met de bijbehorende balancer, de sliding-window-replay en DSpark.

Wat het niet bevat, en waarom dat meer uitmaakt

De drie ontbrekende onderdelen zijn geen kleine weglatingen. Elk ervan is een systeem dat er moet zijn voordat de engine productieverkeer kan verwerken, en elk is op een eigen manier kostbaar.

• Het KV-cachesysteem.Prefixhergebruik is waar het meeste geld zit in een chatworkload, omdat een cache-hit een prefill vervangt. Zonder cacheopslag herberekent elke aanvraag zijn prompt. DeepSeeks eigen uiteenzetting beschrijft de opslag die het gebruikt: een toegewijd 3FS-cluster in plaats van lokaal hostgeheugen, precies zodat elke prefill-machine op elke prefix een cache-hit kan krijgen en de cachecapaciteit onafhankelijk van compute kan worden opgeschaald.

• VE/Prefill/Decode-disaggregatie. De README vermeldt dat het grootste deel van de functionaliteit aan de enginezijde al in de release aanwezig is; wat ontbreekt, is de deployment. Door de vision encoder, prefill en decode te disaggregeren, kun je elke fase dimensioneren op basis van zijn eigen bottleneck en de tijd tot het eerste token afzonderlijk regelen van de tijd tussen tokens. Dat is een infrastructuurbeslissing, geen flag.

• Load balancing over dataparallelle replica's. DeepSeek draait vier balancers — prefill, decode, vision-encoder en expert-parallel — en beschrijft ze alle vier in het verslag. Geen van de routeringslogica wordt meegeleverd. Zonder die logica is een replicavleet slechts zo goed als de router die je ervoor zet, en een naïeve round-robin-router zal de cache-hitrate vernietigen die de store juist moest beschermen.

Samen gelezen vertelt de weglating je wat voor soort artefact dit is. DeepInfer is een referentie-implementatie van het rekenpad, gepubliceerd zodat het kernel- en schedulingwerk kan worden geïnspecteerd en hergebruikt, niet een distributie die je installeert en waar je verkeer naartoe stuurt.

De hardwarepoort is het echte filter.

DeepInfer richt zich op NVIDIA SM100 en Huawei Ascend 950. Er is geen Ampere-pad en geen Hopper-pad, waardoor de meeste GPU's in de meeste clusters van vandaag buiten beschouwing vallen. De rest van de toolchain is even specifiek: alleen Linux, GCC 13 of nieuwer, Python 3.12, CUDA 13 voor NVIDIA of CANN 9.2 voor Ascend. En er zijn helemaal geen releases: de repository had nul gepubliceerde releases toen die op 21 oktober 2026 werd gelezen, dus er is niets om te downloaden en niets om vast te zetten. Je kloont het en bouwt het tegen je eigen toolchain.

Die combinatie is ongebruikelijk voor een open-source-release met zoveel aandacht, en kan het beste worden gelezen als een nauwkeurige afbakening van het bereik dan als een vergissing. De kernels in de repository zijn geschreven voor een specifieke instructieset en een specifieke interconnect; de cijfers in de README komen van die hardware. Het rekenpad een generatie terugporten is precies het soort werk dat een community snel doet en een engineeringorganisatie niet kan beloven. Binnen dagen na de release verscheen op GitHub een port van een derde partij voor oudere NVIDIA-onderdelen, wat een nuttig signaal is over de vraag en helemaal geen signaal over of de gepubliceerde doorvoercijfers de port overleven.

De deploymentopzet die DeepSeek daadwerkelijk draait

De architectuurbeschrijving is waar de aannames van de repository leesbaar worden. Het systeem is opgesplitst in een vision-encoder, prefill en decode, plus toegewijde opslagknooppunten. Prefill gebruikt expert-parallelisme van 2 tot 8 met overeenkomstig dataparallelisme en kiest de kleinste configuratie die HBM toelaat. Decode gaat de andere kant op: expert-parallelisme en dataparallelisme van 64 tot 128, wat DeepSeek Wide-EP noemt, met de grootste configuratie die de beschikbare GPU's toelaten. Tensor-parallelisme en context-parallelisme worden helemaal niet gebruikt. De vision-encoder draait één GPU per instantie, met goedkopere GPU's aanbevolen, omdat de encoder niet is waar het geld naartoe gaat.

De kleinste deployment die zinvol is, volgt uit die cijfers. Eén prefill-GPU en één decode-GPU zullen draaien, en in de praktijk is de verhouding tussen de twee pools ongeveer één op één. Maar omdat decode 64 GPU's of meer wil om het voordeel van expert-parallelisme te krijgen, is de kleinste efficiënte eenheid 64 prefill-GPU's plus 64 decode-GPU's. Dat is het getal om vast te houden wanneer je welke bewering dan ook over de efficiëntie van DeepInfer leest: de cijfers beschrijven een deployment met 128 GPU's, en de helft daarvan is één fase.

Het splitsen van prefill en decode over datacenters is technisch mogelijk omdat DeepSeek-V4.1-Flash zijn KV-cache aanzienlijk comprimeert, en DeepSeek's eigen deployment plaatst inferentieknooppunten in verschillende maar aangrenzende datacenters. Het budget is ongeveer 400 Gbps aan interconnect per acht GPU's, en het verslag is openhartig over de betrouwbaarheidskosten — glasvezel tussen gebouwen is gemakkelijk door te snijden.

Waarom is decoderen zo wijdverspreid?

Brede expert-parallelisatie is de meest ingrijpende keuze in het ontwerp, en wordt gemakkelijk verkeerd begrepen als een scaling-truc. In een mixture-of-experts-laag raakt elk token een klein aantal experts, dus de kosten van een decodeerstap worden gedomineerd door het verplaatsen van expertgewichten en -activaties in plaats van door rekenintensiteit. Het spreiden van de experts over 64 of 128 GPU's vermindert het geheugenverkeer per stap dat elke GPU bijdraagt, wat het aantal tokens per seconde verhoogt als — en dat is de voorwaarde — de belasting over de experts gelijkmatig blijft. Daar is de expert-parallelle loadbalancer voor.

De instellingen van DeepSeek zijn specifiek genoeg om te kopiëren. Voor prefill heeft elke GPU vier redundante experts bovenop de experts die deze bezit, worden statistieken verzameld over een venster van 100 stappen en worden experts elke 1.000 stappen opnieuw toegewezen, waarbij gewichten binnen de groep worden herschikt via NVLink-gedeeld geheugen. De gemeten onbalans — de traagste rank gedeeld door het gemiddelde — kwam uit op 1,074 voor een EP4/DP4-configuratie en 1,045 voor EP2/DP2. Voor decode worden de instellingen ruimer: één redundante expert per GPU, een statistiekvenster van 1.000 stappen, hertoewijzing elke 10.000 stappen en een gemeten onbalans van 1,090. Het verschil tussen beide is precies het punt. Prefill ziet werk dat in bursts komt en heterogeen is, en heeft snelle herbalancering nodig; decode ziet een gelijkmatige stroom en kan zich een lang venster veroorloven, dus het balanceert zelden opnieuw en betaalt bijna niets voor dat voorrecht.

De routeringskant heeft hetzelfde karakter. Prefill-verzoeken worden op basis van de totale contextlengte in vier niveaus ingedeeld — onder 16K, 16 tot 64K, 64 tot 256K, en 256K en hoger — en engines worden aan niveaus toegewezen op basis van het aandeel van elk niveau in de rekenvraag in de vorige ronde. Binnen een GPU is de chunkgrootte voor elke prefill-stap niet vast: een gefit kwadratisch kostenmodel voorspelt hoe lang een stap duurt gegeven het aantal sequentietokens en de al berekende prefix, en de scheduler bepaalt de grootste chunk die binnen de resterende tijd past bij een budget van 32.768 tokens. De decode-balancer balanceert tegelijkertijd twee dimensies, het aantal verzoeken en de totale KV-cachelengte, en stuurt korte verzoeken naar GPU's met een lage gelijktijdigheid en een lange cache, en lange verzoeken naar GPU's met een kleine cache. DeepSeeks eigen samenvatting van hoeveel dit allemaal oplevert: ongeveer 80 procent van een perfect gebalanceerde offline benchmark.

De cache, en de driedaagse vraag

De KV-cache staat op een toegewijd 3FS-cluster, niet in het lokale hostgeheugen, en die keuze bepaalt de rest van het opslagontwerp. Gegevens worden opgeslagen met 10+2-erasurecoding, zodat elke coderingsgroep twee gelijktijdige nodefouten doorstaat; een leesactie stuurt verzoeken naar alle 11 nodes in de groep en elke 10 reacties zijn voldoende om te decoderen. Op elke opslagnode draait een garbagecollection-worker die volgens LRU verwijdert zodra een watermerk wordt overschreden. De aanbevolen server heeft 20 solid-state drives van elk 30,73 TB en haalt ten minste 40 GB/s aan lees- en 5 GB/s aan schrijfsnelheid, gedimensioneerd om ongeveer 24 uur aan gegevens per server te behouden. In de praktijk draait het cluster op ongeveer 14,4 TB logische cache per online GPU, met een fysieke capaciteit die groter is dan dat.

Residentie is waar de afweging zichtbaar wordt. Er is geen vervallogica aan de cachezijde; de TTL wordt aan de opslagzijde ingesteld op drie dagen voor agentverkeer en zeven dagen voor chatbotverkeer, op een cluster met ongeveer 100 petabyte solid-stateopslag. De splitsing bestaat omdat chatbotverkeer een veel zwaardere lange staart van hits heeft — een kleine hoeveelheid cache wordt vele malen gelezen, dus het verliezen ervan kost meer aan het algehele cachehitpercentage dan het volume suggereert. DeepSeeks gemeten kosten van het terugbrengen van chatbotretentie naar drie dagen bedragen 0,5 tot 1 procent van het cachehitpercentage. Dat is een klein getal dat toevallig een grote hoeveelheid herberekende prefill vertegenwoordigt.

Sliding-window attention krijgt een aparte cache met andere regels. De SWA-cache komt niet in de gepagineerde blokken; elke sequentie bezet één slot met vaste grootte in het hostgeheugen, en voor DeepSeek-V4.1-Flash zijn de opgeslagen lagen de eerste 20. Alleen dat gebied blijft bewaard: 20 lagen × 134 tokens × 528 bytes, dat is 1.415.040 bytes per sequentie in een MXFP8-formaat. Niets gaat naar de opslagcluster; het blijft in het geheugen van de machine die het heeft geproduceerd, met een in-memory directory die bijhoudt welke machine wat bevat, en een cross-machine hit haalt het terug via een 400 Gbps VLAN.

De twee mechanismen die de headline-cijfers opleveren

Begrensde replay is het interessantere van de twee, omdat het een onbegrensde kostenpost neemt en er een constante van maakt. Normaalgesproken betekent een sliding-window-cache-miss dat het venster vanaf het begin opnieuw moet worden berekend, en de kosten groeien met de contextlengte en het aantal lagen. DeepSeek herberekent daarentegen alleen de meest recente 128 tokens en kapt het attention-venster af tot dat segment, waardoor een benaderende SWA-cache tegen een vaste prijs ontstaat. Aan de encoderzijde ontkoppelt dit de prefix-cache-hitlengte volledig van de SWA-cache: als de SWA-cache ontbreekt, worden de laatste 128 tokens van de getroffen prefix opnieuw afgespeeld terwijl de blokcache onaangeroerd wordt hergebruikt.

Aan de decoderzijde is de besparing groot. In deze architectuur wordt de block cache van de decoderlagen geprojecteerd vanuit de hidden state van de laatste encoderlaag, dus alleen de decoder-SWA-cache hoeft per laag te worden berekend — en om die exact te reconstrueren zouden bij elke prefill de laatste 2.560 tokens door 20 decoderlagen moeten worden gestuurd. Als je in plaats daarvan 128 tokens opnieuw afspeelt en het resultaat alleen voor decode gebruikt in plaats van het in de prefixcache te laten terechtkomen, halveert de totale prefill-berekening bijna. Die ene wijziging is meer waard dan de meeste kernel-optimalisaties, en het is iets wat alleen een team dat de modelarchitectuur bezit kan doen.

De bijdrage van DSpark is kleiner en conventioneler. Drafttokens hebben verschillende acceptatiekansen, afhankelijk van het verzoek en de positie, dus het verifiëren van een vast aantal van vijf drafts per stap verspilt rekenkracht aan tokens die worden afgewezen. Een confidence head voorspelt de acceptatiegraad van elk drafttoken, en de scheduler sorteert de drafts op verwachte opbrengst en verifieert alleen het prefix dat de doorvoer maximaliseert. In productie genereert het draftmodel nog steeds vijf tokens per stap; het aantal dat wordt geverifieerd daalt van 5,00 naar tussen 3,2 en 4,4, een daling van ongeveer 30 procent, terwijl de geaccepteerde lengte nauwelijks verandert — 3,29 tegen 3,20. Afgelezen van EP64/DP64-benchmarkgegevens komt dat neer op 4 tot 7 procent meer doorvoer bij ongeveer 60 gelijktijdige sequenties per rank. Bij precies 60 gaat de doorvoer per rank van 13.730 naar 14.466 tokens per seconde. Onder ongeveer 16 gelijktijdige sequenties is de techniek een klein nettoverlies, wat de moeite waard is om te weten voordat je het toepast voor een implementatie met weinig verkeer.

Wat het cijfer van 155 biljoen betekent

Het meest geciteerde getal dat aan deze release wordt gekoppeld, is een enkel cluster dat 155 biljoen tokens per dag verwerkt, bij een totale omzet van 38 Amerikaanse dollar per GPU-uur tegen dalprijzen. Beide helften zijn door de leverancier gerapporteerd en geen van beide is een benchmark die je kunt reproduceren, wat ze niet oninteressant maakt — een omzetcijfer per GPU-uur is een wezenlijk ander soort claim dan een doorvoercijfer, omdat het benutting, prijsstelling en cache-hitratio in één regel samenvat. Het is ook het cijfer dat het vaakst zonder de bijbehorende kwalificaties wordt geciteerd, dus die kwalificaties verdienen het om opgeschreven te worden: één cluster, dalprijzen, omzet in plaats van kosten, en geaggregeerd over prefill, decode en vision encoder.

Twee kleinere onthullingen zijn directer van nut. De FlashMLA-decodeerkernel in de openbare repository mist één handmatig afgestemde assembly-optimalisatie die de interne versie wel heeft, waardoor hij op zichzelf 5 tot 10 procent langzamer is; DeepSeek stelt dat de end-to-endprestaties hoogstens 5 procent van elkaar verschillen. En het interne conceptmodel voor speculatief decoderen is nieuwer dan het gepubliceerde, waarbij het prestatieverschil als klein wordt beschreven. Beide uitspraken scheppen een verwachting over hoeveel van de gepubliceerde prestaties een derde partij kan bereiken door de code te kopiëren, en het antwoord is: het grootste deel, mits de hardware overeenkomt.

De repository, zoals die er nu voor staat

De bovenstaande schermafbeelding is gemaakt op 21 oktober 2026 en laat zien dat de pagina 16,3k sterren aangeeft. De GitHub API, dezelfde dag opgevraagd, gaf 16.590 sterren, 1.649 forks en 176 openstaande issues, waarbij issues zijn uitgeschakeld en discussies in plaats daarvan naar GitHub Discussions worden geleid. Het aantal sterren is sindsdien blijven stijgen, dus lees elk cijfer hier als een tijdstip en niet als een eigenschap van de code. Verkeer van die omvang in minder dan een week zegt meer over de interesse in de servingstack van DeepSeek dan over de gereedheid van de code, en het aantal van nul releases zegt de rest.

Als je erover nadenkt om het zelf te draaien

De eerlijke samenvatting is dat DeepInfer het waard is om aandachtig te lezen en moeilijk te beheren. Vier vragen vertellen je of het bij je past.

• Heeft u SM100 of Ascend 950? Al het andere in de toolchain volgt hieruit. Zonder de juiste accelerator zijn de gepubliceerde cijfers niet overdraagbaar, en de community-ports zijn niet gevalideerd op productieschaal.

• Kun je 64 decode-GPU's in één communicatiedomein draaien? Brede expertparallellisme is geen optimalisatie die je kunt overslaan; het is de configuratie waarop het decode-pad is ontworpen. Onder die schaal draai je een ander systeem met dezelfde naam.

• Beschikt u al over een prefixcache? Zo niet, dan vergelijkt u het compute-pad van DeepInfer met een concurrerende stack die er standaard een meelevert, en dan valt de vergelijking slechter uit dan het ontwerp verdient.

• Kun je het je permitteren om de routeringslaag te schrijven? Prefill-bucketing, decode-balancing en expert-reassignment zijn goed genoeg beschreven om ze opnieuw te implementeren, en ze opnieuw implementeren is weken werk dat de repository niet voor je doet.

Als je liever geen van het bovenstaande wilt bezitten

Voor de meeste teams is de praktische vraag niet hoe ze DeepSeek-V4.1-Flash moeten uitrollen, maar waar ze het moeten aanroepen. Het model is beschikbaar via een compatibele API zonder een cluster van 128 GPU's te bouwen of een loadbalancer opnieuw te implementeren, en dat is hetzelfde model waarvan dit artikel de architectuur beschrijft — dezelfde contextverwerking, hetzelfde gedrag bij gestructureerde uitvoer, zonder het disaggregatiewerk.

De vergelijking die je moet maken is niet welke engine in abstracto sneller is, want de gepubliceerde cijfers zijn door leveranciers gerapporteerde metingen op hardware die de meeste lezers niet hebben. Het gaat erom of de workload er een is waarbij een cache-TTL van 3 dagen en een decode-pool van 64 GPU's de prijs veranderen, of een waarbij een verzoek om de paar seconden via een API eenvoudigweg goedkoper is dan elk van de hierboven beschreven bewerkingen. Voor het tweede geval — de meeste gevallen dus — is de juiste hoeveelheid DeepInfer om te gebruiken nul, en de juiste hoeveelheid om te lezen alles. Begin bij de modelpagina van DeepSeek V4.1 Flash als je het endpoint wilt; begin bij de README van de repository als je wilt weten wat het endpoint doet.