Llm-D 1.0 debutează la conferința PyTorch cu o stivă de servire a inferenței pentru producție

Contribuitorii la proiectul llm-d au anunțat llm-d 1.0 pe 20 octombrie 2026, la PyTorch Conference North America, prezentând o stivă de servire distribuită a inferenței, nativă pentru Kubernetes, potrivit unui anunț al IBM Research. IBM a declarat că această versiune duce llm-d dincolo de demonstrarea unor tehnici individuale de performanță și urmărește să ajute organizațiile să implementeze modelele în propria infrastructură, pe măsură ce costurile inferenței cresc.

llm-d este conceput pentru a implementa stive de inferență pentru orice model, pe orice accelerator și în orice cloud. Red Hat, IBM și Google sunt principalii responsabili de întreținerea proiectului și au cofondat llm-d împreună cu CoreWeave și NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda și Mistral AI s-au alăturat în calitate de contribuitori. Cloud Native Computing Foundation (CNCF) găzduiește llm-d ca proiect sandbox. IBM descrie rezultatul drept o alternativă neutră față de furnizori, destinată organizațiilor care doresc performanțe de inferență de nivel de vârf, cum le numește compania, fără să depindă în totalitate de un singur furnizor proprietar de modele, de un singur cloud sau de o singură platformă hardware.

Carlos Costa, Distinguished Engineer la IBM Research și cofondator și responsabil principal de întreținerea llm-d, a declarat că versiunea 1.0 aduce maturitatea necesară pentru a rula llm-d ca pe orice alt serviciu critic. El a indicat o interfață API stabilă, posibilitatea ca mai mulți locatari cu priorități concurente să folosească aceeași infrastructură și actualizări care nu întrerup operațiunile.

Noutățile din versiunea 1.0

Notele de lansare v1.0.0 ale proiectului, publicate pe GitHub pe 20 octombrie 2026, cu etichete semnate și verificate, pun în prim-plan calitatea serviciului pentru mai mulți locatari: controlul fluxului ține cont de priorități și echitate și include eliminarea controlată a încărcării, un mecanism probabilistic de admitere, echitate adaptată programului și calcularea priorității turelor. Astfel, cererile sensibile la latență și încărcările de lucru cu agenți, care apar în rafale, pot folosi aceeași flotă fără să se priveze reciproc de resurse în condiții de supraîncărcare. Configurarea controlului fluxului este centralizată într-un singur câmp, flowControl.

Pentru operațiuni fără întreruperi, routerul beneficiază de disponibilitate ridicată, cu un nod de rezervă activ și actualizări secvențiale sigure, iar un controler DisaggregatedSet gestionează replicile de preumplere și decodare ca pe o singură unitate logică, cu implementări coordonate, actualizări sincronizate, disponibilitate condiționată de instantaneul Pod și rutare nativă pe revizii. Interfața API de configurare a routerului trece la versiunea v1, Responses API acceptă previous_response_id, iar calea de solicitare a selectorului de endpointuri este consolidată pentru a spori fiabilitatea, performanța și scalabilitatea. Este inclus și un ghid pentru acceleratoare, adaptat topologiei, destinat DRA și DRANET.

Servirea adaptată agenților adaugă un plugin session-state-producer și o afinitate de sesiune dinamică, pentru a menține conversațiile cu mai multe ture aproape de contextul lor din cache; programarea în funcție de prioritatea turelor și starea din Responses API îi ajută pe agenți să reutilizeze contextul de la o tură la alta. Versiunea aliniază componentele proiectului la v1.0.0 și adaugă elemente în ecosistem, inclusiv o integrare cu ai-dynamo/modelexpress pentru încărcarea directă între noduri a ponderilor modelelor, pachetul llm-d-api-extensions și instrumentele de diagnosticare llm-d-pd-utils. De asemenea, marchează drept învechite versiunile de imagini container llm-d-rocm proprii proiectului. Imaginile serverelor de modele includ versiuni vLLM și SGLang pentru diverse ținte de acceleratoare, iar ghidul pentru separarea preumplerii de decodare impune acum LeaderWorkerSet v0.11.1 sau o versiune mai nouă, cu API-ul DisaggregatedSet activat.

Tehnici de bază și controlul fluxului

De la lansare, proiectul s-a concentrat pe cinci abordări pentru îmbunătățirea inferenței: rutarea adaptată la memoria cache cu prefixe, care direcționează o cerere către o infrastructură ce poate deține deja contextul comun; descărcarea memoriei cache KV, care mută informațiile din cache între resursele GPU, CPU și de stocare; optimizarea inferenței în loturi; separarea preumplerii de decodare, care separă citirea unui prompt de generarea unui răspuns; și paralelismul extins al experților, care distribuie modelele mari de tip mixture-of-experts pe numeroase acceleratoare. Aceste tehnici existau înainte de versiunea 1.0; potrivit IBM, noutatea constă în integrarea lor și în maturitatea operațională din jurul acestora, precum și în disciplina operațiunilor din ziua a doua, care presupune menținerea performanței atunci când traficul se modifică, hardware-ul se defectează, software-ul este actualizat sau utilizatori diferiți concurează pentru aceleași resurse.

În versiunea 1.0, controlul fluxului, echitatea și prioritizarea sunt menite să împiedice încărcările de lucru care apar în rafale să copleșească serviciile sensibile la latență, indiferent dacă folosesc același hardware sau o combinație de acceleratoare. Cererile pot rămâne direcționate către infrastructura adecvată pe parcursul mai multor ture, pentru a menține active cache-urile cu prefixe. llm-d funcționează cu motoare de inferență precum vLLM sau SGLang, cărora le adaugă capabilități de rutare distribuită și de operare. Stephen Watt, vicepreședinte în cadrul biroului directorului tehnologic de la Red Hat, a declarat că llm-d reunește ecosistemele PyTorch și CNCF, aducând orchestrarea nativă pentru Kubernetes direct la vLLM și la motoarele moderne de inferență.

Rezultate demonstrate și costuri declarate

Într-o postare despre evaluarea comparativă, publicată la 22 iulie 2026, proiectul a măsurat servirea pentru agenți a modelului GLM-5.2, descris acolo ca un model de tip mixture-of-experts cu 744 de miliarde de parametri, dintre care 39 de miliarde activi, și 78 de straturi. Analiza volumului de lucru s-a bazat pe 219 sesiuni Claude Code de producție, în care cererea mediană a agentului principal conținea 195K de tokeni de intrare și returna 317 tokeni de ieșire, iar în 96% dintre tururile agentului principal se reutilizau cel puțin 90% dintre tokenii de intrare. Postarea arată că rutarea adaptată la prefix a valorificat 96–97% din reutilizarea cache-ului disponibilă în volumul de lucru. La un tarif presupus de închiriere pentru H200 de 2,71 USD per GPU-oră, autorii estimează că servirea găzduită intern, pe două configurații cu câte 64 de GPU-uri, costă între 0,05 și 0,08 USD per milion de tokeni de intrare și între 1,92 și 3,55 USD per milion de tokeni de ieșire. Potrivit autorilor, aceste valori includ doar costul închirierii GPU-urilor și presupun o sarcină susținută.

Într-o demonstrație separată, IBM și Red Hat au implementat GLM-5.2 pe 544 de GPU-uri NVIDIA H100. În relatarea IBM Research, modelul este descris ca având aproximativ 753 de miliarde de parametri cu ponderi deschise, dintre care aproximativ 39 de miliarde activi. IBM relatează că implementarea a furnizat, la vârf, peste 6,6 milioane de tokeni de ieșire pe minut, deservind simultan până la 3.000 de agenți de programare, fără nicio preempțiune, și că, la un nivel de operare de 2.500 de agenți, a susținut 7.612 cereri pe minut. IBM afirmă că, la tarifele actuale de închiriere din cloud, găzduirea internă a modelului GLM-5.2 pe GPU-uri H100 cu llm-d costă de 5 până la 10 ori mai puțin per token decât serviciile API comerciale echivalente. „Deservirea a mii de agenți simultani fără preempțiuni le oferă operatorilor o cale credibilă de la rezultatele unui test comparativ la o implementare în producție”, a declarat Maroon Ayoub, inginer principal senior în învățare automată în echipa de inginerie pentru inferență a Red Hat.

Potrivit aceleiași relatări, la baza acestor rezultate, planul de date dezagregat a efectuat 6,2 milioane de transferuri de cache KV, cu o medie de 2,71 GiB per transfer, fără niciun eșec de transfer, iar toate testele comparative s-au încheiat fără erori de servire.