llm-d развернул 753B-модель GLM-5.2 на 544 H100 и обслужил 3000 агентов

Агентская нагрузка ломает привычную схему инференса

По мере роста возможностей ИИ-агентов они предъявляют новые требования к инфраструктуре инференса. В отличие от обычных чат-ботов, агентские системы вроде кодинг-ассистентов многократно обрабатывают огромные контексты, переиспользуют информацию между множеством взаимодействий и запускают параллельные подагенты, порождающие непредсказуемые всплески активности. Такие нагрузки упираются прежде всего в чтение и управление контекстом, а не в генерацию текста, и создают проблемы с задержкой, памятью, пропускной способностью и стоимостью.

Проект llm-d — совместная инициатива, которую ведут IBM Research, Red Hat и Google при участии других игроков отрасли: это открытый фреймворк для обслуживания LLM в масштабе, отвечающий на вызовы новых типов нагрузок. На фоне роста стоимости токена и требований к защите собственных данных предприятия всё чаще ищут способ развернуть открытые модели на своей инфраструктуре, и llm-d доказывает, что способен обрабатывать сегодняшний агентский трафик. Раньше проект уже показал эффективное обслуживание крупных mixture-of-experts моделей на NVIDIA H200; теперь цель была той же, но на NVIDIA H100 — ускорителях, которые массово стоят в корпоративных и облачных парках.

Отправной точкой стали данные предыдущего исследования по 219 реальным сессиям Claude Code. Выяснилось, что медианный запрос несёт около 195 000 токенов, а генерирует всего 317: вычислительная сложность лежит почти целиком в обработке входящего контекста, а не в порождении ответа. Из этого команда вывела три свойства агентских нагрузок: исключительно длинные контексты, активное переиспользование информации из предыдущих шагов и всплески параллельной активности подагентов.

Масштаб переиспользования оказался впечатляющим: 96% запросов главного агента повторяли как минимум 90% входных данных предыдущего запроса дословно, а больше половины всех запросов приходили группами параллельных задач подагентов без предварительного предупреждения. Эффективная система должна кэшировать и переиспользовать вычисления, а не считать их заново.

Демонстрация: GLM-5.2 на 544 ускорителях

В демонстрации команда развернула GLM-5.2 — открытую mixture-of-experts модель примерно на 753 млрд параметров, из которых активны около 39 млрд, — на 544 ускорителях NVIDIA H100. Модель выбрали как показательный пример того, что операторы платформ могут разворачивать уже сегодня.

На нагрузке из сотен параллельных агентских сессий с высоким уровнем переиспользования контекста, повторяющей продакшн-профиль трафика, развёртывание выдало более 6,6 млн выходных токенов в минуту на пике и обслужило до 3000 параллельных кодинг-агентов без единого вытеснения. По текущим облачным ставкам самостоятельный хостинг GLM-5.2 на H100 с llm-d обходится в 5–10 раз дешевле за токен, чем сопоставимые коммерческие API, причём максимальная экономия приходится именно на тяжёлый по входу агентский трафик.

«Мы поставили цель показать, что самостоятельно размещённая открытая модель может выполнять реальные агентские нагрузки с конкурентной интерактивной пропускной способностью на длинных контекстах, используя ускорители, которые уже есть у большинства организаций, — приводит блог слова Carlos Costa, Distinguished Engineer в IBM Research и мейнтейнера llm-d. — llm-d уже доказал, что справляется с этим в масштабе. Мы хотели закрыть разрыв для модели такого размера на распространённом парке прошлого поколения — это мы и продемонстрировали».

Шесть механизмов вместо одной оптимизации

Чтобы сократить повторную обработку контекста, сохранить переиспользование кэша под нагрузкой и разводить масштабирование prefill и decode, в llm-d объединили шесть возможностей.

Первая — маршрутизация с учётом префикса (prefix-aware routing): запрос направляется на тот сервер, где уже лежит его кэшированный контекст, чтобы система переиспользовала прежние вычисления. На агентском бенчмарке CyberGym переход от оптимизированной приблизительной маршрутизации к точному сопоставлению префиксов дал на 79% более высокую пропускную способность и на 67% меньшее время до первого токена.

Вторая и третья — многоуровневое управление KV-кэшем, которое продлевает рабочий кэш в DRAM центрального процессора, чтобы полезные префиксы выживали при давлении на память GPU, и peer-to-peer-обмен KV-кэшем между серверами, когда лучшее совпадение находится на другом узле. Четвёртая — широкий параллелизм по экспертам с data-parallel attention: модель на 753 млрд параметров не помещается на один сервер, а такой подход распределяет её по узлам, избегая репликации KV-кэша, которую потребовал бы tensor parallelism для multi-head latent attention в GLM-5.2. Пятая — разделение prefill и decode на независимые пулы, которые общаются через библиотеку zero-copy-передач NVIDIA NIXL; за всю программу бенчмарков не зафиксировано ни одного сбоя передачи. Шестая — multi-token prediction (MTP), генерирующая несколько выходных токенов за один прямой проход и усиливающая остальные оптимизации, поскольку работает поверх них.

«llm-d — это не просто набор функций, — говорит Costa. — Это про то, как все они работают вместе, в продакшене, на инфраструктуре, которую может развернуть любая организация». Сам проект описан как открытый Kubernetes-ориентированный стек для распределённого инференса LLM, который запускает vLLM, SGLang и другие движки на кластере и входит в песочницу CNCF.

Что показали бенчмарки

Развёртывание разместили в разделённой топологии с отдельными группами prefill и decode, а рядом со внутренней нагрузкой прогнали структурированные бенчмарки — каждый со свежими префиксами и сидами, чтобы прежнее состояние кэша не влияло на результат.

AutomationBench проверял чистую параллельность, масштабируясь с 2000 до 3000 одновременных кодинг-агентов. На 2500 агентах, комфортной рабочей точке, система держала 7612 запросов в минуту при пиковом входном потоке 134,89 млн токенов в минуту и пиковом выходном 6,05 млн токенов в минуту без единого вытеснения. На 3000 агентах выход достиг 6,60 млн токенов в минуту, прежде чем система подошла к границе обслуживания — без вытеснений и отказов.

CyberGym оценивал длинноконтекстные агентские завершения: 400 параллельных агентов, каждый обрабатывал контексты по 376 тыс. символов на десяти шагах. С полным стеком маршрутизации все 400 траекторий завершились за 248 секунд при 967,7 запросах в минуту, p90 времени до первого токена составил 17,59 секунды, а p90 времени в очереди — всего 1,11 секунды. Локальная доля попаданий в префиксный кэш выросла до 73,18% против 44,46% при приблизительной маршрутизации.

AgentX измерял интерактивную пропускную способность на 128 параллельных агентах с контекстами около 195 тыс. токенов в течение примерно 15 минут: 7251 запрос при 7,7 запроса в секунду и p90 времени до первого токена 5,77 секунды. В ходе прогона 168 запросов вызвали P2P-поиск переиспользуемых блоков KV-кэша на другом воркере.

Под всем этим работала разделённая плоскость данных: NIXL выполнила 6,2 млн передач KV-кэша со средним размером 2,71 ГиБ, держа примерно 580 Гбит/с на p90 по всему парку без сбоев. Кэш уровня CPU принял 2,53 ПиБ сохранённых блоков промптов и вернул на GPU 2,16 ПиБ, тратя в среднем 79,6 мс на восстановление. Все бенчмарки завершились без ошибок обслуживания.

В измеренной декомпозиции кэша стек отдал 85,2% входных токенов из кэша и снизил долю неcкэшированного prefill до 14,8% — с 27,1%, то есть примерно на 45% уменьшил остаточный пересчёт по сравнению с одним лишь GPU-локальным кэшированием.

«Мы не гнались за одной пиковой цифрой пропускной способности. Мы хотели понять, может ли открытая модель такого размера выдерживать длинные контексты, переиспользование и всплески, которые определяют агентские системы. Обслуживание тысяч параллельных агентов без вытеснений даёт операторам правдоподобный путь от результата бенчмарка к продакшн-развёртыванию», — говорит Maroon Ayoub, Senior Principal MLE, Inference Engineering, участник команды Red Hat.

Что это значит для операторов платформ

Технологии вроде llm-d приближают обслуживание открытых моделей уровня фронтира к организациям, у которых уже есть GPU-инфраструктура. Раньше обслуживание модели такого размера с конкурентной пропускной способностью требовало либо ускорителей нового поколения, либо полностью управляемого API-эндпоинта; демонстрация показывает, что с правильным программным стеком широко распространённая инфраструктура H100 даёт сильный результат — без ожидания следующего поколения ускорителей.

«Операторы больших парков H100 могут посмотреть на эти цифры и увидеть жизнеспособный путь к обслуживанию моделей фронтирного масштаба на своей инфраструктуре, — говорит Costa. — Агентский инференс — это системная задача. Выигрыш приходит от отказа от лишней работы, маршрутизации к нужному кэшу и независимого масштабирования prefill и decode, а не только от сырой производительности GPU». «Эти результаты — не потолок для инфраструктуры H100, — добавляет Nili Guy, Senior Technical Staff Member из команды IBM Research. — Они дают нам прочную базу, и каждое улучшение открытого стека обслуживания расширяет то, что способен выдержать тот же парк».

Команда продолжит развивать llm-d в открытом режиме, перенося уроки внутренних развёртываний в масштабе на реальные болевые точки сообщества. Проект остаётся открытым, входит в песочницу Cloud Native Computing Foundation, поддерживается IBM Research, Red Hat, Google и растущим сообществом контрибьюторов и предоставляет руководства по развёртыванию и проверенные конфигурации.