Асинхронное батчирование сокращает простои GPU и может дать до ~24% ускорения инференса LLM

Во второй статье серии по эффективному инференсу LLM, опубликованной 14 мая 2026 года, авторы демонстрируют, что асинхронное батчирование — разделение подготовки батчей на CPU и вычислений на GPU-снижает периоды простоя и повышает загрузку ускорителей без изменений в моделях или ядрах. Это важно, потому что простаивающий GPU напрямую увеличивает стоимость длительных инференс‑задач и снижает пропускную способность сервисов. Авторы разбирают базовую проблему синхронного батчинга: CPU собирает и обновляет KV‑таблицы, отправляет данные на GPU, GPU выполняет форвард и возвращает результаты на CPU, после чего цикл повторяется. Такой последовательный поток заставляет CPU и GPU попеременно простаивать; даже при continuous batching этот синхронный порядок оставляет значительную часть времени генерации неиспользуемой для ускорителя.

В статье показан конкретный профиль работы: генерация 8K токенов с batch size 32 на 8B‑модели заняла 300.6 секунды, при этом GPU простаивал 24.0% времени в ожидании действий CPU. Авторы указывают и экономический контекст: например, конфигурация H200 на Inference Endpoints стоит примерно $5 в час (около $120 в день), поэтому улучшение загрузки ускорителя напрямую снижает расходы на инференс.

Предложенное решение — асинхронное батчирование, при котором подготовка батча N+1 выполняется параллельно с вычислениями батча N. Это уменьшает простои GPU и снижает паддинг, обеспечивая более равномерную загрузку железа. Теоретически, если полностью устранить узкие места на стороне CPU, время примера из профиля могло бы упасть до примерно 228 секунд — бесплатный прирост порядка 24% без изменений в модели или ядре. Авторы описывают ключевые технические вызовы для реализации асинхронности: как запустить задачу на GPU и немедленно вернуть управление CPU; как гарантировать своевременную готовность данных для обеих сторон; и как формировать батч N+1, когда его содержимое может зависеть от предсказаний батча N. Эти вопросы определяют архитектуру и методы синхронизации, требуемые для корректной работы.

Помимо теории, статья предлагает практические шаги: инструментацию continuous batching для дампа временных интервалов активности CPU и GPU, скрипт для анализа таймлайнов с выявлением простоев и пошаговую реализацию асинхронного батчинга «с нуля». Для инженеров это значит реальную возможность заметно повысить пропускную способность и сократить затраты на длительные инференс‑воркфлоу, не меняя моделей или ядра.