Llm-D 1.0 esiteltiin PyTorch-konferenssissa tuotantokäyttöön tarkoitetun päättelypinon kanssa

llm-d-projektin osallistujat julkistivat llm-d 1.0:n eli Kubernetes-natiivin hajautetun päättelypalvelupinon 20. lokakuuta 2026 PyTorch Conference North America -tapahtumassa IBM Researchin tiedotteen mukaan. IBM kertoi, että julkaisu vie llm-d:n yksittäisten suorituskykytekniikoiden esittelyä pidemmälle ja pyrkii auttamaan organisaatioita ottamaan mallien käyttöönoton omiin käsiinsä päättelykustannusten noustessa.

llm-d on suunniteltu päättelypinojen käyttöönottoon millä tahansa mallilla, kiihdyttimellä ja pilvialustalla. Red Hat, IBM ja Google ovat projektin johtavia ylläpitäjiä, ja ne perustivat llm-d:n yhdessä CoreWeaven ja NVIDIAn kanssa; AMD, Cisco, Hugging Face, Intel, Lambda ja Mistral AI ovat liittyneet projektiin osallistujina. Cloud Native Computing Foundation (CNCF) ylläpitää llm-d:tä hiekkalaatikkoprojektina. IBM kuvailee tulosta toimittajariippumattomaksi vaihtoehdoksi organisaatioille, jotka haluavat sen mukaan huipputason päättelysuorituskykyä olematta täysin riippuvaisia yhdestä omisteisesta mallipalveluntarjoajasta, pilvestä tai laitteistoalustasta.

Carlos Costa, IBM Researchin arvostettu insinööri sekä llm-d:n perustaja ja johtava ylläpitäjä, kertoi version 1.0 tuovan mukanaan riittävän kypsyyden, jotta llm-d:tä voidaan käyttää muiden kriittisten palvelujen tavoin. Hän mainitsi esimerkkeinä vakaan ohjelmointirajapinnan, useat kilpailevia prioriteetteja noudattavat asiakkaat, jotka jakavat saman infrastruktuurin, sekä päivitykset, jotka eivät keskeytä toimintaa.

Mitä versio 1.0 tuo mukanaan

Projektin v1.0.0-julkaisutiedotteessa, joka julkaistiin GitHubissa 20. lokakuuta 2026 allekirjoitettuine ja varmennettuine tunnisteineen, painotetaan ensin usean asiakkaan palvelun laatua: prioriteetit ja oikeudenmukaisuuden huomioivaa vuonohjausta, johon kuuluu hallittu kuorman pudotus, todennäköisyyspohjainen pyyntöjen hyväksyntä, ohjelmat huomioiva oikeudenmukaisuus sekä vuoroprioriteettien pisteytys. Näin viiveherkät pyynnöt ja purskeiset agenttikuormat voivat jakaa saman palvelinkokonaisuuden ilman, että ne ylikuormitustilanteessa estävät toistensa palvelun. Vuonohjauksen asetukset on koottu yhden flowControl-kentän alle.

Keskeytyksettömän toiminnan varmistamiseksi reititin saa korkean käytettävyyden kuuman varapalvelimen ja turvallisten vaiheittaisten päivitysten avulla. DisaggregatedSet-ohjain hallitsee esitäyttö- ja dekoodausreplikat yhtenä loogisena kokonaisuutena, ja siihen kuuluvat koordinoidut käyttöönotot, vaiheittain synkronoidut päivitykset, Pod-tilannevedokseen sidottu valmiustarkistus sekä natiivisti tuettu versioreititys. Reitittimen määritysrajapinta siirtyy v1-versioon, Responses API tukee previous_response_id-tunnistetta, ja päätepisteen valitsimen pyyntöpolkua on vahvistettu luotettavuuden, suorituskyvyn ja skaalautuvuuden parantamiseksi. Mukana on myös topologian huomioiva kiihdytinopas DRA:lle ja DRANETille.

Agenttien tarpeet huomioiva palvelu lisää istunnon tilan tuottavan liitännäisen ja mukautuvan istuntoaffiniteetin, jotka pitävät monivuorovaikutteiset keskustelut lähellä välimuistiin tallennettua kontekstiaan. Vuorokohtainen prioriteettien ajoitus ja Responses API:n tila auttavat agentteja hyödyntämään kontekstia uudelleen vuorojen välillä. Julkaisussa projektin komponentit yhdenmukaistetaan versioon v1.0.0, ja ekosysteemiin lisätään muun muassa integraatio ai-dynamo/modelexpressin kanssa mallipainojen vertaisverkkolatausta varten, llm-d-api-extensions-paketti sekä llm-d-pd-utils-diagnostiikkatyökalut. Lisäksi projektin omien llm-d-rocm-säilökuvien koonti poistetaan käytöstä. Mallipalvelimien kuvat sisältävät vLLM- ja SGLang-koonnit eri kiihdytinkohteille, ja esitäytön ja dekoodauksen eriyttämisopas edellyttää nyt LeaderWorkerSet-versiota v0.11.1 tai uudempaa sekä DisaggregatedSet-rajapinnan käyttöönottoa.

Keskeiset tekniikat ja vuonohjaus

Julkaisustaan lähtien projekti on keskittynyt viiteen tapaan parantaa päättelyä: etuliitevälimuistin huomioivaan reititykseen, joka ohjaa pyynnön infrastruktuuriin, jossa sen jaettu konteksti saattaa jo olla; KV-välimuistin siirtoon, jossa välimuistiin tallennettua tietoa siirretään GPU:n, suorittimen ja tallennustilan välillä; eräajopäättelyn optimointiin; esitäytön ja dekoodauksen eriyttämiseen, jossa kehotteen lukeminen erotetaan vastauksen tuottamisesta; sekä laajaan asiantuntijoiden rinnakkaislaskentaan, jossa suuria asiantuntijaseosmalleja hajautetaan useille kiihdyttimille. Nämä tekniikat olivat käytössä jo ennen versiota 1.0. IBM:n mukaan uutta ovat niiden ympärille rakennettu integraatio ja operatiivinen kypsyys sekä tuotantokäytön toimintakuri: suorituskyvyn ylläpitäminen liikenteen muuttuessa, laitteiston vikaantuessa, ohjelmiston päivittyessä tai käyttäjien kilpaillessa samoista resursseista.

Versiossa 1.0 vuonohjauksen, oikeudenmukaisuuden ja priorisoinnin on tarkoitus estää purskeisia kuormia ylikuormittamasta viiveherkkiä palveluja riippumatta siitä, jakavatko kuormat saman laitteiston vai käyttävätkö ne eri kiihdyttimien yhdistelmää. Pyynnöt voidaan lisäksi pitää niille sopivassa infrastruktuurissa useiden vuorojen ajan, jotta etuliitevälimuistit pysyvät lämpiminä. llm-d toimii vLLM:n ja SGLangin kaltaisten päättelymoottorien kanssa ja lisää niiden päälle hajautetun reitityksen ja operatiivisia ominaisuuksia. Red Hatin teknologiajohtajan toimistossa varatoimitusjohtajana toimiva Stephen Watt kertoi llm-d:n yhdistävän PyTorch- ja CNCF-ekosysteemit tuomalla Kubernetes-natiivin orkestroinnin suoraan vLLM:ään ja nykyaikaisiin päättelymoottoreihin.

Esitellyt tulokset ja ilmoitetut kustannukset

22. heinäkuuta 2026 julkaistussa vertailutestijulkaisussa projektissa mitattiin GLM-5.2:n agenttipohjaista inferenssipalvelua. Mallia kuvattiin julkaisussa 744 miljardin parametrin mixture-of-experts-malliksi, jossa on 39 miljardia aktiivista parametria ja 78 kerrosta. Työkuorman analyysi perustui 219 Claude Code -istuntoon tuotantokäytössä. Niissä pääagentin pyynnön mediaani sisälsi 195 000 syötetokenia ja tuotti 317 tulostokenia, ja 96 prosentissa pääagentin vuoroista käytettiin uudelleen vähintään 90 prosenttia syötteestä. Julkaisun mukaan etuliitetietoinen reititys hyödynsi 96–97 prosenttia siitä välimuistin uudelleenkäytöstä, jonka työkuorma mahdollisti. Kun H200-vuokrahinnaksi oletetaan 2,71 dollaria GPU-tunnilta, julkaisussa itse ylläpidetyn palvelun kustannuksiksi arvioidaan kahdessa 64 GPU:n kokoonpanossa 0,05–0,08 dollaria miljoonaa syötetokenia kohden ja 1,92–3,55 dollaria miljoonaa tulostokenia kohden. Kirjoittajien mukaan nämä luvut kattavat vain GPU-vuokran ja perustuvat jatkuvaan kuormitukseen.

Erillisessä esittelyssä IBM ja Red Hat ottivat käyttöön GLM-5.2:n 544 NVIDIA H100 -grafiikkasuorittimella. IBM Researchin kuvauksessa mallia luonnehditaan avoimilla painoilla varustetuksi malliksi, jossa on noin 753 miljardia parametria ja noin 39 miljardia aktiivista parametria. IBM kertoo käyttöönoton tuottaneen huippukuormituksessa yli 6,6 miljoonaa tulostokenia minuutissa samalla, kun palvelu käsitteli jopa 3 000:ta samanaikaista koodausagenttia ilman pakkokeskeytyksiä. Lisäksi 2 500 agentin käyttökuormalla saavutettiin jatkuvasti 7 612 pyyntöä minuutissa. IBMin mukaan GLM-5.2:n itse ylläpitäminen H100-grafiikkasuorittimilla ja llm-d:llä maksaa nykyisillä pilvipalvelujen vuokrahinnoilla 5–10 kertaa vähemmän tokenia kohden kuin vastaavan kaupallisen API-palvelun käyttö. ”Tuhansien samanaikaisten agenttien palveleminen ilman pakkokeskeytyksiä antaa operaattoreille uskottavan polun vertailutestituloksesta tuotantokäyttöön”, sanoi Maroon Ayoub, Red Hatin inferenssitekniikan tiimin vanhempi pääkoneoppimisinsinööri.

Saman kuvauksen mukaan näiden tulosten taustalla eriytetty datataso suoritti 6,2 miljoonaa KV-välimuistin siirtoa, joiden keskikoko oli 2,71 GiB, eikä yksikään siirto epäonnistunut. Kaikki vertailutestit suoritettiin ilman palveluvirheitä.