Google выпустила llm-d 1.0 — первую стабильную версию открытого стека распределённого инференса LLM. Анонс прозвучал на конференции PyTorch Conference North America. Проект превращает отдельные серверы моделей на vLLM или SGLang в единый согласованный пул поверх Kubernetes — для сценариев, где привычная балансировка по кругу перестаёт работать: агентных нагрузок и обучения с подкреплением (RL) на собственной инфраструктуре.
Что такое 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, широкий expert parallelism и пакетный инференс уже были в проекте раньше. Версия 1.0 — про то, чтобы всё это надёжно работало в продакшене, то есть про то, что в IBM называют day 2 operations. Стек работает на Kubernetes с GPU NVIDIA, AMD или Intel либо с TPU Google, поверх vLLM или SGLang.
Что нового в версии 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 построен на Kubernetes Gateway API Inference Extension. Он отслеживает, какие реплики держат каждый закэшированный префикс, а затем взвешивает загрузку и прогнозируемую задержку, прежде чем выбрать реплику. Агенты обращаются к одной точке входа, а каждый шаг попадает туда, где его контекст уже лежит.
Когда память ускорителя заполняется, KV-кэш переезжает в память хоста, затем на SSD или в Managed Lustre. Для этого используются OffloadingConnector из vLLM, Mooncake или HiCache из SGLang. Фазы prefill и decode выполняются отдельными пулами: prefill нагружает вычисления, decode упирается в память. Такой подход к кэшу и разделению фаз — то, что отличает llm-d от простого набора подов за сервисом Kubernetes; похожие задачи решают и другие открытые оркестраторы вроде NVIDIA Run:ai.
Что показывают бенчмарки
Все цифры ниже — самоотчёт Google и компаний, внедривших llm-d.
- Ironwood TPU (TPU 7x): маршрутизация по префиксам плюс выгрузка в память хоста сократили медианный TTFT более чем на 85%. Пропускная способность выросла в 2,4 раза по сравнению с обычным сервисом Kubernetes.
- Платформа Gemini: доля попаданий в кэш префиксов удвоилась с 35% до 70%. TTFT для кодинг-агентов упал более чем на 35%, а P95 TTFT под всплесками чата — более чем на 50%.
- Бенчмарк на 17 000 узлов GKE: пропускная способность выросла в 2,9 раза на трёх кластерах при 99,9% успешных запросов и накладных расходах менее 1%.
- A3 Mega, модель 70B: Lustre плюс выгрузка в оперативную память улучшили TTFT примерно на 40% на промптах в 50 тыс. токенов. Сквозная задержка снизилась на 30%, а GPU-часы — почти на 60%.
- RL с разделением времени: загрузка ускорителя выросла примерно с 40% до более чем 70%, то есть около 30% простоя остаётся.
Внедрившие проект компании сообщают о похожих результатах. Snap указывает долю попаданий в кэш префиксов до 75–80%. Zenteiq — рост пропускной способности более чем в 4 раза: с 1,47 млрд до 5,97 млрд токенов в сутки на 1000 чипов TPU v6e. Демо IBM обслуживало 3000 одновременных кодинг-агентов при цене в 5–10 раз ниже API-прайса.
Чем отличается от NVIDIA Dynamo и AIBrix
Это не прямые конкуренты. CoreWeave запускает llm-d вместе с Dynamo, а NVIDIA передаёт компоненты Dynamo в llm-d. Различия в деталях:
| Параметр | 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, TPU Google | GPU NVIDIA (Blackwell, Hopper, Ada, Ampere) | смешанные GPU |
| Маршрутизация по кэшу | да, по префиксам и загрузке | да, по KV-кэшу | да, на уровне шлюза |
| Уровни KV-кэша | HBM, CPU, SSD, Managed Lustre | GPU, CPU, SSD, удалённое хранилище (KVBM) | — |
| Разделение prefill/decode | да, DisaggregatedSet |
да | да |
| Главный результат | рост в 2,9 раза на 17 000 узлов (самоотчёт) | TTFT в 2 раза быстрее, Qwen3-Coder 480B (Baseten) | не раскрыт |
Как развернуть
В Google Cloud роутер llm-d работает как управляемый сервис в GKE Inference Gateway и может охватывать кластеры и регионы с глобальным переключением при сбое. KEDA и HPA масштабируют пулы по глубине очереди и прогнозируемой задержке, Kueue следит за квотами на модель. Проверенные Helm-чарты разворачивают пулы TPU и GPU за одной точкой входа.
Google рекомендует идти поэтапно: сначала поставить маршрутизацию по префиксам перед существующим развёртыванием vLLM, затем добавить управление потоком, многоуровневую выгрузку KV-кэша и разделение фаз. Опубликованные прогоны можно сравнить в Prism. Если вы уже строите ИИ-нагрузки на Kubernetes, полезно посмотреть и на TauGrid от Microsoft — ещё один открытый стек для той же задачи.
Частые вопросы
Кого касается llm-d 1.0?
Тех, кто обслуживает LLM на собственной инфраструктуре: платформенные команды, владельцев GPU- и TPU-пулов, разработчиков агентных и RL-нагрузок на Kubernetes. Если модели вызываются через внешний API, стек напрямую не нужен.
Какие ускорители поддерживаются?
GPU NVIDIA, AMD и Intel, а также TPU Google. Движки — vLLM и SGLang, причём TorchTPU позволяет запускать PyTorch-модели нативно внутри обоих.
Насколько цифры бенчмарков можно считать независимыми?
Никак: все они самоотчёт Google и внедривших компаний. Сравнивать их с замерами конкурентов напрямую нельзя, но опубликованные прогоны доступны для сверки в Prism.
Что даёт маршрутизация по префиксам?
Запрос попадает на реплику, где его контекст уже в кэше. На Gemini это удвоило долю попаданий с 35% до 70%, а на Ironwood TPU сократило медианный TTFT более чем на 85%.
Остаётся ли простой ускорителей при RL?
Да, около 30%: разделение времени подняло загрузку с примерно 40% до чуть выше 70%, но полностью паузы не исчезли.
Обновляться ли на 1.0 с более ранних версий?
Версия 1.0 заявлена как стабильная база с API v1 и обновлениями без простоя — роутер с горячим резервом и DisaggregatedSet перекатывают пулы prefill и decode вместе. Это и есть аргумент в пользу перехода в продакшене.
Как начать, не перестраивая всё сразу?
Поставить маршрутизацию по префиксам перед существующим развёртыванием vLLM, а затем по очереди добавлять управление потоком, многоуровневую выгрузку KV-кэша и разделение фаз.
Можно ли использовать llm-d вместе с NVIDIA Dynamo?
Да, это не взаимоисключающие вещи: CoreWeave запускает llm-d рядом с Dynamo, а NVIDIA передаёт компоненты Dynamo в llm-d.
Под какой лицензией проект?
Apache 2.0, управление — CNCF Sandbox, принят 12 марта 2026 года.
Источник: marktechpost.com