Continuous Batching (непрерывная пакетная обработка)

Continuous batching — техника обслуживания LLM, планирующая работу на уровне итераций, а не запросов. Статический батчинг ждёт, пока соберётся группа запросов, выполняет их вместе и не принимает новых, пока не завершится весь пакет — одна длинная генерация держит остальных в заложниках. Continuous batching пересобирает пакет на каждом шаге декодирования: как только любая последовательность выдала финальный токен, её слот на лету передаётся ожидающему запросу. Подход, популяризованный Orca и реализованный в vLLM, TGI и TensorRT-LLM, обычно повышает пропускную способность GPU в несколько раз при той же задержке, потому что ускоритель не простаивает на паддинге и отстающих. Он сочетается со страничным управлением KV-кэшем, поскольку последовательности разной длины должны эффективно делить память. Для SaaS-команд, размещающих открытые модели у себя, выбор сервера с continuous batching — часто самый сильный рычаг снижения стоимости токена. О том, что это за техника, стоит сказать точно, потому что название подталкивает к неверному прочтению. Continuous batching — это не «батч побольше». Это другой алгоритм планирования, работающий на уровне итераций: сервер добавляет поступающие запросы в активный пакет и выводит из него завершённые потокенно, вместо того чтобы считать пакет фиксированной группой, которую надо собрать, прогнать и слить целиком. Именно это различие позволяет ему поглощать дико разную длину генерации, которую даёт реальный трафик — один пользователь просит слово, другой три страницы, — без того чтобы короткие запросы ждали длинный. Так как это чисто планировочное изменение, на качество вывода оно не влияет никак: те же веса дают то же распределение, просто ускоритель перестаёт простаивать. И это не то, что конечный пользователь настраивает параметрами API. Это серверная инфраструктура, выбираемая в момент подбора или развёртывания движка инференса, и со стороны клиента размещённого API она невидима — хотя выгоду вы получаете косвенно, поскольку разблокированная ею пропускная способность на GPU входит в то, как провайдеры удерживают нынешний уровень цен за токен, сохраняя маржу. Если вы размещаете модель сами, практический вывод таков: планировщик значит не меньше модели — два развёртывания одинаковых весов на одинаковом железе могут отличаться в разы по числу обслуженных запросов на доллар в зависимости от того, пересобирает ли сервер пакет на каждом шаге. Сочетайте это с постраничным управлением KV-кэшем: последовательности разной длины, делящие память GPU, — ровно то условие, при котором фрагментация обходится дорого. Последнее замечание: техника повышает пропускную способность, а не задержку отдельного запроса. Под высокой нагрузкой конкретный запрос может даже завершиться чуть медленнее, потому что делит ускоритель с другими; выигрыш — в суммарном числе запросов, обслуженных тем же железом. Если не измерять пропускную способность и задержку раздельно, этот размен останется незамеченным.