Онлайн‑инференс без узких мест: как выбрать Supermicro GPU‑сервер для низкой задержки и высокой QPS
Для российских компаний, внедряющих LLM‑сервисы, онлайн‑инференс становится критическим компонентом: пользователю не важно, как долго обучалась модель, но любая задержка ответа более 200–300 мс напрямую бьет по конверсии и удовлетворенности.
В отличие от обучения, где важен суммарный объём вычислений за недели или месяцы, онлайн‑инференс требует задержки < 50 мс и устойчивой обработки 1000+ запросов в секунду, при этом ключевым KPI становится загрузка каждой отдельной GPU и скорость загрузки моделей в память.
Ультраплотные 1U/2U GPU‑серверы Supermicro, собранные локально в России на платформе Alt Linux + Proxmox, позволяют в условиях санкций собрать кластер за < 3 недель, получить TCO на 25 % ниже типичных OEM‑решений и обеспечить поддержку полного стека TensorRT + ONNX Runtime.
Типичные вопросы по онлайн‑инференсу LLM
- Хватит ли одной GPU A40 для онлайн‑инференса Llama‑7B/70B или сразу строить кластер с балансировкой нагрузки между несколькими GPU?
- Что эффективнее по QPS/Вт и QPS/рубль: H100 или более массовые A40/A6000, если речь идет о боевом сервисе с жесткими SLA?
- Как добиться времени холодной загрузки модели < 10 секунд и какие требования к NVMe‑кэшу и пропускной способности дискового массива?
- Как выдержать 1000+ QPS без сетевых узких мест: достаточно ли 25GbE, или для стабильного p99 нужен 100GbE и RDMA?
- Каковы реальные сроки поставки A40 в условиях санкций, и можно ли использовать RTX 4090 как замену в продакшене?
- Как организовать изоляцию арендаторов: через аппаратный vGPU/MIG или достаточно Docker + Kubernetes на уровне контейнеров и пространств имён?
- Какие целевые метрики мониторинга считать «зелеными»: загрузка GPU, p99 задержки, ошибки декодирования, saturation сети?
- Что дает 1U/2U‑форм‑фактор по сравнению с 4U‑«тренировочными» серверами, если нужен максимум QPS на стойку?
Ключевые метрики: не только FLOPS, но и QPS
В задачах онлайн‑инференса основными целевыми метриками становятся p50/p95/p99 задержки, стабильный QPS и загрузка GPU > 90 % при сохранении резерва по памяти и сетевым ресурсам для пикового трафика.
Вычислительная мощность в TFLOPS важна, но без оптимизированного стека TensorRT/ONNX, NVMe‑кэша и корректно спроектированной сети даже флагманский H100 не даст ожидаемой отдачи по QPS и приведет к завышенному 3‑летнему TCO.
Три уровня задач онлайн‑инференса
Для практической архитектуры удобно делить онлайн‑инференс LLM на три класса задач: легкие модели до 13B, средний диапазон 13–70B и крупные модели > 70B, которые требуют конвейерного распараллеливания по нескольким GPU.
| Класс нагрузки | Масштаб модели | Цель по QPS | Цель по задержке | Типовая топология |
|---|---|---|---|---|
| Легкий инференс | < 13B | До 100 QPS на сервис | p95 < 50 мс | 1U, 1–2 GPU A40, локальный NVMe‑кэш |
| Средний инференс | 13–70B | До 500 QPS на кластер | p95 < 70 мс | 2U, 2–4 GPU A40/A6000, 25–100GbE |
| Крупные модели | > 70B | 1000+ QPS (кластер) | p95 < 100 мс | 4U, 8 GPU, pipeline/tensor parallel |
Линейка Supermicro для онлайн‑инференса
Для онлайн‑инференса LLM удобно использовать трехуровневую линейку Supermicro: 1U для легких моделей и edge‑сценариев, 2U для средних нагрузок и 4U для крупных моделей с конвейерным распараллеливанием и высоким QPS.
| Сценарий | Рекомендуемый сервер | Графика | CPU / ОЗУ | Сеть / хранилище | Мощность / бюджет |
|---|---|---|---|---|---|
| < 13B, до 100 QPS | SYS‑1029GQ‑TRT (1U) | 2–4× NVIDIA A40 48 GB | Intel Xeon, до 512 GB DDR4/DDR5 | 2× 25GbE, до 8× NVMe | До 1600 W, ориентир 400–600 тыс. руб. |
| 13–70B, до 500 QPS | SYS‑2029GP‑TRT (2U) | 4× NVIDIA A6000 48 GB или A40 | 2× AMD EPYC, до 1 TB ОЗУ | 2× 100GbE, до 16× NVMe | До 2000 W, ориентир 700–900 тыс. руб. |
| > 70B, 1000+ QPS | SYS‑4029GP‑TRT (4U) | 8× NVIDIA H100 PCIe (или гибрид) | 2× Xeon, до 2 TB ОЗУ | 4× 100GbE, до 24× NVMe | До 3000 W (жидкостное охлаждение), ориентир 1,2–1,6 млн руб. |
Формула подбора: GPU из QPS и задержки
В отличие от обучения, где число GPU определяется параметрами модели и batch‑размером, в онлайн‑инференсе отправной точкой являются целевые QPS и средняя длина ответа в токенах, а также реальная пропускная способность одной GPU по токенам в секунду.
Приближенная формула выглядит так: GPU = ⌈(QPS × avg_tokens/s) ÷ throughput_GPU⌉ × 1,3, где коэффициент 1,3 закладывает резерв на пики нагрузки, деградацию производительности и непредвиденный рост трафика.
Пример: 500 QPS для Llama‑70B
Для сервиса с целевыми 500 QPS и средней скоростью генерации 50 токенов в секунду на запрос при пропускной способности одной A40 порядка 200 токенов/с расчет дает около 13 GPU, что удобно реализуется как кластер из четырех узлов по 4 GPU с небольшим запасом.
Такая конфигурация позволяет выдерживать рост нагрузки, проводить A/B‑эксперименты с новыми версиями модели и выполнять плановые обновления без падения QPS ниже SLA.
Оптимизация задержки: TensorRT и ONNX Runtime
Использование TensorRT для оптимизации графа и INT8‑квантования позволяет получить ускорение до 3–5 раз по сравнению с «чистым» PyTorch‑инференсом, приводя задержку Llama‑7B на A40 к значениям < 20 мс при грамотной настройке batch и стека.
ONNX Runtime обеспечивает унифицированный слой между фреймворками и GPU‑поколениями: один и тот же граф можно переносить с A40 на H100 без полной переработки сервиса, что критично в условиях санкций и необходимости гибко менять железо.
Память и NVMe‑кэш: борьба за миллисекунды
Для онлайн‑инференса важно, чтобы не только сама модель, но и её KV‑кеш умещались в ОЗУ и GPU‑памяти без постоянных выгрузок, иначе хвостовая задержка резко растет из‑за лишних операций ввода‑вывода и аллокаций.
Оценку можно выразить формулой: RAM_инференса = FP16‑модель (параметры × 2 байта) + KV‑кеш (batch × seq_len × число слоёв × 80 байт), из которой для Llama‑70B при batch=128 и seq_len=2048 получается необходимость порядка 1,2 TB DDR5.
NVMe‑кэш и скорость загрузки модели
| Целевой QPS | Схема NVMe | Ёмкость кэша | Время загрузки модели | Рекомендованный класс SSD |
|---|---|---|---|---|
| До 100 QPS | 4× NVMe Gen4, RAID0 | 8 TB | < 5 с | Enterprise‑класс (например, PM1743) |
| До 500 QPS | 8× NVMe Gen5, RAID0 | 16 TB | < 3 с | Высокопроизводительные модели (например, 7500 MAX) |
| 1000+ QPS | NVMe‑oF‑пул | 50 TB и более | < 1 с | NVMe‑накопители дата‑центрового класса |
Сетевая архитектура для QPS 1000+
Для QPS до 500 на кластер часто достаточно 25GbE c RoCEv2 и нулевой копией при правильно настроенных очередях и буферах, однако при 500+ QPS узким местом становится не только пропускная способность, но и джиттер.
Для высоконагруженных кластеров онлайн‑инференса рекомендуется использовать 100GbE с современными адаптерами и ToR‑коммутаторами, короткие DAC‑кабели до 2 метров и включенную поддержку механизмов борьбы с перегрузкой для удержания p99 < 100 мс.
Kubernetes‑кластер: автоскейлинг под трафик
Типичная схема для кластеров онлайн‑инференса строится вокруг Kubernetes: фронтенд‑балансировщик (Nginx Ingress) принимает HTTP/gRPC‑трафик, маршрутизируя его на узлы с NVIDIA Triton Inference Server или собственными сервисами на FastAPI/gRPC.
Автомасштабирование через HPA позволяет увеличивать число Pod‑ов по мере приближения среднего QPS к 80 % от целевого значения, а связка Prometheus + Grafana обеспечивает мониторинг GPU‑загрузки и p99‑задержки с настройкой оповещений.
Многотенантность и безопасность
Для многотенантных сценариев в одном кластере можно сочетать аппаратную сегментацию GPU (MIG/vGPU) и логическую сегментацию через Kubernetes Namespaces и отдельные наборы Deployment/Service для каждого арендатора.
Дополнительный уровень безопасности дает сервисная mesh‑оболочка (например, Istio), обеспечивающая аутентификацию, шифрование трафика mTLS и лимиты на уровне tenant‑id, что упрощает биллинг и контроль SLA.
Рекомендуемые конфигурации Supermicro для онлайн‑инференса
| Масштаб модели и цель | Рекомендуемый сервер | GPU‑конфигурация | CPU / память | Сеть / хранилище | Мощность / ориентир бюджета |
|---|---|---|---|---|---|
| < 13B, 100 QPS | Supermicro SYS‑1029GQ‑TRT (1U) | 2–4× A40 48 GB | Xeon 6338, до 512 GB ОЗУ | 2× 25GbE, до 8× NVMe | До 1600 W, ~400–600 тыс. руб. |
| 13–70B, 500 QPS | Supermicro SYS‑2029GP‑TRT (2U) | 4× A6000 48 GB или A40 | 2× EPYC 9454, до 1 TB ОЗУ | 2× 100GbE, до 16× NVMe | До 2000 W, ~700–900 тыс. руб. |
| > 70B, 1000+ QPS | Supermicro SYS‑4029GP‑TRT (4U) | 8× H100 PCIe, pipeline parallel | 2× Xeon 8592+, до 2 TB ОЗУ | 4× 100GbE, до 24× NVMe | До 3000 W (жидкостное охлаждение), ~1,2–1,6 млн руб. |
Типичные ошибки и влияние на TCO
- Ошибка 1: использовать «тренировочные» 4U‑серверы с высокими TDP и жидкостным охлаждением для чистого инференса, получая лишние 2–3× по энергопотреблению при одинаковом QPS.
- Ошибка 2: запускать инференс без TensorRT/ONNX‑оптимизации, оставляя PyTorch в режиме разработки и увеличивая задержку в 3–4 раза без выигрыша в качестве.
- Ошибка 3: ограничиваться 25GbE при кластере 1000+ QPS, получая периодические всплески задержки и потери пакетов вместо стабильного p99.
3‑летний TCO кластера 1U‑узлов
| Статья затрат | Стоимость (условно, тыс. руб.) | Доля в 3‑летнем TCO |
|---|---|---|
| Закупка 8× 1U‑узлов | 4000 | 75 % |
| Электроэнергия и охлаждение | 500 | 9 % |
| Поддержка и эксплуатация | 300 | 6 % |
| Итого за 3 года | 4800 | 100 % |
Для оценки окупаемости можно использовать простое правило: ROI = прирост QPS × ARPU / 3‑летний TCO; целевым уровнем для высоконагруженных LLM‑сервисов можно считать ROI > 2 и срок окупаемости < 8 месяцев.
