Llm-D 1.0 lanceres på PyTorch-konferencen med en inferensstak til produktionsbrug

Bidragydere til llm-d-projektet annoncerede llm-d 1.0, en Kubernetes-nativ, distribueret inferensplatform, den 20. oktober 2026 på PyTorch Conference North America, ifølge en meddelelse fra IBM Research. IBM sagde, at udgivelsen løfter llm-d ud over demonstrationer af individuelle ydeevneteknikker og skal hjælpe organisationer med at hjemtage modelimplementeringen, efterhånden som inferensomkostningerne stiger.

llm-d er udviklet til at udrulle inferensstakke for enhver model på enhver accelerator og i enhver cloud. Red Hat, IBM og Google er projektets ledende vedligeholdere og grundlagde llm-d sammen med CoreWeave og NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda og Mistral AI er kommet til som bidragydere. Cloud Native Computing Foundation (CNCF) er vært for llm-d som et sandbox-projekt. IBM beskriver resultatet som et leverandørneutralt alternativ for organisationer, der ønsker det, IBM kalder inferensydelse i topklasse, uden at være helt afhængige af én proprietær modeludbyder, cloud eller hardwareplatform.

Carlos Costa, Distinguished Engineer hos IBM Research og medstifter og ledende vedligeholder af llm-d, sagde, at version 1.0 tilfører den modenhed, der skal til for at drive llm-d som enhver anden kritisk tjeneste. Han fremhævede en stabil API, flere lejere med konkurrerende prioriteter, der deler den samme infrastruktur, samt opgraderinger, der ikke afbryder driften.

Hvad version 1.0 tilfører

Projektets udgivelsesnoter til v1.0.0, der blev offentliggjort på GitHub den 20. oktober 2026 med signerede og verificerede tags, fremhæver først servicekvalitet for flere lejere: flowstyring, der tager højde for prioritering og fairness, med kontrolleret aflastning af belastning, herunder en probabilistisk adgangskontrol, programbevidst fairness og prioritering efter tur. Det gør det muligt for latenstidsfølsomme anmodninger og arbejdsbelastninger fra agenttrafik med kraftige udsving at dele en serverflåde uden at udsulte hinanden under overbelastning. Konfigurationen af flowstyringen samles i ét enkelt flowControl-felt.

For at sikre drift uden nedetid får routeren høj tilgængelighed med varm standby og sikre løbende opdateringer, mens en DisaggregatedSet-controller håndterer prefill- og decode-replikaer som én logisk enhed med koordinerede udrulninger, opgraderinger i takt, klarmelding, der afhænger af et Pod-snapshot, og indbygget routing efter revision. Routerens konfigurations-API opgraderes til v1, Responses API understøtter previous_response_id, og endpoint-pickerens anmodningssti styrkes med henblik på pålidelighed, ydeevne og skalerbarhed. Der medfølger en vejledning om acceleratorer, der tager højde for topologien, til DRA og DRANET.

Agentbevidst inferensservering tilføjer et plugin til produktion af sessionstilstand og en dynamisk sessionstilknytning, så samtaler med flere ture holdes tæt på den cachelagrede kontekst. Prioritering efter tur og tilstand i Responses API hjælper agenter med at genbruge konteksten på tværs af ture. Udgivelsen samler projektets komponenter under v1.0.0 og tilføjer dele til økosystemet, herunder en integration med ai-dynamo/modelexpress til peer-to-peer-indlæsning af modelvægte, pakken llm-d-api-extensions og diagnosticeringsværktøjerne llm-d-pd-utils. Projektets egne builds af llm-d-rocm-containerafbildningen udfases. Serverafbildningerne omfatter builds af vLLM og SGLang til forskellige acceleratormål, og vejledningen om adskillelse af prefill og decode kræver nu LeaderWorkerSet v0.11.1 eller nyere med DisaggregatedSet-API’et aktiveret.

Kerneteknikker og flowstyring

Siden lanceringen har projektet fokuseret på fem metoder til at forbedre inferens: routing, der tager højde for præfikscache, og som sender en anmodning til infrastruktur, der muligvis allerede rummer den delte kontekst; aflæsning af KV-cache, som flytter cachelagret information mellem GPU-, CPU- og lagerressourcer; optimering af batchinferens; adskillelse af prefill og decode, som skiller læsningen af en prompt fra genereringen af et svar; samt bred ekspertparallelisering, der fordeler store mixture-of-experts-modeller på tværs af mange acceleratorer. Disse teknikker fandtes før version 1.0. Ifølge IBM er det nye integrationen og den driftsmæssige modenhed omkring dem samt disciplinen i den daglige drift: at fastholde ydeevnen, når trafikken ændrer sig, hardware svigter, software opdateres, eller forskellige brugere konkurrerer om de samme ressourcer.

I version 1.0 skal flowstyring, fairness og prioritering forhindre, at arbejdsbelastninger med kraftige udsving overbelaster latenstidsfølsomme tjenester, uanset om arbejdsbelastningerne deler den samme hardware eller spænder over en blanding af acceleratorer. Anmodninger kan forblive knyttet til den relevante infrastruktur over flere ture, så præfikscacherne holdes varme. llm-d fungerer sammen med inferensmotorer som vLLM eller SGLang og føjer distribueret routing og driftsfunktioner til ovenpå. Stephen Watt, vicepræsident på Red Hats kontor for teknologidirektøren, sagde, at llm-d forener PyTorch- og CNCF-økosystemerne ved at bringe Kubernetes-nativ orkestrering direkte til vLLM og moderne inferensmotorer.

Dokumenterede resultater og oplyste omkostninger

I et benchmarkindlæg offentliggjort den 22. juli 2026 målte projektet agentbaseret afvikling af GLM-5.2, der her blev beskrevet som en mixture-of-experts-model med 744 mia. parametre, 39 mia. aktive parametre og 78 lag. Analysen af arbejdsbelastningen byggede på 219 produktionssessioner med Claude Code, hvor anmodningen fra hovedagenten havde en median på 195.000 inputtokens og returnerede 317 outputtokens, og hvor mindst 90 % af inputtet blev genbrugt i 96 % af hovedagentens ture. Indlægget rapporterer, at præfiksbevidst routing udnyttede 96–97 % af den cachegenbrug, som arbejdsbelastningen muliggjorde. Med en antaget lejepris for H200 på 2,71 $ pr. GPU-time angiver det, at selvhostet afvikling på to konfigurationer med 64 GPU’er koster 0,05–0,08 $ pr. million inputtokens og 1,92–3,55 $ pr. million outputtokens. Forfatterne oplyser, at beløbene kun dækker GPU-leje og forudsætter en vedvarende belastning.

I en separat demonstration implementerede IBM og Red Hat GLM-5.2 på 544 NVIDIA H100-GPU’er. I IBM Researchs redegørelse beskrives modellen som en open-weight-model med cirka 753 mia. parametre, hvoraf omkring 39 mia. er aktive. IBM rapporterer, at implementeringen på sit højeste leverede mere end 6,6 millioner outputtokens i minuttet, mens den betjente op til 3.000 samtidige kodeagenter uden præemptioner, og at en driftstilstand med 2.500 agenter opretholdt 7.612 anmodninger i minuttet. IBM oplyser, at selvhosting af GLM-5.2 på H100-GPU’er med llm-d ved de aktuelle cloudlejepriser koster 5 til 10 gange mindre pr. token end tilsvarende kommercielle API-priser. »At betjene tusindvis af samtidige agenter uden præemptioner giver operatørerne en troværdig vej fra et benchmarkresultat til en produktionsimplementering,« sagde Maroon Ayoub, senior principal-ingeniør inden for maskinlæring i Red Hats team for inferensudvikling.

Ifølge samme redegørelse gennemførte det disaggregerede dataplan 6,2 millioner overførsler af KV-cache med et gennemsnit på 2,71 GiB pr. overførsel og uden overførselsfejl, og alle benchmarks blev gennemført uden serveringsfejl.