V100 против vLLM: как заставить GPT OSS 120B работать на устаревшем железе

Почему V100 и vLLM не дружат из коробки

Вы достали из серверной стойки пару V100, прочитали про vLLM с его магическим PagedAttention и решили запустить GPT OSS 120B. Казалось бы, 32GB VRAM на карту, tensor parallelism - и модель полетит. Но вместо этого получаете ошибку о несовместимости архитектуры или банальный OOM. Знакомо?

Проблема в том, что разработчики vLLM оптимизируют под новое железо. V100 вышел в 2017 - это вечность в мире AI. Но эти карты до сих пор работают в дата-центрах, их продают на вторичке за копейки, и многие пытаются на них запускать современные модели.

Что сломается первым

Давайте сразу к конкретике. Вот что не работает на V100 с современным vLLM:

• FP8 inference - V100 не поддерживает FP8 формально
• Некоторые оптимизации attention - используют инструкции, которых нет в Volta
• Автоматическое распределение слоев - может пытаться использовать неподдерживаемые операции
• PagedAttention в полном объеме - отдельные оптимизации требуют compute capability 8.0+

Но это не значит, что все потеряно. Просто нужно знать, где обходить ограничения.

Подготовка: что нужно сделать до запуска

1 Собираем правильный vLLM

Не берите последнюю версию из pip. Нужна конкретная сборка с патчами для Volta. Вот команды, которые работают:

# Клонируем репозиторий с определенным коммитом
git clone https://github.com/vllm-project/vllm.git
cd vllm
git checkout v0.3.3  # Эта версия стабильнее работает с V100

# Устанавливаем с определенными флагами
pip install -e . --no-build-isolation \
  --no-cache-dir \
  --verbose \
  CUDA_ARCHITECTURES="70"  # Форсируем компиляцию под Volta

2 Готовим модель к квантованию

GPT OSS 120B в FP16 требует ~240GB VRAM. Даже на 4x V100 (128GB суммарно) это не влезет. Значит, нужно квантование. Но не любое.

Ошибка, которую все делают: пытаются использовать AWQ или GPTQ через стандартные загрузчики vLLM. На V100 это часто приводит к ошибкам ядра или падению производительности.

Правильный путь: готовим модель отдельно, с контролем над процессом:

# Скачиваем модель
python -c "from huggingface_hub import snapshot_download; snapshot_download(repo_id='openai-community/gpt-oss-120b', local_dir='./gpt-oss-120b')"

# Конвертируем в совместимый формат
python -m vllm.entrypoints.convert \
  --model ./gpt-oss-120b \
  --output ./gpt-oss-120b-vllm \
  --dtype half \
  --quantization awq \
  --awq-zero-point  # Этот флаг важен для V100!

Запускаем с правильными параметрами

Теперь самое интересное. Вот конфигурация, которая работает на 4x V100:

python -m vllm.entrypoints.api_server \
  --model ./gpt-oss-120b-vllm \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.95 \
  --max-model-len 4096 \
  --enforce-eager  # КРИТИЧЕСКИ ВАЖНО для V100! \
  --disable-custom-all-reduce \
  --dtype half \
  --quantization awq \
  --port 8000

Что делают эти флаги:

Ошибки, которые точно встретятся (и как их фиксить)

Ошибка 1: "CUDA error: no kernel image is available for execution"

Самая частая. Означает, что vLLM скомпилирован под более новую архитектуру.

Решение:

# Полностью пересобираем vLLM
cd vllm
pip uninstall -y vllm
rm -rf build/ dist/ *.egg-info

# Чистая сборка с явным указанием архитектуры
TORCH_CUDA_ARCH_LIST="7.0" \
CMAKE_CUDA_ARCHITECTURES="70" \
pip install -e . --no-build-isolation --verbose

Ошибка 2: "RuntimeError: CUDA out of memory" при достаточной VRAM

Модель вроде должна влезать, но не влезает. Проблема в fragmentation или неправильном распределении.

Решение: принудительно ограничиваем память и включаем более агрессивную дефрагментацию:

python -m vllm.entrypoints.api_server \
  --model ./gpt-oss-120b-vllm \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.90  # Уменьшаем с 0.95 \
  --max-model-len 2048  # Уменьшаем контекст \
  --enforce-eager \
  --disable-custom-all-reduce \
  --block-size 16  # Уменьшаем размер блока для PagedAttention \
  --swap-space 4  # Резервируем 4GB на диске для свопа \
  --port 8000

Ошибка 3: Медленная генерация после нескольких запросов

PagedAttention на V100 может деградировать со временем из-за фрагментации.

Решение: мониторим и периодически перезапускаем:

# Скрипт для мониторинга и автоматического перезапуска
import time
import subprocess
import requests

while True:
    try:
        # Проверяем здоровье
        resp = requests.get("http://localhost:8000/health")
        if resp.status_code != 200:
            raise Exception("Service down")
        
        # Проверяем latency
        start = time.time()
        resp = requests.post("http://localhost:8000/v1/completions", 
                            json={"model": "gpt-oss-120b", 
                                  "prompt": "test", 
                                  "max_tokens": 1})
        latency = time.time() - start
        
        if latency > 10.0:  # Если latency > 10 секунд
            print(f"High latency: {latency}. Restarting...")
            subprocess.run(["pkill", "-f", "api_server"])
            time.sleep(5)
            # Запускаем заново с теми же параметрами
            # ...
            
    except Exception as e:
        print(f"Error: {e}. Restarting...")
        # Перезапускаем сервер
        
    time.sleep(60)  # Проверяем каждую минуту

Оптимизация производительности

На V100 вы не получите тех же токенов в секунду, что на H100. Но можно выжать максимум.

1. Используйте более низкую точность - если AWQ работает плохо, попробуйте INT8 через отдельную конвертацию
2. Настройте batch size - на V100 оптимальный batch size меньше, чем на новых картах. Начинайте с 1-2
3. Отключите лишнее - мониторинг, логирование, метрики съедают ресурсы
4. Рассмотрите continuous batching - но только если у вас много параллельных запросов

Ожидаемая производительность на 4x V100 с AWQ квантованием:

• Генерация: 2-4 токена/секунду
• Пропускная способность при continuous batching: 10-20 запросов/минуту
• Latency первого токена: 3-7 секунд

Да, это медленно. Но это работает. И это дешевле, чем покупать H100.

Альтернативы, если vLLM категорически не идет

Если после всех танцев с бубном vLLM не запускается, есть варианты:

1. llama.cpp с GPU offload - медленнее, но стабильнее. В статье про Solar-Open-100B на домашнем железе есть похожие техники.

2. TensorRT-LLM - требует больше работы по конвертации, но может дать лучшую производительность на V100

3. Деление модели между GPU и CPU - как в статье про запуск LLM на 10 ГБ VRAM

Главный секрет, о котором молчат

V100 имеет одну фичу, которую часто упускают: поддержку независимых процессов на каждом GPU. Это значит, что можно запустить несколько инстансов vLLM на одной карте, каждый со своей частью модели.

Схема для 2x V100 и GPT OSS 120B:

# На первой карте запускаем первые 60 слоев
CUDA_VISIBLE_DEVICES=0 python -m vllm.entrypoints.api_server \
  --model ./gpt-oss-120b-vllm \
  --tensor-parallel-size 1 \
  --pipeline-parallel-size 2 \
  --pipeline-parallel-rank 0 \
  --port 8001

# На второй карте - остальные 60 слоев
CUDA_VISIBLE_DEVICES=1 python -m vllm.entrypoints.api_server \
  --model ./gpt-oss-120b-vllm \
  --tensor-parallel-size 1 \
  --pipeline-parallel-size 2 \
  --pipeline-parallel-rank 1 \
  --port 8002

Плюс такого подхода: если один процесс упадет, не падает вся система. Минус: нужно писать свой балансировщик запросов.

Что делать, когда ничего не помогает

Бывает, что конкретная партия V100 (чаще всего ранние ревизии) имеет проблемы с некоторыми операциями. В этом случае:

1. Обновите драйверы до последней поддерживаемой версии (470.x или новее)
2. Проверьте, что CUDA toolkit версии 11.8 (последняя с полной поддержкой Volta)
3. Попробуйте запустить с --disable-log-stats --disable-log-requests
4. Рассмотрите аппаратную замену - иногда проще найти RTX 3090, как в статье про бюджетные альтернативы

И последнее: если вы запускаете в продакшене, обязательно прочитайте статью про сбои vLLM на RTX 6000. Многие проблемы похожи.

Будущее V100 в эпоху 120B моделей

V100 умрет не завтра. Эти карты будут работать еще лет 5, просто потому что их много и они надежны. Но с каждой новой версией vLLM поддержка будет ухудшаться.

Мой прогноз: к концу 2025 года запустить современные модели на V100 будет возможно только через специальные форки vLLM или через эмуляцию новых инструкций (что убьет производительность).

Поэтому если вы планируете долгосрочный проект на V100 - форкните vLLM сейчас и зафиксируйте версию. Или готовьтесь к миграции на более новое железо. Как показывает статья про RTX 5070 Ti, даже новое железо не гарантирует отсутствия проблем.

А пока - запускайте. Пусть медленно, пусть с костылями. Но запускайте. Потому что 120B модель на железе 2017 года - это все еще магия. Просто магия, которая требует много терпения и знания, где искать нужные флаги.