Llm-D 1.0 дебютує на конференції PyTorch зі стеком інференсу для промислового використання

Учасники проєкту llm-d представили llm-d 1.0 — нативний для Kubernetes стек розподіленого обслуговування інференсу — 20 жовтня 2026 року на конференції PyTorch Conference North America, згідно з повідомленням IBM Research. В IBM зазначили, що цей випуск виводить llm-d за межі демонстрації окремих методів підвищення продуктивності й має допомогти організаціям розгортати моделі власними силами на тлі зростання витрат на інференс.

llm-d створено для розгортання стеків інференсу з будь-якою моделлю, на будь-якому прискорювачі й у будь-якій хмарі. Red Hat, IBM і Google — провідні супровідники проєкту; вони заснували llm-d разом із CoreWeave та NVIDIA. До проєкту також долучилися як учасники AMD, Cisco, Hugging Face, Intel, Lambda і Mistral AI. Cloud Native Computing Foundation (CNCF) приймає llm-d як проєкт-пісочницю. В IBM описують цей результат як незалежну від постачальників альтернативу для організацій, які прагнуть, за висловом компанії, продуктивності інференсу фронтирного класу, не покладаючись цілковито на одного постачальника пропрієтарних моделей, хмарних послуг чи апаратної платформи.

Карлос Коста, заслужений інженер IBM Research, співзасновник і провідний супровідник llm-d, зазначив, що версія 1.0 забезпечує достатній рівень зрілості, аби експлуатувати llm-d як будь-який інший критично важливий сервіс. Серед її переваг він назвав стабільний API, спільне використання тієї самої інфраструктури багатьма клієнтами з конкуруючими пріоритетами та оновлення, які не переривають роботу.

Що нового у версії 1.0

У центрі уваги приміток до випуску v1.0.0, опублікованих на GitHub 20 жовтня 2026 року з підписаними й перевіреними тегами, — якість обслуговування в багатокористувацькому середовищі: керування потоками з урахуванням пріоритетів і справедливості та контрольоване відхилення навантаження, зокрема ймовірнісний механізм допуску, справедливий розподіл ресурсів з урахуванням програм і оцінювання пріоритету ходу. Це дає змогу запитам, чутливим до затримок, і агентним навантаженням зі сплесками трафіку використовувати один парк ресурсів, не позбавляючи одне одного ресурсів під час перевантаження. Налаштування керування потоками об’єднано в одному полі flowControl.

Для безперервної роботи маршрутизатор отримує механізми високої доступності з гарячим резервуванням і безпечними поетапними оновленнями, а контролер DisaggregatedSet керує репліками попереднього заповнення й декодування як єдиним логічним блоком, забезпечуючи скоординоване розгортання, синхронізовані оновлення, перевірку готовності на основі знімка Pod і маршрутизацію за версіями. API конфігурації маршрутизатора переходить до версії v1, Responses API підтримує previous_response_id, а шлях обробки запитів до засобу вибору кінцевої точки посилено для підвищення надійності, продуктивності й масштабованості. Також додано посібник із прискорювачів, який враховує топологію та присвячений DRA і DRANET.

Обслуговування з урахуванням агентів доповнено плагіном session-state-producer і механізмом динамічної прив’язки сесії, щоб багатокрокові розмови залишалися ближче до кешованого контексту; для повторного використання контексту агентами між ходами також передбачено планування з пріоритетом ходу та стан Responses API. Усі компоненти проєкту узгоджено з версією v1.0.0. До екосистеми додано інтеграцію з ai-dynamo/modelexpress для однорангового завантаження ваг моделей, пакет llm-d-api-extensions і засоби діагностики llm-d-pd-utils. Власні збірки контейнерного образу llm-d-rocm проєкту переведено в статус застарілих. Образи серверів моделей містять збірки vLLM і SGLang для різних цільових прискорювачів, а посібник із розподілення попереднього заповнення й декодування тепер вимагає LeaderWorkerSet версії v0.11.1 або новішої з увімкненим API DisaggregatedSet.

Основні методи та керування потоками

Від самого запуску проєкт зосереджений на п’яти підходах до підвищення ефективності інференсу: маршрутизації з урахуванням кешу префіксів, яка спрямовує запит до інфраструктури, де вже може зберігатися спільний контекст; вивантаженні KV-кешу, що переміщує кешовану інформацію між ресурсами GPU, CPU та сховищами; оптимізації пакетного інференсу; розділенні попереднього заповнення й декодування, за якого читання запиту відокремлено від генерування відповіді; а також широкому паралелізмі експертів, що розподіляє великі моделі типу «суміш експертів» між багатьма прискорювачами. Усі ці методи з’явилися ще до версії 1.0; за словами IBM, новизна полягає в їх інтеграції та вищому рівні експлуатаційної зрілості, а також у дисципліні експлуатації після розгортання, яка дає змогу підтримувати продуктивність, коли змінюється трафік, виходить з ладу обладнання, оновлюється програмне забезпечення або різні користувачі конкурують за ті самі ресурси.

У версії 1.0 керування потоками, забезпечення справедливості й розподіл пріоритетів мають не допускати, щоб навантаження зі сплесками трафіку перевантажували сервіси, чутливі до затримок, незалежно від того, чи використовують ці навантаження те саме обладнання, чи охоплюють різні типи прискорювачів. Щоб підтримувати кеші префіксів у теплому стані, запити можна закріплювати за відповідною інфраструктурою на кілька ходів розмови. llm-d працює з рушіями інференсу, зокрема vLLM і SGLang, і додає до них можливості розподіленої маршрутизації та експлуатації. Стівен Вотт, віцепрезидент офісу директора з технічних питань Red Hat, зазначив, що llm-d об’єднує екосистеми PyTorch і CNCF, забезпечуючи безпосереднє керування через Kubernetes для vLLM і сучасних рушіїв інференсу.

Продемонстровані результати й заявлені витрати

У дописі з результатами бенчмарку, опублікованому 22 липня 2026 року, проєкт виміряв обслуговування запитів для агентних сценаріїв із GLM-5.2 — описаної там як моделі типу «суміш експертів» із 744 млрд параметрів, 39 млрд активних параметрів і 78 шарами. Аналіз робочого навантаження спирався на 219 виробничих сеансів Claude Code, у яких медіанний запит головного агента містив 195K вхідних токенів і повертав 317 вихідних токенів, а в 96% ходів головного агента повторно використовувалося щонайменше 90% вхідних даних. У дописі зазначено, що маршрутизація з урахуванням префіксів забезпечила 96–97% повторного використання кешу, доступного за цього робочого навантаження. За умови орендної ставки H200 у розмірі $2.71 за GPU-годину автори оцінюють вартість самостійного розгортання на двох конфігураціях із 64 GPU у $0.05–$0.08 за мільйон вхідних токенів і $1.92–$3.55 за мільйон вихідних токенів; за словами авторів, ці суми враховують лише оренду GPU та передбачають стабільне навантаження.

В окремій демонстрації IBM і Red Hat розгорнули GLM-5.2 на 544 графічних процесорах NVIDIA H100. В обліковому записі IBM Research її охарактеризовано як модель із відкритими вагами, що має приблизно 753 млрд параметрів, з яких близько 39 млрд є активними. За даними IBM, під час пікового навантаження розгортання забезпечувало понад 6,6 мільйона вихідних токенів за хвилину, обслуговуючи до 3 000 одночасних агентів програмування без примусових переривань; за режиму роботи з 2 500 агентами стабільно оброблялося 7 612 запитів за хвилину. IBM стверджує, що за поточних ставок оренди хмарних ресурсів самостійне розгортання GLM-5.2 на GPU H100 із llm-d обходиться в 5–10 разів дешевше за токен, ніж еквівалентні тарифи комерційних API. «Обслуговування тисяч одночасних агентів без примусових переривань дає операторам реалістичний шлях від результату бенчмарку до виробничого розгортання», — сказав Марун Аюб, старший головний інженер із машинного навчання в команді інженерії інференсу Red Hat.

За даними того самого джерела, в основі цих результатів — дезагрегована площина даних, яка виконала 6,2 мільйона передавань кешу KV із середнім обсягом 2,71 GiB на передавання, не зазнавши жодного збою під час передавання; усі бенчмарки завершилися без помилок обслуговування.