Настройка динамического батчинга для LLM: ускорение GPU

Динамический батчинг LLM: почему ускорители простаивают

Ускоритель, обслуживающий один запрос за раз, почти всегда работает вполсилы. Пока языковая модель генерирует ответ токен за токеном, на каждом шаге выполняются небольшие операции над одной последовательностью, а память занята весами. Вычислительные блоки простаивают — и это не редкий сбой, а штатный режим поштучной обработки запросов.

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

Динамический батчинг LLM закрывает этот разрыв: запросы, пришедшие в короткое окно, объединяются в одну пачку. Ключевое отличие от статической схемы — состав пересобирается на каждом шаге генерации: завершённые последовательности покидают пачку, новые занимают их место. Она остаётся заполненной, и обработка не ждёт самого медленного запроса в наборе.

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

Что меняется после настройки: скорость отклика и загрузка ускорителей

Пока запросы уходят в ускоритель по одному, он простаивает между прогонами: вычисления занимают доли времени, остальное уходит на ожидание следующего вызова. Динамический батчинг собирает запросы, пришедшие в коротком окне, в один прогон — Triton Inference Server и родственные среды делают это на уровне планировщика, а не кода модели. Пропускная способность на том же парке вырастает кратно: узкое место смещается с ускорителя на сеть и подготовку данных.

Второе следствие — задержка отклика перестаёт зависеть от наплыва пользователей. Пока окно ожидания и верхняя граница батча заданы явно, одиночный запрос не ждёт «пока наберётся компания», а пиковый поток не выстраивается в растущую очередь. Снимаем медиану и 95-й перцентиль до и после: обычно выигрывает не средний, а худший случай — именно поэтому интерфейс перестаёт подвисать на пиках.

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

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

Варианты сборки запросов в пакеты: сравнение режимов

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

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

Порядок внедрения: от профиля нагрузки до вывода в работу

Динамический батчинг не включается одним переключателем: окно сбора, максимальный размер батча и лимиты ожидания подбираются под конкретный профиль трафика. Ниже — этапы внедрения: от замера реальной нагрузки до передачи сервиса в эксплуатацию.

1. Замер профиля нагрузки — распределение запросов по длине входа и выхода, доля коротких и длинных ответов, пиковые интервалы. Без этих чисел размер батча подбирается наугад.

2. Схема сбора очереди — где запросы объединяются: в приложении, в промежуточном слое или в самом сервисе вывода, и как согласуются окна ожидания между уровнями.

3. Настройка сервиса вывода — предельный размер батча, окно ожидания, поведение при переполнении очереди и приоритет интерактивных запросов перед фоновыми.

4. Разделение по классам трафика — короткие диалоговые запросы уходят в небольшие батчи, пакетная обработка в крупные, чтобы длинные задания не задерживали ответ пользователю.

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

6. Предохранители и откат — возврат к одиночной обработке одним переключением и пороги, при которых батчинг отключается автоматически.

7. Передача в эксплуатацию — конфигурация, панели с ключевыми метриками, регламент изменения лимитов и разбор типовых отказов.

Что передаём на руки: конфигурации, схемы, регламенты

Передаём не презентацию, а рабочий комплект: по нему ваш инженер сможет менять поведение батчинга, диагностировать всплески задержек и вернуть предыдущий режим, не дожидаясь нас. Ниже — что остаётся в репозитории и во внутренней базе знаний к моменту сдачи.

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

Кейс: рост пропускной способности на том же парке ускорителей

Заказчик — сервис поддержки с потоком обращений через чат: один парк ускорителей, ночью нагрузка ровная, днём короткие пики в 4-5 раз выше средней. Расширять парк не хотели: в такие пики ускорители простаивали, и вложения в новые карты нужно было чем-то обосновать.

До изменений размер батча был выставлен фиксированным — по средней нагрузке. На пике запросы копились в очереди: 95-й перцентиль времени отклика доходил до 4,5 секунды, а 9% обращений падали по превышению времени ожидания — при неравномерной загрузке ускорителей.

Работу перестроили на сервер вывода моделей vLLM с непрерывным батчингом: планировщик пересобирает батч на каждом шаге генерации и подставляет новые запросы в освободившиеся слоты, не дожидаясь завершения текущего набора. Параллельно ограничили длину очереди, задали потолок по памяти под кэш и развели приоритеты — короткие обращения больше не ждут длинных генераций.

Что стало на том же парке: пропускная способность выросла примерно втрое — с 18 до 52 запросов в секунду, 95-й перцентиль отклика опустился до 1,2 секунды, доля отказов по перегрузке — с 9% до 0,4%, загрузка ускорителей в пиковые часы вышла на 85-90% вместо 40-60%. Конфигурацию с ожидаемым бюджетом задержки и лимитами очереди перенесли на остальные модели сервиса без изменения железа.

Чем непрерывная сборка пакетов отличается от динамической?

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

Отсюда разница в эффекте. На смешанном трафике, где рядом идут короткая реплика и длинное рассуждение, ускоритель перестаёт ждать отстающих — пропускная способность растёт в разы на том же оборудовании, а задержка до первого ответа становится предсказуемой.

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

Выбор режима определяется профилем нагрузки. Однородные короткие запросы почти не чувствуют разницы подходов — там достаточно динамической сборки, она проще в сопровождении. Смешанные длины ответов — случай непрерывной.

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

Сомнения перед внедрением: очереди, задержки, устойчивость

На этапе выбора подрядчика технические сомнения звучат почти одинаково: не станет ли хуже от того, что запросы теперь обрабатываются пакетами. Динамический батчинг LLM выглядит логично на графиках утилизации ускорителя, но у инженера сразу возникает встречный вопрос — какой ценой. Ниже пять вопросов, которые чаще всего задают на разборе, и короткие ответы по делу.

Что при неравномерной нагрузке — простой или захлёб?

Диспетчер пересчитывает размер пакета и окно по фактическому входящему потоку: ночью он держит пакеты крупными и выжимает ускоритель, на резком всплеске — уменьшает их, чтобы не копить задержку. Границы задаются в конфигурации как политика, а не подбираются на глаз.

Начнёт ли сервис отбрасывать запросы при перегрузке?

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

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

Размер пакета ограничивается сверху по объёму доступной памяти, поэтому аварийная остановка обработки исключена. При пике политика сама снижает размер пакета — пропускная способность проседает плавно, без полного отказа.

Как проверяем устойчивость и что с откатом?

Устойчивость под пиком подтверждаем прогоном по профилю реальной нагрузки — ступенчатый рост, обрыв соединений, повторные запросы. Откат к статическому режиму делается одним параметром конфигурации, без пересборки сервиса и правок в коде приложения.

Обсудим задачу: что нужно для оценки и плана работ

Оценка проекта по динамическому батчингу для LLM опирается не на общие соображения, а на профиль вашей нагрузки и текущую схему обслуживания запросов. Чем конкретнее вводные, тем меньше уточняющих кругов и тем точнее план работ — с порядком этапов и точками, где возможен откат.

• Профиль нагрузки. Сколько запросов приходит в среднем и в пике, как они распределены по длине входа и выхода, есть ли суточные всплески. Это определяет, сколько запросов объединяется в один пакет и где выигрыш будет заметен.
• Текущая схема. Один экземпляр модели или несколько, как распределяются запросы, есть ли очередь и кэш ответов, как обновляются веса. Без этого непонятно, что именно менять.
• Ограничения по времени ответа. Где задержка критична — интерактив, потоковая выдача, — а где можно подождать. Динамический батчинг балансирует между пропускной способностью и ожиданием, и границы задаёте вы.
• Инфраструктура и доступы. Какие ускорители и в каком количестве, как устроено развёртывание, есть ли тестовый контур для прогона нагрузки без риска для продуктивной среды.
• Метрики. Чем измеряете пропускную способность и задержку сейчас, какие срезы собираете и по каким показателям будете принимать работу.
• Команда и роли. Кто на вашей стороне отвечает за инфраструктуру, кто за модель, кто принимает результат — чтобы не ждать ответов по кругу.

Опишите задачу в свободной форме — вернёмся с оценкой, планом работ и уточняющими вопросами, если чего-то не хватит.