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 с GPU NVIDIA, AMD или Intel либо Google TPU, поверх 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 нативно внутри вышестоящих 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>GPU NVIDIA</td><td>Различные GPU</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 раза в трёх кластерах, при успешном выполнении в 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 |
| Ускорители | GPU NVIDIA, AMD и Intel, Google TPU | GPU NVIDIA (Blackwell, Hopper, Ada, Ampere) | Различные GPU (неоднородное обслуживание) |
| Маршрутизация с учётом кэша | Да, с учётом префикса и нагрузки | Да, с учётом 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.
Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.