Решения

TensorRT‑LLM: компиляция и FP8‑оптимизация

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

TL;DR

Компиляция графа в TensorRT‑движок (per‑модель, per‑конфиг) даёт минимальную латентность и предсказуемость.
FP8 (Hopper) и BF16/FP16 (Ampere/Hopper) — ключ к высокой утилизации Tensor Cores при приемлемом качестве.
Тонкая настройка профилей (max seq len, max batch, beam width), KV‑кэш и tensor parallel критичны для p95.
Для строгого SLA держите жёсткие лимиты длины и раздельные пулы под короткие/длинные запросы.

Когда выбирать TensorRT‑LLM

Жёсткие требования по p95/p99‑латентности (онлайн‑чат, ассистенты в продуктах, интерактивный UX).
Статичная или предсказуемая матрица сценариев (модель(и) + фиксированный контекст), где компиляция окупается.
Наличие H100/A100/L40S и желание выжать максимум из Tensor Cores.

Альтернативы: для максимально высокой цены/производительности по токенам смотрите /solutions/llm-inference/vllm/; для универсального REST‑сервинга — /solutions/llm-inference/tgi/.

Архитектура запуска (в общих чертах)

Чекпоинт модели (HF‑совместимый) →
Сборка движка (builder): выбор точности, профилей (длины, батчи), плагинов;
Сервер TensorRT‑LLM: HTTP/gRPC‑эндпоинты, управление KV‑кэшем, телеметрия;

Шлюз/балансировщик (по желанию): роутинг трафика, аутентификация, rate‑limits.

Быстрый старт: сборка и сервер

Сборка движка (пример)

				
					# 1) Подготовьте чекпоинт (весы и токенайзер) в ./ckpt
# 2) Соберите движок под вашу целевую длину контекста и точность
trtllm-build \
  --checkpoint-dir ./ckpt \
  --output-dir ./engines/llama3-8b-fp8 \
  --max-seq-len 8192 \
  --dtype bfloat16 \
  --fp8 \
  --gemm-plugin auto

Пояснения:

—max-seq-len — проектная длина контекста (вход+выход), от неё зависят память и ядра.
—dtype — базовая точность весов/активаций; bf16/fp16 на Ampere/Hopper.
—fp8 — включает режимы FP8 на H100 (веса/активации в FP8, аккумулирование в bf16/fp16).
—gemm-plugin auto — выбор высокопроизводительных GEMM‑плагинов под вашу платформу.

Запуск сервера

				
					trtllm-server \
  --engine-dir ./engines/llama3-8b-fp8 \
  --http-port 8000 \
  --grpc-port 50051 \
  --world-size 1

Если токенайзер хранится отдельно, передайте путь в параметрах сервера. Для нескольких GPU увеличьте —world-size и настройте tensor parallel (см. ниже).

Профили и формы запросов: как снимать «хвосты» p95

Профиль сборки задаёт рамки, в которых движок работает без деградаций: максимальные длины (max seq len), максимальный батч и опции декодирования (beam width и т.п.). Рекомендации:

Делайте раздельные движки на короткий и длинный контекст (например, 4K и 8–16K).
Если сценарии различаются по длинам — заведите два пула серверов и маршрутизируйте запросы по «коротким» и «длинным».
Фиксируйте жёсткие лимиты на max_tokens в API, чтобы не «блокировать» GPU длинными генерациями.
Для оффлайн‑пакетной генерации собирайте отдельный профиль с большим батчем.

FP8 и точность вычислений

H100 (Hopper): FP8 даёт максимум пропускной способности; аккумулирование обычно идёт в BF16/FP16. В интерфейсе сборки (см. выше) включайте —fp8.
Ampere (A100/L40S): используйте BF16/FP16.
Практика: после переключения формата обязательно сравните качество (перплексия/валид‑набор). Если видите деградацию — оставьте чувствительные узлы (например, выходные проекции) в BF16/FP16 при FP8‑основе.

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

KV‑кэш растёт линейно с длиной контекста и числом одновременных сессий.
Прикидка (упрощённо):

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

Как уменьшить:

Снизить max seq len, ограничить max_tokens на запрос.
Использовать более лёгкий dtype для KV (если доступен в вашей сборке).
Развести «длинные» и «короткие» запросы по разным пулам.
Держать общий системный префикс коротким и однотипным (prefill дешевле).

Tensor parallel и многогпу

Tensor parallel (TP) — делит веса слоя по нескольким GPU одного узла; уменьшает пиковую память на GPU и ускоряет крупные матрицы.
Рекомендации: размещайте TP внутри узла (NVLink), не смешивайте очень большие max seq len с высоким TP в одном движке без измерений.
Шеринг кэша: следите, чтобы KV‑память не стала новым узким местом при росте одновременности.

Настройка под цель: три профиля

A) Минимальная латентность (строгий SLA)

Раздельные движки 4K/8K.
Низкие лимиты max_tokens в API.
BF16/FP8 (на H100), небольшой TP (1–2), несколько реплик.
Стриминг токенов включён, короткие ответы — отдельный pool приоритета.

B) Сбалансированный

Один движок 8K, BF16/FP16.
Ограничение max_tokens, средний TP, 1–2 реплики.
Параллельные очереди: «короткие» получают приоритет.

C) Максимальный throughput (офлайн/батч)

Отдельный движок с увеличенным max batch, BF16/FP16.
Нет стриминга, бачинговый планировщик.
Отдельный пул GPU, чтобы не влиять на онлайн‑SLA.

Стоимость и расчёты

Обозначим: TPS_decode — токены/с на декоде (на весь батч), B — фактический батч на декоде, T — латентность запроса.

QPS (приближённо): QPS ≈ B / T
Tokens/hour: TPS_decode × 3600
Цена за 1M токенов:

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

Для планирования снимите реальные prefill_rate и TPS_decode на вашей модели и целях длины, затем отмасштабируйте под пул и p95‑запас.

См. также: /solutions/llm-inference/costs/, /solutions/cost-planner/.

Наблюдаемость и эксплуатация

Минимум метрик:

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

Подробнее: /solutions/llm-inference/observability/, /solutions/monitoring-logging/.

Траблшутинг

Высокая p95 после сборки. Проверьте соответствие реальных запросов профилю (seq len, batch), уменьшите max_tokens, вынесите длинные запросы в отдельный пул/движок.
GPU‑OOM. Снизьте max seq len, уменьшите gpu memory utilization сервера, используйте TP, пересоберите движок под более короткие формы или лёгкий dtype KV.
Нестабильная скорость decode. Ограничьте смешение сильно разных длин в одном батче; проверьте CPU‑узкие места (токенизация/JSON).
Деградация качества на FP8. Оставьте чувствительные узлы в BF16/FP16; проверьте валидацию (перплексия/оценки) перед переключением трафика.
Долгая «холодная» загрузка. Храните движки на локальном NVMe, используйте прогрев (warm‑up) при деплое.

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

Шаблон “TensorRT‑LLM Serve” в /solutions/templates/:
– скрипт сборки trtllm-build с профилями low‑latency / balanced / batch;
– trtllm-server с healthcheck и логами;
– примеры маршрутизации «коротких/длинных» запросов.
Для экономии — смотрите /solutions/llm-inference/quantization/ и /solutions/cost-planner/.
Для многоузловых сценариев — /solutions/multi-gpu/ и /solutions/llm-inference/multi-model/.

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

Зафиксированы SLA (p95, TPS/QPS) и лимиты max_tokens.
Собраны движки под целевые длины (4K/8K/…); проверены на синтетике и тест‑трафике.
Выбрана точность: BF16/FP16 (Ampere/Hopper) или FP8 (H100) с проверкой качества.
Настроены пулы (короткие/длинные), TP и количество реплик.
Включены метрики/трейсы, алерты на латентность/ошибки/память.
Описан фоллбек‑план (второй движок/модель, ограничения длины, деградация параметров).

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

Обзор: /solutions/llm-inference/

Альтернативы: /solutions/llm-inference/vllm/, /solutions/llm-inference/tgi/, /solutions/llm-inference/llama-cpp/

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

Эксплуатация: /solutions/llm-inference/streaming/, /solutions/llm-inference/observability/