Токенов в секунду мало? Разгоняем LLM до предела: от железа до батчинга

Почему ваш LLM ползет как улитка (и как заставить его лететь)

Вы загрузили свежую модель, запустили инференс, а токены вылезают со скоростью два слова в минуту. Знакомо? Проблема не в том, что модель "тяжелая". Проблема в том, что вы не знаете, где спрятаны тормоза.

Tokens per second (токен/с) — это не просто цифра в бенчмарке. Это реальная скорость ответа для пользователей, стоимость инфраструктуры и ваше собственное терпение. Разница между 5 и 50 токен/с — это разница между "забросить проект" и "запустить в продакшн".

Сначала диагноз: что именно тормозит?

Прежде чем что-то оптимизировать, нужно понять узкое место. Типичные сценарии:

• Медленный первый токен (TTFT): Модель думает 10 секунд перед ответом. Виновник — загрузка весов, инициализация кэша K/V для длинного контекста.
• Низкая скорость генерации: Токены идут, но медленно. Проблема в вычислительной мощности или памяти.
• Падение скорости с ростом контекста: На 1000 токенах все летает, на 32000 — ползет. Классическая история с attention.

Измеряйте отдельно: время до первого токена (TTFT) и скорость генерации последующих токенов. Инструменты: встроенные метрики vLLM, llama.cpp с флагом --log-disable, или простой скрипт на Python с замером времени.

Железо: фундамент, который нельзя проебать

Можно настроить софт идеально, но на слабом железе вы упретесь в потолок. Вот что важно в 2026 году.

1 Выбор GPU: не только видеопамять

Все гонятся за объемом VRAM, чтобы впихнуть модель побольше. Это ошибка. Пропускная способность памяти (memory bandwidth) часто важнее. Модель в 40 млрд параметров на RTX 4090 (1 ТБ/с) может работать быстрее, чем на карте с 48 ГБ, но 800 ГБ/с.

Совет: если вы не гоняете Llama 3.3 405B, берите две RTX 5090 вместо одной RTX 5090 Ti. Меньше проблем с памятью на модель, выше параллелизм. Подробнее про мульти-GPU конфигурации читайте в статье "Две RTX PRO 6000 и терабайт памяти".

2 Оперативная память и CPU

Для CPU inference или загрузки весов в GPU это критично. DDR5-7200 против DDR5-4800 дает разницу в 15-20% скорости загрузки модели. PCIe 5.0 x16 обязательна для multi-GPU, чтобы не упираться в шину.

CPU с AVX-512 и AMX (Intel) или AVX-512 + SVE (ARM) ускоряют llama.cpp на CPU в разы. Но если вы используете GPU, CPU почти не важен — берете самый дешевый совместимый.

Квантование: искусство жертвовать качеством (но не слишком)

Сжать модель в 2-4 раза, чтобы она влезла в память и ускорилась — магия квантования. Но в 2026 году появились нюансы.

Тренд 2025-2026: не просто снижать битность (FP16 -> INT8), а использовать смешанное квантование. Например, чувствительные слои attention оставлять в FP8, а линейные слои сжимать в INT4. llama.cpp поддерживает это через --quantization-type q4_k_m (смешанное Q4_K).

# Пример запуска с современным квантованием в llama.cpp (версия > 2025.12)
./main -m ./models/llama-3.3-70b-q4_k_m.gguf -p "Ваш промпт" -n 512 -t 12 -c 4096
# Ключевые флаги:
# -t: количество потоков CPU. Для GPU inference почти не важно.
# -c: размер контекста. Увеличивает потребление памяти, может снижать скорость.

Ловушка: после квантования некоторые модели (особенно мелкие, 7B) начинают "галлюцинировать" сильнее. Всегда тестируйте качество на вашем датасете, а не смотрите только на perplexity.

Выбор бэкенда: vLLM, llama.cpp, или что-то экзотическое?

Софт решает не меньше железа. Три главных игрока в 2026.

vLLM: король продакшна

Почти стандарт для сервисов. Его сила — PagedAttention и Continuous Batching. Он умеет эффективно обрабатывать десятки запросов параллельно, переиспользуя память.

# Запуск vLLM с оптимизациями под длинный контекст
python -m vllm.entrypoints.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.3 \
    --tensor-parallel-size 1 \
    --gpu-memory-utilization 0.9 \
    --max-model-len 8192 \
    --enforce-eager  # Избегаем graph capture для сложных моделей

Плюсы: Максимальная throughput при множестве пользователей, отличная поддержка длинного контекста, активное развитие.
Минусы: Сложнее в настройке, требует больше памяти из-за батчинга, может иметь высокий TTFT для первого запроса. Про это подробно писали в разборе "Kimi-K2.5 на vLLM".

Используйте vLLM, если у вас API-сервис с асинхронными запросами от многих клиентов.

llama.cpp: универсальный солдат

Работает везде: CPU, GPU (CUDA, Metal, Vulkan), даже на Raspberry Pi. В 2026 году обзавелся поддержкой speculative decoding (draft-логика) и ngram-кэширования, что дает ускорение в 2-3 раза для некоторых задач.

Как это работает? Маленькая "черновая" модель быстро генерирует несколько предположительных токенов, большая модель их проверяет за один проход. Подробный разбор техник есть в статье про ускорение Devstral Small 2.

# Запуск с draft-моделью для ускорения (экспериментальная фича)
./main -m ./models/llama-3.3-70b-q4_k_m.gguf \
       --draft-model ./models/llama-3.3-7b-q4_0.gguf \
       --draft-n 5  # Черновая модель генерирует 5 токенов для проверки

Плюсы: Невероятная гибкость, низкие требования к памяти, множество квантований.
Минусы: Нет native continuous batching (есть, но слабее), throughput при множестве запросов ниже.

Используйте llama.cpp для демо, экспериментов, или когда нужно запустить модель на нестандартном железе.

Hugging Face Text Generation Inference (TGI): где-то посередине

Более простая альтернатива vLLM от Hugging Face. Хороша, если ваша модель уже в формате Hugging Face и не хочется разбираться с тонкостями vLLM. В 2026 поддерживает TensorRT-LLM бэкенд для максимальной скорости на NVIDIA.

Настройка контекста: самый неочевидный тормоз

Вы поставили контекст в 128k токенов, потому что "так круто". И получили падение скорости в 5 раз. Почему?

1. Память K/V кэша. Каждый токен контекста хранит ключи и значения для attention. Для модели 70B в FP16 это ~2.5 МБ на токен. 128k токенов = 320 ГБ памяти. Даже в квантованном виде это сотни гигабайт. Решение: использовать слайдинг-виндов (sliding window attention), как в Mistral, или кэширование сжатых состояний.

2. Вычислительная сложность attention. Стандартное attention масштабируется как O(n²) по длине контекста. Для 128k это убийственно. Используйте модели с эффективными attention-механизмами (FlashAttention-3, RingAttention) или включайте их поддержку в бэкенде.

# Пример настройки для vLLM с учетом длинного контекста
from vllm import SamplingParams
from vllm import LLM

# Важно: ограничивать max_model_len разумно
llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.3",
          max_model_len=16384,  # Не ставьте 128000, если не нужно!
          enable_prefix_caching=True,  # Кэширование префиксов для повторяющихся промптов
          gpu_memory_utilization=0.85)

Правило: устанавливайте длину контекста равной максимальной, которая реально нужна в вашем приложении, плюс небольшой запас. Не гонитесь за большими цифрами. Если интересно, как правильно тестировать длинные контексты, смотрите гайд "Когда 512k токенов — это не хвастовство, а боль".

Батчинг: искусство кормить модель пачками

Одиночный запрос использует GPU на 5-10%. Continuous batching (непрерывный батчинг) собирает несколько запросов в один вычислительный пакет, увеличивая утилизацию до 70-80%. Это основной способ увеличить общую пропускную способность (total throughput) сервиса.

Как это выглядит в vLLM:

• Приходят запросы A, B, C в разное время.
• vLLM динамически объединяет их в батч для forward pass.
• Когда запрос A завершил генерацию, он выходит из батча, а его место может занять новый запрос D.
• GPU постоянно занят.

Но батчинг увеличивает задержку (latency) для отдельных запросов, потому что они ждут, пока соберется группа. Настройка баланса — это искусство. Подробно механизм разобран в статье "Continuous Batching: ключевой механизм для высокой нагрузки".

Чеклист: от 10 до 100+ токен/с за 30 минут

1. Измерьте базовую скорость. Запустите модель с дефолтными настройками, запишите TTFT и tokens/s.
2. Подберите квантование. Скачайте версию Q4_K_M. Если не влезает в память — Q3_K_M. Перезамерьте скорость и качество.
3. Настройте длину контекста. Установите max_model_len или -c в значение, которое реально нужно. Не 128k, если хватает 8k.
4. Включите аппаратные фичи. Для llama.cpp: --gpu-layers 99 (все слои на GPU). Для vLLM: --enforce-eager если есть ошибки.
5. Экспериментируйте с батчингом. Если нагрузка позволяет, включите continuous batching и подберите --max-num-batched-tokens.
6. Обновите драйверы и софт. CUDA 12.6, llama.cpp сборка от сегодня, vLLM 0.4.8+. Старые версии тормозят.

Ошибки, которые съедают 50% скорости (и как их избежать)

• Охлаждение "для офиса". GPU при полной нагрузке троттлит через 2 минуты, частота падает, скорость тоже. Решение: мониторить температуру (nvidia-smi -q), ставить активное охлаждение.
• SWAP на SSD. Часть модели ушла в своп на SSD, latency взлетает до небес. Всегда проверяйте, что модель полностью в RAM/VRAM.
• Фоновая загрузка весов. При запуске сервиса vLLM "лениво" загружает веса при первом запросе. Первый пользователь ждет 30 секунд. Используйте warmup или предзагрузку.
• Неправильный формат модели. Загрузили .safetensors, а бэкенд ожидает .gguf. Конвертация на лету съедает время и память.

Что дальше? Будущее ускорения в 2026-2027

Тренды, которые уже работают в лабораториях и скоро придут к вам:

• Модели-специалисты для инференса. Отдельные версии моделей (например, Llama-3.3-Inference-70B), обученные/дообученные specifically для быстрого генеративного вывода, с упрощенной архитектурой.
• Аппаратное квантование в реальном времени. GPU сам переводит веса из FP16 в INT8 при загрузке, без потери качества.
• Полностью статичные графы. TensorRT-LLM компилирует модель в единственный CUDA граф, убирая все оверхед диспетчеризации. Скорость растет на 10-20%, но гибкость нулевая.
• Оптимизация под многоузловые кластера. Когда одна модель не помещается даже в 8 GPU, фреймворки учатся эффективно дробить ее между серверами без потерь на коммуникации. Это уже боль, см. "GPU-to-GPU коммуникация в PyTorch".

Итог: увеличение tokens per second — это не один волшебный флаг. Это системная работа: от выбора видеокарты до настройки размера батча. Начните с диагностики, примените чеклист, и ваша модель ускорится в разы. А если нет — пишите в комментарии, разберем конкретный кейс.