Continuous batching и статический батчинг: как работает планирование запросов LLM
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Статический батчинг объединяет запросы для одного запуска инференса. Continuous batching обновляет набор активных запросов между итерациями генерации: завершённые запросы удаляются, а ожидающие запросы добавляются, если они соответствуют условиям. Это позволяет серверу повторно использовать ресурсы, не дожидаясь завершения всех исходных запросов.
Для инженеров, отвечающих за сервинг, польза зависит от различий в длине ответов, политики планировщика, ёмкости памяти и требований к латентности.
Сравните ответы разной длины
Допустим, трём запросам нужны 10, 40 и 100 выходных токенов. В простом цикле генерации с фиксированным батчем, который не заменяет завершённые запросы, ресурсы первых двух освобождаются до завершения третьего. Однако сервер всё равно ждёт самый длинный ответ в батче, прежде чем запустить следующий полный батч.
Планировщик на уровне итераций может удалить каждый завершённый запрос и принять другой. Orca предложила архитектуру сервинга LLM с таким подходом к планированию. Для приёма запроса по-прежнему нужны свободные блоки KV cache и подходящий бюджет итерации. Continuous batching не означает, что каждый запрос из очереди запускается немедленно.
Новым промптам также нужен префилл. Префилл, разбитый на чанки, может делить бюджет итераций с текущими операциями декодирования. Поэтому правила приёма и приоритетов планировщика влияют и на время до первого токена, и на интервалы между последующими токенами.
Сравните планировщик и весь рантайм
Эксперимент Anyscale 2023 года показал примерно 4x для FasterTransformer, 8x для конфигураций с continuous batching и 23x для vLLM относительно простой базовой реализации. В нём использовались OPT-13B, A100-40GB, 1,000 запросов, входы длиной 512 токенов и экспоненциальное распределение длины выходов со средним значением 128 токенов. Эти результаты относятся к полным реализациям в такой конфигурации, а не к отдельному эффекту одного изменения в планировании.
Для своего сравнения зафиксируйте:
| Что проверить | Почему это важно |
|---|---|
| Распределения поступления запросов и длины выходов | Определяют неиспользуемые ресурсы и нагрузку на очередь |
| Максимальное число активных последовательностей и бюджет токенов | Ограничивают работу в каждой итерации |
| Выделение памяти для KV и вытеснение | Могут блокировать приём новых запросов |
| TTFT и латентность генерации для каждого запроса | Показывают затраты для отдельных запросов |
| Доля успешных запросов и goodput | Показывают, соответствует ли дополнительная работа целевым требованиям сервиса |
Анализируйте короткие и длинные запросы отдельно. Более высокий общий throughput может сочетаться с худшей латентностью для одной группы запросов. Выбирайте настройки планирования по измеренным требованиям сервиса.
Инженерное руководство: continuous batching объясняет вместе механизмы выделения ресурсов и планирования.