Google Cloud випустила llm-d 1.0 із маршрутизацією з урахуванням кешу для флотів TPU і GPU
Команда Google випустила llm-d 1.0 — першу стабільну версію свого стека розподіленого інференсу. Цей відкритий, нативний для Kubernetes рівень перетворює сервери моделей vLLM або SGLang на єдиний узгоджений пул. Його представили на конференції PyTorch Conference North America. Він орієнтований на агентні та RL-навантаження із самостійним розгортанням, де балансування навантаження за принципом round-robin перестає працювати.
Коротко
- Стек для обслуговування: Google повідомляє про опублікований бенчмарк на багаторегіональному розгортанні GKE із 17 000 вузлів.
- Працює на: Kubernetes із графічними процесорами NVIDIA, AMD або Intel чи TPU Google, поверх vLLM або SGLang.
- Продуктивність: заявлені постачальниками покращення забезпечуються маршрутизацією з урахуванням кешу, багаторівневим вивантаженням KV-кешу та розділенням prefill/decode.
- Найкращий результат: скорочення медіанного TTFT більш ніж на 85% і зростання пропускної здатності у 2,4 раза на навантаженні кодування на TPU Ironwood.
- Найгірший результат: розподіл часу для RL підвищує коефіцієнт використання прискорювача лише до понад 70%, тому приблизно 30% часу він залишається бездіяльним.
Що таке llm-d 1.0?
llm-d заснували у 2025 році Red Hat, IBM, Google Cloud, CoreWeave та NVIDIA. Red Hat, IBM і Google є головними супроводжувачами проєкту. У проєкті беруть участь понад 500 контриб’юторів із більш ніж 25 організацій. Це проєкт CNCF Sandbox, прийнятий 12 березня 2026 року, і він ліцензований за Apache 2.0.
Маршрутизація з урахуванням префіксів, вивантаження KV-кешу, розділення prefill/decode, широкомасштабний експертний паралелізм і пакетний інференс уже були реалізовані. Версія 1.0 присвячена їхньому надійному використанню в продуктивному середовищі — тому, що IBM називає операціями другого дня.
Що нового в llm-d 1.0?
- Якість обслуговування для кількох орендарів: керування потоком з урахуванням пріоритетів і справедливості не дає імпульсним агентам позбавляти запити, чутливі до затримки, необхідних ресурсів.
- Стабільна основа: API v1 і посилений шлях обробки запитів, перевірені в кількох хмарах і на різних прискорювачах.
- Оновлення без простою: висока доступність маршрутизатора з гарячим резервом, а також DisaggregatedSet, який одночасно оновлює пули prefill і decode.
- Обслуговування з урахуванням агентів: маршрутизація з урахуванням сесій, планування з пріоритетом ходу та нативний стан Responses API.
- Асинхронний інференс: llm-d-async-processor отримує завдання з Google Cloud Pub/Sub або Redis і передає їх у вільні потужності.
- Розширена підтримка TPU: TorchTPU запускає моделі PyTorch нативно всередині upstream-версій vLLM і SGLang.
Як llm-d маршрутизує запити?
Маршрутизатор llm-d побудований на Kubernetes Gateway API Inference Extension. Він відстежує, які репліки містять кожен кешований префікс. Потім перед вибором репліки враховує навантаження та прогнозовану затримку. Агенти звертаються до однієї кінцевої точки, а кожен крок потрапляє туди, де вже зберігається його контекст.
Коли пам’ять прискорювача заповнюється, KV-кеш переміщується в пам’ять хоста, а потім на SSD або Managed Lustre. Для цього використовуються OffloadingConnector від vLLM, Mooncake або HiCache від SGLang. Prefill і decode виконуються в окремих пулах, оскільки prefill потребує значних обчислень, а decode обмежений пропускною здатністю пам’яті.
</span><b>Запит агента</b><small>1 кінцева точка</small></div> <div class="node"><span class="ic">
</span><b>маршрутизатор llm-d</b><small>з урахуванням префікса + навантаження</small></div>
<div class="node"><span class="ic">
</span><b>Prefill / decode</b><small>окремі пули</small></div>
<div class="node"><span class="ic">
</span><b>Багаторівневий KV-кеш</b><small>від HBM до Lustre</small></div>
</div>
<div class="pkt"><span></span></div>
<div class="exp" id="mtp-exp"></div>
<div class="tiers" id="mtp-tiers">
<div style="background:rgba(66,133,244,.15)">HBM прискорювача</div>
<div style="background:rgba(52,168,83,.15)">Оперативна пам’ять CPU хоста</div>
<div style="background:rgba(251,188,4,.15)">Локальний SSD</div>
<div style="background:rgba(234,67,53,.15)">Managed Lustre</div>
</div>
<div class="ctl">
<button class="btn gh" id="mtp-prev">Назад</button>
<button class="btn" id="mtp-next">Наступний крок</button>
<button class="btn gh" id="mtp-play">Автовідтворення</button>
<span class="st" id="mtp-st">Крок 1 із 4</span>
</div>
</div>
<div class="pn">
<div class="seg">
<button class="btn" data-g="lat">Затримка та кеш</button>
<button class="btn gh" data-g="thr">Пропускна здатність</button>
</div>
<div class="bars" id="mtp-bars"></div>
<div class="note">Усі показники надані Google, Snap і Zenteiq самостійно. Джерело: блог Google Cloud, 20 жовтня 2026 року.</div>
</div>
<div class="pn">
<div class="grid">
<div class="card"><span class="k">QoS для кількох орендарів</span><b>Керування потоком</b><p>Маршрутизація з урахуванням пріоритетів і справедливості не дає імпульсним агентним циклам позбавляти інтерактивних користувачів ресурсів.</p></div>
<div class="card"><span class="k">Оновлення</span><b>DisaggregatedSet</b><p>Побудований на LeaderWorkerSet. Одночасно оновлює пули prefill і decode до сумісних версій без розриву сесій.</p></div>
<div class="card"><span class="k">Надійність</span><b>Висока доступність маршрутизатора</b><p>Гарячий резерв і поетапні оновлення забезпечують безперервний рух трафіку під час оновлень і технічного обслуговування.</p></div>
<div class="card"><span class="k">Агенти</span><b>Маршрутизація з урахуванням сесій</b><p>Планування з пріоритетом ходу та нативний стан Responses API допомагають агентам повторно використовувати контекст між ходами.</p></div>
<div class="card"><span class="k">Фонові завдання</span><b>Асинхронний процесор</b><p>Отримує запити з Google Cloud Pub/Sub або Redis і виконує їх у вільних потужностях.</p></div>
<div class="card"><span class="k">TPU</span><b>Розподіл часу TorchTPU</b><p>Вбудовує інференс у вільні цикли RL. Коефіцієнт використання зростає приблизно з 40% до понад 70%.</p></div>
</div>
<div class="note">Натисніть картку, щоб переглянути деталі. Стабільні API v1 доступні в усіх компонентах.</div>
</div>
<div class="pn"><div class="tw">
<table>
<tr><th></th><th class="us">llm-d 1.0</th><th>NVIDIA Dynamo</th><th>AIBrix</th></tr>
<tr><td>Версія</td><td>1.0 (жовтень 2026)</td><td>v1.5.1 (жовтень 2026)</td><td>v0.7.0 (червень 2026)</td></tr>
<tr><td>Управління</td><td>CNCF Sandbox</td><td>Під керівництвом NVIDIA</td><td>Організація проєкту vLLM</td></tr>
<tr><td>Рушії</td><td>vLLM, SGLang</td><td>SGLang, TRT-LLM, vLLM</td><td>vLLM, SGLang, TRT-LLM</td></tr>
<tr><td>Прискорювачі</td><td>NVIDIA, AMD, Intel, TPU</td><td>Графічні процесори NVIDIA</td><td>Різні графічні процесори</td></tr>
<tr><td>Рівні KV</td><td>HBM, CPU, SSD, Lustre</td><td>GPU, CPU, SSD, віддалене сховище</td><td>Розподілений KV-кеш</td></tr>
<tr><td>Ліцензія</td><td>Apache 2.0</td><td>Apache 2.0</td><td>Apache 2.0</td></tr>
<tr><td>Зірки на GitHub</td><td>4,8 тис.</td><td>8,3 тис.</td><td>5,1 тис.</td></tr>
</table></div>
<div class="note">Кількість зірок станом на 20 жовтня 2026 року. Джерела: репозиторії GitHub і документація кожного проєкту.</div>
</div>
<div class="ft"><span>Джерела: Google Cloud, IBM Research, Red Hat, GitHub</span><a href="https://www.marktechpost.com" target="_blank" rel="noopener">© Marktechpost</a></div>
</div>
<script>
(function(){
var R=document.getElementById('mtp-llmd1');
var tabs=R.querySelectorAll('.tabs button'),pns=R.querySelectorAll('.pn');
tabs.forEach(function(b){b.onclick=function(){tabs.forEach(function(x){x.classList.remove('on')});pns.forEach(function(x){x.classList.remove('on')});b.classList.add('on');pns[+b.dataset.t].classList.add('on');if(+b.dataset.t===1)draw(cur);rs();};});
var steps=[
'Агент надсилає один крок багатоходового завдання до єдиної кінцевої точки llm-d. Пули TPU і GPU розташовані за нею та запускають vLLM або SGLang.',
'Маршрутизатор відстежує, які репліки вже містять кожен кешований префікс. Він враховує навантаження та прогнозовану затримку, а потім надсилає крок туди, де зберігається його контекст.',
'Prefill (обчислювально інтенсивний) і decode (обмежений пам’яттю) виконуються в окремих пулах. DisaggregatedSet оновлює їх разом без розриву сесій.',
'Коли пам’ять прискорювача заповнюється, KV-кеш переміщується в оперативну пам’ять хоста, а потім на SSD або Google Cloud Managed Lustre замість видалення.'];
var s=0,nodes=R.querySelectorAll('.node'),pk=R.querySelector('.pkt span'),ex=document.getElementById('mtp-exp'),st=document.getElementById('mtp-st'),ti=R.querySelectorAll('#mtp-tiers div'),timer=null;
function show(){nodes.forEach(function(n,i){n.classList.toggle('act',i===s)});pk.style.left=(s*25)+'%';ex.textContent=steps[s];st.textContent='Крок '+(s+1)+' із 4';
ti.forEach(function(t,i){t.classList.remove('lit');if(s===3)setTimeout(function(){t.classList.add('lit')},i*350);else if(i===0)t.classList.add('lit')});}
document.getElementById('mtp-next').onclick=function(){s=(s+1)%4;show()};
document.getElementById('mtp-prev').onclick=function(){s=(s+3)%4;show()};
document.getElementById('mtp-play').onclick=function(){var b=this;if(timer){clearInterval(timer);timer=null;b.textContent='Автовідтворення';return}b.textContent='Пауза';timer=setInterval(function(){s=(s+1)%4;show()},2600)};
show();
var data={lat:[
['TPU Ironwood: скорочення медіанного TTFT','>85%',85,'#4285F4','агентне кодування проти звичайного сервісу K8s'],
['Gemini: скорочення P95 TTFT (імпульсний чат)','>50%',50,'#34A853','GKE Inference Gateway'],
['A3 Mega 70B: покращення TTFT','~40%',40,'#FBBC04','Lustre + вивантаження на CPU, промпти на 50 тис. токенів'],
['Gemini: скорочення TTFT (агенти кодування)','>35%',35,'#EA4335','продуктивний трафік'],
['Gemini: коефіцієнт потрапляння в кеш префіксів','35% до 70%',70,'#4285F4','подвоївся']],
thr:[
['Zenteiq: сукупна пропускна здатність','>4x',4,'#34A853','від 1,47 млрд до 5,97 млрд токенів на день на 1 000 TPU v6e'],
['GKE із 17 000 вузлів: пропускна здатність','2,9x',2.9,'#4285F4','3 кластери, 99,9% успішних операцій'],
['TPU Ironwood: загальна пропускна здатність','2,4x',2.4,'#FBBC04','проти звичайного сервісу K8s']]};
var cur='lat';
function draw(g){cur=g;var box=document.getElementById('mtp-bars'),mx=g==='thr'?4:100;box.innerHTML='';
data[g].forEach(function(d){var r=document.createElement('div');r.className='row';r.innerHTML='<div class="lb"><span>'+d[0]+' <em>'+d[4]+'</em></span><b>'+d[1]+'</b></div><div class="tr"><div class="fl" style="background:'+d[3]+'"></div></div>';box.appendChild(r);
var f=r.querySelector('.fl');setTimeout(function(){f.style.width=(d[2]/mx*100)+'%'},60);});rs();}
R.querySelectorAll('[data-g]').forEach(function(b){b.onclick=function(){R.querySelectorAll('[data-g]').forEach(function(x){x.classList.add('gh')});b.classList.remove('gh');draw(b.dataset.g)}});
R.querySelectorAll('.card').forEach(function(c){c.onclick=function(){c.classList.toggle('open');setTimeout(rs,380)}});
function rs(){try{parent.postMessage({mtpH:R.offsetHeight+40,id:'mtp-llmd1'},'*')}catch(e){}}
window.addEventListener('load',rs);window.addEventListener('resize',rs);setTimeout(rs,300);
})();
</script>
</body></html>
" style="width:100%;max-width:880px;height:600px;border:0;display:block;margin:0 auto;" loading="lazy">
Що показують бенчмарки llm-d 1.0?
Усі наведені нижче показники надані Google і користувачами llm-d самостійно.
- TPU Ironwood (TPU 7x): маршрутизація з урахуванням префіксів разом із вивантаженням у пам’ять хоста скоротили медіанний TTFT більш ніж на 85%. Пропускна здатність зросла у 2,4 раза порівняно зі звичайним сервісом Kubernetes.
- Платформа Gemini: коефіцієнт потрапляння в кеш префіксів подвоївся — з 35% до 70%. TTFT для агентів кодування скоротився більш ніж на 35%. P95 TTFT під час імпульсного чату скоротився більш ніж на 50%.
- Бенчмарк GKE із 17 000 вузлів: пропускна здатність зросла у 2,9 раза в 3 кластерах, із 99,9% успішних операцій і накладними витратами менш ніж 1%.
- A3 Mega, модель 70B: вивантаження в Lustre та оперативну пам’ять CPU покращило TTFT приблизно на 40% для промптів на 50 тис. токенів. Сумарна затримка скоротилася на 30%, а кількість GPU-годин — майже на 60%.
- Розподіл часу для RL: коефіцієнт використання прискорювача зріс приблизно з 40% до понад 70%.
Користувачі повідомляють про подібні результати. Snap повідомляє про коефіцієнт потрапляння в кеш префіксів до 75–80%. Zenteiq повідомляє про зростання пропускної здатності більш ніж у 4 рази — з 1,47 млрд до 5,97 млрд токенів на день на 1 000 чипів TPU v6e. На демонстрації IBM обслуговували 3 000 одночасних агентів кодування за ціною у 5–10 разів нижчою за API-тарифи.
Як llm-d порівнюється з NVIDIA Dynamo та AIBrix?
| Функція | llm-d 1.0 | NVIDIA Dynamo | AIBrix |
|---|---|---|---|
| Остання версія | 1.0 (20 жовтня 2026 року) | v1.5.1 (6 жовтня 2026 року) | v0.7.0 (16 червня 2026 року) |
| Ліцензія | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Управління | CNCF Sandbox | Під керівництвом NVIDIA (організація ai-dynamo) | Організація проєкту vLLM, походження ByteDance |
| Рушії | vLLM, SGLang | SGLang, TensorRT-LLM, vLLM | vLLM, SGLang, TensorRT-LLM |
| Прискорювачі | Графічні процесори NVIDIA, AMD, Intel, Google TPU | Графічні процесори NVIDIA (Blackwell, Hopper, Ada, Ampere) | Різні графічні процесори (гетерогенне обслуговування) |
| Маршрутизація з урахуванням кешу | Так, з урахуванням префіксів і навантаження | Так, з урахуванням KV | Так, маршрутизація через шлюз |
| Рівні KV-кешу | HBM, CPU, SSD, Managed Lustre | GPU, CPU, SSD, віддалене сховище (KVBM) | Розподілений KV-кеш |
| Розділення P/D | Так, DisaggregatedSet | Так | Так |
| Головний результат | Пропускна здатність у 2,9 раза вища, 17 000 вузлів (самостійно заявлені дані) | TTFT у 2 рази швидший, Qwen3-Coder 480B (Baseten) | Не розкрито |
Це не прямі конкуренти. CoreWeave запускає llm-d разом із Dynamo, а NVIDIA робить внесок компонентами Dynamo у llm-d.
Як розгорнути llm-d 1.0?
У Google Cloud сервіс GKE Inference Gateway запускає маршрутизатор llm-d як керований сервіс. Він також може охоплювати кластери та регіони із глобальним перемиканням у разі відмови. KEDA і HPA масштабують пули залежно від довжини черги та прогнозованої затримки. Kueue забезпечує квоти для кожної моделі. Перевірені Helm-чарти розгортають пули TPU і GPU за однією кінцевою точкою.
Команда Google пропонує поетапний підхід. Почніть із маршрутизації з урахуванням префіксів перед наявним розгортанням vLLM. Потім додайте керування потоком, багаторівневе вивантаження KV та розділення. Опубліковані результати можна порівняти на Prism.
Головні висновки
- llm-d 1.0 — перший стабільний випуск з API v1.
- Нові можливості: керування потоком, висока доступність маршрутизатора, DisaggregatedSet і маршрутизація з урахуванням агентів.
- Gemini подвоїв кількість потраплянь у кеш префіксів — із 35% до 70%.
- Бенчмарк GKE із 17 000 вузлів забезпечив зростання пропускної здатності у 2,9 раза.
Ознайомтеся з анонсом Google Cloud, публікацією IBM Research, репозиторієм на GitHub і документацією GKE. Уся подяка належить досліднику цього проєкту. Також підписуйтеся на нас у Twitter і не забудьте приєднатися до нашого сабреддіту про машинне навчання із понад 150 тис. учасників та підписатися на нашу розсилку. Стривайте! Ви є в Telegram? тепер ви також можете приєднатися до нас у Telegram.
Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.