«Диспетчерская вышка для AI-трафика»: IBM Research объяснила шесть механизмов распределённого инференса в llm-d

Почему это похоже на управление воздушным движением

Запустить большую языковую модель на GPU — одно дело, а обслуживать её одновременно для тысяч и миллионов людей и агентов — совсем другое. Запросы приходят с разными приоритетами и длиной и требуют разных вычислений: одни ждут немедленного ответа на простой вопрос, другие отправляют большие задачи в фоне. Трафик агентов добавляет новый шаблон — всплески связанных запросов, паузы на вызов инструмента и возврат почти с тем же контекстом, — а система должна эффективно использовать дорогие ускорители, не создавая длинных очередей и не пересчитывая одно и то же.

Аналогия с аэропортом: диспетчеры учитывают расположение, пункт назначения, размер и запас топлива самолёта, а также уже движущийся трафик. Распределённый инференс играет похожую координирующую роль уровнем выше серверов моделей вроде vLLM и SGLang: движки обслуживания эффективно запускают модели на отдельных серверах, а распределённый фреймворк координирует их группы в кластере. Его маршрутизатор может учитывать глубину очереди, доступность кэша и роли серверов, прежде чем решить, куда направить запрос.

Маршрутизация с учётом префикс-кэша

Когда модель читает промпт, она строит внутреннее представление слов и их связей, храня многое из этого промежуточного состояния в key-value-кэше. Если более поздний запрос начинается с того же текста, даже частично, модель может переиспользовать сохранённое вычисление вместо повторной обработки общего текста. Такая возможность возникает постоянно: чат-бот получает одни и те же системные инструкции в начале каждого разговора, помощник по коду снова и снова смотрит один и тот же репозиторий, агент возвращается к длинной истории шагов, пробуя разные решения.

Обычный балансировщик может отправить следующий запрос на наименее занятый сервер независимо от того, есть ли в его кэше нужный контекст, и модели приходится перечитывать материал, уже обработанный другим сервером. Маршрутизация с учётом префикс-кэша вместо этого отвечает на два вопроса: на каком сервере уже лежит наибольшая часть префикса промпта и у какого сервера достаточно ёмкости, чтобы принять запрос. Маршрутизатор llm-d оценивает доступные серверы по информации о кэше и рабочим условиям и выбирает подходящее назначение, а реализация бывает приближённой — с лёгким индексом недавних решений — и точной, основанной на фактических данных токенов и обновлениях состояния кэша от серверов. В недавней демонстрации команды llm-d такая маршрутизация захватила 97% доступного переиспользования в протестированной нагрузке.

Выгрузка KV-кэша

Маршрутизация по кэшу ценна ровно настолько, насколько кэшированная информация остаётся доступной, а память ускорителей быстро заполняется длинными промптами, множеством одновременных пользователей и долгими агентными сессиями. Когда места мало, сервер модели может вытеснить старые записи KV-кэша, и при следующем запросе материал приходится вычислять снова, впустую расходуя циклы ускорителя. Распределённый инференс решает это выгрузкой KV-кэша: самые нужные записи остаются в высокоскоростной памяти ускорителя, а остальные переезжают на более крупные, но медленные уровни — память CPU, локальное твердотельное хранилище или общую файловую систему. Индекс кэша отслеживает, что и где хранится, чтобы слой маршрутизации мог учитывать выгруженные данные в своих решениях.

Чтение из памяти CPU или с диска медленнее, чем из памяти ускорителя, но заметно быстрее и дешевле, чем пересчёт всего промпта, поэтому выгрузка расширяет эффективную ёмкость кэша за пределы физической памяти ускорителей. В той же демонстрации llm-d память GPU обеспечила примерно 90–92% переиспользуемых префиксов prefill для 128 одновременных запросов, а выгрузка на CPU помогла сохранить префиксы сверх ёмкости GPU. Поскольку выгрузка идёт во время prefill, а записи на медленные уровни происходят асинхронно, такой выигрыш не замедляет генерацию токенов.

Управление потоком и пакетные задания

Маршрутизация отвечает, куда идёт запрос, но под нагрузкой нужно решить и то, какие запросы идут первыми, а какие ждут. При всплеске трафика одинаковое отношение ко всем запросам означает, что чувствительный к задержке запрос встанет за очередью менее приоритетной работы. Управление потоком в llm-d регулирует допуск и порядок запросов на входе в систему, обеспечивая справедливость между пользователями и приоритет между нагрузками: интерактивный трафик защищается, а всплесковая или отложимая работа подстраивается под оставшуюся ёмкость. Это особенно важно для агентного трафика, который неравномерен по природе, и управление потоком сглаживает всплески в упорядоченный поток вместо перегрузки кластера.

Не каждому запросу нужен немедленный ответ: исследовательские оценки, обработка документов, генерация синтетических данных и крупномасштабное тестирование могут включать тысячи или миллионы промптов, завершаемых со временем. Такие пакетные задания повышают загрузку оборудования, используя ёмкость, которая иначе простаивала бы, но при плохом обращении могут затопить систему и задержать интерактивный трафик. llm-d поддерживает пакетный и офлайн-инференс двумя компонентами: Batch Gateway даёт OpenAI-совместимый интерфейс для отправки, отслеживания и управления заданиями, а асинхронный процессор вытягивает отдельные запросы из очередей сообщений, включая Redis и Google Pub/Sub, и передаёт их маршрутизатору llm-d. Так управление заданиями отделяется от размещения запросов: пакетный слой решает, как работа входит в систему, а маршрутизатор — где выполнять каждый конкретный запрос, и пакетные задания опираются на управление потоком, чтобы не выпускать всё задание в кластер сразу.

Разделение prefill и decode

Генерация ответа LLM включает две вычислительные фазы: на prefill модель обрабатывает входной промпт и строит KV-кэш, что может требовать больших объёмов параллельных вычислений при промпте в десятки тысяч токенов, а на decode модель порождает ответ по одному токену. Decode последователен и чувствителен к задержкам доступа к памяти и коммуникаций, поэтому предъявляет к железу другие требования, чем prefill. Обычная система обслуживания может запускать обе фазы на одной группе ускорителей — это упрощает развёртывание, но создаёт конкуренцию между разнородными нагрузками: крупное prefill-задание способно прервать или задержать ровный поток генерации токенов, а железо, настроенное на отзывчивый decode, плохо подходит для очень длинных промптов.

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

Широкая экспертиза параллельность

Крупнейшие современные языковые модели используют архитектуру смеси экспертов: вместо применения всех частей модели к каждому токену механизм маршрутизации выбирает лишь небольшую часть специализированных сетей-экспертов. Это уменьшает объём вычислений на запрос, но не отменяет необходимости хранить полный набор весов, а большие MoE-модели могут требовать сотен гигабайт только под веса, оставляя меньше памяти ускорителя под KV-кэш. Традиционная тензорная параллельность делит отдельные операции между несколькими GPU, что требует частых коммуникаций между ними и для некоторых механизмов внимания создаёт копии одних и тех же данных KV-кэша, сокращая ёмкость для длинных контекстов и одновременных пользователей.

Широкая экспертиза параллельность идёт другим путём: она распределяет экспертов модели по GPU и, при необходимости, по физическим серверам, а когда модель определяет, какие эксперты должны обработать токен, система отправляет токен только на GPU с выбранными экспертами. Эта коммуникация разрежена, поэтому GPU обмениваются лишь нужной для выбранных экспертов информацией, а не синхронизируют непрерывно каждую операцию модели. Выигрыш по памяти существенный: в демонстрации IBM и Red Hat этого года широкая схема хранила около 65.1 GiB весов экспертов на GPU против 89.5 GiB в рассмотренной тензорно-параллельной схеме, а на том же железе широкие конфигурации дали от трёх до девяти раз больше ёмкости KV-кэша в зависимости от топологии. Широкая экспертиза параллельность дополняет разделение prefill и decode: одно делит инференс по фазам, другое распределяет экспертов модели по кластеру.

Как это складывается в llm-d

Как и в аэропорту, где диспетчеры, наземные и лётные службы ценны по отдельности, но не могут вести операцию в одиночку, каждый из шести механизмов работает не сам по себе. Маршрутизация по префикс-кэшу находит, где лежит переиспользуемый контекст; выгрузка KV-кэша сохраняет больше этого контекста в иерархии памяти и хранилищ; управление потоком поддерживает ёмкость для одновременных пользователей; пакетный инференс регулирует вход больших объёмов фоновой работы; разделение prefill и decode отправляет разные фазы на подходящие ресурсы, а широкая экспертиза параллельность физически распределяет крупные модели по кластеру. Вместе они превращают обслуживание LLM из набора изолированных серверов моделей в согласованную распределённую систему, и это различие становится важнее по мере перехода от простого чата к агентам с длинными контекстами, вызовами инструментов и неравномерными всплесками трафика. Главный урок аналогии в том, что производительность зависит от координации, а не только от сырой мощности: добавление ускорителей не делает инференс быстрым и дешёвым само по себе — системе нужно знать, куда направлять работу, что можно переиспользовать, какие задачи могут подождать и какие ресурсы лучше подходят каждой стадии.

llm-d запущен в мае 2025 года как совместная работа основателей IBM Research, Red Hat, Google Cloud, NVIDIA и CoreWeave. Ряд партнёров-основателей участвовал с самого начала, включая AMD, Cisco, Hugging Face, Intel, Lambda и Mistral AI, а также академических сторонников из Калифорнийского университета в Беркли и Чикагского университета. Сегодня разработку llm-d продолжают вести IBM Research, Red Hat и Google Cloud, а сообщество партнёров и контрибьюторов заметно выросло. В марте 2026 года основатели передали llm-d в Cloud Native Computing Foundation как sandbox-проект, чтобы продвигать развёртывание инференс-стеков для любой модели, на любом ускорителе, в любом облаке.