Инференс LLM на GPU: режимы сервинга и SLA

Задача страницы. Дать понятную основу для прод‑инференса LLM: какие есть режимы сервинга, как считать TPS/QPS/латентность, как выбрать фреймворк и GPU, как планировать мощность и стоимость, и куда углубляться дальше.

TL;DR

• Режимы: offline‑пакетный, online‑синхронный, стриминг токенов (SSE/WebSocket). Для прод‑чатов почти всегда нужен стриминг.
• Выбор стека: vLLM — высокий throughput (PagedAttention, prefix‑кэш). TensorRT‑LLM — минимальная латентность с компиляцией графа/FP8 (H100). TGI — универсальный сервинг, стабильный API, пулы моделей. SGLang — очень высокий TPS на A/H‑сериях. llama.cpp — лёгкий сервинг на тонких GPU/CPU с INT4/INT8.
• SLA и стоимость: фиксируйте p50/p95 латентность, целевой TPS/QPS и бюджет за 1M токенов. Снижайте стоимость через квантизацию, батчинг, prefix‑кэш и мульти‑модельный шедулинг.

Режимы сервинга и SLO/SLA

Режимы

• Offline (batch): очереди заданий, нет стриминга. Подходит для генерации массивов контента или оффлайн‑аналитики.
• Online (request/response): синхронный вызов, ответ целиком. Просто, но p95 ухудшается на длинных ответах.
• Стриминг: отдача токенов по мере готовности (SSE/WebSocket). Минимизирует «пустое ожидание» у пользователя и сглаживает p99.

SLO → SLA

• Метрики: p50/p95/p99 latency, throughput (tokens/sec), QPS (req/sec), доля ошибок, стабильность версии модели.
• Ограничения: максимальная длина контекста, лимиты на одновременные генерации, тайм‑ауты.

Как считать производительность

Обозначим: L_in — длина промпта, L_out — средняя длина ответа, P — скорость prefill (токены входа/с), D — скорость decode, B — размер батча, O — накладные.

Латентность одной сессии:

T ≈ (L_in / P) + (L_out / (D / B)) + O
QPS ≈ B / T
Cost_per_1M_tokens ≈ (GPU_hour_price × Num_GPU) / (TPS_decode × 3600 / 1e6)

Для планирования закладывайте запас по p95. Prefill «дорогой» при длинных промптах; decode — при длинных ответах и низком батчинге.

Выбор фреймворка под задачу

• Высокий TPS/низкая цена за 1М токенов → vLLM: PagedAttention, prefix‑caching, гибкое планирование батчей.
• Минимальная p95‑латентность и «жёсткий SLA» → TensorRT‑LLM (компиляция графа, FP8/FP16, kernels).
• Стандартизированный REST/гейтвей, мульти‑модель → TGI с очередями и масштабированием.
• Экстремальный TPS на A/H → SGLang.
• Лёгкий сервинг/тонкие инстансы → llama.cpp (INT4/INT8), CPU‑offload.

Сопутствующие темы: квантизация, мульти‑модель, стриминг.

Выбор GPU: ориентиры

• 7B–8B: комфортно на 24–48 GB VRAM (bf16/fp16); при INT4/INT8 можно на меньших картах.
• 13B: 40–80 GB VRAM или квантизация.
• 34–70B: 80 GB+ (или несколько GPU), почти всегда квантизация + агрессивный батчинг.
• H100/A100/L40S: для стриминга при больших очередях H100 выигрывает в p95; L40S/A100 дают отличный баланс цена/производительность.

Смотрите также планировщик стоимости и расчёт стоимости инференса.

Память на инференсе: KV‑кэш и квантизация

• KV‑кэш растёт ~линейно с L_in + L_out и числом одновременных запросов.
• Снижайте память: paged‑KV, FP8/INT8‑кэш, prefix‑кэш общих подсказок.

Подробнее: vLLM, квантизация.

Мульти‑модельный хостинг и планировщик

• Подходы: static‑pool (фиксированные веса), on‑demand загрузка, горячий кэш моделей.
• Шедулинг: приоритизация по классу запроса, лимиты на модель, fair‑share.
• Изоляция: квоты VRAM/CPU/диска на модель, тайм‑ауты, защита от «тяжёлых» промптов.

Подробнее: мульти‑модельный хостинг.

Чек‑лист запуска в прод

• Зафиксированы SLA (p95, TPS/QPS), лимиты контекста.
• Выбран фреймворк и метод квантизации; подтверждена совместимость токенайзера.
• Настроены стриминг, тайм‑ауты, ограничения (макс. длина/скорость).
• Включены prefix‑кэш/пулы моделей (если актуально).
• Метрики/трейсы/логи подключены; алерты на деградации.
• Тест СИ: нагрузочный прогон, валидация p95 и «хвостов».

Навигация по разделу «Инференс LLM»

Платформы сервинга: vLLM • TensorRT‑LLM • TGI • SGLang • llama.cpp

Производительность и стоимость: квантизация • мульти‑модель • стоимость

Продукт и эксплуатация: стриминг • агенты • guardrails • наблюдаемость