ИИтог

Оркестратор передачи данных с учётом топологии сети ускоряет разделённый инференс LLM в 3, 18 раз

инфраструктураРедакция ИИтогarXiv🔥69Рейтинг ИИтог69Влияние70Новизна75Релевантность95Неожиданность50Участники30Достоверность75

При разделённом (disaggregated) инференсе больших языковых моделей этапы prefill (обработка входного запроса) и decode (генерация ответа) выполняются на разных пулах GPU, поэтому между ними приходится постоянно передавать KV-кеш, промежуточное состояние модели. Для модели с 70 миллиардами параметров это 2,6 ГБ на один запрос, а суммарный трафик в продакшене превышает 100 ГБ/с. Авторы статьи указывают, что существующие системы разделённого инференса, DistServe, Splitwise и Mooncake, передают этот кеш через единый RDMA-транспорт, не учитывая, что пропускная способность между двумя GPU может различаться в 72 раза в зависимости от их физического расположения: 900 ГБ/с внутри одного домена NVLink, 50 ГБ/с через InfiniBand между узлами и всего 12,5 ГБ/с через TCP между дата-центрами.

Предложенное решение, оркестратор передачи данных, который при запуске определяет иерархию соединений в кластере и для каждой передачи выбирает оптимальный транспорт. Он строится на трёх механизмах. Первый, конвейерная послойная передача KV-кеша, которая идёт параллельно с ещё продолжающимся prefill и, по оценке авторов, скрывает от 60 до 85% задержки передачи за счёт совмещения с вычислениями. Второй, размещение с учётом доменов NVLink для моделей типа Mixture-of-Experts (MoE, «смесь экспертов»): распределение экспертов по GPU увязывается с тем, где физически находится KV-кеш. Третий, использование модулей памяти CXL 3.0 как общего буферного уровня для переполнения: по сравнению с NVMe-накопителями он даёт в 6 раз больше ёмкости при задержке в 86 раз ниже.

Авторы прямо признают, что полноценно испытать систему на практике не удалось: для этого нужны многоузловые кластеры с разнородными соединениями и оборудование CXL 3.0, которое выходит за рамки академических ресурсов и пока недоступно даже в облачных GPU-сервисах. Поэтому статья опирается на аналитические модели пропускной способности, реализацию отдельных компонентов системы и прогнозный расчёт для трёх архитектур, по этим расчётам, задержка передачи данных сокращается в 3, 18 раз относительно единого RDMA-транспорта. Имена авторов и их организация в тексте не указаны.

Ключевые факты

  • Проблема: при разделении LLM-инференса на пулы prefill и decode KV-кеш приходится гонять между GPU, 2,6 ГБ на запрос для модели 70B, суммарно свыше 100 ГБ/с в продакшене.
  • Существующие системы DistServe, Splitwise и Mooncake используют единый RDMA-транспорт, хотя пропускная способность между GPU различается в 72 раза: 900 ГБ/с NVLink, 50 ГБ/с InfiniBand, 12,5 ГБ/с TCP.
  • Предложенный оркестратор определяет топологию соединений при старте и выбирает оптимальный транспорт под каждую конкретную передачу.
  • Три механизма: конвейерная послойная передача (скрывает 60, 85% задержки за счёт совмещения с вычислениями), размещение экспертов MoE с учётом доменов NVLink, буфер на памяти CXL 3.0 (в 6 раз больше ёмкость, задержка в 86 раз ниже, чем у NVMe).
  • По аналитическим расчётам (не измерено на реальном железе), снижение задержки передачи в 3, 18 раз против единого RDMA; полноценная проверка требует оборудования, недоступного в академических условиях и облачных GPU-сервисах.

Почему это важно

Разделённый инференс, стандартный способ обслуживать большие языковые модели в продакшене: этапы обработки запроса и генерации ответа разносят по разным пулам GPU, чтобы каждый пул был загружен своей задачей эффективнее. Но за это приходится платить постоянной передачей KV-кеша между пулами, и при росте нагрузки эта передача сама становится узким местом, трафик превышает 100 ГБ/с, а действующие системы гоняют его по единому транспорту, не различая, соединены ли GPU быстрым NVLink внутри стойки или медленным TCP между дата-центрами. Работа показывает, что это расточительно: пропускная способность между разными парами GPU отличается в 72 раза, и игнорировать эту разницу, значит недоиспользовать самое быстрое железо и упираться в самое медленное.

Кому это важно

В первую очередь, инженерам, которые строят и эксплуатируют инфраструктуру инференса больших языковых моделей: облачным провайдерам GPU, командам, обслуживающим MoE-модели с большим числом экспертов, и разработчикам систем вроде DistServe, Splitwise и Mooncake, которых работа прямо называет в числе тех, кто пока использует единый RDMA-транспорт без учёта топологии сети.

Как это применить

Идея, не менять сам факт разделения prefill и decode, а сделать передачу KV-кеша между ними осознанной по топологии: система при запуске сканирует, как физически связаны GPU в кластере (NVLink, InfiniBand, TCP), и дальше для каждой передачи выбирает самый быстрый доступный маршрут. Дополнительно передача кеша распараллеливается по слоям модели и идёт одновременно с ещё не завершившимся prefill, а для MoE-моделей размещение экспертов по GPU согласуется с тем, где физически лежит нужный кеш. Память CXL 3.0 предлагается использовать как общий буфер, когда основная память GPU переполнена, с заметным выигрышем по ёмкости и задержке относительно NVMe-накопителей.

Можно ли доверять

Работа опирается на аналитические модели пропускной способности и реализацию отдельных компонентов системы, а не на измерения на полноценном рабочем кластере, сами авторы объясняют это тем, что нужное оборудование (многоузловые кластеры с разнородными соединениями и модули CXL 3.0) выходит за рамки академических ресурсов и пока не встречается даже в коммерческих облаках GPU. Заявленное ускорение в 3, 18 раз, это прогнозный расчёт для трёх архитектур, а не измеренный на практике результат, и относиться к нему стоит соответственно.

Риски и подводные камни

Главный риск, разрыв между расчётом и реальностью: аналитическая модель может не учесть накладные расходы реальной сети, работу планировщика под конкурентной нагрузкой или особенности конкретного железа, и итоговое ускорение на практике может оказаться меньше заявленного диапазона. Часть выигрыша завязана на CXL 3.0, оборудовании, которое пока не является массовым в облачных GPU-сервисах, так что применимость решения ограничена до его более широкого распространения. В тексте не указаны ни авторы, ни их организация, ни дата публикации, что затрудняет независимую проверку и оценку конфликта интересов.