Как настроить сервер для обработки 1B+ токенов в день: опыт исследовательской лаборатории с GPT-OSS-120B

Когда 7 токенов в секунду — это провал, а не результат

Помните ту статью, где мы мучили GPT-OSS-120B на процессорах? 7.2 токена в секунду на Xeon — это не шутка, это реальность CPU-инференса в 2025 году. Для исследовательской лаборатории, где нужно обрабатывать терабайты текстовых данных, такие скорости — путь в никуда. Когда ваш эксперимент требует прогнать через модель миллиард токенов за сутки, а не за месяц, приходится искать другие решения.

Именно с такой проблемой столкнулась наша группа. Задача: развернуть локальный сервер для GPT-OSS-120B, который должен стабильно выдавать 1 миллиард токенов в день. Это не синтетический бенчмарк, а реальная нагрузка от десятков внутренних инструментов и исследовательских пайплайнов. Облачные API? Съедают бюджет быстрее, чем модель генерирует текст. Обычный сервер с парой карт? Не потянет. Нужна была система, которая работает как часы, а не как паровая машина.

Решение: железо, которое не боится нагрузки

После недель тестов и сломанных графиков мы остановились на конфигурации, которая не просто работает, а работает с запасом. Главный герой — не модель, а инфраструктура под ней.

1 Выбор железа: где экономить смертельно

Здесь нет места компромиссам. Каждый сэкономленный доллар на железе обернется часами простоя и терабайтами необработанных данных.

• GPU: 2x NVIDIA H200 94GB HBM3e. Не H100, именно H200. На 07.04.2026 это один из лучших выборов для инференса больших моделей. Память: 94 ГБ на карту. Почему две? GPT-OSS-120B в формате FP16 весит около 240 ГБ. С квантованием Q4_K_M — около 68 ГБ. Но для высокой пропускной способности и батчинга нужно держать модель в памяти с запасом. Две карты в NVLink дают нам 188 ГБ общей памяти — более чем достаточно для модели и кеша ключей-значений.
• CPU: AMD EPYC 9175F. Да, тот самый из тестов CPU-инференса. Но здесь он не для генерации, а для управления IO, препроцессинга и обслуживания vLLM. 32 ядра, 64 потока, поддержка PCIe 5.0 — идеально.
• Оперативная память: 512 ГБ DDR5-4800 ECC. Меньше 512 ГБ — даже не думайте. Модель, система, кеши, батчи — всё жрет память. ECC обязательно, потому что один битый бит в весах модели приведет к ерунде на выходе.
• Хранение: 2x NVMe PCIe 5.0 по 4 ТБ в RAID 0. Да, RAID 0. Нагрузка дисковая — чтение весов модели при старте и логгирование. Нам нужна максимальная скорость. Резервирование данных делается на отдельном сетевом хранилище.
• Сеть: Mellanox ConnectX-7 100 Гбит/с. Если сервер не один в стойке, а часть кластера, сеть становится бутылочным горлышком. 100 Гбит — минимум.

2 Установка ПО: минимальная система, максимальная производительность

Ставим Ubuntu Server 24.04 LTS. Пропускаем графический интерфейс — он только мешает. Первое, что делаем после установки — обновляем ядро до последней стабильной версии и ставим NVIDIA драйверы.

# Добавляем репозиторий с новым ядром
sudo add-apt-repository ppa:canonical-kernel-team/ppa
sudo apt update
sudo apt install linux-generic-hwe-24.04

# Устанавливаем драйверы NVIDIA для H200
# На 07.04.2026 актуальная ветка — 560
sudo apt install nvidia-driver-560 nvidia-utils-560

Перезагружаемся и проверяем, что карты видны и NVLink активен.

nvidia-smi
nvidia-smi topo -m

В выводе топологии должно быть указано NVLink между картами. Если нет — проверьте физическую установку и питание.

3 Настройка vLLM: где рождаются токены

Мы используем vLLM версии 0.4.2 (актуально на 07.04.2026). Это не просто сервер, это движок, который умеет работать с такими монстрами, как GPT-OSS-120B. Установка через pip.

pip install vllm==0.4.2

А теперь самое важное — конфигурация запуска. Вот наш рабочий скрипт start_server.sh:

#!/bin/bash
export CUDA_VISIBLE_DEVICES=0,1

export VLLM_WORKER_MULTIPROC_METHOD=spawn
export VLLM_ATTENTION_BACKEND=XFORMERS

python -m vllm.entrypoints.openai.api_server \
    --model GPT-OSS-120B \
    --tensor-parallel-size 2 \
    --max-model-len 16384 \
    --gpu-memory-utilization 0.92 \
    --served-model-name gpt-oss-120b \
    --api-key your-internal-key-here \
    --port 8000 \
    --host 0.0.0.0 \
    --enforce-eager \
    --disable-custom-all-reduce \
    --max-num-batched-tokens 32768 \
    --max-num-seqs 256 \
    --quantization awq \
    --worker-use-ray \
    --ray-workers-use-native-cuda

Разберем ключевые флаги:

• --tensor-parallel-size 2: Модель раскидывается на две GPU. Для GPT-OSS-120B это обязательно.
• --gpu-memory-utilization 0.92: Не 0.95, не 0.99. Именно 0.92. При большем значении vLLM начинает слишком агрессивно управлять памятью, что приводит к фрагментации и падению производительности при долгой работе.
• --max-num-batched-tokens 32768: Максимальное количество токенов в одном батче. Чем больше, тем выше пропускная способность, но растет latency. 32768 — золотая середина для нашей нагрузки.
• --max-num-seqs 256: Максимальное количество одновременных запросов. Если у вас меньше, сервер будет недогружен. Если больше — начнется trashing.
• --quantization awq: Используем активационно-взвешенную квантизацию. Модель занимает меньше памяти, падение качества минимально. Для GPT-OSS-120B в 2026 году есть готовые AWQ-версии.

4 Оптимизация системы: отключаем всё лишнее

Сервер должен делать только одну вещь — генерировать токены. Всё остальное — враг.

# Отключаем частые враги производительности
sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily.timer
sudo systemctl disable unattended-upgrades.service

# Настраиваем управление питанием CPU на performance
sudo apt install cpufrequtils
sudo sed -i 's/^GOVERNOR=.*/GOVERNOR="performance"/' /etc/init.d/cpufrequtils
sudo systemctl restart cpufrequtils

# Выставляем параметры сети для снижения latency
sudo tee -a /etc/sysctl.conf << EOF
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 300000
EOF
sudo sysctl -p

# Монтируем tmpfs для временных файлов vLLM
sudo mount -t tmpfs -o size=64G tmpfs /dev/shm

5 Мониторинг и масштабирование: как понять, что всё сломалось

Без мониторинга вы слепы. Мы используем связку Prometheus + Grafana. vLLM имеет встроенный эндпоинт для метрик Prometheus.

Ключевые метрики, которые мы отслеживаем:

• vllm:num_requests_running: Количество активных запросов. Если постоянно упирается в max-num-seqs, нужно увеличивать параметр или добавлять ещё серверов.
• vllm:gpu_utilization: Загрузка GPU. Здоровая цифра — 85-95%. Если ниже, сервер недогружен. Если 100% долгое время — возможен thermal throttling.
• vllm:gpu_memory_usage: Использование памяти GPU. Резкий рост может указывать на утечку.
• vllm:request_latency_seconds: Задержка обработки запросов. Резкие пики — сигнал о проблемах с железом или сетью.

Нагрузка не всегда равномерна. Для обработки пиков мы настроили горизонтальное масштабирование: когда метрика vllm:num_requests_waiting превышает порог в 50, система автоматически запускает ещё один инстанс сервера через Kubernetes. Да, мы завернули vLLM в контейнеры. Это тема для отдельной статьи, но если коротко — используем образ с собранным vLLM и монтируем веса модели через PVC.

Нюансы, которые не пишут в мануалах

Теория — это хорошо, но реальность всегда бьёт по самому больному.

• Тепло. Две H200 в одной стойке выделяют как маленькая печь. Система охлаждения должна быть рассчитана на 1200+ Вт тепловыделения. Мы поставили сервер в ряд с принудительной вытяжкой. Если температура GPU превышает 85°C — начинается троттлинг, и производительность падает на 20-30%.
• Память GPU. После недели непрерывной работы vLLM может фрагментировать память. Симптомы: растёт latency, падает пропускная способность. Лечение: плановый перезапуск раз в 7-10 дней. Пишем скрипт, который делает это ночью.
• Сеть. 100 Гбит — это много, но если вы загружаете веса модели с сетевого хранилища, это может занять 10-15 минут. Держите локальную копию на NVMe. Обновление модели — отдельный квест с версионированием и A/B тестированием.
• Квантизация. AWQ — отлично, но некоторые слои модели могут быть чувствительны. Всегда тестируйте качество на вашем датасете после квантизации. Иногда проще использовать более консервативные методы.

Результаты: цифры, которые стоили нам седых волос

После всех настроек система вышла на стабильный режим:

• Пропускная способность: В среднем 13 200 токенов в секунду на пике. В сутки — около 1.14 миллиарда токенов.
• Задержка (p95): 850 мс для запроса до 1000 токенов.
• Загрузка GPU: 88-93%.
• Потребляемая мощность: ~2.1 кВт при полной нагрузке.

Сравните это с 7.2 токенами в секунду на CPU. Разница в 1800 раз. Стоимость? Сервер окупился за 4 месяца, если считать экономию на облачных API. Если считать ускорение исследований — за 2 недели.

Что делать, если бюджет не тянет две H200?

Реальность такова, что не у всех есть полмиллиона рублей на железо. Альтернативы есть, но они требуют компромиссов.

1. Использовать меньше мощные GPU, но больше штук. Например, 4x RTX 6000 Ada Generation. Сложность в настройке tensor parallelism на 4 картах растёт, но vLLM справляется.
2. Взять в аренду. Сервисы вроде Selectel предлагают готовые конфигурации с H200 по часам. Хорошо для тестов или переменной нагрузки.
3. Совместная покупка. Как это сделали ребята с Blackwell. Риски есть, но и экономия существенная.
4. Использовать меньшую модель. GPT-OSS-120B — монстр. Для многих задач хватит и Gemma 3 4B, особенно если её правильно сконфигурировать под vLLM.

Вопросы, которые задают чаще всего (и наши ответы)

Почему именно vLLM, а не Text Generation Inference или llama.cpp?

vLLM в 2026 году — это самый зрелый и производительный движок для продакшн-инференса больших моделей. У него лучшая поддержка tensor parallelism, эффективный memory management и встроенный API, совместимый с OpenAI. llama.cpp хорош для CPU или единичных запросов, но для высоконагруженного сервера — нет.

Как вы решаете проблему с обновлением модели?

Синий-зелёное развертывание. Запускаем второй сервер с новой версией модели, переключаем на него часть трафика (например, 10%), следим за метриками качества и производительности. Если всё хорошо, увеличиваем долю до 100%. Старый сервер остаётся на подхвате на случай отката.

Что делать, если один GPU выходит из строя?

Система спроектирована с учётом отказа одного узла. Если одна H200 падает, vLLM автоматически переключается в режим работы на одной карте (с пропорциональным уменьшением max-num-batched-tokens). Пропускная способность падает вдвое, но сервис остаётся жив. У нас есть холодный запас GPU для замены.

Вы используете кеширование ответов?

Да, но не на уровне vLLM. Мы поставили Redis с 256 ГБ памяти как кеш перед сервером. Если приходит идентичный запрос (считаем хэш промпта), возвращаем ответ из кеша. Это снижает нагрузку на модель на 15-20%, так как многие исследовательские запросы дублируются.

Стоит ли пробовать децентрализованные решения, вроде Gonka?

Для исследовательской лаборатории, где важна стабильность и предсказуемость latency, — нет. Gonka и аналоги хороши для задач, где стоимость важнее времени отклика. У нас каждый час простоя — это замороженные эксперименты.

И последнее: эта конфигурация — не истина в последней инстанции. К моменту, как вы это прочитаете, возможно, выйдут новые GPU, новые версии vLLM и новые методы квантизации. Суть в подходе: измеряйте всё, автоматизируйте рутину и не бойтесь пересматривать архитектуру, когда она перестаёт справляться. Ваш следующий шаг — не покупка ещё одной H200, а анализ, куда уходят эти миллиарды токенов и нельзя ли половину из них не генерировать вовсе.

Подписаться на канал