Решения

SGLang/LightLLM: лёгкий высокоскоростной сервинг

Задача страницы. Показать, как развернуть SGLang и/или LightLLM на облачных GPU, настроить высокоскоростной батчинг и стриминг, спланировать SLA/стоимость и избежать узких мест (KV‑кэш, длины контекста, токенизация).

TL;DR

  • Оба стека ориентированы на максимальный TPS на A/H‑сериях при умеренной латентности: лёгкий рантайм, агрессивный continuous batching.
  • Поддерживаются стриминг токенов и OpenAI‑совместимые эндпоинты (удобно интегрировать в существующий код).
  • Секрет скорости — стабильные длины, умеренный контекст, грамотный KV‑кэш и жёсткие лимиты в API.
  • Нужен минимум DevOps‑обвязки: поднимаются как обычные процессы/контейнеры, хорошо комбинируются с пулом коротких и длинных запросов.

Когда выбирать SGLang/LightLLM (и когда нет)

Выбирайте их, если:

  • приоритет — низкая цена за 1М токенов при хорошем TPS (чат‑боты, ассистенты, массовые генерации);
  • требуется OpenAI‑совместимый API и простая интеграция;
  • вы контролируете длины (max_tokens, max context) и придерживаетесь «коротких/средних» сценариев.

Подумайте об альтернативе, если:

Быстрый старт: SGLang

Запуск сервера (пример, один узел) 

				
					python -m sglang.launch_server \
  --model ./ckpt \
  --port 30000 \
  --tp 1 \
  --context-length 8192 \
  --dtype bfloat16 \
  --trust-remote-code

Ключевые параметры:

  • —tp — tensor parallel внутри узла (делит веса по GPU);
  • —context-length — суммарный лимит (вход+выход);
  • —dtype — bf16/fp16 для Ampere/Hopper.

OpenAI‑совместимый запрос (стриминг SSE) 

				
					curl -N http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3-8b",
    "messages": [{"role":"user","content":"В чём идея continuous batching?"}],
    "stream": true,
    "max_tokens": 256,
    "temperature": 0.2
  }'

Быстрый старт: LightLLM

Запуск сервера (пример, один узел) 

				
					python -m lightllm.launch_server \
  --model ./ckpt \
  --port 8000 \
  --tp 1 \
  --max-seq-len 8192

Запрос (OpenAI‑совместимый) 

				
					curl -s http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3-8b",
    "prompt": "Объясни, зачем ограничивать max_tokens при прод-инференсе.",
    "max_tokens": 200,
    "temperature": 0.3
  }'

Примечание: точные флаги и именования эндпоинтов могут отличаться по версиям. Держите их в шаблонах запуска (см. ниже) и фиксируйте версии образов.

Производительность: на чём держится «высокий TPS»

  • Continuous batching. Планировщик в каждый момент пересобирает батч из активных сессий, поддерживая высокую утилизацию GPU.
  • Бережный prefill. Длинные промпты резко увеличивают время до первого токена; сокращайте преамбулы и унифицируйте системные сообщения.
  • Распределение по длинам. Делите трафик на short/long пулы и задавайте разные лимиты.
  • Токенизация на CPU. Убедитесь, что CPU не стал узким местом: отдельные воркеры токенизации и разумная параллельность.

Память и KV‑кэш: быстрая прикидка

Приблизительно:

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

Что помогает:

  • ограничение context-length/max_tokens;
  • отдельный пул для длинных запросов (меньше конкуренция за кэш);
  • квантизация и «лёгкий» dtype (см. раздел ниже);
  • контроль одновременности: не допускайте лавинообразного роста активных сессий.

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

  • INT8/INT4 существенно снижают цену за 1М токенов и требования к VRAM.
  • Храните базовую модель и несколько адаптеров (LoRA) для разных доменов — быстро переключать стиль/язык без перезапуска сервиса.

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

Профили конфигураций (ориентиры)

A) «Минимальная цена за 1М токенов»

  • INT8/INT4, context-length ≤ 8K, жёсткий max_tokens (200–400), высокий пул одновременности.
  • Разделение на short/long; short обслуживается приоритетно.

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

  • bf16/fp16, context-length 8–16K, умеренные лимиты max_tokens, стриминг включён.
  • 1–2 реплики на узел; при росте нагрузки — добавляйте ещё.

C) «Ближе к низкой p95»

  • Жёсткие лимиты длины, отдельный короткий пул с высокой приоритизацией, меньше одновременности.
  • Длинные запросы уводятся в отдельный пул/инстанс.

SLA и стоимость: быстрые формулы

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

Латентность запроса:

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

QPS и цена за 1М:

QPS ≈ B / T

Tokens_per_hour ≈ D × 3600

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

Используйте пилотные замеры P/D, затем подбирайте лимиты, размеры пулов и число GPU под SLA. См. /solutions/llm-inference/costs/ и /solutions/cost-planner/.

Мониторинг и логи

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

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

Сопутствующие разделы: /solutions/llm-inference/observability/, /solutions/monitoring-logging/.

Траблшутинг

  • Высокая p95. Сократите max_tokens, уменьшите context-length, разнесите короткие/длинные запросы по пулам, увеличьте реплики short‑pool.
  • GPU‑OOM. Уменьшите лимиты контекста, ограничьте одновременность, примените INT8/INT4, увеличьте tp или число GPU.
  • Низкий TPS. Проверьте CPU‑узкие места (токенизация), увеличьте одновременность, унифицируйте промпты (меньше разброса длин).
  • «Холодные» старты. Держите часто используемые модели горячими (в VRAM/NVMe), прогревайте сервер при деплое.
  • Неровная латентность. Избавьтесь от экстремально длинных запросов в общем пуле; включите стриминг и бэкап‑тайм‑ауты.

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

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

  • Зафиксированы SLA (p95, QPS/TPS) и лимиты context-length/max_tokens.
  • Выбран профиль (стоимость/баланс/низкая p95), протестированы P/D на пилоте.
  • Настроены пулы short/long, приоритеты и число реплик.
  • Включены метрики/трейсы/логи; алерты на latency/KV/ошибки.
  • Подготовлен план деградации (фоллбек‑модель, снижение лимитов, разделение трафика).

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