Решения

Text Generation Inference (TGI): пулы моделей и шедулинг

Задача страницы. Показать, как развернуть TGI для прод‑инференса LLM, настроить шедулинг/батчинг, организовать пулы моделей, управлять ограничениями длины и стоимостью, а также мониторить качество сервиса.

TL;DR

TGI — универсальный REST‑сервинг LLM с динамическим батчингом и стримингом токенов.
Для строгости SLA настраивайте: лимиты контекста, макс. токены, очереди коротких/длинных запросов.
Пулы моделей (несколько TGI‑инстансов) позволяют разделять трафик по задачам, доменам и длинам; добавляйте горячие/тёплые модели и автомасштабирование.
Снижайте стоимость через квантизацию, батчинг, prefix‑кэш в стеке и грамотный KV‑кэш.

Когда выбирать TGI

Нужен стабильный REST‑API и готовые фичи операционного уровня: очереди, токен‑стриминг, профили производительности.
Один формат запуска для разных моделей (HF‑совместимые веса, шардирование, FP16/BF16/INT8/INT4).
Мульти‑модельная среда: несколько сервисов под разными моделями + внешний роутер/гейтвей.

Альтернативы и сравнение:
— максимум TPS/минимальная цена за 1М токенов: /solutions/llm-inference/vllm/
— минимальная p95‑латентность на H100: /solutions/llm-inference/tensorrt-llm/
— лёгкий стек/тонкие инстансы: /solutions/llm-inference/llama-cpp/

Архитектура: из чего состоит развёртывание

Инициализация модели (веса + токенайзер).
TGI‑процессы: планировщик/очередь, воркеры шардов, стриминг эндпоинтов.
Гейтвей (NGINX/ingress/маршрутизатор) — разруливает пулы моделей и приоритеты.
Мониторинг/логи — метрики latency/TPS, кэш, ошибки.

Быстрый старт (один узел)

Запуск сервера (одна модель, 1‑N шардов)

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

Пояснения по ключам

—num-shard — шардирование весов по нескольким GPU узла.
—max-input-length — предел суммы токенов во входе (prefill).
—max-total-tokens — предел на вход+выход, защищает от «длинных» генераций.
—port — HTTP‑порт сервера.

Запрос без стрима

				
					curl -s http://localhost:8080/generate \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "inputs": "Объясни внимание в трансформерах простыми словами.",
    "parameters": {"max_new_tokens": 200, "temperature": 0.2, "top_p": 0.9}
  }'

Стриминг токенов (SSE)

				
					curl -N http://localhost:8080/generate_stream \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": "Сделай краткое резюме принципа внимания.",
    "parameters": {"max_new_tokens": 150, "temperature": 0.3}
  }'

Динамический батчинг и шедулинг

Как работает. Планировщик TGI формирует батчи запросов с учётом доступных GPU, ограничений длины и активных генераций. Это повышает утилизацию и снижает стоимость.

Практические настройки

Ограничивайте длины (—max-input-length, —max-total-tokens) — это главный рычаг p95.
Профили по длинам: разделите трафик на короткие и длинные очереди (см. пулы ниже).
Параметры генерации держите умеренными по умолчанию: max_new_tokens, temperature, top_p, repetition_penalty.
Стриминг включайте для пользовательских UI — он «ломает тишину» и сглаживает p99.

Пулы моделей: шаблон эксплуатации

Идея. Несколько TGI‑сервисов → единый гейтвей маршрутизирует запросы по модели, длине, приоритету или тенанту.

Организация пулов

По длине:
– Short‑pool (строгий SLA): max_total_tokens небольшое, агрессивный батчинг.
– Long‑pool (анализ/код): большие лимиты, отдельные GPU.
По доменам: «общая модель», «RU‑дообученная», «кодовая».
По средам: prod (только стабильные веса) и staging (экспериментальные).

				
					if model=="llama3-8b-ru" and estimated_total_tokens<=4096 -> short-pool
elif model=="llama3-8b-ru" -> long-pool
elif model=="code-7b" -> code-pool
else -> default-pool

Горячие/тёплые модели

Hot — загружены в VRAM постоянно (нулевая холодная задержка).
Warm — на диске/NVMe, поднимаются по сигналу спроса.
Cold — только в реестре, требуют времени на загрузку.

Шардирование и многогпу

—num-shard N делит веса между N GPU на одном узле (TP внутри узла).
Для нескольких узлов используйте слой оркестрации (несколько инстансов TGI за балансировщиком).
Планируйте KV‑кэш (ниже) — он быстро «съедает» HBM при больших очередях.

Память и KV‑кэш

Прикидка памяти на KV‑кэш (упрощённо):

KV_bytes ≈ 2 × L_layers × (L_in + L_out_avg) × H_heads × d_head × bytes_per_elem

Как держать под контролем

Лимиты длины (вход/выход) и строгая политика max_total_tokens.
Изоляция длинных запросов в отдельный пул.
Квантизация и более лёгкий dtype для KV (если поддерживается сборкой).
Prefix‑кэш на уровне стека (общие системные подсказки).

Квантизация и адаптеры

INT8/INT4 и пост‑тренировочная квантизация снижают стоимость за 1М токенов и повышают плотность батча.
LoRA‑адаптеры: удобно держать несколько отраслевых адаптеров над одной базовой моделью; переключение — без полного рестарта пула.

Подробнее про экономию: /solutions/llm-inference/quantization/, /solutions/llm-inference/costs/.

SLA, производительность и стоимость

Обозначим: L_in — входные токены, L_out — выход, P — prefill ток/с, D — decode ток/с (на батч), B — фактический батч.

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

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

QPS:

QPS ≈ B / T

Цена за 1M токенов:

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

Tokens_per_hour ≈ TPS_decode × 3600
Рекомендация: измерьте P и D на пилоте, затем подберите лимиты контекста и размеры пулов до выполнения SLA.

Наблюдаемость и алерты

Минимальный набор:

Latency p50/p95/p99, timeouts, ошибки по кодам.
Throughput: токены/с на prefill/decode, QPS, «занятость» GPU.
Память: использование HBM, доля KV‑кэша, эвикции.
Система: CPU (токенизация), сеть (стриминг), диск (логи/кэш).

См. /solutions/llm-inference/observability/ и /solutions/monitoring-logging/.

Типовые профили конфигураций

A) Short‑pool (строгий SLA)

-max-input-length 2048, —max-total-tokens 4096
Стриминг включён, небольшой num-shard, 2–4 реплики.
Приоритетная очередь, агрессивный батчинг.

B) Balanced‑pool

—max-input-length 4096, —max-total-tokens 8192
Квантизация INT8/INT4 для лучшей цены за 1М, 1–2 реплики.

C) Long‑pool

—max-input-length 8192+, —max-total-tokens 12000+
Отдельные GPU/узлы, более мягкие SLO, меньшая конкуренция.

Траблшутинг

Высокая p95. Ужесточите max_total_tokens, разделите трафик на short/long, увеличьте число реплик short‑pool.
GPU‑OOM. Снизьте лимиты длины, уменьшите одновременность, примените INT8/INT4, увеличьте num-shard.
Низкий TPS. Увеличьте размер батча/одновременность, проверьте CPU‑узкие места (токенизация), укоротите префиксы.
Длинные «холодные» старты. Держите ключевые модели горячими, используйте локальный NVMe‑кэш весов.
Скачки латентности. Проверьте contention по сети/диску, выведите long‑запросы в отдельный пул.

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

Шаблон “TGI‑Serve” в /solutions/templates/:
– профили short/balanced/long;
– подготовленные скрипты запуска/healthcheck и логгирование;
– примеры маршрутизации по длине/модели/тенанту.
Планирование затрат и режимов инстансов: /solutions/cost-planner/, /solutions/llm-inference/costs/.
Совместимые инструменты: /solutions/llm-inference/multi-model/, /solutions/llm-inference/streaming/.

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

Зафиксирован SLA (p95, QPS/TPS) и лимиты max_total_tokens.
Спроектированы пулы (short/balanced/long), настроен гейтвей.
Проверены пилотные метрики P/D, рассчитана цена за 1М токенов.
Включены стриминг и алерты; есть дашборды latency/TPS/KV.
Продуман фоллбек: запасная модель/ограничение длины при перегрузе.