Как оптимизировать LLM inference pipeline
Приходилось ли заниматься оптимизацией LLM inference pipeline: routing, batching, serving? Какие рычаги ускорения и удешевления инференса стоит назвать?
Короткий ответ
Нужно говорить про throughput/latency trade-off: continuous batching, padding-aware batching, KV cache, quantization, model/runtime choice, async serving, streaming, scheduler и мониторинг tail latency.
Полный разбор
Сильный ответ начинается с метрики: оптимизируем не абстрактно "быстрее", а latency, TTFT, tokens/sec, throughput, GPU utilization, cost per 1k tokens и tail latency. После этого можно разложить pipeline на prefill, decode, scheduler, batching, memory, runtime и сетевой слой.
Практические рычаги: continuous batching, grouping запросов по длине, ограничение max context, KV cache reuse, paged attention, quantization, выбор dtype, tensor/pipe parallel при больших моделях, speculative decoding, prefix caching, streaming ответов, асинхронный API и backpressure.
Важно проговорить ограничения: слишком крупные batch ухудшают latency, quantization может бить по качеству, длинный context раздувает KV cache, а оптимизация runtime не помогает, если bottleneck в продуктовой логике или внешних tools.
Теория
LLM serving отличается от обычного batch inference тем, что decode идет токен за токеном, а запросы имеют разную длину. Поэтому scheduler и memory management часто важнее, чем только raw FLOPS модели.
Типичные ошибки
- Перечислить только quantization и не обсудить batching/scheduler.
- Не разделить prefill и decode.
- Не назвать измеримые метрики: TTFT, tokens/sec, p95 latency, GPU utilization.
Как отвечать на собеседовании
- Сначала спроси, что оптимизируем: latency, throughput или cost.
- Раздели ответ на model-level, runtime-level и service-level оптимизации.