Nvidia відкрила сирцевий код системи діагностики збоїв ШІ NVIDIA Attribution

Nvidia відкрила сирцевий код NVIDIA Attribution — workload-орієнтованої системи діагностики та атрибуції збоїв, яка роками використовується у власній AI-інфраструктурі компанії. За даними Nvidia, інструмент щотижня аналізує мільйони навантажень на сотнях тисяч GPU, допомагаючи відокремити першопричину збою від каскаду вторинних помилок.

Проблема каскадних помилок у розподілених завданнях

У розподілених навантаженнях збій на одному GPU або у фабриці мережі часто проявляється як помилки бібліотеки NCCL на інших вузлах, зміни стану планувальника та тисячі наступних повідомлень. Стандартні винятки вказують лише на місце зупинки процесу, а не на джерело проблеми.

NVIDIA Attribution зіставляє логи навантаження, метрики, телеметрію та стан планувальника, після чого повертає структурований висновок: вердикт (terminal_state), домен збою (sub_domain), першопричину, уражені вузли, ланцюжок супутніх симптомів і доказову базу.

Архітектура: Service та Blueprint

Система складається з двох основних розгортальних компонентів, що використовують спільне ядро (attribution engine):

• NVIDIA Attribution Service: сервіс із REST/HTTP API, який запускає правила аналізу над нормалізованими спостереженнями та повертає результат для окремої спроби виконання навантаження.
• NVIDIA Attribution Blueprint: оркестратор на Python, який визначає контекст завдання через планувальник або часове вікно, збирає логи й телеметрію, надсилає дані у Service, зберігає структурований результат і надає вебінтерфейс (read-only dashboard).

Blueprint підтримує конектори контексту виконання для Slurm, Kueue і статичних конфігурацій; конектори логів і метрик для Loki, локальних файлів, Kubernetes pod logs і PromQL; а також конектори виводу в stdout та SQLite.

Робота рушія правил

Аналіз відбувається у чотири етапи: визначення меж навантаження, збір спостережень, екстракція та кореляція подій і формування структурованого результату.

Рушій використовує декларативні та Python-правила, які постачаються разом із сервісом і не завантажуються динамічно через HTTP API. Правила проходять ранню фільтрацію (EARLY) та фінальне уточнення (FINAL). Наприклад, у разі апаратного збою NVLink (помилка XID 149) система декодує біти помилки, позначає проблему цілісності сигналу як першопричину на конкретному вузлі, а наступні помилки NCCL на інших вузлах понижує до статусу допоміжних симптомів. Якщо наявних даних недостатньо або під них підпадають кілька причин, система фіксує статус sub_domain як неоднозначний (ambiguous).