Версия в один абзац: на 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’е честнее библиотек под ним.
Поля, которые отвечают, отвечают настоящими значениями. Поэтому коллектор у
нас нарочито скучный:
- systemd-таймер гоняет
nvidia-smiс коротким интервалом. - Небольшой скрипт парсит только те поля, которые на GB10 реально отвечают,
и пишет их метриками Prometheus в
.prom-файл. - textfile-коллектор node-exporter’а подбирает файл вместе с остальными метриками хоста.
- Одна дополнительная метрика несёт таймстемп последнего запуска самого коллектора, и алерт срабатывает на устаревание. Мониторинговая труба, способная умереть молча, — ровно та болезнь, о которой эта страница; лекарство обязано действовать и на само лекарство.
Никаких демонов сверх тех, что хост уже крутит, никаких привилегированных сайдкаров, и каждая метрика, доходящая до дашборда, — та, про которую человек проверил: на этом железе она отвечает. Полный разбор с деталями парсинга опубликован на Habr; рецепт, к которому он относится, — на этом сайте.
Зачем мы проговариваем это вслух
Потому что этот режим отказа невидим по построению. Отсутствующая метрика никого не будит. Команды узнают, что телеметрия их Spark’а — фикция, в тот момент, когда что-то ломается, а дашборду нечего об этом сказать. Дороже момента для такого открытия не бывает.
Наша позиция из покупательского ответа по этому железу в силе: обслуживающая коробка, за которой нельзя наблюдать, — коробка, которую нельзя эксплуатировать. Spark эксплуатируем. Он просто не наблюдаем штатным стеком, и ничто в штатном стеке об этом не предупреждает.
Скоуп
Здесь описаны юниты GB10 в нашей лаборатории, на прошивке и драйверном стеке, актуальных на момент нашего bring-up, с обслуживанием через vLLM. Поведение мониторинга может меняться с релизами драйверов; коллекторный подход переживает такие перемены лучше библиотечных биндингов — отчасти поэтому мы его и выбрали. Ничего здесь не является утверждением о датацентровом Blackwell, где правильный ответ — dcgm-exporter.