NVIDIA Minerva 분석: 느린 AI 작업을 GPU·네트워크와 연결하는 법

경보 세 개를 하나의 조사 질문으로 바꾼다

분산 학습 작업 J1이 평소보다 느리다. 같은 시간대에 한 스위치에서 오류가 늘고, 여러 GPU의 이용률이 내려간다. 운영 화면 세 곳에는 각각 이상이 표시되지만, 담당자는 다시 묻는다. “그 스위치가 정말 J1의 통신 경로에 있는가?” 이 연결이 없으면 네트워크팀과 학습팀이 같은 사건을 따로 조사할 수 있다.

NVIDIA는 2026년 10월 22일 Minerva를 발표했다. 장비와 AI 작업의 텔레메트리, 즉 상태·성능 기록을 모으고, 관계 그래프와 AI/ML로 이상을 묶어 조사와 조치를 돕는 AIOps 플랫폼이다. 발표에서 IREN은 사용 중인 사례로, 여러 다른 기업은 도입 계획으로 구분된다. 이를 모두 완료된 배포나 독립 검증 성과로 세지 않는다. 공식 발표

이번 변화가 중요한 이유는 AI 인프라의 운영 단위가 장비 한 대에서 여러 장비에 걸친 작업 하나로 넓어진다는 데 있다. 장비가 켜져 있어도 작업이 통신을 기다리거나 실패한 계산을 반복하면 유효한 결과는 적을 수 있다. 이는 발표를 바탕으로 한 필자의 해석이며, Minerva의 시간 절감률을 실측한 결론은 아니다.

이 글은 10월 26일 확인한 발표와 1.0.1 사용자 문서를 기준으로 한다. 문서의 갱신일은 플랫폼 개요·릴리스 노트가 10월 13일, Network Model이 10월 21일, Auto Correlation이 10월 23일로 서로 다르다. 아래 장애와 수치는 직접 만든 설명용 사례다. 제품 설치, 실제 GPU 장애, UI 조작과 자동 복구는 실행하지 않았다.

수치에 ‘어느 작업의 어느 장비인가’를 붙이는 구조

Minerva의 플랫폼 개요는 수집, 객체 모델링, 맥락 보강, 머신러닝, 저장, 외부 표시·통지의 여섯 역할을 설명한다. 원시 기록을 받아 장비와 관계를 만들고, 장비의 역할 같은 속성을 붙인 다음 분석과 조회에 사용한다. AI에게 로그를 길게 보내는 것만으로 설명되는 구조는 아니다. 1.0.1 Platform Overview

Network Model 문서는 장비·인터페이스·큐 같은 객체와 관계를 그래프로 표현한다. 측정값은 Measures, 식별자·속성·관련 객체의 속성은 Dimensions로 다룬다. 예컨대 오류 수치만 보는 대신 어느 인터페이스이며 어떤 장비에 속하는지 함께 걸러 볼 수 있다. 해당 속성값이 없으면 Null로 표시한다. Network Model

이 구조를 업무 질문으로 바꾸면 다음과 같다. 오른쪽 열은 공식 필드 명세가 아니라 독자가 준비할 정보의 예다.

조사 질문	연결에 필요한 정보의 예
어느 작업이 느린가?	작업 식별자, 실행 구간, 정상 때의 진행 속도
그때 어디서 실행됐나?	작업과 노드의 배치 관계, 관계가 유효했던 시각
해당 노드는 무엇을 공유하나?	NIC·스위치·링크·스토리지의 연결 관계
이상이 실제로 겹쳤나?	측정 시각, 수집 주기, 시계 차이와 누락
다른 작업도 같은가?	같은 경로를 쓰는 작업과 다른 경로의 비교 대상

관계의 시점이 특히 중요하다. 작업이 다른 노드로 이동했다면 지금의 배치도로 과거 장애를 설명할 수 없다. 장비 이름을 재사용하거나 수집이 늦게 도착하는 경우도 있다. 그래프가 있다는 사실보다 사건 당시의 작업·장비 대응을 복원할 수 있는지가 조사 품질을 좌우한다. 이 부분은 도입 평가를 위한 분석이며, 제품의 모든 과거 관계 복원 동작을 확인했다는 뜻은 아니다.

Run:ai가 “작업을 어디에 놓고 자원을 어떻게 나눌까”를 다룬다면, 여기서 보는 Minerva의 질문은 “놓인 작업이 왜 느리거나 실패했을까”다. 두 계층의 정보는 연결할 수 있지만, 스케줄러를 설치했다고 물리 경로의 이상 원인까지 자동으로 밝혀지지는 않는다.

가상 장애: 같은 시간에 발생했다고 같은 원인은 아니다

아래는 관계를 읽는 연습이다. 실제 Minerva 화면·출력이나 내부 상관 알고리즘을 재현한 것이 아니다. J1은 랙 R1과 R2의 노드를, J2는 R3의 노드를 쓴다. 사건이 발생한 10분 시점의 배치가 정확하며, 랙 경로 외에 공유하는 상위 장비와 스토리지는 아직 조사하지 않았다고 가정한다.

가상 관측	지금 할 수 있는 판단	다음 행동
10분에 R1 경로 오류와 J1 지연이 함께 나타남	R1은 J1과 연결된 조사 후보	J1의 통신 대기·해당 링크 상태·발생 순서를 대조
같은 분에 J2도 느려짐	시각만으로 R1 원인에 합칠 수 없음	R3 경로와 공유 상위 장비·입력 데이터·스토리지 확인
40분에는 J1이 R3, J2가 R1·R2로 이동함	새 R1 사건의 관련 작업은 J2	사건 시점의 배치로 다시 연결
R2의 오류 기록이 비어 있음	오류가 없었는지, 수집이 끊겼는지 모름	수집기 상태와 마지막 관측 시각 확인

첫 행도 R1의 고장이 확정됐다는 뜻은 아니다. 작업이 만든 트래픽 증가가 경로의 혼잡을 일으켰을 수도 있고, 둘 모두 다른 장애의 결과일 수도 있다. 연결 관계는 확인 순서를 좁혀 주지만 인과의 방향까지 결정하지 않는다. 조치 후 회복, 다른 조건을 유지한 재현, 관련 없는 경로와의 비교가 추가 증거가 된다.

두 번째 행에서 J2를 별도 조사 대상으로 남기는 것은 상관 분석의 실패가 아니다. 오히려 잘못 합치는 일을 줄이는 데 필요하다. 반대로 J1과 J2가 같은 상위 스위치나 스토리지를 쓴다는 새 근거가 나오면 사건을 합칠 이유가 생긴다. 처음 만든 그룹은 확정 결론이 아니라 수정 가능한 조사 단위다.

1.0.1의 Auto Correlation 문서는 Dimensions 방식은 Rack·jobId 같은 공통 메타데이터로, Topology 방식은 네트워크 연결 관계로 사건을 묶는다고 설명한다. 어떤 뷰를 포함할지 정하는 설정도 있다. “설치하면 모든 경보가 알아서 정확히 묶인다”는 기대와는 다르다. Configure Auto Correlation

도입 테스트에서는 같은 시각이지만 무관한 사건, 관련 장비인데 시차가 있는 사건, 작업이 이동한 사건, 기록이 누락된 사건을 따로 준비할 만하다. 위 사례의 관계 선택과 뒤의 산술은 직접 작성한 계산 자료에서 확인할 수 있다. 이 자료의 통과 결과를 Minerva 탐지 정확도로 읽으면 안 된다.

수집기와 분석 플랫폼을 나누면 도입 비용도 보인다

공식 개요는 Collector Stack과 Platform Stack을 구분한다. 수집기는 장비에 직접 접근해 데이터를 받아 전달하고, 플랫폼은 객체 관계·분석·저장·표시를 맡는다. 자체 관측 도구와 Minerva를 함께 쓰는 DIY 방식, 통합 구성을 쓰는 turnkey 방식이 설명돼 있다. 기존 Grafana 등을 모두 버려야만 검토할 수 있는 구조는 아니다. 플랫폼 구성과 소비 방식

다만 같은 문서의 배포 가능성 설명을 그대로 설치 조건으로 옮기면 문제가 생긴다.

확인한 공식 자료	쓰여 있는 범위	이 글의 적용 판단
제품 페이지·플랫폼 개요	온프레미스와 SaaS, 분리된 수집·분석 구조 설명	제품 차원의 선택지·구조를 이해하는 자료
1.0.1 릴리스 노트	Cloud/SaaS 배포 미지원 명시	1.0.1 검토에서 SaaS 지원을 확정하지 않음
제품 FAQ	Collector부터 주요 기능을 DSX OS에서 오픈소스로 공개할 예정	전체 Minerva가 이미 오픈소스라고 확대하지 않음

근거: 제품 페이지와 FAQ · 1.0.1 Release Notes. 공식 자료 사이의 범위 차이가 남아 있다. 다른 상용 제공 경로나 후속 버전의 조건은 별도 확인해야 하며, 이 글은 SaaS를 이용할 수 없다고 모든 계약에 일반화하지 않는다. 확인한 자료만으로 가격·국가별 제공·계약별 보관 조건도 확정하지 않는다.

보안 설정 역시 버전별 인수 항목이다. 1.0.1 릴리스 노트에는 백엔드 API가 기본으로 인증되지 않는다는 경고, 테넌트 격리가 적용되는 데이터 유형의 제한이 있다. 따라서 팀 이름으로 화면을 나눴다는 사실만으로 조직 간 데이터 격리를 보증할 수 없다. 도입 전에 해당 버전의 인증 설정과 실제 조회 범위를 확인해야 한다. 이는 문서상 알려진 제약을 옮긴 것이며 이번에 취약점을 재현한 결과는 아니다. 1.0.1의 Known Issues

비용을 비교할 때도 견적의 소프트웨어 금액만으로 끝내기 어렵다. 필자의 제안은 수집 장비 범위, 초당 기록량, 보관 기간, 전송 위치, 담당자의 대응 시간을 같이 적는 것이다. 여러 데이터센터의 기록을 한곳으로 보낼수록 분석은 쉬워질 수 있지만 전송·저장·접근 관리 비용은 달라진다. 실제 요금과 자원 소모를 확인하지 않았으므로 이 글에서는 절감액을 계산하지 않는다.

경보 수 대신 ‘남은 유효한 작업’을 평가한다

NVIDIA는 Minerva의 목표를 GPU 시간, goodput, 가동 시간, 토큰 생산 같은 AI factory yield와 연결한다. 이 글에서는 goodput을 설명할 때 최종 결과에 기여한 유효한 작업량에 주목한다. 발표의 효과 설명은 공급자의 주장이고, 모든 지표를 한 공식으로 합친 제품 점수를 뜻하지 않는다. 발표의 평가 방향

가령 같은 GPU 32장을 두 시간 예약했다면 사용한 자원 시간은 32 × 2 = 64 GPU·시간이다. 중간 실패로 계산 일부를 잃고, 같은 속도로 계산했을 때 1.5시간에 해당하는 진도만 최종 체크포인트에 남았다고 하자.

예약한 자원 시간       = 32 × 2   = 64 GPU·시간
보존된 진도의 환산량   = 32 × 1.5 = 48 GPU·시간
잃은 진도의 환산량     = 64 − 48  = 16 GPU·시간
보존 비율             = 48 ÷ 64  = 75%

이는 동일한 작업 속도·동일 GPU라는 가정의 설명용 계산이다. GPU 이용률이나 Minerva의 공식 지표 산식이 아니다. 데이터·배치·모델이 바뀌면 같은 한 시간의 진도도 달라지므로 단순 환산을 유지할 수 없다. 실제 평가에서는 완료한 학습 스텝, 체크포인트, 품질 조건과 재시작 이력을 함께 남겨야 한다.

이 사례에서 경보가 절반으로 줄었다고 16 GPU·시간을 되찾았다고 말할 수는 없다. 중요한 경보까지 숨겼다면 오히려 손실이 커진다. 도입 전후에는 조사 시작까지의 시간, 잘못 묶은 사건, 누락된 실제 장애, 복구 후 남은 진도를 함께 비교하는 편이 낫다.

공식 Operational Readiness Review는 설치 후 데이터 소스가 들어오는지 확인하고, 유휴 상태의 기준 화면과 미해결 항목 목록을 남기도록 안내한다. 토폴로지·텔레메트리를 먼저 확인한 뒤 작업 검증으로 넘어가는 흐름이다. 운영 준비 검토

여기에 필자는 동일 작업을 실행할 때의 기준선도 추가할 것을 제안한다. 유휴 상태가 정상이라고 학습 중 통신과 저장 경로까지 정상인 것은 아니기 때문이다. 평가를 위해 운영 장비에 무리하게 장애를 만들 필요는 없다. 허용된 시험 환경이나 이미 보유한 비식별 장애 기록에서, 기존 조사 방식과 새 방식이 같은 질문에 어떤 근거를 내놓는지부터 비교할 수 있다.

어떤 팀이 먼저 검토할 만한가

여러 랙의 GPU와 네트워크를 별도 팀이 맡고, 작업이 느려질 때마다 장비 목록과 시각을 수작업으로 맞춘다면 Minerva의 접근을 검토할 이유가 있다. 유리한 조건은 수집량 자체보다 작업 식별자·배치 정보·장비 관계를 실제로 연결할 수 있는가다. 반대로 외부 모델 API만 호출하는 팀은 공급자 내부의 장비 정보를 받지 못하므로 애플리케이션 trace부터 살펴보는 편이 현실적이다.

단일 GPU 작업이 느린 경우에도 모델·입력·메모리 병목부터 확인하는 편이 빠를 수 있다. 수집 누락이 심한 클러스터라면 상관 분석의 채택보다 데이터 경로 복구가 먼저다. 다음 양식은 특정 제품 설정 파일이 아닌, 도입 범위를 한 작업군으로 제한하는 인수 기록이다.

대상 작업과 버전 / 정상 진행의 기준:
연결할 작업 ID·노드·인터페이스 / 관계의 유효 시각:
수집 주기·마지막 관측·누락 표시 / 필요한 보관 기간:
사건을 묶는 기준 / 별개로 남겨야 할 대조 사건:
원인 후보를 지지하는 증거 / 반박하거나 부족한 증거:
조치 담당·범위 / 조치 후 확인할 작업 진도와 품질:
배포판·인증·데이터 접근 조건 / 운영·지원 비용:
채택 기준 / 기존 방식으로 돌아갈 조건:

핵심 산출물은 “AI가 원인을 말했다”는 한 문장보다, 어느 작업과 어느 장비를 어떤 시점의 근거로 연결했는지 설명하는 기록이다. 그 기록이 담당자를 바꾸어도 이어지고 실제 작업 회복과 맞아야 도입 가치가 드러난다.

작업의 배치·할당 문제가 먼저라면 Run:ai의 GPU 공유와 배치 분석을, 모델 API를 포함한 서비스 응답이 느리다면 OpenTelemetry로 지연을 나누는 방법을 이어 읽을 수 있다. 이 인수 양식을 다시 쓸 때는 글 위의 저장 기능을 이용하고, 후속 분석은 인프라 주제 모음과 RSS에서 확인할 수 있다.