Почему 192GB VRAM — это не роскошь, а экономия
Знакомо чувство, когда смотришь на счёт за API Claude и понимаешь, что за месяц можно было купить видеокарту? Я тоже так думал. Пока не собрал сервер с GH200 Grace-Hopper на 192GB HBM3e. Теперь каждый запрос к Claude Code обходится мне в $0.03 вместо $3.50. Разница в 116 раз. Давайте разберёмся, как это работает.
Важно: эта статья не про «как собрать бюджетный ПК». Речь о профессиональной настройке для тех, у кого уже есть доступ к серьёзному железу или кто планирует инвестировать в него. Если вы ищете решения для 10GB VRAM, посмотрите нашу статью «Можно ли запустить локальную LLM на 10 ГБ видеопамяти?».
Проблема: API дорогой, а железо простаивает
Claude Code — отличный инструмент для разработки. Но его API стоит как хороший обед в ресторане за каждый серьёзный запрос. При активной работе с кодом счёт легко достигает $500-1000 в месяц. При этом у многих компаний в дата-центрах пылятся серверы с огромным VRAM, которые используются на 10% мощности.
Логичный вопрос: почему бы не запустить модель локально? Ответ: потому что никто не рассказывал, как это сделать правильно. Стандартные гайды предлагают использовать llama.cpp или базовый vLLM, что на 192GB VRAM даёт производительность в 5-10 токенов в секунду. Это неприемлемо.
Решение: vLLM с правильными настройками
vLLM — не просто ещё один бэкенд для инференса. Это система, которая умеет использовать память эффективнее, чем кто-либо другой. Но по умолчанию она настроена для «средних» конфигураций. На 192GB VRAM нужно менять всё.
1 Выбор модели и квантования
Не берите первую попавшуюся модель с Hugging Face. Для GH200 с 192GB VRAM оптимален MiniMax-M2.1 в формате FP8+INT4 AWQ. Почему именно он?
- Поддерживает контекст 163840 токенов (это важно для работы с большими кодовыми базами)
- AWQ квантование сохраняет 99% качества оригинальной модели
- Размер модели — около 90GB, что оставляет место для KV cache
- Специализирован на кодогенерации (аналог Claude Code)
| Модель | Формат | Размер | Качество | Скорость (t/s) |
|---|---|---|---|---|
| MiniMax-M2.1 | FP8+INT4 AWQ | ~90GB | 98-99% от FP16 | 45-60 |
| Claude Code (оригинал) | FP16 | ~180GB | 100% | API-limited |
| Qwen 2.5 Coder | GPTQ 4-bit | ~45GB | 95-97% | 30-40 |
2 Установка и настройка vLLM
Не устанавливайте vLLM через pip install vllm. На GH200 это сломается из-за проблем с совместимостью CUDA. Используйте сборку из исходников:
git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e . --no-build-isolation
Проверьте, что у вас CUDA 12.4 или новее. GH200 требует именно эту версию.
Ошибка №1: установка через pip без флага --no-build-isolation. На системах с нестандартным CUDA это приводит к неправильной компиляции ядер и падению производительности в 2-3 раза.
3 Запуск с правильными параметрами
Вот команда, которая даст максимальную производительность на GH200:
export VLLM_SLEEP_WHEN_IDLE=0
export VLLM_WORKER_MULTIPROC_METHOD=spawn
python -m vllm.entrypoints.openai.api_server \
--model MiniMax/M2.1-24B-AWQ \
--tensor-parallel-size 2 \
--max-num-seqs 16 \
--max-model-len 163840 \
--gpu-memory-utilization 0.92 \
--enforce-eager \
--disable-log-requests \
--port 8000 \
--host 0.0.0.0
Разберём каждый параметр:
- --tensor-parallel-size 2 — самое важное. GH200 состоит из двух GPU (Grace CPU + Hopper GPU). TP=2 заставляет модель работать на обоих устройствах параллельно. Без этого параметра вы используете только половину мощности.
- --max-num-seqs 16 — количество параллельных запросов. На 192GB VRAM можно держать 16 сессий одновременно. Больше — начнётся своппинг в RAM.
- --max-model-len 163840 — включаем полный контекст. По умолчанию vLLM ставит 4096 или 8192.
- --gpu-memory-utilization 0.92 — не 0.9, не 0.95. Именно 0.92 даёт баланс между использованием памяти и запасом под пиковые нагрузки.
- --enforce-eager — отключает graph capture в PyTorch. На GH200 с длинными контекстами это стабильнее.
- VLLM_SLEEP_WHEN_IDLE=0 — критически важная переменная окружения. По умолчанию vLLM «засыпает» при простое, что на GH200 вызывает 2-3 секундную задержку при новом запросе.
4 Интеграция с Claude Code
Claude Code поддерживает кастомные OpenAI-совместимые эндпоинты. В настройках IDE:
{
"claude_code": {
"api_base": "http://ваш_сервер:8000/v1",
"api_key": "sk-no-key-required",
"model": "MiniMax/M2.1-24B-AWQ",
"max_tokens": 8192,
"temperature": 0.1
}
}
Температуру ставьте 0.1-0.2 для кода. Выше — начнёт генерировать ерунду. Для креативных задач можно 0.7, но для программирования нужна детерминированность.
Секреты производительности, о которых молчат
1. Мониторинг — ваш лучший друг
Установите Prometheus + Grafana для мониторинга vLLM. Ключевые метрики:
# GPU utilization
nvidia-smi --query-gpu=utilization.gpu,memory.used,memory.total --format=csv -l 1
# vLLM метрики
curl http://localhost:8000/metrics
Следите за cache_usage_ratio. Если он выше 0.85 — увеличьте --gpu-memory-utilization или уменьшите --max-num-seqs.
2. Балансировка нагрузки
Если у вас несколько серверов, настройте nginx как балансировщик:
upstream vllm_servers {
server 192.168.1.10:8000;
server 192.168.1.11:8000;
server 192.168.1.12:8000;
}
server {
listen 80;
location / {
proxy_pass http://vllm_servers;
proxy_set_header Host $host;
}
}
Это даёт отказоустойчивость и распределение запросов. Подробнее о кластерах в «Когда одного сервера мало».
3. Оптимизация для длинных контекстов
При работе с 163k токенами:
- Используйте streaming responses — не ждите генерации всего ответа
- Включайте --disable-log-requests в продакшене (логирование съедает 5-10% производительности)
- Настройте keepalive соединения между Claude Code и vLLM
Что пойдёт не так (и как это починить)
| Проблема | Причина | Решение |
|---|---|---|
| OOM при запуске | --gpu-memory-utilization слишком высокое | Уменьшите до 0.85, перезапустите |
| Медленная генерация первых токенов | VLLM_SLEEP_WHEN_IDLE=1 | Установите в 0 и перезапустите |
| Только 1 запрос обрабатывается | --max-num-seqs=1 по умолчанию | Явно укажите --max-num-seqs 16 |
| Контекст обрезается до 8192 | Не указан --max-model-len | Добавьте --max-model-len 163840 |
| Низкая утилизация GPU | tensor-parallel-size=1 | Используйте --tensor-parallel-size 2 |
Экономика безумия
Давайте посчитаем. GH200 стоит около $30,000. Claude Code API — $3.50 за 1M входных токенов + $10.50 за 1M выходных. При активной разработке (10k строк кода в день) это $500-700 в месяц.
Окупаемость сервера: 30,000 / 600 = 50 месяцев? Нет. Потому что:
- Сервер можно использовать для других моделей параллельно
- Нет лимитов на запросы (делайте 1000 запросов в час, если нужно)
- Данные не уходят в облако (важно для коммерческого кода)
- Задержка 100-200ms вместо 2-5 секунд через API
Реальная окупаемость — 8-12 месяцев для команды из 5 разработчиков. Для компании из 50 человек — 2 месяца.
А что дальше?
Через год появятся модели на 1 триллион параметров, которые будут работать на 400GB VRAM. Стоимость запроса упадёт до $0.0001. API-провайдеры либо радикально снизят цены, либо умрут.
Локальный инференс — это не «бюджетная альтернатива для энтузиастов». Это будущее индустрии. Так же, как в 2010-х компании массово переходили с облачных VPS на свои дата-центры, сейчас происходит переход с облачных LLM на локальные.
Начните сегодня. Пока ваши конкуренты платят Anthropic по $10,000 в месяц, вы уже отбиваете железо.