Vad är DeepInfer? DeepSeeks inferensmotor, och delarna som den inte levererade

DeepInfer är inferensramverket som DeepSeek publicerade den 16 oktober 2026 under Apache-2.0, och det serverar exakt en modell: DeepSeek-V4.1-Flash, med DeepSeek-V4.1-Flash-1017 som standardcheckpoint. Att det bara omfattar en enda modell är det första man måste förstå, eftersom det förklarar nästan allt annat om repot. Detta är inte ett allmänt serveringsramverk som råkar innehålla en DeepSeek-konfiguration. Det är kodvägen DeepSeek kör i produktion, nedskuren till de delar som går att generalisera, och den är ärlig om nedskärningen: README:s egen lista över vad en komplett inferenstjänst behöver och vad den här utgåvan inte innehåller tar upp ett KV-cachesystem, VE/Prefill/Decode-disaggregering och lastbalansering över dataparallella repliker. Det du får är beräkningsvägen – kärnor, parallellism, spekulativ avkodning, schemaläggning, strukturerad utdata. Det du inte får är lagrings- och routningslagret som gör beräkningsvägen billig att driva i stor skala. DeepSeek förklarar varför: dessa komponenter är tätt kopplade till intern infrastruktur, så designen beskrivs i en publicerad redogörelse medan koden stannar internt.

Vad finns egentligen i arkivet?

Den publicerade funktionslistan framstår som en rundtur genom flaskhalsarna när en stor mixture-of-experts-modell ska servas. Där finns kärnbiblioteken som DeepSeek har släppt tidigare – FlashMLA för attention, DeepGEMM för matrismultiplikationerna, DeepEP för expert-parallell kommunikation, plus TileKernels och DeepSelect. Där finns parallelliseringsschemat: attention körs som dataparallellism med balanserad kontextparallellism, MoE-halvan körs som expertparallellism med en expert-parallell lastbalanserare. Där finns DSpark, stacken för spekulativ avkodning, med verifieringslängder som schemaläggs i stället för att vara fasta. Där finns SWA-begränsad replay, som är mekanismen som hindrar en cache för glidande fönster-attention från att tvinga fram en fullständig omberäkning vid varje cachemiss. Där finns asynkron batchschemaläggning, batch-invariant inferens med deterministisk sampling och strukturerad utdata begränsad av regex, JSON-schema eller EBNF.

Ingångspunkten är medvetet liten. När du har ställt in DEEPINFER_ACCELERATOR till nvidia eller motsvarande Ascend och kört build.sh, levererar repot examples/offline_inference.py, som kör standardcheckpointen från början till slut. DEEPINFER_HF_MODEL_DIR pekar den mot en annan katalog för vikter. De publicerade benchmarkresultaten mättes på fyra SM100-GPU:er för prefill och 64 SM100-GPU:er för decode, vilket är den typ av driftsättning som motorn skrevs för och inte en demo formad för en bärbar dator.

README:n anger också var koden kommer ifrån, vilket är värt att känna till innan man läser den. Motorn byggdes ursprungligen i första hand på vLLM, med designinspiration från SGLang och TensorRT-LLM. Det arvet syns i strukturen – schemaläggaren, gränssnittet för paged attention och samplingsvägen kommer att kännas igen av alla som har läst de projekten – och det förklarar varför utgåvan är en fork av en serving-stack snarare än en arkitektur skriven från grunden. Det DeepSeek lade till är den del som är specifik för sin egen modell: den disaggregerade driftsättningen, den breda expertparallelismen med sin balanserare, återspelningen med glidande fönster och DSpark.

Vad den inte innehåller, och varför det spelar större roll

De tre saknade delarna är inte små utelämningar. Var och en är ett system som måste finnas på plats innan motorn kan hantera produktionstrafik, och var och en är kostsam på sitt eget sätt.

• KV-cache-systemet.Prefixåteranvändning är där de stora pengarna finns i en chattarbetsbelastning, eftersom en cacheträff ersätter en prefill. Utan ett cachelager räknar varje begäran om sin prompt. DeepSeeks egen beskrivning redogör för det lager de använder: ett dedikerat 3FS-kluster i stället för lokalt värdminne, just för att vilken prefill-maskin som helst ska kunna träffa vilket prefix som helst och cachelagringskapaciteten ska kunna skalas oberoende av beräkningskapaciteten.

• VE/Prefill/Decode-disaggregering. README:n noterar att det mesta av motorfunktionaliteten redan finns i utgåvan; det som saknas är driftsättningen. Genom att disaggregera vision-encodern, prefill och decode kan du dimensionera varje steg mot dess egen flaskhals och styra tiden till första token separat från tiden mellan token. Det är ett infrastrukturbeslut, inte en flagga.

• Lastbalansering över dataparallella repliker. DeepSeek kör fyra lastbalanserare – prefill, decode, vision encoder och expert-parallel – och beskriver alla fyra i redogörelsen. Ingen av routningslogikerna levereras. Utan den är en replikflotta bara så bra som vilken router du än sätter framför den, och en naiv round-robin-router förstör cacheträffrekvensen som lagret byggdes för att skydda.

Läst tillsammans säger utelämnandet dig vilken typ av artefakt detta är. DeepInfer är en referensimplementation av beräkningsvägen, publicerad så att kärn- och schemaläggningsarbetet kan granskas och återanvändas, inte en distribution som du installerar och riktar trafik mot.

Hårdvarugrinden är det verkliga filtret

DeepInfer riktar in sig på NVIDIA SM100 och Huawei Ascend 950. Det finns ingen Ampere-väg och ingen Hopper-väg, vilket utesluter de flesta GPU:erna i de flesta kluster idag. Resten av verktygskedjan är lika specifik: endast Linux, GCC 13 eller nyare, Python 3.12, CUDA 13 för NVIDIA eller CANN 9.2 för Ascend. Och det finns inga utgåvor alls – förvaret hade noll publicerade utgåvor när det lästes den 21 oktober 2026, så det finns inget att ladda ner och inget att låsa. Du klonar det och bygger det mot din egen verktygskedja.

Den kombinationen är ovanlig för en open source-utgivning med så här mycket uppmärksamhet, och den bör bäst läsas som ett korrekt uttalande om omfattningen snarare än ett förbiseende. Kärnorna i repositoryt är skrivna för en specifik instruktionsuppsättning och en specifik interconnect; siffrorna i README kommer från den hårdvaran. Att porta beräkningsvägen ner en generation är precis den typ av arbete som en community gör snabbt och som en ingenjörsorganisation inte kan lova. Inom dagar från utgivningen dök en tredjepartsport som riktar sig mot äldre NVIDIA-delar upp på GitHub, vilket är en användbar signal om efterfrågan och ingen signal alls om huruvida de publicerade genomströmningssiffrorna överlever portningen.

Driftsättningsformen som DeepSeek faktiskt kör

Arkitekturbeskrivningen är där repots antaganden blir begripliga. Systemet är uppdelat i en visionsencoder, prefill och decode samt dedikerade lagringsnoder. Prefill använder expertparallelism på 2 till 8 med matchande dataparallelism och väljer den minsta konfiguration som HBM tillåter. Decode går åt andra hållet: expertparallelism och dataparallelism på 64 till 128, vilket DeepSeek kallar Wide-EP, med den största konfiguration som tillgängliga GPU:er tillåter. Tensorparallelism och kontextparallelism används inte alls. Visionsencodern kör en GPU per instans, och billigare GPU:er rekommenderas, eftersom det inte är i encodern pengarna går.

Den minsta driftsättning som är meningsfull följer av de siffrorna. En prefill-GPU och en decode-GPU kommer att köras, och i praktiken är förhållandet mellan de två poolerna ungefär ett till ett. Men eftersom decode vill ha 64 GPU:er eller fler för att få den expertparallella fördelen, är den minsta effektiva enheten 64 prefill-GPU:er plus 64 decode-GPU:er. Det är siffran att hålla fast vid när man läser något påstående om DeepInfers effektivitet: siffrorna beskriver en driftsättning med 128 GPU:er, och hälften av den är ett steg.

Att dela upp prefill och decode mellan datacenter är tekniskt möjligt eftersom DeepSeek-V4.1-Flash komprimerar sin KV-cache avsevärt, och DeepSeeks egen driftsättning placerar faktiskt inferensnoder i olika men närliggande datacenter. Budgeten är ungefär 400 Gbps sammanlänkning per åtta GPU:er, och beskrivningen är öppen med tillförlitlighetskostnaden — fiber mellan byggnader är lätt att kapa.

Varför är avkodningen så utspridd

Bred expertparallellism är det enskilt mest avgörande valet i designen, och det är lätt att misstolka som en skalningstrick. I ett mixture-of-experts-lager berör varje token ett litet antal experter, så kostnaden för ett avkodningssteg domineras av att flytta expertvikter och aktiveringar snarare än av aritmetisk intensitet. Att sprida ut experterna över 64 eller 128 GPU:er minskar den minnestrafik per steg som varje GPU bidrar med, vilket ökar antalet tokens per sekund om – och detta är förutsättningen – belastningen över experterna förblir jämn. Det är vad expert-parallell lastbalanseraren är till för.

DeepSeeks inställningar är tillräckligt specifika för att kopieras. För prefill har varje GPU fyra redundanta experter utöver de den äger, statistik samlas in över ett fönster på 100 steg och experter omfördelas var 1 000:e steg, med vikter som blandas inom gruppen via NVLinks delade minne. Uppmätt obalans – den långsammaste ranken dividerad med medelvärdet – uppgick till 1,074 för en EP4/DP4-konfiguration och 1,045 för EP2/DP2. För decode sträcks inställningarna ut: en redundant expert per GPU, ett statistikfönster på 1 000 steg, omfördelning var 10 000:e steg och en uppmätt obalans på 1,090. Skillnaden mellan de två är poängen. Prefill ser stötvis, heterogent arbete och behöver snabb ombalansering; decode ser en jämn ström och har råd med ett långt fönster, så det ombalanserar sällan och betalar nästan ingenting för privilegiet.

Routningssidan har samma karaktär. Prefill-förfrågningar delas in efter total kontextlängd i fyra nivåer – under 16K, 16 till 64K, 64 till 256K samt 256K och över – och motorer tilldelas nivåer utifrån varje nivås andel av beräkningsbehovet i föregående omgång. Inom en GPU är chunkstorleken för varje prefill-steg inte fast: en anpassad kvadratisk kostnadsmodell förutsäger hur lång tid ett steg tar utifrån antalet sekvenstoken och det prefix som redan har beräknats, och schemaläggaren beräknar den största chunk som ryms inom en budget på 32 768 token under den återstående tiden. Decode-balanseraren balanserar två dimensioner samtidigt – antal förfrågningar och total KV-cache-längd – och skickar korta förfrågningar till GPU:er med låg samtidighet och lång cache, samt långa förfrågningar till GPU:er med liten cache. DeepSeeks egen sammanfattning av hur mycket allt detta ger: ungefär 80 procent av ett perfekt balanserat offline-benchmark.

Cachen, och den tre dagar långa frågan

KV-cachen ligger i ett dedikerat 3FS-kluster, inte i lokalt värdminne, och det beslutet styr resten av lagringsdesignen. Data lagras med 10+2-raderingskodning, så varje kodningsgrupp överlever två samtidiga nodfel; en läsning skickar förfrågningar till alla 11 noder i gruppen och vilka 10 svar som helst räcker för att avkoda. En skräpsamlingsarbetare körs på varje lagringsnod och vräker ut poster enligt LRU när en vattenmärkesnivå har passerats. Den rekommenderade servern har 20 SSD-enheter på 30,73 TB vardera och klarar minst 40 GB/s vid läsning och 5 GB/s vid skrivning, dimensionerad för att behålla ungefär 24 timmars data per server. I praktiken ligger klustret på ungefär 14,4 TB logisk cache per GPU som är online, med en fysisk kapacitet som är större än så.

Residens är där avvägningen blir synlig. Det finns ingen utgångslogik på cachesidan; TTL:n ställs in på lagringssidan till tre dagar för agenttrafik och sju dagar för chatbotstrafik, på ett kluster som rymmer ungefär 100 petabyte solid-state-lagring. Uppdelningen finns eftersom chatbotstrafik har en mycket tyngre lång svans av träffar – en liten mängd cache läses många gånger om, så att förlora den kostar mer i total träffrekvens än volymen antyder. DeepSeeks uppmätta kostnad för att minska chatbotretentionen till tre dagar är 0,5 till 1 procent av cacheträffrekvensen. Det är en liten siffra som råkar representera en stor mängd omräknad prefill.

Sliding-window-attention får en separat cache med andra regler. SWA-cachen går inte in i de sidindelade blocken; varje sekvens upptar en plats med fast storlek i värdminnet, och för DeepSeek-V4.1-Flash är lagren som lagras de första 20. Endast det området består – 20 lager gånger 134 tokens gånger 528 byte, vilket är 1 415 040 byte per sekvens i ett MXFP8-format. Inget går till lagringsklustret; det stannar i minnet hos maskinen som producerade det, med en katalog i minnet som registrerar vilken maskin som har vad, och en träff mellan maskiner hämtar tillbaka det över ett 400 Gbps VLAN.

De två mekanismerna som producerar rubriksiffrorna

Avgränsad replay är den mer intressanta av de två eftersom den tar en obegränsad kostnad och gör den konstant. Normalt innebär en cache-miss i det glidande fönstret att fönstret räknas om från början, och kostnaden växer med kontextlängd och antal lager. DeepSeek räknar i stället endast om de senaste 128 tokens och trunkerar uppmärksamhetsfönstret till det segmentet, vilket ger en ungefärlig SWA-cache till ett fast pris. På kodarsidan frikopplar detta längden på prefix-cachens träff helt från SWA-cachen: om SWA-cachen saknas spelas de sista 128 tokens i det träffade prefixet upp igen medan blockcachen återanvänds orörd.

Det är på dekodersidan som besparingen är stor. I den här arkitekturen projiceras dekoderlagrens blockcache från det sista encoderlagrets dolda tillstånd, så endast dekoderns SWA-cache behöver beräknas per lager – och att rekonstruera den exakt skulle innebära att skicka de sista 2 560 tokens genom 20 dekoderlager vid varje prefill. Genom att i stället spela upp 128 tokens och endast använda resultatet för avkodning, i stället för att låta det gå in i prefixcachen, nästan halveras den totala prefill-beräkningen. Den enda ändringen är värd mer än de flesta kerneloptimeringar, och det är sådant som bara ett team som äger modellarkitekturen kan göra.

DSparks bidrag är mindre och mer konventionellt. Draft-tokens har olika acceptanssannolikheter beroende på förfrågan och position, så att verifiera ett fast antal på fem draft-tokens per steg slösar beräkningskraft på token som kommer att avvisas. Ett konfidenshuvud förutsäger acceptansgraden för varje draft-token, och schemaläggaren sorterar draft-tokens efter förväntat utbyte och verifierar endast det prefix som maximerar genomströmningen. I produktion genererar draft-modellen fortfarande fem token per steg; antalet som verifieras sjunker från 5,00 till mellan 3,2 och 4,4, en minskning med ungefär 30 procent, medan den accepterade längden knappt ändras – 3,29 mot 3,20. Avläst ur benchmarkdata för EP64/DP64 motsvarar det 4 till 7 procents högre genomströmning vid omkring 60 samtidiga sekvenser per rank. Vid exakt 60 går genomströmningen per rank från 13 730 till 14 466 token per sekund. Under omkring 16 samtidiga sekvenser är tekniken en liten nettoförlust, vilket är värt att känna till innan den införs för en driftsättning med låg trafik.

Vad siffran 155 biljoner innebär

Den mest citerade siffran kopplad till den här lanseringen är ett enda kluster som hanterar 155 biljoner tokens per dag till en total intäkt på 38 US-dollar per GPU-timme vid dalprissättning. Båda halvorna är leverantörsrapporterade och ingen av dem är ett riktmärke som du kan reproducera, vilket inte gör dem ointressanta – en intäktssiffra per GPU-timme är en genuint annan typ av påstående än ett genomströmningstal, eftersom den samlar utnyttjandegrad, prissättning och cacheträffsfrekvens på en enda rad. Det är också den siffra som mest sannolikt citeras utan sina förbehåll, så förbehållen förtjänar att skrivas ned: ett kluster, dalprissättning, intäkt snarare än kostnad, och aggregerat över prefill, decode och vision encoder.

Två mindre avslöjanden är mer direkt användbara. FlashMLA-avkodningskärnan i det offentliga förvaret saknar en handoptimerad assemblyoptimering som den interna versionen har, vilket gör den 5 till 10 procent långsammare isolerat; DeepSeek uppger att prestandan från start till mål skiljer sig högst 5 procent. Och den interna draftmodellen för spekulativ avkodning är nyare än den publicerade, med en prestandaskillnad som beskrivs som liten. Båda uttalandena skapar en förväntan om hur mycket av den publicerade prestandan en tredje part kan nå genom att kopiera koden, och svaret är: det mesta, förutsatt att hårdvaran matchar.

Repositoriet i dess nuvarande skick

Skärmbilden ovan togs den 21 oktober 2026 och visar sidan med 16,3k stjärnor. GitHub-API:et, som frågades samma dag, returnerade 16 590 stjärnor, 1 649 forks och 176 öppna ärenden, med ärenden inaktiverade och diskussionerna hänvisade till GitHub Discussions i stället. Antalet stjärnor har fortsatt att klättra sedan dess, så läs varje siffra här som en tidsstämpel snarare än som en egenskap hos koden. Trafik av den storleken på under en vecka säger mer om intresset för DeepSeek:s serveringsstack än om kodens mognad, och att antalet utgåvor är noll säger resten.

Om du funderar på att köra det själv

Den ärliga sammanfattningen är att DeepInfer är värd att läsa noggrant och svår att driva. Fyra frågor avgör om det passar.

• Har du SM100 eller Ascend 950? Allt annat i verktygskedjan följer av detta. Utan rätt accelerator kan de publicerade siffrorna inte överföras, och community-portarna är ovaliderade i produktionsskala.

• Kan du köra 64 decode-GPU:er i en och samma kommunikationsdomän? Bred expertparallelism är inte en optimering du kan hoppa över; det är den konfiguration som decode-vägen utformades kring. Under den skalan kör du ett annat system med samma namn.

• Har du redan en prefixcache? Om inte jämför du DeepInfers beräkningsväg mot en konkurrerande stack som levereras med en sådan, och jämförelsen kommer att se sämre ut än designen förtjänar.

• Har du råd att skriva routningslagret? Prefill-bucketning, decode-balansering och expertomfördelning beskrivs tillräckligt väl för att kunna återimplementeras, och att återimplementera dem är flera veckors arbete som kodförrådet inte gör åt dig.

Om du föredrar att inte äga någon av ovanstående

För de flesta team är den praktiska frågan inte hur man distribuerar DeepSeek-V4.1-Flash utan var man anropar den. Modellen är tillgänglig via ett kompatibelt API utan att bygga ett kluster med 128 GPU:er eller återimplementera en lastbalanserare, och det är samma modell vars arkitektur den här artikeln har beskrivit – samma kontexthantering, samma beteende för strukturerad utdata, utan arbetet med disaggregation.

Jämförelsen man bör göra är inte vilken motor som är snabbare i abstrakt mening, eftersom de publicerade siffrorna är leverantörsrapporterade mätningar på hårdvara som de flesta läsare inte har. Det är huruvida arbetsbelastningen är en där en cache-TTL på 3 dagar och en decode-pool med 64 GPU:er förändrar priset, eller en där en förfrågan med några sekunders mellanrum via ett API helt enkelt är billigare än någon av de operationer som beskrivs ovan. För det andra fallet – vilket är de flesta fall – är rätt mängd DeepInfer att använda ingen, och rätt mängd att läsa är allt av det. Börja med sidan för modellen DeepSeek V4.1 Flash om du vill ha slutpunkten; börja med repots README om du vill veta vad slutpunkten gör.