# GPU-мониторинг на DGX Spark: когда dcgm-exporter мёртв, а NVML отвечает N/A

> Штатный стек GPU-наблюдаемости на unified memory GB10 работает наполовину: dcgm-exporter не запускается, NVML отдаёт N/A на заметной доле запросов, и Grafana остаётся зелёной и пустой. Коллектор, с которым мы реально обслуживаем vLLM, и как его собрать.

- Published: 2026-08-16
- Evidence level: lab_single_run
- Funding: Собственное финансирование, внутреннее исследование
- Canonical: https://agmind.ai/ru/reports/dgx-spark-gpu-monitoring/

Версия в один абзац: на GB10 dcgm-exporter не работает, а NVML отвечает
N/A на заметную часть того, на что операторы вешают алерты. Надёжный
путь — парсить nvidia-smi в node-exporter через textfile-коллектор, с
алертом на устаревание самого коллектора. Детали, и почему этот отказ так
хорошо прячется, — ниже.

Есть конкретный момент, до которого доходит каждый оператор DGX Spark. Модель
обслуживается, vLLM отвечает, борд в Grafana подключён ровно так, как годами
подключался на каждой CUDA-коробке. И борд зелёный. Зелёный, пустой и врущий:
половина панелей без данных, вторая половина показывает прочерки, и нигде
ничего не говорит почему.

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

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

**dcgm-exporter на GB10 не функционирует.** Стандартный контейнер, который на
датацентровом железе NVIDIA кормит GPU-метриками Prometheus, с
unified-memory-дизайном Spark'а не работает. Громко он при этом тоже не
падает. Вы получаете экспортер, который запущен, и дашборд, за которым ничего
нет.

**NVML отдаёт N/A на заметную долю запросов.** Библиотека под `nvidia-smi` и
большинством питоновских мониторинг-сниппетов возвращает N/A по многим полям,
на которые операторы вешают алерты, — в первую очередь по памяти. Unified
memory ломает допущения, на которых строились эти счётчики: отдельного пула
VRAM нет, отчитываться не о чем, и инструментарий, который такой пул ждёт, не
отчитывается ни о чём.

Комбинация мерзкая ровно тем, что каждая половина выглядит виной другой.
Экспортер молчит — вы идёте проверять библиотеку; библиотека отвечает N/A —
вы решаете, что экспортер ответил бы так же, и перестаёте копать. Тем
временем коробка обслуживает 284B-параметровый MoE в продакшене вообще без
работающей GPU-телеметрии.

## Что работает: nvidia-smi, распарсенный, через textfile-коллектор

Простой текстовый вывод `nvidia-smi` на Spark'е честнее библиотек под ним.
Поля, которые отвечают, отвечают настоящими значениями. Поэтому коллектор у
нас нарочито скучный:

1. systemd-таймер гоняет `nvidia-smi` с коротким интервалом.
2. Небольшой скрипт парсит только те поля, которые на GB10 реально отвечают,
   и пишет их метриками Prometheus в `.prom`-файл.
3. textfile-коллектор node-exporter'а подбирает файл вместе с остальными
   метриками хоста.
4. Одна дополнительная метрика несёт таймстемп последнего запуска самого
   коллектора, и алерт срабатывает на устаревание. Мониторинговая труба,
   способная умереть молча, — ровно та болезнь, о которой эта страница;
   лекарство обязано действовать и на само лекарство.

Никаких демонов сверх тех, что хост уже крутит, никаких привилегированных
сайдкаров, и каждая метрика, доходящая до дашборда, — та, про которую человек
проверил: на этом железе она отвечает. Полный разбор с деталями парсинга
опубликован [на Habr](https://habr.com/ru/articles/1030802/); рецепт, к
которому он относится, — [на этом сайте](https://agmind.ai/ru/reports/deepseek-v4-flash-0731-dgx-spark-recipe/).

## Зачем мы проговариваем это вслух

Потому что этот режим отказа невидим по построению. Отсутствующая метрика
никого не будит. Команды узнают, что телеметрия их Spark'а — фикция, в тот
момент, когда что-то ломается, а дашборду нечего об этом сказать. Дороже
момента для такого открытия не бывает.

Наша позиция из [покупательского ответа по этому железу](https://agmind.ai/ru/reports/dgx-spark-worth-it/)
в силе: обслуживающая коробка, за которой нельзя наблюдать, — коробка,
которую нельзя эксплуатировать. Spark эксплуатируем. Он просто не наблюдаем
штатным стеком, и ничто в штатном стеке об этом не предупреждает.

## Скоуп

Здесь описаны юниты GB10 в нашей лаборатории, на прошивке и драйверном стеке,
актуальных на момент нашего bring-up, с обслуживанием через vLLM. Поведение
мониторинга может меняться с релизами драйверов; коллекторный подход
переживает такие перемены лучше библиотечных биндингов — отчасти поэтому мы
его и выбрали. Ничего здесь не является утверждением о датацентровом
Blackwell, где правильный ответ — dcgm-exporter.

---

Machine-readable claim registry: https://agmind.ai/claims.json · llms.txt: https://agmind.ai/llms.txt