Когда vLLM ломается на двух RTX 6000: полное расследование сбоев и пошаговое лечение

Тишина. Потом писк. И черный экран

Ты запускаешь vLLM на сервере с двумя RTX 6000. Модель загружается, первые токены генерируются. И вдруг — жесткий сброс. Система падает, GPU отключаются, в логах появляются загадочные ошибки CUDA. Знакомо? Добро пожаловать в клуб.

Эта проблема преследует инженеров, работающих с многокарточными конфигурациями для инференса LLM. Особенно с картами типа RTX 6000, которые потребляют до 300Вт каждая. Система работает, пока не работает. А потом перестает.

Что ломается на самом деле

Проблемы с vLLM на многокарточных серверах делятся на три категории:

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

Шаг 0: подготовка к вскрытию

Перед тем как лезть в настройки, собери данные. Без них ты слепой.

1Сними показания с больного

Запусти эти команды сразу после сбоя:

Проверь dmesg на предмет ошибок NVRM (драйвер NVIDIA) или PCIe:

dmesg | grep -E "NVRM|PCIe|GPU|reset" | tail -50

Посмотри, что происходит с GPU прямо сейчас:

nvidia-smi --query-gpu=timestamp,name,pci.bus_id,driver_version,pstate,pcie.link.gen.max,pcie.link.gen.current,temperature.gpu,power.draw,clocks.gr,clocks.mem --format=csv -l 1

Эта команда покажет не только температуру и потребление, но и текущую скорость PCIe. Если видишь падение с PCIe 4.0 x16 до PCIe 1.1 x1 — это признак проблем с питанием или перегревом.

2Проверь, как vLLM видит железо

Запусти минимальный тест, который не должен падать:

python -c "import torch; print(torch.cuda.device_count()); [print(f'GPU {i}: {torch.cuda.get_device_name(i)}') for i in range(torch.cuda.device_count())]"

Если видишь меньше карт, чем физически установлено — проблема на уровне инициализации PCIe. Если видишь все карты, но vLLM падает при запуске модели — проблема в распределении памяти или конфликте библиотек.

Питание: главный враг стабильности

Две RTX 6000 в пике потребляют до 600Вт. Добавь процессор, память, диски — легко перевалить за 800Вт. Номинальный блок питания 1000Вт? Недостаточно.

Пиковые нагрузки для GPU длятся миллисекунды, но блок питания должен их выдерживать. Дешевые блоки не справляются.

3Ограничь потребление GPU

NVIDIA позволяет ограничить максимальную мощность карты. Для RTX 6000 штатный лимит — 300Вт. Снизь до 280Вт:

sudo nvidia-smi -pl 280

Для обеих карт:

sudo nvidia-smi -i 0 -pl 280

sudo nvidia-smi -i 1 -pl 280

Разница в производительности составит 5-7%, но стабильность возрастет на порядок. Особенно если у тебя слабый блок питания.

PCIe ASPM: функция, которая ломает все

Active State Power Management (ASPM) — функция энергосбережения PCIe. В теории она уменьшает потребление, когда карта не активна. На практике она вызывает случайные сбросы шины PCIe под нагрузкой.

Особенно страдают серверные материнские платы и многокарточные конфигурации.

4Отключи ASPM в ядре

Добавь параметр ядра при загрузке:

В /etc/default/grub найди строку GRUB_CMDLINE_LINUX_DEFAULT и добавь:

pcie_aspm=off

Выглядеть должно так:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=off"

Обнови конфигурацию GRUB:

sudo update-grub

И перезагрузись.

Проверь, что отключилось:

lspci -vv | grep -A 20 "VGA compatible controller" | grep ASPM

Если видишь "ASPM Disabled" — хорошо. Если нет — возможно, нужно отключить ASPM в BIOS/UEFI.

NVIDIA persistent mode: почему он нужен

По умолчанию драйвер NVIDIA выгружает контекст GPU при простое. Это экономит память, но вызывает задержки при повторной инициализации. В многокарточных конфигурациях это может приводить к десинхронизации и сбоям.

5Включи персистентный режим

sudo nvidia-persistenced --verbose

Проверь статус:

sudo systemctl status nvidia-persistenced

Чтобы включить автоматически при загрузке:

sudo systemctl enable nvidia-persistenced

Персистентный режим держит драйвер загруженным даже когда нет активных процессов. Это уменьшает время отклика и стабилизирует работу многокарточных конфигураций.

Проблемы с памятью: когда VRAM достаточно, но vLLM говорит, что нет

Типичная ошибка: "CUDA out of memory". Ты проверяешь nvidia-smi — свободно 40GB. Но vLLM падает при загрузке модели в 30GB.

Проблема в фрагментации памяти. vLLM использует собственный аллокатор PagedAttention, который чувствителен к большим непрерывным блокам памяти.

6Очисти память перед запуском

Перед запуском vLLM выполни:

sudo nvidia-smi --gpu-reset

Осторожно: эта команда сбросит все GPU и завершит работающие процессы. Используй только на чистой системе.

Или более мягкий вариант — освободи кеш CUDA из Python:

import torch

torch.cuda.empty_cache()

for i in range(torch.cuda.device_count()):

torch.cuda.set_device(i)

torch.cuda.empty_cache()

Конфигурация vLLM для нестабильного железа

Если железо все еще капризничает, добавь эти параметры при запуске vLLM:

Пример запуска с параметрами стабильности:

python -m vllm.entrypoints.api_server \

--model mistralai/Mistral-7B-Instruct-v0.2 \

--tensor-parallel-size 2 \

--gpu-memory-utilization 0.85 \

--max-num-batched-tokens 1024 \

--disable-custom-all-reduce

BIOS/UEFI: настройки, которые все ломают

Современные материнские платы слишком умные. Они пытаются оптимизировать потребление, частоты, тайминги. И ломают стабильность.

Залезь в BIOS и проверь:

• Above 4G Decoding: ВКЛЮЧЕНО (обязательно для многокарточных конфигураций)
• Resizable BAR: ВКЛЮЧЕНО (может помочь с производительностью)
• PCIe Speed: установи вручную на Gen3 или Gen4 (не Auto)
• Power Supply Idle Control: установи на Typical Current Idle
• Global C-state Control: ОТКЛЮЧИТЬ

C-states — это состояния энергосбережения процессора. При переходе между ними возникают микро-задержки, которые могут сбить синхронизацию PCIe.

Температура: молчаливый убийца

RTX 6000 — карты с пассивным охлаждением в reference-дизайне. Они рассчитаны на хороший обдув в серверном шасси. В обычном корпусе перегреваются.

Проверь температуру под нагрузкой:

watch -n 1 nvidia-smi --query-gpu=temperature.gpu --format=csv

Критические значения:

• До 85°C — нормально
• 85-95°C — тревога, производительность снижается
• Выше 95°C — троттлинг или отключение

Если карты перегреваются, проверь:

1. Обдув в корпусе: минимум 2 вентилятора на вдув, 2 на выдув
2. Расстояние между картами: минимум один слот пустым
3. Пыль на радиаторах: чисти каждые 3 месяца

Когда ничего не помогает

Бывает. Железо нестабильно, и никакие настройки не помогают. Что делать?

Вариант 1: Запусти модель на одной карте. Раздели нагрузку — запусти два независимых инстанса vLLM на разных портах, каждый на своей карте. Неэлегантно, но работает.

Вариант 2: Перейди на llama.cpp с RPC. Он менее требователен к стабильности PCIe. У нас есть подробное руководство по настройке llama.cpp RPC-server.

Вариант 3: Используй CPU+RAM инференс для стабильности. Медленнее, но не зависит от капризов GPU. Гайд по CPU+RAM инференсу здесь.

Чеклист на каждый день

Создай скрипт мониторинга и запускай его перед началом работы:

Сохрани этот скрипт и запускай его по cron каждые 5 минут. Если что-то выходит за норму — получи уведомление.

Самая частая ошибка, которую все делают

Запускать vLLM с параметром --tensor-parallel-size равным количеству GPU. Всегда.

Неправильно: 2 GPU → tensor-parallel-size=2

Правильно: сначала проверь, действительно ли модель требует распределения тензоров. Для моделей до 13B часто эффективнее запустить несколько инстансов на разных GPU.

Проверь производительность:

# Запуск с tensor parallelism

python -m vllm.entrypoints.api_server --model ... --tensor-parallel-size 2

# Запуск двух независимых инстансов

python -m vllm.entrypoints.api_server --model ... --port 8000 --device 0 &

python -m vllm.entrypoints.api_server --model ... --port 8001 --device 1 &

Второй вариант часто стабильнее и дает лучшую пропускную способность для небольших моделей.

Итог: порядок действий при сбое

1. Не перезагружайся. Собери логи: dmesg, nvidia-smi, журналы vLLM.
2. Проверь температуру и потребление. Если что-то зашкаливает — проблема в охлаждении или питании.
3. Ограничь мощность GPU до 90% от номинала. Если помогло — меняй блок питания.
4. Отключи ASPM в ядре и BIOS. Перезагрузись.
5. Включи NVIDIA persistent mode.
6. Очисти память GPU перед запуском.
7. Запусти vLLM с параметрами стабильности (--gpu-memory-utilization 0.9, --max-num-batched-tokens).
8. Если не помогло — проверь настройки BIOS (Above 4G, C-states, PCIe speed).
9. Если все еще не работает — рассмотри запуск на одной карте или переход на CPU/llama.cpp.

Стабильность многокарточных систем — это искусство компромиссов. Между производительностью и надежностью. Между мощностью и нагревом. Между автоматическими оптимизациями и ручными настройками.

Самый важный урок: vLLM не падает сам по себе. Он падает потому, что какая-то часть системы не выдерживает нагрузки. Ищи эту часть. Методично. С логами в одной руке и мультиметром в другой.

И помни: если система работает стабильно с ограничением мощности на 10% — это не поражение. Это знание. Знание того, где находится предел. А знание пределов своей системы — это и есть профессиональная инженерия.