Решения

Затраты инференса LLM: TPS‑таргеты и ценообразование

Задача страницы. Дать практическую методику расчёта стоимости инференса LLM: как связаны TPS/QPS, TTFT/TTLT, длины контекста, квантизация и цена за 1M токенов; как планировать ёмкость пулов (short/long) и выбрать модель ценообразования для продукта.

TL;DR

  • Стоимость за 1M токенов определяется Tokens/hour и ценой GPU‑часа. Сокращайте контекст/выход и повышайте decode TPS — получите лучшую экономику.
  • Планируйте по профилям трафика (short/balanced/long) и держите раздельные пулы. Батчинг + стриминг дают максимум QPS без потери UX.
  • Ключевые рычаги: квантизация (INT4/INT8/FP8), жёсткие лимиты max context/max_tokens, разделение по длинам, выбор стека (vLLM/TensorRT‑LLM/TGI/SGLang/llama.cpp).
  • Начинайте с пилотных замеров prefill_rate и decode TPS, затем делайте «what‑if» на калькуляторе ниже.

Связанные страницы:
 /solutions/cost-planner/ • /solutions/llm-inference/quantization/ • /solutions/llm-inference/streaming/ • /solutions/llm-inference/multi-model/ • /solutions/llm-inference/observability/ • /solutions/monitoring-logging/ • /solutions/interruptible-patterns/

Базовая модель: как связаны задержки, TPS и цена

Обозначим:

  • L_in — входные токены (префикс/история), L_out — выход.
  • P — скорость prefill (ток/с), D — decode TPS (ток/с на батч), B — фактический батч на декоде.
  • O — накладные (парсинг, сеть, пост‑обработка).

Латентность запроса (приближённо):

T ≈ (L_in / P) + (L_out / (D / B)) + O

QPS (пропускная способность):

QPS ≈ B / T

Tokens/hour и цена за 1M токенов:

Tokens_per_hour ≈ D × 3600

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

Интерпретация: повысили D (decode TPS) или уменьшили L_out — цена за 1M снижается. Увеличили B — растёт QPS при той же цене.

Что мерить на пилоте (перед расчётами)

Соберите на реальном сэмпле трафика (см. /solutions/llm-inference/observability/):

  • Распределения L_in, L_out (p50/p95) по каждому сценарию.
  • Prefill_rate (P) и decode TPS (D) выбранного стека на вашей модели/кванте.
  • TTFT/TBT/TTLT и queue wait в пулах short/long.
  • KV‑кэш: занятость/эвикции; GPU: HBM/util.
  • Эти четыре группы метрик достаточно, чтобы построить рабочий прогноз ёмкости и цены.

Быстрый калькулятор (вставьте в любой бэкенд/скрипт)

				
					def cost_model(Lin, Lout, P, D, B, overhead,
               gpu_hour_price, num_gpu):
    # Латентность
    T = (Lin / P) + (Lout / (D / B)) + overhead   # сек
    # Пропускная способность
    QPS = B / T
    # Экономика
    tokens_per_hour = D * 3600
    cost_per_1M = (gpu_hour_price * num_gpu) / (tokens_per_hour / 1e6)
    return dict(T=T, QPS=QPS, tokens_per_hour=tokens_per_hour, cost_per_1M=cost_per_1M)

Как подставлять:

  • Берите Lin/Lout как p50 или p95 конкретного пула, P/D — из пилота, B — «средний активный батч» на декоде вашего стека (из метрик).
  • Для short‑pool оптимизируйте T (жёсткие лимиты), для balanced — cost_per_1M, для long — стабильность при больших Lin.

Профили трафика и пулы

Short (строгий SLA)

  • L_in ≤ ~1–2K, L_out ≤ ~200–300, приоритетная очередь, высокий B.
  • Рекомендуемые стеки: vLLM /solutions/llm-inference/vllm/ или TensorRT‑LLM /solutions/llm-inference/tensorrt-llm/.
  • Цель: TTFT/TTLT p95 и стабильный QPS.

Balanced

  • Средние длины, смешанный трафик, умеренные лимиты.
  • vLLM/TGI/SGLang: смотрите /solutions/llm-inference/tgi/, /solutions/llm-inference/sglang/.

Long

  • Длинные контексты/ответы; мягкая p95, меньшая конкуренция.
  • Отдельный пул/инстансы; обязательны лимиты и контроль KV‑кэша.
  • Возможен отдельный стек (например, TGI/llama.cpp): /solutions/llm-inference/llama-cpp/.

Ключевые рычаги снижения цены за 1M токенов

  1. Квантизация весов и KV‑кэша: INT4/INT8, FP8 (Hopper) → меньше VRAM, больше одновременность, выше D.
     Подробнее: /solutions/llm-inference/quantization/.
  2. Лимиты длины: max context, max_tokens, сокращение системных префиксов и истории → меньше L_in/L_out.
  3. Батчинг + стриминг: continuous batching, отдача токенов потоком → высокий B и отличный UX.
     См. /solutions/llm-inference/streaming/.
  4. Разделение по длинам: short/long пулы, разные SLO/лимиты; уменьшает «хвосты» и очереди.
     См. /solutions/llm-inference/multi-model/.
  5. Prefix‑кэш / prefill‑экономия: унифицируйте шаблоны промптов (особенно в vLLM) → растёт полезный D.
     См. /solutions/llm-inference/vllm/.
  6. Выбор стека под цель:
    – минимальная p95 → TensorRT‑LLM;
    – максимальный TPS → vLLM/SGLang;
    – универсальный REST и пулы → TGI;
    – тонкие инстансы → llama.cpp.

On‑Demand vs Interruptible (preemptible)

  • On‑Demand — фиксированная цена/ч с гарантией доступности.
  • Interruptible — ниже цена/ч, но возможны прерывания; подходит для асинхронных/пакетных задач и non‑critical потоков.
  • Эксплуатационные приёмы: автосейвы/чекпоинты, очереди повторов, гибридные пулы (часть реплик — on‑demand, часть — interruptible).

Подробно: /solutions/interruptible-patterns/, чекпоинты — /solutions/llm-training/checkpointing/.

Примеры «what‑if» (как меняется экономика)

A) Перешли с FP16 на INT8

  • D вырос, VRAM хватает на больший пул → Tokens/hour ↑, Cost_per_1M ↓.
  • Проверить качество/метрики на вашем домене (см. /solutions/llm-training/eval/).

B) Ужесточили max_tokens в short‑pool с 400 до 256

  • L_out ↓ → T ↓ → QPS ↑; цена за 1M меняется меньше, но SLA сильно выигрывает.

C) Выделили long‑пул

  • Short‑пул избавился от хвостов p95; итоговая цена/1M часто снижается за счёт лучшей утилизации.

Модели ценообразования для продукта

  • Per‑token (in/out) — честно и прозрачно; требуется точный биллинг токенов.
  • Per‑request — просто для клиента; важно жёстко ограничить max_tokens.
  • Tiered — пакеты токенов в месяц; удобно для B2B.
  • Reserved capacity — гарантированная полка QPS за фикс/мес, сверх — по счётчику.
  • Per‑minute streaming — для «долгих» сценариев (код/аналитика), но контролируйте idle‑тайм.

Как задать цену: Target margin + модель издержек:

UnitCost_per_1M = Cost_per_1M × (1 + Overheads)

Price_per_1M    = UnitCost_per_1M / (1 — TargetMargin)

Где Overheads — сеть/хранилище/гейтвей/резерв/ПО.

Пошаговый план внедрения

  1. Сегментируйте трафик на short/balanced/long.
  2. Снимите метрики P/D, L_in/L_out, TTFT/TTLT, KV/GPU (пилот).
  3. Соберите калькулятор в /solutions/cost-planner/ с вашим прайсом GPU.
  4. Выберите стек по цели (SLA/цена) и квантизацию.
  5. Задайте лимиты max context/max_tokens, включите стриминг.
  6. Разверните пулы и биллинг по выбранной модели.
  7. Наблюдаемость и алерты: /solutions/llm-inference/observability/.
  8. Итеративно оптимизируйте по p95/cost (A/B пулы, canary‑веса).

Чек‑лист перед продом

  • Определены SLO: TTFT/TBT/TTLT p95, целевые QPS/TPS, Cost_per_1M.
  • Измерены P/D, распределения L_in/L_out на пилоте.
  • Выбран стек (vLLM/TensorRT‑LLM/TGI/SGLang/llama.cpp) и схема квантизации.
  • Настроены пулы short/long и жёсткие лимиты длины.
  • Включён стриминг, continuous batching.
  • Настроен биллинг: модель тарифа, учёт токенов/минут/запросов.
  • Метрики и алерты: /solutions/llm-inference/observability/.
  • План деградации: снижение лимитов, фоллбек‑модель, перераспределение трафика.

Как это использовать в cloudcompute.ru

  • В /solutions/templates/ доступны пресеты “Cost‑Planner” и сервера под vLLM/TensorRT‑LLM/TGI/SGLang/llama.cpp.
  • Для быстрых оценок и мониторинга цены за 1M токенов подключите счётчики из /solutions/llm-inference/observability/ и добавьте панель «Economy».

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

/solutions/llm-inference/ • /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/streaming/ • /solutions/llm-inference/observability/ • /solutions/cost-planner/