Root Profi

self-hosted AI · 8 мин

NVIDIA V100 в домашнем сервере: установка, диагностика и проблемы HBM

Практический разбор установки б/у NVIDIA V100 SXM2 32GB в домашний сервер: VFIO passthrough, диагностика ECC/HBM, Xid 48/63/64 и решение не запускать AI-нагрузку на нестабильной карте.

self-hosted AIGPUNVIDIA V100LinuxVFIOdiagnostics

Коротко

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

В этой истории мы готовили домашний сервер под NVIDIA V100 SXM2 32GB. Цель была понятная: получить ускоритель с большим объёмом видеопамяти для локальных LLM и других AI-экспериментов. На бумаге всё выглядело привлекательно: 32 GB HBM, серверный класс, не самая новая, но всё ещё интересная архитектура.

Техническая часть установки оказалась не самым слабым местом. Корпус подобрали с учётом HDD, СЖО и airflow. V100 удалось пробросить в отдельную VM через VFIO. Драйвер NVIDIA установился, nvidia-smi увидел карту. Но дальше диагностика показала аппаратную проблему HBM-памяти.

Главный вывод: если б/у серверный GPU определяется в системе, это ещё не значит, что он исправен. Для вычислений важна не только видимость устройства, но и состояние памяти, ECC, page retirement и логи драйвера.

Исходная проблема

Задача была практичная: поставить серверный ускоритель в домашний сервер и использовать его как compute GPU для локальных AI-задач.

Ограничений было несколько:

  1. В сервере уже есть диски, поэтому корпус должен нормально работать с несколькими 3.5” HDD.
  2. Нужен был не декоративный корпус со стеклом, а практичная компоновка с нормальным airflow.
  3. V100 SXM2 на PCIe-переходнике требует внимания не только к чипу, но и к зоне HBM, VRM, backplate и питанию.
  4. Хостовая видеокарта GT 710 должна была остаться для удалённой консоли через GL.iNet KVM.
  5. V100 нужно было отдать в отдельную VM, а не использовать напрямую на хосте.

На подготовительном этапе был выбран корпус be quiet! Pure Base 600 BG021 Black. Он подходит под 3.5” HDD, не имеет стеклянной панели, поддерживает 240-мм СЖО и оставляет место под V100-сборку.

Что нужно было получить

Ожидаемый результат выглядел так:

  1. Хост сохраняет свою консольную видеокарту.
  2. V100 привязана к vfio-pci.
  3. VM видит V100 как отдельный 3D controller.
  4. Внутри VM установлен NVIDIA-драйвер.
  5. nvidia-smi показывает Tesla V100-SXM2-32GB.
  6. ECC и логи не показывают критичных ошибок памяти.
  7. После этого можно переходить к лёгким CUDA/LLM-тестам.

До пункта с диагностикой памяти всё выглядело неплохо.

Практическое решение

1. Подготовка корпуса и охлаждения

Для V100 в домашнем сервере охлаждение нельзя сводить только к температуре GPU core. У SXM2-модуля на PCIe-переходнике есть зоны, которым нужен отдельный airflow:

  • HBM и обвязка;
  • VRM;
  • backplate или медная пластина;
  • питание и разъёмы;
  • соседние элементы платы.

Поэтому схема с верхним радиатором СЖО на выдув выглядела разумно: фронтальный приток остаётся для HDD и платы V100, а тепло от радиатора уходит вверх из корпуса.

2. VFIO passthrough

На хосте было важно не отключить nouveau глобально, потому что GT 710 нужна для локальной консоли и KVM. Поэтому правильная идея - не чёрный список всех NVIDIA-карт, а точечная привязка V100 к vfio-pci.

В рабочем состоянии картина была такой:

GT 710 на хосте -> nouveau
V100 на хосте -> vfio-pci
V100 внутри VM -> 3D controller NVIDIA GV100GL

Важный плюс: удалось обойтись без pcie_acs_override. Это хорошо, потому что ACS override может быть удобным костылём для лаборатории, но не должен быть первым способом решения IOMMU-групп.

3. Драйвер внутри VM

В VM была Xubuntu/Ubuntu 24.04. ubuntu-drivers devices предложил несколько веток драйверов, а рекомендованной была nvidia-driver-535.

После установки драйвера nvidia-smi увидел карту:

NVIDIA-SMI 535.309.01
Driver Version: 535.309.01
CUDA Version: 12.2
Tesla V100-SXM2-32GB
32768 MiB

На этом этапе легко ошибиться и решить: “всё, карта работает”. Но для б/у серверного ускорителя это только начало проверки.

4. Первый тревожный сигнал

В выводе nvidia-smi появился счётчик:

Volatile Uncorr. ECC

Для вычислительной карты с ECC это не косметика. Uncorrectable ECC - сигнал, что память уже обнаруживает ошибки, которые не удаётся исправить обычным механизмом коррекции.

Дополнительная диагностика показала:

Volatile Double Bit Device Memory: 5
Aggregate Double Bit Device Memory: 331

Позже значения продолжали расти после перезагрузок.

5. Проверка ECC и retired pages

Команды, которые оказались важнее любых LLM-тестов:

nvidia-smi -q -d ECC
nvidia-smi -q -d PAGE_RETIREMENT
sudo dmesg -T | grep -iE 'nvrm|xid|ecc|nvidia'

PAGE_RETIREMENT показал:

Retired Pages
    Double Bit ECC: 8
    Pending Page Blacklist: Yes

Это значит, что драйвер уже нашёл страницы памяти, связанные с double bit ECC ошибками, и пытается исключить их из работы.

6. Xid 48, 63 и 64

Самые важные строки были в dmesg:

Xid 48: An uncorrectable double bit error (DBE) has been detected on GPU in the framebuffer
Xid 63: Dynamic Page Retirement: New page retired, reboot to activate
Xid 64: Dynamic Page Retirement: Fatal Error, unable to retire page

Разбор по смыслу:

  • Xid 48 - обнаружена uncorrectable double bit ECC ошибка в framebuffer, то есть в памяти GPU;
  • Xid 63 - драйвер пытается вывести плохую страницу из работы;
  • Xid 64 - драйвер не смог корректно вывести страницу из работы.

На фоне роста счётчиков это уже не похоже на случайный сбой при старте.

7. Почему это не похоже на проблему драйвера

Был понятный вопрос: может быть, нужен nvidia-driver-535-server, 570 или 580?

Но признаки указывали не на ветку драйвера:

  • карта определяется;
  • драйвер загружается;
  • nvidia-smi работает;
  • CUDA Driver API виден;
  • ошибки появляются как DBE framebuffer;
  • retired pages растут;
  • Xid 64 говорит, что механизм изоляции страниц не справляется.

Если бы проблема была только в драйвере, ожидались бы ошибки загрузки модуля, несовместимость ядра, отсутствие устройства или сбои API. Здесь же диагностика прямо указывает на память GPU.

8. Почему не стали запускать LLM

Технически такая карта могла бы даже загрузить модель и какое-то время отвечать. Но это плохой критерий исправности.

LLM-инференс активно использует VRAM. Если HBM уже показывает uncorrectable ECC ошибки без нормальной нагрузки, то под реальной нагрузкой возможны:

  • падения CUDA-процессов;
  • reset GPU;
  • зависания;
  • некорректные вычисления;
  • деградация доступной памяти;
  • рост retired pages;
  • спорная ситуация с возвратом, если карту продолжать нагружать.

Поэтому правильное решение было не “проверить ещё ComfyUI или LM Studio”, а остановиться, сохранить логи и оформить возврат.

Ограничения и риски

Этот кейс не означает, что все б/у V100 плохие. Он показывает другое: серверный ускоритель с вторичного рынка нельзя принимать на веру.

Особенно рискованны варианты:

  • без скриншотов ECC и retired pages до покупки;
  • без понятной истории эксплуатации;
  • с нестандартными SXM2 carrier boards;
  • после пересылки без уверенности в упаковке;
  • когда продавец проверяет только факт “карта определяется”.

Для AI-задач память важна так же, как сам GPU. Большой объём VRAM не помогает, если эта VRAM нестабильна.

Чек-лист проверки б/у серверного GPU

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

nvidia-smi
nvidia-smi -q -d ECC
nvidia-smi -q -d PAGE_RETIREMENT
sudo dmesg -T | grep -iE 'nvrm|xid|ecc|nvidia'

Смотреть нужно не только на название GPU, но и на признаки:

  • нет ли Volatile Uncorr. ECC;
  • нет ли Aggregate Double Bit ECC;
  • нет ли retired pages по Double Bit ECC;
  • Pending Page Blacklist должен быть No;
  • в dmesg не должно быть Xid 48, Xid 63, Xid 64;
  • ошибки не должны расти после перезагрузок.

Если продавец готов прислать такие выводы до покупки, это снижает риск. Если проверка сводится к фото карты и фразе “рабочая”, риск остаётся высоким.

Главный вывод

Этот апгрейд не стал рабочей AI VM на V100, но он всё равно был полезным.

Мы подтвердили, что инфраструктурная часть была реализуема: корпус, airflow, VFIO passthrough, драйвер в VM. Но диагностика показала, что конкретный экземпляр карты нельзя считать надёжным.

Инженерный подход - это не только довести систему до зелёной галочки. Иногда инженерный подход - это вовремя сказать: “железо нестабильно, дальше не эксплуатируем”.

Для б/у серверных GPU главный вопрос не “видит ли система карту”, а “можно ли доверять её памяти под нагрузкой”.

Что проверить дальше

Если в инфраструктуре планируется локальный AI, GPU-сервер или покупка б/у серверного железа, лучше заранее заложить этап диагностики: питание, охлаждение, passthrough, драйверы, ECC, логи и тесты стабильности. Это дешевле, чем потом искать причину странных падений уже в рабочей системе.