Решения

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

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

TL;DR

  • Режимы: offline‑пакетный, online‑синхронный, стриминг токенов (SSE/WebSocket). Для прод‑чатов почти всегда нужен стриминг.
  • Выбор стека:
     – /solutions/llm-inference/vllm/ — высокий throughput (PagedAttention, prefix‑кэш).
     – /solutions/llm-inference/tensorrt-llm/ — минимальная латентность с компиляцией графа/FP8 (H100).
     – /solutions/llm-inference/tgi/ — универсальный сервинг, стабильный API, пулы моделей.
     – /solutions/llm-inference/sglang/ — очень высокий TPS на A/H‑сериях.
     – /solutions/llm-inference/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 (без очередей):

QPS ≈ B / T

Производительность по токенам:

TPS_decode ≈ D   (зависит от модели/GPU/фреймворка)

Tokens_per_hour ≈ TPS_decode × 3600

Стоимость на 1M токенов (грубая оценка):

Cost_per_1M_tokens ≈ (GPU_hour_price × Num_GPU) / (Tokens_per_hour / 1e6)

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

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

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

Сопутствующие темы: /solutions/llm-inference/quantization/, /solutions/llm-inference/multi-model/, /solutions/llm-inference/streaming/.

Выбор 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 дают отличный баланс цена/производительность.

Смотрите также /solutions/cost-planner/ и /solutions/llm-inference/costs/.

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

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

Подробнее: /solutions/llm-inference/vllm/, /solutions/llm-inference/quantization/.

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

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

Подробнее: /solutions/llm-inference/multi-model/.

Стриминг токенов: интерфейсы и тайм‑ауты

  • Протоколы: SSE (проще проксировать), WebSocket (интерактивные UI).
  • Настройки: keep‑alive, heartbeat, границы чанков (по токену/времени), бэкап‑тайм‑ауты на prefill/decode, backpressure.

Подробнее: /solutions/llm-inference/streaming/.

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

  • Guardrails: фильтрация, PII‑санитайзинг, шаблоны безопасных промптов.
  • Наблюдаемость: метрики latency/TPS, трассировка запросов, логи сэмплов, отладка «хвостов» p99.

Подробнее: /solutions/llm-inference/guardrails/, /solutions/llm-inference/observability/, /solutions/llm-training/eval/.

Стоимость и SLA: как свести воедино

Шаги планирования

  1. Зафиксируйте SLA: p95 latency, минимальный TPS/QPS, доступность.
  2. Выберите стек (см. раздел 3) и квантизацию: /solutions/llm-inference/quantization/.
  3. Оцените P, D из пилотных прогонов → рассчитайте T, QPS, Стоимость за 1М (формулы выше).
  4. Решите, что дёшевле: меньше GPU + агрессивная квантизация/батчинг или больше GPU + низкие задержки.
  5. Для экономии используйте Interruptible при нестрогих SLA, а для жёстких p95 — On‑Demand. Подробнее: /solutions/cost-planner/.

Мини‑конфиги запуска (для ориентира)

vLLM (стриминг + prefix‑кэш + ограничение контекста)

				
					vllm serve meta-llama/Llama-3-8B \
  --max-model-len 8192 \
  --enable-prefix-caching \
  --gpu-memory-utilization 0.90 \
  --enforce-eager \
  --trust-remote-code
# API: /generate (стриминг SSE) /chat

TensorRT‑LLM (оптимизация под H100)

				
					# Предварительно: сборка движка (builder), затем сервер:
trtllm-build --checkpoint-dir ./ckpt --gemm-plugin auto --fp8
trtllm-server --engine-dir ./engines --http-port 8000 --grpc-port 50051

TGI (универсальный REST‑сервис)

				
					text-generation-launcher --model ./ckpt \
  --max-input-length 8192 --max-total-tokens 12288 \
  --sharded false --num-shard 1 --port 8080

SGLang (высокий TPS)

				
					python -m sglang.launch_server --model ./ckpt --port 30000 --tp 1 --context-length 8192

llama.cpp (тонкий сервинг, INT4/INT8)

				
					./server -m ./model.gguf -c 4096 -ngl 35 -t 12 --port 8081 --timeout 120

Параметры (len, кэш, tp, порт, тайм‑ауты) подбираются под вашу модель/SLA.

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

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

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

Платформы сервинга:
 → /solutions/llm-inference/vllm/ • /solutions/llm-inference/tensorrt-llm/ • /solutions/llm-inference/tgi/ • /solutions/llm-inference/sglang/ • /solutions/llm-inference/llama-cpp/


Производительность и стоимость:
 → /solutions/llm-inference/quantization/ • /solutions/llm-inference/multi-model/ • /solutions/llm-inference/costs/


Продукт и эксплуатация:
→ /solutions/llm-inference/streaming/ • /solutions/llm-inference/agents/ • /solutions/llm-inference/guardrails/ • /solutions/llm-inference/observability/

Траблшутинг

  • Высокая p95: уменьшите L_in (суммарный контекст), включите стриминг, повысьте батч‑эффект на декоде, используйте более быстрый стек (TensorRT‑LLM/H100).
  • GPU‑OOM: сократите max-model-len, понизьте dtype KV‑кэша, включите paged‑KV/prefix‑кэш, примените INT8/INT4.
  • Нестабильный TPS: проверьте конкурентный доступ к диску/сети, утилизацию CPU (токенайзер), кол‑во воркеров, «пробки» в планировщике.
  • Низкая полезность ответа: проверьте промпт‑шаблоны, системные сообщения, включите фильтры/guardrails, обновите базовую модель.