Llm-D 1.0 lanseres på PyTorch Conference med en inferensstakk for produksjonsbruk

Bidragsytere til llm-d-prosjektet kunngjorde llm-d 1.0, en Kubernetes-basert, distribuert stakk for inferenstjenester, 20. oktober 2026 på PyTorch Conference North America, ifølge en kunngjøring fra IBM Research. IBM sa at lanseringen tar llm-d forbi demonstrasjoner av enkeltstående ytelsesteknikker, og skal hjelpe organisasjoner med å ta modellutrullingen internt etter hvert som inferenskostnadene øker.

llm-d er utviklet for å distribuere inferensstakker for enhver modell, på enhver akselerator og i enhver sky. Red Hat, IBM og Google er prosjektets hovedvedlikeholdere og grunnla llm-d sammen med CoreWeave og NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda og Mistral AI har sluttet seg til som bidragsytere. Cloud Native Computing Foundation (CNCF) er vertskap for llm-d som et sandkasseprosjekt. IBM beskriver resultatet som et leverandørnøytralt alternativ for organisasjoner som ønsker det IBM omtaler som inferensytelse på nivå med de fremste løsningene, uten å være helt avhengige av én proprietær modelltilbyder, én sky eller én maskinvareplattform.

Carlos Costa, Distinguished Engineer ved IBM Research og medgründer og hovedvedlikeholder av llm-d, sa at versjon 1.0 gir prosjektet den modenheten som trengs for å kjøre llm-d som enhver annen kritisk tjeneste. Han viste til et stabilt API, flere leietakere med motstridende prioriteringer som deler den samme infrastrukturen, og oppgraderinger som ikke avbryter driften.

Dette kommer i versjon 1.0

Prosjektets versjonsmerknader for v1.0.0, publisert på GitHub 20. oktober 2026 med signerte og verifiserte tagger, fremhever først tjenestekvalitet for flere leietakere: flytkontroll som tar hensyn til prioritering og rettferdighet, med kontrollert avvisning av belastning, inkludert en probabilistisk opptaksmekanisme, programbevisst rettferdighet og prioriteringspoeng for hver tur. Dette gjør at forespørsler som er følsomme for forsinkelser, og agentarbeidsbelastninger med store svingninger, kan dele en ressursgruppe uten at noen av dem blir stående uten ressurser ved overbelastning. Konfigurasjonen for flytkontroll samles under ett enkelt felt, flowControl.

For drift uten nedetid får ruteren høy tilgjengelighet med varm reserve og trygge, trinnvise oppdateringer. En DisaggregatedSet-kontroller håndterer prefyllings- og dekodingsreplikaer som én logisk enhet, med koordinerte utrullinger, synkroniserte oppgraderinger, beredskap som avhenger av Pod-snapshot og innebygd ruting etter revisjon. Konfigurasjons-API-et for ruteren oppgraderes til v1, Responses API støtter previous_response_id, og forespørselsbanen for endepunktvelgeren styrkes med tanke på pålitelighet, ytelse og skalerbarhet. En veiledning om akseleratorer som tar hensyn til topologi, for DRA og DRANET, er inkludert.

Agentbevisst betjening får et programtillegg for produksjon av økttilstand og dynamisk økttilknytning, slik at samtaler med flere runder holdes nær den mellomlagrede konteksten. Planlegging med prioritering av hver tur og tilstand i Responses API skal hjelpe agenter med å gjenbruke kontekst på tvers av turer. Utgivelsen samordner prosjektets komponenter på v1.0.0, legger til økosystemkomponenter, blant annet en integrasjon med ai-dynamo/modelexpress for direkte lasting av modellvekter mellom noder, pakken llm-d-api-extensions og diagnoseverktøyet llm-d-pd-utils, og avvikler prosjektets egne bygg av llm-d-rocm-containerbilder. Modellserverbildene omfatter bygg av vLLM og SGLang for ulike akseleratormål, og veiledningen for oppdeling av prefylling og dekoding krever nå LeaderWorkerSet v0.11.1 eller nyere med DisaggregatedSet API aktivert.

Kjerneteknikker og flytkontroll

Siden lanseringen har prosjektet fokusert på fem metoder for å forbedre inferens: ruting som tar hensyn til prefiksmellomlager, og sender en forespørsel til infrastruktur som kanskje allerede har den delte konteksten; avlasting av KV-mellomlager, som flytter mellomlagret informasjon mellom GPU-, CPU- og lagringsressurser; optimalisering av batchinferens; oppdeling av prefylling og dekoding, som skiller lesingen av en prompt fra genereringen av et svar; og bred ekspertparallellisme, som fordeler store blandinger-av-eksperter-modeller på mange akseleratorer. Disse teknikkene fantes før versjon 1.0. Ifølge IBM er nyheten integrasjonen og den driftsmessige modenheten rundt dem, samt disiplinen i dag-2-driften: å opprettholde ytelsen når trafikken endrer seg, maskinvare svikter, programvare oppdateres eller ulike brukere konkurrerer om de samme ressursene.

I versjon 1.0 skal flytkontroll, rettferdighet og prioritering hindre at arbeidsbelastninger med store svingninger overvelder tjenester som er følsomme for forsinkelser, enten arbeidsbelastningene deler samme maskinvare eller går på en blanding av akseleratorer. Forespørsler kan dessuten forbli knyttet til riktig infrastruktur over flere turer, slik at prefiksmellomlagrene holdes varme. llm-d fungerer sammen med inferensmotorer som vLLM og SGLang, og legger til distribuert ruting og driftsfunksjoner. Stephen Watt, visepresident ved kontoret til teknologidirektøren i Red Hat, sa at llm-d forener PyTorch- og CNCF-økosystemene ved å bringe Kubernetes-basert orkestrering direkte til vLLM og moderne inferensmotorer.

Dokumenterte resultater og oppgitte kostnader

I et innlegg om referansetester publisert 22. juli 2026 målte prosjektet agentbasert inferensdrift for GLM-5.2, som der ble beskrevet som en blanding-av-eksperter-modell med 744 milliarder parametere, 39 milliarder aktive parametere og 78 lag. Analysen av arbeidsbelastningen bygget på 219 produksjonsøkter med Claude Code. I disse hadde forespørslene fra hovedagenten en median på 195 000 inndatatokener og ga 317 utdata-tokener, og i 96 % av turene til hovedagenten ble minst 90 % av inndataene gjenbrukt. Innlegget oppgir at ruting som tar hensyn til prefikser, fanget opp 96–97 % av cachegjenbruken som arbeidsbelastningen muliggjorde. Med en antatt leiepris for H200 på 2,71 dollar per GPU-time anslår det at egen drift på to oppsett med 64 GPU-er koster fra 0,05 til 0,08 dollar per million inndatatokener og fra 1,92 til 3,55 dollar per million utdata-tokener. Forfatterne presiserer at beløpene bare dekker leie av GPU-er og forutsetter vedvarende belastning.

I en separat demonstrasjon satte IBM og Red Hat GLM-5.2 i drift på 544 NVIDIA H100-GPU-er. I beretningen fra IBM Research omtales modellen som en modell med åpne vekter og omtrent 753 milliarder parametere, hvorav rundt 39 milliarder er aktive. IBM oppgir at løsningen på topp leverte mer enn 6,6 millioner utdata-tokener per minutt samtidig som den betjente opptil 3 000 samtidige kodeagenter uten at noen ble avbrutt, og at et driftspunkt med 2 500 agenter opprettholdt 7 612 forespørsler per minutt. IBM opplyser at egen drift av GLM-5.2 på H100-GPU-er med llm-d, med dagens priser på leie av skykapasitet, koster 5 til 10 ganger mindre per token enn tilsvarende kommersielle API-priser. «Å betjene tusenvis av samtidige agenter uten avbrudd gir operatørene en troverdig vei fra et referansetestresultat til produksjonssetting», sa Maroon Ayoub, senior hovedingeniør innen maskinlæring i Red Hats team for inferensutvikling.

Ifølge den samme beretningen fullførte det disaggregerte dataplanet 6,2 millioner overføringer av KV-hurtigbufferen, med et gjennomsnitt på 2,71 GiB per overføring, uten noen overføringsfeil. Alle referansetestene ble fullført uten feil under inferensdriften.