llm-d 1.0 представлен на конференции PyTorch с промышленным стеком для инференса

Участники проекта llm-d объявили о выпуске llm-d 1.0 — стека распределенного инференса и обслуживания моделей, изначально разработанного для Kubernetes. Объявление прозвучало 20 октября 2026 года на конференции PyTorch North America, согласно объявлению IBM Research. В IBM заявили, что этот выпуск выводит llm-d за рамки демонстрации отдельных методов повышения производительности и призван помочь организациям перенести развертывание моделей на собственную инфраструктуру на фоне роста затрат на инференс.

llm-d создан для развертывания стеков инференса для любой модели, на любом ускорителе и в любом облаке. Red Hat, IBM и Google — ведущие сопровождающие проекта; они основали llm-d вместе с CoreWeave и NVIDIA. К проекту также присоединились в качестве участников AMD, Cisco, Hugging Face, Intel, Lambda и Mistral AI. Cloud Native Computing Foundation (CNCF) размещает llm-d в рамках программы песочницы. В IBM описывают полученное решение как независимую от поставщиков альтернативу для организаций, которым нужна производительность инференса, соответствующая передовым моделям, но которые не хотят полностью зависеть от одного поставщика проприетарных моделей, облака или аппаратной платформы.

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

Что нового в версии 1.0

В примечаниях к выпуску v1.0.0, опубликованных на GitHub 20 октября 2026 года, с подписанными и проверенными тегами, на первый план вынесено обеспечение качества обслуживания в многопользовательской среде: управление потоками с учетом приоритетов и справедливого распределения нагрузки, включая вероятностный механизм допуска, справедливое распределение с учетом программ и оценку приоритета хода. Это позволяет объединять в одном пуле запросы, чувствительные к задержкам, и неравномерные нагрузки от агентов, не допуская, чтобы при перегрузке одни запросы лишали ресурсов другие. Настройки управления потоками сведены в единое поле flowControl.

Для работы без простоев маршрутизатор получил функции высокой доступности с горячим резервированием и безопасным поэтапным обновлением. Контроллер DisaggregatedSet управляет репликами этапов prefill и decode как единым логическим блоком: он координирует развертывание обновлений и синхронное обновление версий, определяет готовность на основе снимка Pod и обеспечивает маршрутизацию с учетом версий. API конфигурации маршрутизатора получил статус v1, Responses API теперь поддерживает previous_response_id, а путь обработки запросов к выборщику конечных точек усилен для повышения надежности, производительности и масштабируемости. В выпуск также включено руководство по ускорителям с учетом топологии для DRA и DRANET.

Для обслуживания с учетом работы агентов добавлены подключаемый модуль — источник состояния сеанса — и динамическая привязка сеанса, чтобы многоходовые диалоги оставались рядом с кэшированным контекстом. Планирование с учетом приоритета хода и состояние Responses API помогают агентам повторно использовать контекст между ходами. Компоненты проекта приведены к версии v1.0.0. В экосистему добавлены, в частности, интеграция с ai-dynamo/modelexpress для одноранговой загрузки весов моделей, пакет llm-d-api-extensions и инструменты диагностики llm-d-pd-utils. Собственные сборки контейнерного образа llm-d-rocm проекта объявлены устаревшими. Образы серверов моделей включают сборки vLLM и SGLang для различных типов ускорителей. В обновленном руководстве по разделению этапов prefill и decode теперь требуется LeaderWorkerSet версии v0.11.1 или новее с включенным API DisaggregatedSet.

Основные методы и управление потоками

С момента запуска проект сосредоточен на пяти подходах к повышению эффективности инференса: маршрутизации с учетом кэша префиксов, которая направляет запрос на инфраструктуру, где может уже храниться общий контекст; выгрузке KV-кэша, при которой кэшированные данные перемещаются между ресурсами GPU, CPU и хранилища; оптимизации пакетного инференса; разделении этапов prefill и decode, при котором обработка входного запроса отделяется от генерации ответа; и широкой параллельной обработке экспертов, при которой большие модели со смешанной экспертной архитектурой распределяются между множеством ускорителей. Все эти методы появились до версии 1.0. По словам IBM, новизна выпуска — в их интеграции и эксплуатационной зрелости, а также в дисциплине эксплуатации второго дня, позволяющей поддерживать производительность при изменении трафика, отказах оборудования, обновлении программного обеспечения или конкуренции разных пользователей за одни и те же ресурсы.

В версии 1.0 управление потоками, справедливое распределение ресурсов и приоритизация призваны не допускать, чтобы неравномерные нагрузки перегружали службы, чувствительные к задержкам, независимо от того, используют ли эти нагрузки одно и то же оборудование или охватывают набор разных ускорителей. Чтобы кэши префиксов оставались заполненными, запросы можно закреплять за подходящей инфраструктурой на протяжении нескольких ходов. llm-d работает с такими движками инференса, как vLLM и SGLang, добавляя поверх них распределенную маршрутизацию и средства эксплуатации. Стивен Уотт, вице-президент аппарата технического директора Red Hat, заявил, что llm-d объединяет экосистемы PyTorch и CNCF, обеспечивая прямую интеграцию оркестрации, изначально разработанной для Kubernetes, с vLLM и современными движками инференса.

Продемонстрированные результаты и заявленные затраты

В опубликованной 22 июля 2026 года публикации с результатами бенчмарка проект оценил обслуживание агентных запросов к GLM-5.2, описанной там как модели типа «смесь экспертов» с 744 млрд параметров, из которых 39 млрд активны, и 78 слоями. Анализ нагрузки опирался на 219 рабочих сессий Claude Code: медианный запрос основного агента содержал 195 тыс. входных токенов и возвращал 317 выходных токенов, а в 96% ходов основного агента повторно использовалось не менее 90% входных данных. Согласно публикации, маршрутизация с учетом префикса обеспечила повторное использование 96–97% кэша, доступного при этой нагрузке. При принятой ставке аренды H200 в 2,71 доллара за GPU-час авторы оценивают стоимость самостоятельного развертывания на двух конфигурациях по 64 GPU в 0,05–0,08 доллара за миллион входных токенов и 1,92–3,55 доллара за миллион выходных токенов. По словам авторов, эти цифры учитывают только аренду GPU и предполагают устойчивую нагрузку.

В ходе отдельной демонстрации IBM и Red Hat развернули GLM-5.2 на 544 графических процессорах NVIDIA H100. В материале IBM Research модель характеризуется как модель с открытыми весами и примерно 753 млрд параметров, из которых активны около 39 млрд. IBM сообщает, что в пиковые периоды развертывание обеспечивало более 6,6 млн выходных токенов в минуту, одновременно обслуживая до 3 000 агентов программирования без единого принудительного прерывания; при этом конфигурация с 2 500 агентами стабильно обрабатывала 7 612 запросов в минуту. По заявлению IBM, при текущих ставках аренды облачных ресурсов самостоятельное развертывание GLM-5.2 на графических процессорах H100 с llm-d обходится в 5–10 раз дешевле за токен, чем использование сопоставимых коммерческих API. «Возможность обслуживать тысячи агентов одновременно без принудительных прерываний дает операторам реальный путь от результатов бенчмарка к развертыванию в рабочей среде», — сказал Марун Айюб, старший ведущий инженер по машинному обучению в команде Red Hat по разработке систем инференса.

Согласно тому же материалу, в основе этих результатов лежала раздельная плоскость данных: она выполнила 6,2 млн передач кэша KV со средним объемом 2,71 ГиБ на передачу, причем ни одна передача не завершилась сбоем. Все бенчмарки прошли без ошибок при обслуживании запросов.