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/Архитектура: из чего состоит развёртывание

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

Быстрый старт (один узел) ### Запуск сервера (одна модель, 1‑N шардов)

Пояснения по ключам- --num-shard — шардирование весов по нескольким GPU узла.

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

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

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

Динамический батчинг и шедулинг Как работает. Планировщик 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 (экспериментальные).

Горячие/тёплые модели- 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 и логгирование; – примеры маршрутизации по длине/модели/тенанту.

Чек‑лист перед продом- Зафиксирован SLA (p95, QPS/TPS) и лимиты max_total_tokens.

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

Готовы запустить?

Запустить GPU-сервер