llm-d 1.0 toi moniasiakkuuden tuotantokäyttöön

CNCF:n sandbox-hankkeen llm-d 1.0 julkaistiin 20. lokakuuta 2026. Kubernetes-pohjaisen pinon vakaa versio tuo jaettuun mallipäättelyyn moniasiakkuuden liikenteenohjauksen, korkean käytettävyyden reitityksen ja hallitut päivitykset. vLLM ja SGLang suorittavat edelleen varsinaisen mallipäättelyn; llm-d ohjaa niiden palvelimille tulevia pyyntöjä ja hallitsee hajautetun palvelun osia. Tuotantokäyttöä koskeva väite perustuu nyt ennen kaikkea siihen, miten pino käsittelee ruuhkaa, vikatilanteita ja päivityksiä.

PyTorch Conference North America -tapahtuman yhteydessä esitellyn hankkeen perustajiin kuuluvat Red Hat, IBM, Google Cloud, CoreWeave ja NVIDIA, ja IBM Researchin insinööri sekä llm-d:n pääylläpitäjä Carlos Costa tiivisti painotuksen IBM Researchin julkaisussa: ”llm-d is ready for day 2 operations.” Ilmaus viittaa työhön, joka alkaa palvelun käyttöönoton jälkeen: kapasiteetin jakamiseen, toimintavarmuuteen ja muutoksiin käynnissä olevassa järjestelmässä. Nämä ovat eri kysymyksiä kuin yhden päättelykokoonpanon suurin mahdollinen nopeus.

Jaettu kapasiteetti saa prioriteetit

Moniasiakkuuden näkyvin muutos on pyyntöjen käsittely ennen kuin ne ehtivät kuormittaa mallipalvelimia. Reititin muodostaa pyynnölle virran asiakkaan tai työkuorman tunnisteesta ja prioriteettiluokasta sekä pitää virroille erilliset jonot. Se lähettää tärkeämmän luokan pyyntöjä ensin ja jakaa vuoroja saman luokan asiakkaiden kesken. Näin yksi nopeasti kasvava kuorma ei automaattisesti täytä kaikkien muidenkin käyttämää palvelinryhmää.

Tilanne on konkreettinen, kun nopeaa vastausta odottava käyttäjä ja useita samanaikaisia kutsuja tekevä agentti käyttävät samaa päätepistettä. Agentin pyyntöjä voidaan pitää reitittimen jonossa sen sijaan, että ne lähetettäisiin jo ruuhkautuneille taustapalvelimille. Jos kysyntä ylittää käytettävissä olevan kapasiteetin, sisäänpääsyn hallinta voi myös karsia kuormaa. Järjestelmän oletustoiminta noudattaa silti saapumisjärjestystä, joten prioriteettikäytäntö on määriteltävä erikseen.

Monivuoroisissa agenttitehtävissä reititin voi ohjata seuraavan pyynnön samalle palvelimelle, jolla aiempaa keskustelukontekstia on KV-välimuistissa. Kun kyseinen palvelin täyttyy, pyyntö voidaan siirtää toiselle. Vuoron huomioiva priorisointi ja Responses API:n tilatuki puolestaan vähentävät tarvetta lähettää koko keskusteluhistoria uudelleen joka kutsulla. Välimuistin hyöty riippuu siitä, palaako työkuorma todella samaan kontekstiin; pelkkä agenttien määrä ei sitä takaa.

Reitittimen vaihto ja mallin päivitys on sovitettu liikenteeseen

Korkea käytettävyys alkaa pyyntöjä ohjaavasta Endpoint Pickeristä. Sille voidaan pitää valmiina varainstanssi, joka ottaa ajoituksen hoitaakseen aktiivisen instanssin vaihtuessa tai vikaantuessa. Tämä suojaa reititystä suunnitellun käyttöönoton aikana ja pienentää yksittäisen reititinvian vaikutusta. Mekanismi ei yksin takaa, ettei mallipalvelin, verkko tai sovellus voisi aiheuttaa katkosta.

Hajautetussa päättelyssä syötteen käsittely eli prefill ja vastauksen tuottaminen eli decode voidaan sijoittaa eri palvelinryhmiin. Jaosta on hyötyä kapasiteetin mitoituksessa, mutta päivitys vaatii yhteensopivat osat molempiin ryhmiin. DisaggregatedSet käsittelee niitä yhtenä kokonaisuutena ja ohjaa pyynnöt uuden version parille vasta, kun tarvittavat osat ovat valmiit. Päivitystä ei siten tarvitse tehdä vaihtamalla koko palvelinryhmää kerralla käsin.

Myös konfigurointirajapinta on vakautettu ja versioitu, mikä helpottaa asetusten automatisointia alustatiimin omissa työkaluissa. Käyttöympäristöön jää silti sovitettavaa: varainstanssi, reitittimen asetukset sekä eriytettyjen palvelinryhmien valmius on pidettävä kunnossa. Julkaisun kuvaama keskeytyksetön päivitys koskee näitä reititys- ja käyttöönoton mekanismeja, ei lupausta kaikkien mahdollisten kokoonpanojen häiriöttömyydestä.

vLLM ja SGLang toimivat saman ohjauskerroksen takana

llm-d:n rooli on koordinoida mallipalvelimia, ei korvata niiden päättelymoottoria. Google Cloudin konferenssiesittelyssä tuhat eristettyä agenttia käytti yhtä llm-d-päätepistettä vLLM:n, SGLangin sekä TPU- ja GPU-kapasiteetin yli. Esittely havainnollistaa, että eri moottoreita ja kiihdyttimiä voidaan koota yhteisen ohjauksen alle. Agenttien lukumäärä kuvaa tätä esitystä, eikä siitä voi päätellä tavallisen tuotantoasennuksen viivettä tai kapasiteettia.

Yhteinen kerros valitsee pyynnölle palvelimen esimerkiksi kuorman, ennakoidun viiveen ja välimuistissa olevan kontekstin perusteella. Projekti kuvaa käyttöönotettuja polkuja NVIDIA-, AMD- ja Intel-laitteistolle sekä Google Cloudin TPU-kiihdyttimille. Yhteinen reititys ei kuitenkaan tee laitekohtaisista tiedonsiirto- ja mallipalvelinintegraatioista samanlaisia. Kunkin yhdistelmän tuki määräytyy sille dokumentoidun käyttöpolun mukaan.

Tämä ero on olennainen alustatiimille, jolla on jo toimiva vLLM- tai SGLang-asennus. Yksi moottori voi hoitaa ennakoitavan kuorman ilman uutta ohjauskerrosta. llm-d:n lisäarvo kasvaa, kun pyyntöjä pitää jakaa useille palvelimille, asiakkaille on annettava eri etusijat tai keskustelukontekstin sijainti vaikuttaa kustannuksiin ja vasteaikaan. Kyse on arkkitehtuurista tehtävästä valinnasta, ei yleispätevästä suorituskykylupauksesta.

Tuotantokelpoisuus tuo myös ylläpitotyötä

Jaetun palvelun hallinta vaatii enemmän kuin reitittimen asentamisen. Ylläpitäjän on määriteltävä asiakkaiden prioriteetit, seurattava jonojen ja palvelinten kuormaa sekä sovitettava Kubernetes-osat käytössä olevaan ympäristöön. Prefill- ja decode-ryhmien erottaminen, välimuistin sijoittelu ja laitteistokohtaiset liitännät tuovat lisää asetuksia ja valvottavia riippuvuuksia. Uudet hallintamekanismit ovat hyödyllisimpiä silloin, kun ne ratkaisevat jo olemassa olevan kuorman tai päivitysten ongelman.

Projektin seuraaviin kehityskohteisiin kuuluvat usean aktiivisen reitittimen rinnakkaiskäyttö sekä keskeneräisen päättelypyynnön siirtäminen vikatilanteessa. Nykyinen varainstanssi turvaa reitityksen jatkumista, mutta käynnissä olevan pyynnön jatkaminen toisessa paikassa on erillinen ongelma. Sen ratkaisu määrittää seuraavan käytettävyyttä koskevan rajan palveluille, joissa yksittäisenkin pitkän agenttitehtävän keskeytyminen on kallista.

Lue myös: