Разные ускорители для одного ответа: как работает мультичиповый инференс
Мультичиповый инференс — это схема обработки, в которой стадии одного запроса к языковой модели выполняют разные вычислительные ресурсы. Например, GPU обрабатывает длинный контекст, специализированный ускоритель генерирует продолжение, а CPU координирует запрос и исполняет код или вызовы инструментов.
Разделение позволяет независимо масштабировать стадии с разными требованиями к вычислениям и памяти. Однако выигрыш не гарантирован: между устройствами нужно передавать состояние запроса, а планировщик должен учитывать очереди, свободную память, расположение данных, пропускную способность сети и требования к задержке.
Почему инференс делят на две фазы
Ответ языковой модели формируется в две основные фазы. Во время подготовки контекста модель параллельно обрабатывает входные токены и сохраняет промежуточные ключи и значения слоёв внимания в KV-кэше. Во время декодирования она по одному выпускает следующие токены, каждый раз используя веса и накопленный кэш.
У этих фаз разные профили нагрузки. Подготовка достаточно длинного контекста обычно сильнее зависит от вычислительной производительности, тогда как последовательное декодирование чаще ограничивает скорость чтения памяти. Руководство Modular по раздельному инференсу также связывает первую фазу со временем до первого токена, а вторую — с интервалом между последующими токенами.
При совместном выполнении на одном устройстве фазы мешают друг другу: длительная обработка нового запроса может задержать очередной токен уже начатого ответа. Раздельные пулы устраняют эту прямую конкуренцию и позволяют по-разному настраивать их размер, пакетную обработку и параллелизм. В этой статье «мультичиповый» означает именно такое распределение работы; устройства могут находиться как в одном сервере, так и на разных узлах.
Маршрут одного запроса
Рассмотрим условного помощника: ему передали длинный договор, попросили найти рискованный пункт, свериться с внутренним справочником и подготовить пояснение. Маршрутизатор выбирает модель и узел подготовки, после чего токенизированный договор поступает на GPU либо другой ускоритель, подходящий для параллельной обработки длинного входа.
Подготовка создаёт KV-кэш и данные, необходимые для первого выходного токена. Затем совместимый узел декодирования получает это состояние и продолжает запрос без повторной обработки всего договора. Передавать нужно не абстрактный «ответ», а конкретные блоки кэша в согласованном формате; узлы должны одинаково понимать их разметку, тип данных и параметры модели.
Исследование DistServe на OSDI 2024 размещает подготовку и декодирование в разных пулах GPU, отдельно подбирает для них ресурсы и учитывает пропускную способность кластера при размещении узлов. Полученные авторами результаты относятся к исследованным моделям, нагрузкам и оборудованию, поэтому не доказывают преимущество разделения в любой инфраструктуре.
Если в ходе генерации модель запросила инструмент, оркестратор приостанавливает этот цикл, передаёт вызов прикладному сервису и возвращает результат модели. Новые токены результата нужно обработать перед продолжением декодирования; совместимый префикс и его кэш при этом можно сохранить. Поэтому агентный ответ способен несколько раз чередовать вычисления модели с работой CPU и внешних сервисов.
Как роли распределяют между оборудованием
Общий принцип не предписывает конкретных производителей. Вычислительно насыщенную подготовку можно направить в один пул, чувствительное к пропускной способности памяти декодирование — в другой, а маршрутизацию и обычную программную логику оставить центральным процессорам. Важно, чтобы выбранные устройства поддерживали одну модель и совместимый формат передаваемого состояния.
Конкретный вариант описан в анонсе Intel и SambaNova: будущая архитектура сочетает GPU для подготовки контекста, RDU SambaNova для декодирования и Xeon 6 в роли основных и исполнительных CPU. Это проект решения, заявленный с ожидаемой доступностью во второй половине 2026 года, а не подтверждение его всеобщей доступности или превосходства при любой нагрузке.
Раздельное масштабирование особенно полезно при меняющемся соотношении входных и выходных токенов. Поток длинных документов требует больше мощности подготовки, а продолжительные ответы дольше занимают декодеры. В однородном пуле увеличение одной стадии неизбежно добавляет ресурсы и для другой; в раздельной системе их количество можно менять независимо.
Откуда берётся экономия и чем за неё платят
Потенциальная экономия возникает из более точного соответствия оборудования задаче и более полной загрузки каждого пула. Устройство подготовки не ждёт коротких шагов генерации, а декодер не прерывает текущие ответы ради длинного нового контекста. Это может увеличить число запросов, обслуживаемых имеющимся оборудованием, но итог зависит от модели, размеров пакетов, длины входов и целевых задержек.
Gimlet Labs предлагает более широкий вариант неоднородного облака. В описании Gimlet Cloud компания заявляет, что её программный слой разбивает нагрузку и распределяет стадии между GPU, CPU, вычислителями около памяти и потоковыми архитектурами, а затем динамически их перебалансирует. Указанные там выигрыши в скорости и эффективности остаются заявлениями Gimlet для собственной системы, а не независимым сравнением всех мультичиповых конфигураций.
Главная цена разделения — перенос KV-кэша. Его объём увеличивается с длиной обрабатываемой последовательности, поэтому медленное межсерверное соединение способно перекрыть выгоду от специализированного декодера. Дополнительные издержки создают хранение весов модели в нескольких пулах, резервирование памяти под всплески трафика, преобразование форматов и поддержка программного слоя для разных архитектур.
Почему результат определяет планировщик
Планировщику приходится одновременно контролировать время до первого токена и интервалы между следующими. Отправить запрос на формально самый быстрый ускоритель недостаточно: к моменту передачи кэша декодер может быть занят, а свободный узел — находиться за соединением с недостаточной пропускной способностью.
Система оценивает длину входа, доступность сохранённого префикса, ожидаемый объём генерации, очереди и запас памяти. Она объединяет совместимые запросы в пакеты, выбирает пару узлов и ограничивает скорость подготовки, если декодеры не успевают принимать новые состояния. Без обратного давления раздельный конвейер не устраняет очередь, а лишь переносит её к сетевому соединению или следующему пулу.
Мультичиповая схема наиболее убедительна при крупном неоднородном потоке, где длинные контексты соседствуют с продолжительной генерацией и вызовами инструментов. При коротких запросах, небольшой загрузке, высокой доле повторно используемых префиксов или слабой сети единый сервер может оказаться быстрее и проще. Поэтому архитектуру оценивают не по числу типов чипов, а по задержкам обеих фаз, объёму передаваемого кэша, загрузке пулов и стоимости эксплуатации всей системы.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.