Llm-D 1.0 lanseras på PyTorch Conference med en inferensstack för produktionsmiljöer

Medarbetare i llm-d-projektet presenterade llm-d 1.0, en Kubernetes-inbyggd distribuerad stack för inferenshantering, den 20 oktober 2026 på PyTorch Conference North America, enligt ett tillkännagivande från IBM Research. IBM uppgav att lanseringen tar llm-d bortom demonstrationer av enskilda prestandatekniker och ska hjälpa organisationer att ta hem modelldistributionen i takt med att inferenskostnaderna ökar.

llm-d har utvecklats för att distribuera inferensstackar för alla modeller, på alla acceleratorer och i alla moln. Red Hat, IBM och Google är projektets huvudansvariga underhållare och grundade llm-d tillsammans med CoreWeave och NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda och Mistral AI har anslutit sig som bidragsgivare. Cloud Native Computing Foundation (CNCF) står värd för llm-d som ett sandboxprojekt. IBM beskriver resultatet som ett leverantörsneutralt alternativ för organisationer som vill ha det företaget kallar inferensprestanda i absoluta framkant, utan att vara helt beroende av en enda leverantör av proprietära modeller, ett enda moln eller en enda hårdvaruplattform.

Carlos Costa, Distinguished Engineer på IBM Research samt medgrundare och huvudansvarig underhållare för llm-d, uppgav att version 1.0 har den mognad som krävs för att köra llm-d som vilken annan verksamhetskritisk tjänst som helst. Han pekade på ett stabilt API, flera klienter med motstridiga prioriteringar som delar samma infrastruktur och uppgraderingar som inte avbryter driften.

Det här tillför version 1.0

Projektets versionsinformation för v1.0.0, som publicerades på GitHub den 20 oktober 2026 med signerade och verifierade taggar, inleds med tjänstekvalitet för miljöer med flera klienter: flödesstyrning med hänsyn till prioritet och rättvis fördelning, med kontrollerad lastavlastning. Detta omfattar en probabilistisk antagningsfunktion, rättvis fördelning med hänsyn till program och poängsättning av turprioritet, så att förfrågningar med känsliga latenskrav och agentarbetslaster med kraftiga trafiktoppar kan dela på en beräkningspool utan att svälta ut varandra vid överbelastning. Konfigurationen för flödesstyrning samlas under ett enda fält, flowControl.

För drift utan avbrott får routern hög tillgänglighet med aktiv reserv och säkra löpande uppdateringar, och en DisaggregatedSet-styrenhet hanterar repliker för prefill och decode som en logisk enhet, med samordnade utrullningar, uppgraderingar i låst takt, beredskap som villkoras av Pod-ögonblicksbilden och inbyggd versionsstyrd routning. Routerns konfigurations-API uppgraderas till v1, Responses API stöder previous_response_id och förfrågningsvägen för endpoint-väljaren har förstärkts för tillförlitlighet, prestanda och skalbarhet. En guide till acceleratorer som tar hänsyn till topologin för DRA och DRANET ingår.

Agentmedveten inferenshantering får ett plugin för generering av sessionstillstånd och föränderlig sessionsaffinitet, så att konversationer med flera turer hålls nära sitt cachade sammanhang. Schemaläggning med turprioritet och tillstånd i Responses API hjälper agenter att återanvända sammanhang mellan turer. I lanseringen samordnas projektets komponenter vid v1.0.0, ekosystemet utökas med bland annat en integrering med ai-dynamo/modelexpress för peer-to-peer-laddning av modellvikter, paketet llm-d-api-extensions och diagnostikverktygen llm-d-pd-utils, och projektets egna byggen av llm-d-rocm-containeravbildningar fasas ut. Avbildningar för modellservrar omfattar byggen av vLLM och SGLang för olika acceleratormål, och guiden till uppdelning av prefill och decode kräver nu LeaderWorkerSet v0.11.1 eller senare, med DisaggregatedSet API aktiverat.

Kärntekniker och flödesstyrning

Sedan lanseringen har projektet fokuserat på fem metoder för att förbättra inferens: routning med hänsyn till prefixcachen, som styr en förfrågan till infrastruktur där det delade sammanhanget kanske redan finns; avlastning av KV-cache, som flyttar cachad information mellan GPU-, CPU- och lagringsresurser; optimering av batchinferens; uppdelning av prefill och decode, där läsningen av en prompt skiljs från genereringen av ett svar; samt bred expertparallellism, som fördelar stora modeller med mixture-of-experts-arkitektur över många acceleratorer. Dessa tekniker fanns redan före version 1.0. Enligt IBM är det nya integreringen och den operativa mognaden kring dem samt disciplinen för dag-2-drift: att upprätthålla prestandan när trafiken förändras, maskinvara slutar fungera, programvara uppdateras eller olika användare konkurrerar om samma resurser.

I version 1.0 ska flödesstyrning, rättvis fördelning och prioritering hindra arbetslaster med kraftiga trafiktoppar från att överbelasta tjänster med känsliga latenskrav, oavsett om arbetslasterna delar samma maskinvara eller körs på en blandning av acceleratorer. Förfrågningar kan förbli knutna till lämplig infrastruktur under flera turer, så att prefixcacherna hålls varma. llm-d fungerar med inferensmotorer som vLLM och SGLang och lägger till distribuerad routning och driftsfunktioner ovanpå dem. Stephen Watt, vice vd vid Red Hats kontor för teknisk chef, uppgav att llm-d förenar PyTorch- och CNCF-ekosystemen genom att föra Kubernetes-inbyggd orkestrering direkt till vLLM och moderna inferensmotorer.

Demonstrerade resultat och angivna kostnader

I ett inlägg om ett riktmärke som publicerades den 22 juli 2026 mätte projektet agentbaserad inferens av GLM-5.2, som där beskrivs som en blandning-av-experter-modell med 744 miljarder parametrar, 39 miljarder aktiva parametrar och 78 lager. Analysen av arbetsbelastningen byggde på 219 produktionssessioner med Claude Code, där den typiska begäran till huvudagenten innehöll 195 000 indatatoken och gav 317 utdatatoken, och där minst 90 % av indatat återanvändes i 96 % av huvudagentens turer. I inlägget rapporteras att prefixmedveten routning fångade upp 96–97 % av den cacheåteranvändning som arbetsbelastningen möjliggjorde. Med en antagen hyra för H200 på 2,71 dollar per GPU-timme uppskattas kostnaden för egen drift med två konfigurationer med 64 GPU:er till 0,05–0,08 dollar per miljon indatatoken och 1,92–3,55 dollar per miljon utdatatoken. Författarna uppger att beloppen endast omfattar GPU-hyra och förutsätter en jämn belastning.

I en separat demonstration distribuerade IBM och Red Hat GLM-5.2 på 544 NVIDIA H100-GPU:er. Modellen beskrivs i IBM Researchs redogörelse som en modell med öppna vikter och cirka 753 miljarder parametrar, varav omkring 39 miljarder är aktiva. IBM rapporterar att distributionen som mest levererade över 6,6 miljoner utdatatoken per minut samtidigt som den hanterade upp till 3 000 samtidiga kodningsagenter utan några förtida avbrott, och att en driftpunkt med 2 500 agenter upprätthöll 7 612 begäranden per minut. IBM uppger att egen drift av GLM-5.2 på H100-GPU:er med llm-d, vid nuvarande molnhyror, kostar 5–10 gånger mindre per token än motsvarande kommersiella API-priser. ”Att betjäna tusentals samtidiga agenter utan förtida avbrott ger operatörer en trovärdig väg från ett riktmärkesresultat till en produktionsdriftsättning”, säger Maroon Ayoub, senior principal-ingenjör inom maskininlärning i Red Hats inferensteknikteam.

Enligt samma redogörelse genomförde det disaggregerade dataplanet 6,2 miljoner överföringar av KV-cache, med ett genomsnitt på 2,71 GiB per överföring och utan några överföringsfel. Samtliga riktmärkesmätningar genomfördes utan serveringsfel.