Оптимизация задержки инференса больших языковых моделей в промышленной эксплуатации.
Практический взгляд на снижение задержки ответа LLM в промышленной эксплуатации за счет оптимизации контекста, непрерывной пакетной обработки, KV-кеширования, квантования, интеллектуальной маршрутизации между моделями и архитектуры инференса, учитывающей особенности GPU.
Mihail Leybuk-GalinСистемный архитекторПоделиться статьёй
1. Задержка — свойство системы
Когда приложение с LLM в рабочей среде кажется медленным, обычно в первую очередь винят саму модель. На практике модель — лишь один компонент гораздо более длинного пути запроса.
Прежде чем первый содержательный токен попадёт в интерфейс, пользовательский запрос может пройти через API-шлюз, аутентификацию, векторный поиск, переранжирование, формирование промпта, планировщик инференса, выполнение на GPU, модерацию и потоковую передачу.
Поэтому оптимизация только количества токенов в секунду может дать отличные результаты в бенчмарках, но не улучшить заметным образом воспринимаемую скорость работы. Первый шаг — определить бюджет задержки и установить, на что тратится каждая миллисекунда.
2. Критический путь инференса LLM
Инференс LLM включает два принципиально разных этапа: prefill и decode. На этапе prefill входной контекст обрабатывается параллельно, а на этапе decode выходные токены генерируются последовательно.
Критический путь запроса к LLM в промышленной эксплуатации
Открыть полноразмерное изображениеДля интерактивных приложений важнейшей метрикой часто оказывается время до первого токена (TTFT). Ответ, который начинает поступать в течение нескольких сотен миллисекунд и постепенно отображается по мере генерации, обычно воспринимается как более быстрый, чем ответ, перед которым система молчит несколько секунд.
Длина промпта напрямую влияет на затраты этапа prefill. Большие контекстные окна не дают бесплатной ёмкости: каждый лишний токен расходует вычислительные ресурсы, пропускную способность памяти и место в KV-кеше. Поэтому контекст необходимо рассматривать как часть инфраструктурного бюджета.
3. Оптимизация вычислений и памяти
После инструментирования пути запроса наибольший выигрыш обычно даёт повышение эффективности использования GPU при одновременном сокращении лишней работы на каждый запрос. Непрерывная пакетная обработка, KV-кеширование, кеширование префиксов, квантование и подбор моделей подходящего размера лучше всего работают в сочетании, а не по отдельности.
inference.yaml
# Production inference profile
model:
precision: fp8
max_context_tokens: 16384
scheduler:
continuous_batching: true
max_concurrent_sequences: 128
max_batch_tokens: 32768
cache:
kv_cache: true
prefix_cache: true
response:
streaming: true
cancel_on_disconnect: trueНепрерывная пакетная обработка позволяет последовательностям разной длины независимо входить в активный пакет и выходить из него, поддерживая загрузку вычислительных ресурсов GPU. KV-кеширование предотвращает повторное вычисление состояния механизма внимания, а кеширование префиксов позволяет исключить повторную обработку prefill для общих системных промптов и определений инструментов.
Квантование снижает нагрузку на память, однако наиболее эффективная оптимизация часто лежит на уровне архитектуры: простые запросы на классификацию, извлечение данных и суммаризацию следует направлять меньшим моделям, оставляя самую большую модель для задач рассуждения, которым она действительно необходима.
4. Проектирование архитектуры обслуживания запросов с низкой задержкой
Системы инференса в рабочей среде должны изолировать компоненты с разными характеристиками масштабирования. Поисковые воркеры, процессы API, пулы инференса и потоковые соединения не должны конкурировать за одни и те же лимиты или масштабироваться по одному и тому же сигналу.
Стратегия маршрутизации
Малая модель
Классификация, извлечение данных, маршрутизация
Средняя модель
Создание кратких изложений и стандартная генерация
Большая модель
Сложные рассуждения и эскалация
Автомасштабирование должно опираться на сигналы, характерные для инференса: глубину очереди, TTFT p95, число активных последовательностей, загрузку GPU и заполненность KV-кеша. Загрузка CPU сама по себе обычно плохо отражает нагрузку на обслуживание запросов с помощью GPU.
5. Результаты и метрики
Оптимизацию в рабочей среде следует оценивать по задержке, которую испытывает пользователь, эффективности использования оборудования и стоимости, а не только по совокупной пропускной способности в бенчмарках.
- Целевой TTFT p95
- 650мс
- Загрузка GPU
- 82%
- Стоимость одной генерации
- -46%
Наиболее эффективные системы в рабочей среде сочетают короткие промпты, непрерывную пакетную обработку, кеширование, модели подходящего размера, квантование, маршрутизацию с учётом очередей, отмену запросов и постепенную потоковую передачу. Цель — предсказуемая задержка при реальной одновременной нагрузке, а не просто более высокий результат в синтетическом бенчмарке.