llm-d 1.0: открытый стек для распределенного инференса

Сегодня на конференции PyTorch Conference мы выпустили llm-d 1.0 — открытый стек на базе Kubernetes для распределенного инференса LLM. Этот проект Cloud Native Computing Foundation (CNCF) Sandbox создан совместными усилиями Google, Red Hat, IBM и других участников, а также сообщества из более чем 500 разработчиков из 25 организаций. Он объединяет два важных сообщества: PyTorch, где vLLM и SGLang обслуживают модели, и Kubernetes, где распределенные системы работают и масштабируются в продакшене.

Выход llm-d 1.0 происходит в то время, когда агенты меняют саму природу инференса. Год назад большая часть трафика инференса представляла собой чат: один промпт на входе, один ответ на выходе. Сегодня рабочие нагрузки смещаются в сторону многошаговых агентов и запусков с подкреплением (RL), которые распределяются по инструментам, разделяют длинные префиксы и поступают всплесками. Обслуживание таких нагрузок на одной машине или за обычным балансировщиком нагрузки round-robin быстро приводит к сбоям. Реплики пересчитывают одни и те же промпты, память ускорителей забивается дублирующимися состояниями, а один цикл активного агента может заблокировать интерактивных пользователей.

llm-d решает эту проблему для команд, обслуживающих собственные модели, превращая кластер серверов моделей в скоординированный пул обслуживания. Во время основного доклада на PyTorch Conference мы продемонстрировали это в действии: 1 000 изолированных агентов на Agent Substrate в GKE обращались к единой конечной точке llm-d, распределяясь между vLLM, SGLang и смешанным парком TPU и GPU в Google Cloud. По мере масштабирования трафика на трех этапах, описанных ниже, маршрутизация с учетом кеша и многоуровневый кеш KV удерживали шаги каждого агента на репликах, хранящих его контекст, в то время как управление потоками ставило в очередь всплесковые циклы агентов, сохраняя высокую скорость интерактивных запросов.

Рисунок 1: Эволюция распределенного инференса от балансировки нагрузки round-robin к маршрутизации с учетом кеша, многоуровневому кешу KV и управлению потоками на основе приоритетов в llm-d 1.0

Что входит в версию 1.0

llm-d уже обеспечивает маршрутизацию с учетом префиксов и нагрузки, выгрузку кеша KV, разделение фаз префилла и декодирования, широкого параллелизма экспертов и пакетного инференса на TPU и GPU в Google Cloud.

• Многопользовательское качество обслуживания. Маршрутизация с учетом приоритетов и справедливости посредством управления потоками llm-d, что позволяет чувствительным к задержкам запросам и всплесковым рабочим нагрузкам агентов совместно использовать общий парк ресурсов для соблюдения соглашений об уровне обслуживания (SLO) без взаимного вытеснения.
• Стабильная основа. API версии v1 и усиленный путь запросов, проверенные на различных облаках и типах ускорителей.
• Более безопасные обновления. Высокая доступность маршрутизатора и обновления без простоев, а также DisaggregatedSet, который координирует скользящие обновления с учетом префилла и декодирования без потери контекста или прерывания активных сеансов.
• Обслуживание с учетом агентов. Маршрутизация с учетом сеансов, планирование с учетом приоритетов шагов и встроенное состояние Responses API, помогающие агентам повторно использовать контекст между ходами.
• Расширенная интеграция с TPU. Нативное обслуживание моделей PyTorch с совместным разделением времени TorchTPU для повышения пропускной способности и утилизации парков TPU в Google Cloud.

Компоненты разработаны таким образом, чтобы вы могли собирать из них собственную уникальную производственную среду. Сохраняйте свой движок, модель и кластер, внедряя только те компоненты обслуживания и конфигурации, которые вам нужны.

llm-d изнутри

В описанных ниже направлениях инженеры Google работали с сообществом llm-d над объединением базовых примитивов Kubernetes, движков обслуживания PyTorch и планирования с учетом ускорителей в единый компонуемый стек.

Рисунок 2: Многоузловая оркестрация llm-d и одноузловые модели движков TorchTPU на Google Kubernetes Engine и Google TPU

Одна конечная точка, множество ускорителей

Парк агентов — это не единая рабочая нагрузка. Интерактивные ходы требуют низкой задержки, фоновые циклы и запуски обучения с подкреплением (RL) требуют высокой пропускной способности, а спрос меняется каждую минуту. llm-d размещает ваши пулы ускорителей за единой конечной точкой, имеющей один маршрутизатор, один индекс кеша KV и одну политику управления потоками перед всем парком. Агенты вызывают единый API; маршрутизатор выбирает реплику для каждого шага и сохраняет контекст сеанса на репликах, которые уже владеют им. Добавление емкости, смешивание поколений ускорителей или перенос модели в другой пул становится изменением платформы, а не переписыванием кода агента. TorchTPU добавляет Google Cloud TPU в этот парк, запуск моделей PyTorch нативно внутри базовых vLLM и SGLang без переписывания моделей. Дополнительные сведения см. в руководстве по llm-d на Google Kubernetes Engine (GKE) TPU.

Маршрутизация с сохранением контекста

Маршрутизатор llm-d создан на базе Gateway API Inference — проекта Kubernetes для оптимизированной под инференс маршрутизации, который мы запустили. В GKE шлюз GKE Inference Gateway запускает маршрутизатор llm-d в качестве управляемого сервиса, упрощая установку и управление и расширяя маршрутизацию между регионами. Маршрутизатор отслеживает реплики, содержащие каждый кешированный префикс, и учитывает нагрузку и прогнозируемую задержку при выборе. Когда память ускорителя заполняется, вместо удаления данных llm-d использует OffloadingConnector от vLLM, Mooncake или HiCache от SGLang для переноса кеша KV в память хоста, а затем на SSD или в Google Cloud Managed Lustre. Такая настройка помогает предотвратить лавинообразное вытеснение префиксов при высоких, многоходовых и длинных контекстных нагрузках диалогов в смешанных парках TPU и GPU.

В рабочей нагрузке агентского кодирования на Ironwood TPU (TPU 7x) маршрутизация с учетом префиксов и выгрузка в память хоста сократили медианное время до первого токена (TTFT) более чем на 85% и увеличили общую пропускную способность в 2,4 раза по сравнению со стандартным сервисом Kubernetes по состоянию на октябрь 2026 года (source).

Разделение для безопасного обновления

Префилл требует больших вычислительных ресурсов, а декодирование ограничено пропускной способностью памяти, поэтому запуск обоих процессов на одних и тех же репликах заставляет каждый из них ждать другой. llm-d запускает префилл, декодирование и мультимодальное кодирование как отдельные пулы, а широкий параллелизм экспертов распределяет большие модели mixture-of-experts по узлам. В версии 1.0 , созданный на базе LeaderWorkerSet (API Kubernetes для многоходового инференса, который мы разработали), управляет этими пулами как единым целым. Скользящие обновления переносят префилл и декодирование вместе на соответствующие версии, при этом каждая фаза масштабируется независимо. Дополнительные сведения см. в руководстве по разделенному обслуживанию.

Асинхронный инференс, работающий параллельно с инференсом в реальном времени

Для трафика, терпимого к задержкам, llm-d 1.0 представляет llm-d-async-processor, который извлекает запросы из очередей, таких как Google Cloud Pub/Sub или Redis, и маршрутизирует их параллельно с трафиком реального времени. Используя шлюзы очередей и диспетчеризации пулов, процессор проверяет доступную емкость и обеспечивает строгие приоритетные полосы и квоты, чтобы фоновые задания выполнялись за счет свободных ресурсов без ущемления интерактивных пользователей.

Разделение времени для задействования простаивающих ресурсов RL

Во время обучения RL ускорители часто простаивают от 40% до 60% времени во время генерации пула запусков или обновления весов. Теперь llm-d поддерживает разделение времени Google Cloud TPU и GPU для встраивания асинхронного инференса в эти периоды бездействия, повышая совокупную рабочую нагрузку ускорителей с базовых ~40% до >70% (источник).

Бенчмарки, которым можно доверять

Настройка распределенного стека инференса между роутерами, уровнями кеша KV и пулами префилла/декодирования требует повторяемых измерений при реалистичной многошаговой нагрузке. Prism — это аналитическая панель с открытым исходным кодом от llm-d для изучения опубликованных бенчмарков по проверенным сценариям llm-d, подкрепленная стандартизированными рецептами llm-d-benchmark и рабочими нагрузками inference-perf. Изучите точные конфигурации, стоящие за цифрами, или загрузите результаты запусков из собственного кластера, чтобы сравнить пропускную способность, задержку и кривые затрат.

Запуск llm-d 1.0 в Google Cloud

llm-d опирается на компоненты Kubernetes, которые вы, возможно, уже используете: Gateway API, LeaderWorkerSet, Dynamic Resource Allocation, Prometheus и OpenTelemetry. Запуск llm-d в Google Cloud объединяет эти элементы с управляемой инфраструктурой:

• GKE Inference Gateway — это роутер llm-d, работающий в режиме шлюза (Gateway Mode), представляющий собой управляемый шлюз GKE, который обрабатывает L7-прокси и балансировку нагрузки, а также вызывает сборщик конечных точек llm-d (Endpoint Picker) при каждом запросе. Это упрощает установку и управление, освобождая вас от необходимости самостоятельно запускать прокси-сервер. Более того, GKE Inference Gateway позволяет масштабировать llm-d между кластерами и регионами с помощью глобального резервного копирования (failover) и проверок безопасности Model Armor.
• Автомасштабирование на основе сигналов инференса. KEDA и Horizontal Pod Autoscaler (HPA) масштабируют пулы на основе глубины очереди, загрузки и прогнозируемой задержки, в то время как Kueue обеспечивает соблюдение квот для каждого модели на общих акселераторах.
• Смешанные пулы узлов с акселераторами. Пулы TPU и GPU Google Cloud работают за одной конечной точкой llm-d, развертываемой с помощью проверенных графиков Helm.
• Выгрузка (offloading) KV-кеша по уровням. Google Cloud Managed Lustre предоставляет общий удаленный уровень поверх локальной HBM памяти TPU и GPU, а также оперативной памяти хост-процессора, что позволяет выполнять задачи с длинным контекстом без исчерпания памяти акселератора.

В продакшене

Этот стек GKE llm-d обслуживает производственный трафик и прошел тестирование в масштабах всего парка:

• Платформа Gemini (ранее Vertex AI) обслуживает производственный трафик через GKE Inference Gateway, что позволило вдвое увеличить коэффициент попадания в префиксный кеш (с 35% до 70%), сократить время до первого токена (TTFT) более чем на 35% для агентов написания кода и уменьшить P95 TTFT более чем на 50% при пиковых нагрузках чат-трафика (источник).
• В опубликованном бенчмарке по многорегиональному развертыванию GKE на 17 000 узлов, обслуживающем модель «микросхема экспертов» (MoE) в США и Европе, многокластерный GKE Inference Gateway и роутер llm-d масштабировали пропускную способность в 2,9 раза по трем кластерам с показателем успешности 99,9% и накладными расходами на маршрутизацию менее 1% (источник).
• В опубликованном бенчмарке на кластере A3 Mega, обслуживающем модель с 70 миллиардами параметров, llm-d с многокомпонентной выгрузкой KV-кеша в Google Cloud Managed Lustre в дополнение к оперативной памяти хост-процессора обеспечил улучшение TTFT примерно на 40% и снижение задержки «от конца до конца» на 30% при обработке промптов длиной 50k токенов по сравнению с выгрузкой только в оперативную память CPU, одновременно сократив потребность в GPU-часах почти на 60% (источник).

Организации, запускающие llm-d в Google Cloud, используют эти возможности по-разному: например, маршрутизацию с учетом префиксов для повышения коэффициента попадания в кеш, открытые интерфейсы, которые вписываются в существующую сетку сервисов (service mesh), и управление потоком для поддержания задержки для приоритетных уровней при скачках трафика.

«В Snap мы интегрируем llm-d в нашу производственную инфраструктуру ИИ для обеспечения высокопроизводительного инференса в больших масштабах. Используя маршрутизацию с учетом префиксного кеша, мы достигли коэффициента попадания в префиксный кеш до 75-80%. Мы ценим открытый исходный код llm-d, так как он обеспечивает плавную интеграцию с нашей сеткой сервисов на базе Envoy». — Винай Кола (Vinay Kola), старший менеджер по разработке программного обеспечения, Snap Inc.

«В ZenteiQ мы используем GKE Inference Gateway на базе llm-d для ускорения генерации синтетических данных для наших суверенных научных базовых моделей. За счет маршрутизации с учетом нагрузки и префиксного кеша мы добились более чем четырехкратного увеличения совокупной пропускной способности инференса, увеличив ежедневную емкость генерации токенов с 1,47 миллиарда до 5,97 миллиарда токенов на 1000 ускорителей TPU v6e. Открытая основа llm-d в интеграции с GKE позволяет нам эффективно обслуживать несколько семейств моделей в больших масштабах без разработки и поддержки собственного планировщика инференса». — Проф. Сашикумар Ганесан (Prof. Sashikumaar Ganesan), основатель Zenteiq.ai

«Обслуживание передовых моделей в интерактивных приложениях и высоконагруженных API означает способность справляться со значительными скачками трафика, не позволяя пиковым нагрузкам ухудшать задержку для приоритетных клиентов. Благодаря маршрутизации llm-d с учетом префиксного кеша, управлению потоками и поддержке дезагрегированного обслуживания мы можем устанавливать строгие приоритетные диапазоны для наших коммерческих уровней, автоматически удерживая или отсеивая запросы с более низким приоритетом при перегрузке пулов, чтобы платный трафик соответствовал нашим соглашениям об уровне обслуживания (SLO) по задержке. Mistral гордится тем, что поддерживает программное обеспечение с открытым исходным кодом, и продолжит вносить свой вклад в проекты llm-d и DisaggregatedSet». — Матис Фелардо (Mathis Felardos), Лукас Фернандес-Мартинс (Lucas Fernandes-Martins) и Нихил Томас (Nikhil Thomas), инженеры по инференсу и участники проекта llm-d из компании Mistral

Команды, обслуживающие собственные модели, просили создать открытый стек, который они могли бы разобрать и адаптировать под свою инфраструктуру, с функциями маршрутизации с учетом кеша, контроля трафика и управления обновлениями, необходимыми в продакшене. llm-d 1.0 дает им именно это, а также сообщество для совместной разработки.

Начало работы

• Ознакомьтесь с полной демонстрацией llm-d с TPU на стенде Google Cloud во время конференции PyTorch Conference.
• Разверните llm-d 1.0 на GKE с помощью проверенных графиков Helm. См. документацию llm-d в GKE.
• Начните с маршрутизации с учетом префиксов перед вашим существующим развертыванием vLLM, затем добавьте управление потоком, KV-кеш offload (SGlang, vLLM) и дезагрегацию.
• Сравните результаты на и внесите свой вклад на GitHub.
• Инфраструктура ИИ
• Контейнеры и Kubernetes
• GKE
• Открытый исходный код