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 GPU, или Google TPU, чрез vLLM или SGLang.
- Производителност: Според данни на производителя подобренията идват от маршрутизиране, съобразено с кеша, многостепенно разтоварване на KV кеша и разделяне на prefill/decode.
- Най-добър резултат: Медианното TTFT е намалено с над 85%, а пропускателната способност е 2,4 пъти по-висока при задача за програмиране на Ironwood TPU.
- Най-слаб резултат: Разпределянето на времето при 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 нарича операции „ден 2“.
Какво е новото в 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)">RAM на хост процесора</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 GPU</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 кешът се премества в RAM на хоста, а след това на 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:[
['Ironwood TPU: намаление на медианното 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 млрд. токена дневно на 1000 TPU v6e'],
['GKE с 17 000 възела: пропускателна способност','2,9x',2.9,'#4285F4','3 клъстера, 99,9% успех'],
['Ironwood TPU: обща пропускателна способност','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.
- Ironwood TPU (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 и RAM на CPU подобрява TTFT с около 40% при подсказки от 50 хил. токена. Закъснението от край до край намалява с 30%, а часовете работа на GPU — с почти 60%.
- Разпределяне на времето при RL: коефициентът на използване на ускорителя се повишава от около 40% до над 70%.
Потребителите съобщават за сходни резултати. Snap отчита коефициенти на попадение в кеша на префикса до 75–80%. Zenteiq съобщава за над 4 пъти по-висока пропускателна способност — от 1,47 милиарда до 5,97 милиарда дневни токена на 1000 TPU v6e чипа. Демонстрация на IBM обслужва 3000 едновременно работещи агенти за програмиране при цена 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 GPU, Google TPU | NVIDIA GPU (Blackwell, Hopper, Ada, Ampere) | Различни GPU (хетерогенно обслужване) |
| Маршрутизиране с отчитане на кеша | Да, с отчитане на префикса и натоварването | Да, с отчитане на KV кеша | Да, маршрутизиране чрез шлюз |
| Нива на KV кеша | HBM, CPU, SSD, Managed Lustre | GPU, CPU, SSD, отдалечено хранилище (KVBM) | Разпределен KV кеш |
| P/D разделяне | Да, DisaggregatedSet | Да | Да |
| Основен резултат | 2,9 пъти по-висока пропускателна способност, 17 000 възела (според самия проект) | 2 пъти по-бързо TTFT, 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 и не забравяйте да се присъедините към нашия 150k+ ML SubReddit и да се абонирате за нашия бюлетин. Чакайте! В Telegram ли сте? Вече можете да се присъедините към нас и в Telegram.
Преведено автоматично от английски. Оригиналната статия е на връзката по-долу.