Llm-D 1.0 wordt gepresenteerd op PyTorch Conference met inference-stack voor productieomgevingen

Bijdragers aan het llm-d-project maakten op 20 oktober 2026 tijdens PyTorch Conference North America de release van llm-d 1.0 bekend: een Kubernetes-native stack voor gedistribueerde inferentie, volgens een aankondiging van IBM Research. IBM zei dat llm-d met deze release verder gaat dan het demonstreren van afzonderlijke prestatietechnieken en dat de release organisaties moet helpen de implementatie van modellen in eigen beheer te nemen nu de kosten van inferentie stijgen.

llm-d is ontwikkeld om inferentiestacks te implementeren voor elk model, op elke accelerator en in elke cloud. Red Hat, IBM en Google zijn de hoofdbeheerders van het project en hebben llm-d samen met CoreWeave en NVIDIA opgericht; AMD, Cisco, Hugging Face, Intel, Lambda en Mistral AI zijn als bijdragers toegetreden. De Cloud Native Computing Foundation (CNCF) huisvest llm-d als sandboxproject. IBM beschrijft het resultaat als een merkonafhankelijk alternatief voor organisaties die de inferentieprestaties van frontierklasse willen behalen, zoals IBM het noemt, zonder volledig afhankelijk te zijn van één aanbieder van propriëtaire modellen, één cloud of één hardwareplatform.

Carlos Costa, Distinguished Engineer bij IBM Research en medeoprichter en hoofdbeheerder van llm-d, zei dat versie 1.0 llm-d de volwassenheid biedt om het net als elke andere kritieke dienst te gebruiken. Hij wees daarbij op een stabiele API, meerdere tenants met concurrerende prioriteiten die dezelfde infrastructuur delen, en upgrades die de bedrijfsvoering niet onderbreken.

Wat versie 1.0 toevoegt

De releaseopmerkingen voor v1.0.0 van het project, op 20 oktober 2026 gepubliceerd op GitHub met ondertekende en geverifieerde tags, beginnen met de kwaliteit van dienstverlening voor meerdere tenants: prioriteits- en eerlijkheidsbewuste stroomregeling met gecontroleerde belastingafbouw, waaronder een probabilistische toelatingsregelaar, programmabewuste eerlijkheid en prioriteitsscores per beurt. Hierdoor kunnen vertragingsgevoelige verzoeken en workloads van agents met piekbelasting dezelfde servergroep delen zonder dat ze elkaar bij overbelasting uithongeren. De configuratie voor stroomregeling is samengebracht in één veld, flowControl.

Voor bedrijfsvoering zonder downtime krijgt de router een hoge beschikbaarheid met een warme stand-by en veilige doorlopende updates. Een DisaggregatedSet-controller beheert prefill- en decodereplica’s als één logische eenheid, met gecoördineerde uitrol, upgrades in lockstep, gereedheidscontroles die afhankelijk zijn van een Pod-snapshot en native routering op basis van revisies. De configuratie-API van de router wordt opgewaardeerd naar v1, de Responses API ondersteunt previous_response_id en het aanvraagpad van de endpointkiezer is robuuster gemaakt met het oog op betrouwbaarheid, prestaties en schaalbaarheid. Ook is een gids voor accelerators opgenomen die rekening houdt met de topologie en betrekking heeft op DRA en DRANET.

Agentbewuste dienstverlening voegt een plug-in voor sessiestatusproducenten en dynamische sessieaffiniteit toe, zodat gesprekken met meerdere beurten dicht bij hun gecachte context blijven. Ook zijn er planning op basis van prioriteit per beurt en de status van de Responses API, zodat agents context tussen beurten opnieuw kunnen gebruiken. De release brengt de componenten van het project allemaal op versie v1.0.0, voegt onderdelen voor het ecosysteem toe, waaronder een integratie met ai-dynamo/modelexpress voor het peer-to-peer laden van modelgewichten, het pakket llm-d-api-extensions en de diagnosehulpmiddelen llm-d-pd-utils, en stelt de eigen builds van de llm-d-rocm-containerimages van het project buiten gebruik. De images van modelservers bevatten builds van vLLM en SGLang voor verschillende acceleratordoelen. De gids voor het scheiden van prefill en decodering vereist nu LeaderWorkerSet v0.11.1 of hoger, met de DisaggregatedSet API ingeschakeld.

Kerntechnieken en stroomregeling

Sinds de lancering richt het project zich op vijf manieren om inferentie te verbeteren: routering die rekening houdt met de prefixcache, waarbij een verzoek wordt doorgestuurd naar infrastructuur die de gedeelde context mogelijk al bevat; het offloaden van de KV-cache, waarbij gecachte informatie wordt verplaatst tussen GPU-, CPU- en opslagbronnen; optimalisatie van batchinferentie; het scheiden van prefill en decodering, waarbij het lezen van een prompt wordt gescheiden van het genereren van een antwoord; en brede expertparallelisatie, waarbij grote mixture-of-expertsmodellen over veel accelerators worden verdeeld. Deze technieken bestonden al vóór versie 1.0. Volgens IBM is de vernieuwing de integratie en operationele volwassenheid eromheen, samen met de discipline van dag-2-beheer: de prestaties op peil houden wanneer het verkeer verandert, hardware uitvalt, software wordt bijgewerkt of verschillende gebruikers om dezelfde resources concurreren.

Binnen versie 1.0 moeten stroomregeling, eerlijkheid en prioritering voorkomen dat workloads met piekbelasting vertragingsgevoelige diensten overbelasten, ongeacht of de workloads dezelfde hardware delen of verschillende accelerators combineren. Verzoeken kunnen bovendien gedurende meerdere beurten aan de juiste infrastructuur gekoppeld blijven, zodat prefixcaches warm blijven. llm-d werkt samen met inferentie-engines zoals vLLM en SGLang en voegt daar gedistribueerde routering en operationele mogelijkheden aan toe. Stephen Watt, vicepresident bij het kantoor van de chief technology officer van Red Hat, zei dat llm-d de ecosystemen van PyTorch en CNCF samenbrengt door orkestratie die native is voor Kubernetes rechtstreeks naar vLLM en moderne inferentie-engines te brengen.

Aangetoonde resultaten en vermelde kosten

In een benchmarkbericht dat op 22 juli 2026 werd gepubliceerd, mat het project hoe GLM-5.2 werd aangeboden voor agentische workloads. Het model werd daarin beschreven als een mixture-of-expertsmodel met 744 miljard parameters, 39 miljard actieve parameters en 78 lagen. De workloadanalyse was gebaseerd op 219 Claude Code-sessies in productie, waarin een verzoek van de hoofdagent mediaan 195K inputtokens bevatte en 317 outputtokens opleverde, en bij 96% van de beurten van de hoofdagent minstens 90% van de input werd hergebruikt. Volgens het bericht wist routering die rekening houdt met prefixes 96–97% van het cachehergebruik dat de workload mogelijk maakte te benutten. Bij een verondersteld huurtarief van H200-GPU’s van $2,71 per GPU-uur komen de auteurs voor zelf gehoste serving op twee configuraties met 64 GPU’s uit op $0,05 tot $0,08 per miljoen inputtokens en $1,92 tot $3,55 per miljoen outputtokens. Volgens de auteurs omvatten deze bedragen alleen de huur van GPU’s en gaan ze uit van een aanhoudende belasting.

In een afzonderlijke demonstratie implementeerden IBM en Red Hat GLM-5.2 op 544 NVIDIA H100-GPU’s. In het verslag van IBM Research wordt het model omschreven als een model met open gewichten, ongeveer 753 miljard parameters en circa 39 miljard actieve parameters. IBM meldt dat de implementatie op piekmomenten meer dan 6,6 miljoen outputtokens per minuut leverde, terwijl tot 3.000 programmeeragents gelijktijdig werden bediend zonder preëmpties, en dat bij een configuratie met 2.500 agents 7.612 verzoeken per minuut werden verwerkt. Volgens IBM kost zelf gehoste GLM-5.2 op H100-GPU’s met llm-d, tegen de huidige huurtarieven voor clouddiensten, per token 5 tot 10 keer minder dan vergelijkbare commerciële API-prijzen. ‘Duizenden agents gelijktijdig bedienen zonder preëmpties biedt operators een geloofwaardige route van een benchmarkresultaat naar een implementatie in productie’, aldus Maroon Ayoub, senior principal engineer voor machine learning in het inference-engineeringteam van Red Hat.

Volgens hetzelfde verslag voltooide de gedisaggregeerde dataplane achter deze resultaten 6,2 miljoen KV-cacheoverdrachten, met een gemiddelde omvang van 2,71 GiB per overdracht en zonder overdrachtsfouten. Alle benchmarks werden voltooid zonder fouten bij het aanbieden van modellen.