Многопоточный inference GPU

Когда модель обслуживает не одного пользователя, а поток запросов (API, чат-бот, батч-обработка датасета), метрика смещается: важна не latency одного запроса, а throughput — токенов/секунду или запросов/минуту. Под это нужны другие карты и другой софт. Правило простое: throughput ≈ batch size × tokens/second на один запрос, и главные рычаги — большой HBM на карте и батчинг-движок.

Batch size и VRAM

При batch-инференсе GPU обрабатывает несколько запросов одновременно, переиспользуя веса модели. Память растёт так:

• Веса модели — фиксированы (например, 13 ГБ для 7B в FP16).
• KV-cache — растёт с числом одновременных запросов и длиной контекста. Это главный потребитель памяти. Для 7B при batch=32 и контексте 4k — ещё 20–40 ГБ поверх весов.
• Активации — растут линейно с batch, обычно меньше KV-cache.

Инструменты для throughput

Простой transformers.generate() не батчит эффективно и не переиспользует память. Для production-инференса используют специализированные движки:

• vLLM — PagedAttention, непрерывный (continuous) batching, до 10× к vanilla-циклу. Стандарт для LLM-сервинга, OpenAI-совместимый API.
• TGI (Text Generation Inference, от HuggingFace) — продакшн-сервер с динамическим batching, стримингом, очередью.
• TensorRT-LLM — максимально быстрая инференс-оптимизация под конкретную модель, требует сборки движка под фиксированную конфигурацию. Долгая настройка, максимальная скорость.
• llama.cpp с континуальным батчингом (--cont-batching) — для квантованных моделей (GGUF Q4/Q5/Q8), дешевле по VRAM, ниже overhead, хорошо на consumer-картах.

Эти движки поднимают throughput на той же карте в 3–10 раз — это почти всегда дешевле, чем покупать больше GPU. Сначала тюньте движок, потом масштабируйте железо.

Consumer vs дата-центровые карты

Когда нужен multi-GPU

Одной карты хватает, пока модель + KV-cache под целевой batch влезают в VRAM. Дальше — multi-GPU:

• Tensor parallelism (vLLM, TGI, TensorRT-LLM) — модель режется по слоям/attention-головам на 2–8 GPU, нужен NVLink или NVSwitch с малой задержкой. Линейное ускорение на 2–4 GPU, на 8 уже с overhead.
• Pipeline parallelism — для очень больших моделей (70B+), выше latency, реже для inference.
• 8× H100 80GB в HGX/DGX — стандарт для обслуживания 70B-моделей в проде. Это кластерные конфигурации, цена и наличие — sales-led (через менеджера Selectel/HOSTKEY), не в общем пуле по часам.

Для 7B и 13B моделей multi-GPU почти никогда не нужен — одна A100 80GB закрывает типичный продакшн с batch 32. Для 70B в FP16 tensor parallelism 8-way обязателен, либо квантование в 4-бит + 2–4 GPU.

Метрики: что мерить

В многопоточном инференсе есть три разные метрики, их нельзя путать:

Часто throughput и latency в конфликте: большой batch повышает throughput, но удлиняет TTFT для каждого запроса в очереди. Подбирайте batch под SLA вашего продукта.

Continuous batching: как работает

Классический статический batching ждёт, пока наберётся N запросов, потом гоняет их вместе — запросы в очереди простаивают. Continuous batching (он же iteration-level / dynamic batching) делает пересборку батча на каждом шаге декодера:

• Когда один запрос закончился, его слот тут же занимает новый запрос из очереди.
• Никто не ждёт завершения самого длинного запроса в батче.
• KV-cache переиспользуется между шагами без перерасчёта.

vLLM и TGI реализуют именно continuous batching. Это даёт основной прирост throughput (3–10×) относительно naive-подхода. Без него любая карта работает в 5–10 раз ниже потенциала.

PagedAttention и KV-cache

KV-cache — главный пожиратель памяти, и без управления он фрагментируется: под каждый запрос резервируется блок «с запасом», часть простаивает. PagedAttention (изобретение vLLM) решает это:

• KV-cache разбивается на фиксированные блоки (как страницы памяти в ОС).
• Блоки выдаются по мере роста последовательности, без резервирования.
• Неактивные последовательности (waiting) можно выгружать на CPU и возвращать.

Эффект: на ту же VRAM помещается в 2–4 раза больше одновременных запросов. Это эквивалентно бесплатному апгрейду карты — обязательно включайте в продакшене.

Оптимизация: сначала софт, потом железо

Дешевле сократить KV-cache и батчить эффективнее, чем купить H100:

1. Используйте vLLM с PagedAttention — сократит фрагментацию KV-cache в 2–4 раза.
2. Включите GQA-вариант модели (Llama 3, Qwen2) — меньше attention-голов, меньше cache.
3. Квантуйте веса в AWQ/GPTQ (4-бит) или FP8 — модель займёт в 2–4 раза меньше VRAM.
4. Квантуйте KV-cache в FP8/INT8 — дополнительное сокращение в 2 раза.
5. Только после этого — больше GPU или multi-GPU.

Практические шаги

1. Оцените нагрузку: запросов/сек, средний контекст, нужна ли низкая latency.
2. Считайте требуемый VRAM: веса + KV-cache под целевой batch.
3. Для batch=1 и dev — RTX 4090 от 83 ₽/час.
4. Для throughput и production — A100 80GB или H100 80GB.
5. Для 70B в проде — конфигурации 8× H100, ищите через sales Selectel или HOSTKEY.
6. Сначала тюньте движок (vLLM/TGI) — это дешевле, чем больше GPU.
7. Подпишитесь на алерт в Telegram — сообщим о появлении A100/H100 по нижней цене.

Смежные гайды

• Аренда A100 — основная карта для throughput
• Аренда H100 — новейшая, быстрее A100
• GPU для LLM-инференса — детально по LLM-сервисингу
• GPU для обучения моделей — если нужна не подача, а дообучение