KoreaDevKNOWLEDGE SHARING

콘텐츠 유형학습하기

AI INFRASTRUCTURE · 04 / 12

GPU 하드웨어와 호스트 준비

GPU 서버를 입고 검수하고 firmware·driver·CUDA 관계를 확인한 뒤 안전한 기준선과 rollback 절차를 만듭니다.

난이도
중급
구성
핵심 단원 3개 · 판단 활동 · 3단계 평가

NEW HIRE ONBOARDING

첫 업무를 받는 순서로 시작합니다

중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.

  1. 01

    상황을 한 문장으로 읽기

    물리 inventory, PCIe topology, driver/runtime compatibility, DCGM health, 제품별 Field Diagnostic과 대표 workload를 단계적으로 확인하고 rollback·RMA 경계를 남깁니다.

  2. 02

    오늘 맡은 일

    격리·복귀·재시험·RMA evidence package의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

  3. 03

    완료를 보여 주는 증거

    공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

  4. 04

    멈추고 선임에게 확인할 경계

    driver update 뒤 8개 GPU 중 1개가 nvidia-smi에서 사라졌습니다. 첫 대응은?

낯선 용어 먼저 풀기

NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)
CPU가 어느 memory와 PCIe 장치에 접근하는지에 따라 경로 비용이 달라지는 구조입니다.

이 과정의 운영 질문

GPU가 보인다는 사실을 어떻게 production 준비 증거로 바꿀까?

물리 inventory, PCIe topology, driver/runtime compatibility, DCGM health, 제품별 Field Diagnostic과 대표 workload를 단계적으로 확인하고 rollback·RMA 경계를 남깁니다.

CORE UNIT 1 / 3

GPU 서버 하드웨어와 인수

GPU·PCIe·NUMA·전원·냉각 상태를 입고 증거와 연결합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

sudo 진단·변경은 승인된 maintenance window와 rollback 계획 필요. NVIDIA repository mirror 또는 승인된 폐쇄망 bundle.

3처음 보는 값과 아직 실행하지 않은 시험은 어떻게 적습니까?

미확인으로 기록합니다. 교육용 예상 출력과 실제 측정값을 구분하고, 승인 없는 작업으로 빈칸을 채우지 않습니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. GPU 서버 하드웨어와 인수의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. GPU 서버 하드웨어와 인수의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. GPU 서버 하드웨어와 인수의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
GPU 서버 하드웨어와 인수 실습 환경과 안전 경계
하드웨어NVIDIA GPU host inventory fixture
소프트웨어Ubuntu 24.04·NVIDIA driver·CUDA·DCGM
필요 권한sudo 진단·변경은 승인된 maintenance window와 rollback 계획 필요
네트워크NVIDIA repository mirror 또는 승인된 폐쇄망 bundle

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Ubuntu Server 24.04 LTS · NVIDIA DCGM 4.x documentation · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장asset 인수에서 확인을 시작합니다
  2. 2장PCIe 경로의 실습 대상을 고정합니다
  3. 3장GPU topology의 출력과 의미를 구분합니다
  4. 4장health 기준의 진행과 중단을 결정합니다
  5. 5장GPU 서버 하드웨어와 인수의 복구를 재검증합니다
GPU 서버 하드웨어와 인수의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · asset 인수에서 확인을 시작합니다

다음 연결: PCIe 경로의 실습 대상을 고정합니다

  1. asset 인수에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. PCIe 경로의 실습 대상을 고정합니다

    실습 상황:: 8-GPU host fixture에서 한 GPU의 PCIe width downgrade와 NIC locality 문제를 찾아 No-Go 사유를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, GPU 누락·PCIe downgrade·Xid 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. GPU topology의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 모든 GPU identity와 실제 PCIe/NUMA 경로가 설계값으로 협상되었는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. health 기준의 진행과 중단을 결정합니다

    GPU별 UUID·PCI 주소·NUMA node·NIC 거리·link 상태와 이상 항목을 표로 제출하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. GPU 서버 하드웨어와 인수의 복구를 재검증합니다

    누락이나 downgrade가 있으면 workload 배치를 막고 kernel/BMC log를 보존합니다. 승인된 maintenance에서 한 부품 또는 slot만 변경한 뒤 전체 topology를 재수집합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

GPU 자산을 PCIe와 NUMA topology까지 인수합니다

NUMA(Non-Uniform Memory Access, 비균일 메모리 접근): CPU가 어느 memory와 PCIe 장치에 접근하는지에 따라 경로 비용이 달라지는 구조입니다.

GPU 개수만 맞아서는 충분하지 않습니다. GPU UUID·serial, PCIe generation/width, NUMA locality, NVLink/NVSwitch, PSU와 냉각 상태가 설계 topology와 일치해야 합니다.

CPU socket과 PCIe switch를 거친 경로는 GPU↔NIC·GPU↔storage traffic에 영향을 줍니다. link가 낮은 generation이나 width로 협상되면 기능은 동작하면서도 성능이 크게 떨어질 수 있습니다.

입고 증거는 carton serial이 아니라 firmware와 OS가 읽은 identity까지 연결합니다. burn-in 전후 inventory와 corrected error delta를 비교해 초기 불량을 찾습니다.

교육 사례에서 GPU와 NIC는 CPU socket 0에 연결되어 있지만 데이터 처리 thread는 socket 1에서 실행됩니다. 모든 장치가 보인다는 사실만으로 데이터 경로가 짧다고 말할 수 없습니다. GPU·NIC·CPU affinity와 PCIe link width를 먼저 기록하고 대표 부하를 같은 배치에서 비교합니다. 슬롯 이동은 지원되는 배선과 전력 구성을 확인한 정비 절차로만 수행합니다.

GPU asset identity, PCIe link generation·width, NUMA·NVLink topology, 온도·ECC·Xid 기준선 네 항목마다 사실인 것과 확인 명령, 어긋났을 때 나타나는 증상을 나란히 적은 4열 표
그림 읽는 법 왼쪽 첫 열의 배지 1부터 4까지가 입고 검사 순서이고, 각 행은 그 항목에서 사실인 것 · 확인 명령과 보이는 값 · 어긋났을 때 나타나는 증상을 나란히 놓습니다. 1행에서는 `nvidia-smi --query-gpu`가 index·uuid·serial·pci.bus_id·온도를 한 줄로 내보내 carton serial이 아니라 OS가 읽은 identity를 자산 목록에 잇는데, 8개 중 하나가 빠져도 겉모습은 같아서 이 출력에서만 드러납니다. 2행에서는 `LnkCap`과 `LnkSta`가 둘 다 `Speed 32GT/s, Width x16`이어야 통과이고, LnkSta가 낮으면 PCIe downgrade이므로 여기서 workload 배치를 멈춥니다. 3행의 `nvidia-smi topo -m`은 GPU·NIC·CPU affinity를 보여 주며, GPU와 NIC가 socket 0인데 처리 thread가 socket 1에서 돌면 모두 보여도 데이터 경로는 짧지 않습니다. 4행은 초기 불량을 찾는 자리로 BMC와 GPU 온도, ECC·Xid·retired page 기준선을 저장하고 burn-in 전후 delta를 비교합니다. GPU 누락·PCIe downgrade·Xid 중 하나라도 보이면 No-Go 사유로 적고, 맨 아래 정리 상자대로 이 실습은 읽기 전용이라 chassis를 열거나 GPU를 재장착하지 않습니다. 색을 구별하지 않아도 배지 번호와 열 제목만으로 읽을 수 있으며, 표 안의 식별자와 수치는 저자 구성 교육용 예시입니다. baseboard 사진이나 NVLink 배선도는 담지 않고 확인 순서와 판단 기준만 담습니다. 자료: Linux PCI Support Library · NVIDIA DCGM User Guide를 바탕으로 저자 구성.
왜 이런가
CPU socket과 PCIe switch를 거친 경로는 GPU↔NIC·GPU↔storage traffic에 영향을 줍니다. link가 낮은 generation이나 width로 협상되면 기능은 동작하면서도 성능이 크게 떨어질 수 있습니다.
언제 문제가 되는가
GPU 누락·PCIe downgrade·Xid 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
chassis를 열거나 GPU를 재장착하기 전에 전원 격리·방전·ESD·중량 작업 절차가 필요합니다. 이 실습은 읽기 전용입니다.
직접 확인하는 방법
chassis와 GPU UUID·serial을 자산 목록에 연결합니다. lspci의 current/max speed와 width를 비교합니다.
이 절을 정리하면GPU별 UUID·PCI 주소·NUMA node·NIC 거리·link 상태와 이상 항목을 표로 제출하면 성공입니다.

CHAPTER 1 / 5

asset 인수에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. chassis와 GPU UUID·serial을 자산 목록에 연결합니다. 2. lspci의 current/max speed와 width를 비교합니다. 3. nvidia-smi topo로 GPU·NIC·CPU affinity를 확인합니다. 4. BMC와 GPU 온도, ECC·Xid·retired page 기준선을 저장합니다.

CHAPTER 2 / 5

PCIe 경로의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
nvidia-smi --query-gpu=index,uuid,serial,pci.bus_id,temperature.gpu --format=csv
nvidia-smi topo -m
sudo lspci -s 41:00.0 -vv | grep -E 'LnkCap:|LnkSta:'

CHAPTER 3 / 5

GPU topology의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
0, GPU-..., 1650..., 00000000:41:00.0, 34
GPU0  X  NV18 ... NODE
LnkCap: Speed 32GT/s, Width x16
LnkSta: Speed 32GT/s, Width x16

CHAPTER 4 / 5

health 기준의 진행과 중단을 결정합니다

CHAPTER 5 / 5

GPU 서버 하드웨어와 인수의 복구를 재검증합니다

CONCRETE CASES

8-GPU host fixture에서 한 GPU의 PCIe width downgrade와 NIC locality 문제를 찾아 No-Go 사유를 작성합니다.

입고 증거는 carton serial이 아니라 firmware와 OS가 읽은 identity까지 연결합니다. burn-in 전후 inventory와 corrected error delta를 비교해 초기 불량을 찾습니다.

잘못된 대응과 확인할 경계

chassis를 열거나 GPU를 재장착하기 전에 전원 격리·방전·ESD·중량 작업 절차가 필요합니다. 이 실습은 읽기 전용입니다.

누락이나 downgrade가 있으면 workload 배치를 막고 kernel/BMC log를 보존합니다. 승인된 maintenance에서 한 부품 또는 slot만 변경한 뒤 전체 topology를 재수집합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 8-GPU host fixture에서 한 GPU의 PCIe width downgrade와 NIC locality 문제를 찾아 No-Go 사유를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, GPU 누락·PCIe downgrade·Xid 조건이 보이면 다음 변경으로 넘어가지 마십시오.

0, GPU-..., 1650..., 00000000:41:00.0, 34
GPU0  X  NV18 ... NODE
LnkCap: Speed 32GT/s, Width x16
LnkSta: Speed 32GT/s, Width x16

값 자체를 외우는 것이 아니라 모든 GPU identity와 실제 PCIe/NUMA 경로가 설계값으로 협상되었는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

chassis를 열거나 GPU를 재장착하기 전에 전원 격리·방전·ESD·중량 작업 절차가 필요합니다. 이 실습은 읽기 전용입니다.

KEY TERMS

이번 단원 핵심 용어

NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)
CPU가 어느 memory와 PCIe 장치에 접근하는지에 따라 경로 비용이 달라지는 구조입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

GPU 서버 하드웨어와 인수의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 2 / 3

Driver와 CUDA software stack

kernel module·driver·runtime·container 호환 경계를 설명합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

sudo 진단·변경은 승인된 maintenance window와 rollback 계획 필요. NVIDIA repository mirror 또는 승인된 폐쇄망 bundle.

3앞 단원 「GPU 서버 하드웨어와 인수」에서 어떤 증거를 남겼습니까?

GPU별 UUID·PCI 주소·NUMA node·NIC 거리·link 상태와 이상 항목을 표로 제출하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Driver와 CUDA software stack의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Driver와 CUDA software stack의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Driver와 CUDA software stack의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Driver와 CUDA software stack 실습 환경과 안전 경계
하드웨어NVIDIA GPU host inventory fixture
소프트웨어Ubuntu 24.04·NVIDIA driver·CUDA·DCGM
필요 권한sudo 진단·변경은 승인된 maintenance window와 rollback 계획 필요
네트워크NVIDIA repository mirror 또는 승인된 폐쇄망 bundle

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Ubuntu Server 24.04 LTS · NVIDIA DCGM 4.x documentation · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장kernel에서 확인을 시작합니다
  2. 2장GPU driver의 실습 대상을 고정합니다
  3. 3장CUDA runtime의 출력과 의미를 구분합니다
  4. 4장application의 진행과 중단을 결정합니다
  5. 5장Driver와 CUDA software stack의 복구를 재검증합니다
Driver와 CUDA software stack의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · kernel에서 확인을 시작합니다

다음 연결: GPU driver의 실습 대상을 고정합니다

  1. kernel에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. GPU driver의 실습 대상을 고정합니다

    실습 상황:: driver는 올라왔지만 container에서 libcuda를 찾지 못하는 fixture의 경계를 진단합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, module/library mismatch·unsupported ABI 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. CUDA runtime의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 kernel module과 user-space library가 같은 driver 계열이며 application이 library를 찾는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. application의 진행과 중단을 결정합니다

    kernel·package·module·NVML·CUDA compatibility·container library의 version matrix와 rollback artifact를 제시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Driver와 CUDA software stack의 복구를 재검증합니다

    module/library mismatch면 추가 package를 덮어쓰지 말고 배치를 중단합니다. package transaction과 이전 kernel/driver 조합으로 rollback한 뒤 reboot·inventory·대표 workload를 다시 검증합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

kernel에서 application까지 GPU software 호환을 확인합니다

Driver와 CUDA runtime: driver는 장치를 제어하고 CUDA runtime은 애플리케이션이 GPU 기능을 사용하는 software 층입니다.

kernel module과 user-space driver library, CUDA runtime/toolkit, application binary, container library는 서로 다른 층입니다. nvidia-smi가 동작해도 application이 요구하는 ABI와 GPU architecture가 맞지 않을 수 있습니다.

NVIDIA driver는 GPU를 소유하고 user-space library를 제공합니다. CUDA의 minor/forward compatibility는 조건이 있으므로 driver가 표시하는 최대 CUDA 수준을 설치된 toolkit version으로 읽으면 안 됩니다.

upgrade 전에는 kernel·driver package·module·library·container runtime의 version matrix와 rollback package를 고정합니다. reboot 전후의 상태를 별도 증거로 남깁니다.

교육 사례에서 nvidia-smi에는 CUDA 12 계열 지원 표시가 있지만 nvcc 명령은 없습니다. 이 표시는 설치된 toolkit을 직접 보고한 값이 아니므로 설치 실패라고 단정할 수 없습니다. 애플리케이션이 요구하는 runtime과 driver 호환성을 문서로 대조하고 실제 process에서 사용하는 library를 확인합니다. 개발용 compiler 필요 여부와 추론 runtime 실행 조건도 따로 판단합니다.

kernel module·driver library·CUDA runtime·application container library 네 층마다 담당하는 것과 확인 명령, 끊기면 나타나는 증상을 나란히 적은 4열 표
그림 읽는 법 왼쪽 첫 열의 배지 1부터 4까지가 확인 순서이고, 각 행은 그 층이 담당하는 것 · 읽을 명령과 보이는 값 · 끊기면 나타나는 증상을 나란히 놓습니다. 1행에서는 `uname -r`이 `6.8.0-xx-generic`을, `modinfo nvidia`가 `version: 5xx.xx.xx`를 보여 주어 kernel과 module이 같은 조합인지 확인합니다. 2행에서는 nvidia-smi의 `Driver Version`이 방금 읽은 module version과 같아야 하고 `ldconfig -p`에 `/lib/x86_64-linux-gnu/libcuda.so.1`이 보여야 user-space library까지 이어집니다. 3행이 판단이 갈리는 자리입니다 — nvidia-smi 상단의 `CUDA Version: 12.x`는 driver가 지원하는 최대 수준이지 설치된 toolkit이 아니므로 `nvcc --version`을 따로 읽습니다. 4행은 실패가 실제로 드러나는 자리로, driver는 올라왔지만 container에서 libcuda를 찾지 못하는 실습 fixture가 여기에 해당합니다. 어느 행에서든 module/library mismatch나 unsupported ABI가 보이면 맨 아래 정리 상자대로 package를 덮어쓰지 말고 rollback합니다. 색을 구별하지 않아도 배지 번호와 열 제목만으로 읽을 수 있으며, 표 안의 식별자와 수치는 저자 구성 교육용 예시입니다. 층 사이의 물리 배선이나 호출 시간 비율을 그린 그림은 아니고 확인 순서와 판단 기준만 담습니다. 자료: NVIDIA CUDA Compatibility · NVIDIA DCGM User Guide를 바탕으로 저자 구성.
왜 이런가
NVIDIA driver는 GPU를 소유하고 user-space library를 제공합니다. CUDA의 minor/forward compatibility는 조건이 있으므로 driver가 표시하는 최대 CUDA 수준을 설치된 toolkit version으로 읽으면 안 됩니다.
언제 문제가 되는가
module/library mismatch·unsupported ABI 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
nvidia-smi 상단의 CUDA Version은 설치된 nvcc version이 아닙니다. `nvcc --version`과 application dependency를 별도로 확인합니다.
직접 확인하는 방법
running kernel과 설치된 driver package revision을 기록합니다. loaded module version과 nvidia-smi driver version을 대조합니다.
이 절을 정리하면kernel·package·module·NVML·CUDA compatibility·container library의 version matrix와 rollback artifact를 제시하면 성공입니다.

CHAPTER 1 / 5

kernel에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. running kernel과 설치된 driver package revision을 기록합니다. 2. loaded module version과 nvidia-smi driver version을 대조합니다. 3. ldconfig와 container runtime이 참조하는 library 경로를 확인합니다. 4. 대표 binary가 요구하는 CUDA와 compute capability 조건을 release note에 맞춥니다.

CHAPTER 2 / 5

GPU driver의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
uname -r
modinfo nvidia | grep '^version:'
nvidia-smi
ldconfig -p | grep -E 'libcuda.so|libnvidia-ml.so'

CHAPTER 3 / 5

CUDA runtime의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
6.8.0-xx-generic
version: 5xx.xx.xx
NVIDIA-SMI ... Driver Version: 5xx.xx.xx CUDA Version: 12.x
libcuda.so.1 => /lib/x86_64-linux-gnu/libcuda.so.1

CHAPTER 4 / 5

application의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Driver와 CUDA software stack의 복구를 재검증합니다

CONCRETE CASES

driver는 올라왔지만 container에서 libcuda를 찾지 못하는 fixture의 경계를 진단합니다.

upgrade 전에는 kernel·driver package·module·library·container runtime의 version matrix와 rollback package를 고정합니다. reboot 전후의 상태를 별도 증거로 남깁니다.

잘못된 대응과 확인할 경계

nvidia-smi 상단의 CUDA Version은 설치된 nvcc version이 아닙니다. `nvcc --version`과 application dependency를 별도로 확인합니다.

module/library mismatch면 추가 package를 덮어쓰지 말고 배치를 중단합니다. package transaction과 이전 kernel/driver 조합으로 rollback한 뒤 reboot·inventory·대표 workload를 다시 검증합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: driver는 올라왔지만 container에서 libcuda를 찾지 못하는 fixture의 경계를 진단합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, module/library mismatch·unsupported ABI 조건이 보이면 다음 변경으로 넘어가지 마십시오.

6.8.0-xx-generic
version: 5xx.xx.xx
NVIDIA-SMI ... Driver Version: 5xx.xx.xx CUDA Version: 12.x
libcuda.so.1 => /lib/x86_64-linux-gnu/libcuda.so.1

값 자체를 외우는 것이 아니라 kernel module과 user-space library가 같은 driver 계열이며 application이 library를 찾는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

nvidia-smi 상단의 CUDA Version은 설치된 nvcc version이 아닙니다. nvcc --version과 application dependency를 별도로 확인합니다.

KEY TERMS

이번 단원 핵심 용어

Driver와 CUDA runtime
driver는 장치를 제어하고 CUDA runtime은 애플리케이션이 GPU 기능을 사용하는 software 층입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Driver와 CUDA software stack의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 3 / 3

GPU host 검증과 rollback

inventory·health·통신 시험으로 host를 인수하고 실패 시 되돌립니다.

난이도
중급
구성
강의 10개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

sudo 상태 변경·GPU 점유 진단은 승인된 maintenance window와 console·rollback 필요. NVIDIA repository mirror 또는 승인된 폐쇄망 bundle.

3앞 단원 「Driver와 CUDA software stack」에서 어떤 증거를 남겼습니까?

kernel·package·module·NVML·CUDA compatibility·container library의 version matrix와 rollback artifact를 제시하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. DCGM 기반 host acceptance와 제품별 Field Diagnostic의 역할·실패 경계·RMA 연결을 설명할 수 있다.
  2. 기준선·진단 출력·PASS·FAIL·RETEST·summary.json을 근거로 다음 행동을 판정할 수 있다.
  3. 격리·복귀·재시험·RMA evidence package의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
GPU host 검증과 rollback 실습 환경과 안전 경계
하드웨어NVIDIA GPU host inventory fixture
소프트웨어Ubuntu 24.04·NVIDIA driver·CUDA·DCGM·제품별 Field Diagnostic package
필요 권한sudo 상태 변경·GPU 점유 진단은 승인된 maintenance window와 console·rollback 필요
네트워크NVIDIA repository mirror 또는 승인된 폐쇄망 bundle

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Ubuntu Server 24.04 LTS · NVIDIA DCGM 4.x documentation · NVIDIA DGX Spark Field Diagnostic documentation Support page 2026-08-25 갱신 · User Guide version 미표기 · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장기준선에서 확인을 시작합니다
  2. 2장health 시험의 실습 대상을 고정합니다
  3. 3장통신 부하의 출력과 의미를 구분합니다
  4. 4장인수·복구의 진행과 중단을 결정합니다
  5. 5장GPU host 검증과 rollback의 복구를 재검증합니다
  6. 6장제품·package 승인을 먼저 고정합니다
  7. 7장격리·preflight를 통과한 뒤 실행합니다
  8. 8장제품별 명령을 실행합니다
  9. 9장PASS·FAIL·RETEST와 증거를 판독합니다
  10. 10장판정·증거에 따라 복구하거나 이관합니다
GPU host 검증과 rollback의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/10 · 기준선에서 확인을 시작합니다

다음 연결: health 시험의 실습 대상을 고정합니다

  1. 기준선에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. health 시험의 실습 대상을 고정합니다

    실습 상황:: 제공된 DCGM 진단과 NCCL 결과에서 failure domain을 분류하고 rollback 또는 hardware escalation을 선택합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 진단 실패·Xid·ECC 증가 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 통신 부하의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 모든 기대 GPU가 동일 revision에서 health 시험을 통과하고 새 치명 오류가 없는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 인수·복구의 진행과 중단을 결정합니다

    identity·진단 JSON·workload 조건·성능·error delta와 명시적 Go/No-Go를 하나의 evidence directory에 남기면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. GPU host 검증과 rollback의 복구를 재검증합니다

    실패 시 run ID directory를 보존하고 node를 scheduling에서 제외합니다. 이전 driver/image로 rollback하거나 hardware owner에게 UUID·Xid·sensor·재현 조건을 전달한 뒤 같은 plan으로 재시험합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

  6. 제품·package 승인을 먼저 고정합니다

    Field Diagnostic을 시작하기 전에 다음 증거를 같은 run ID에 묶습니다. 항목 하나라도 미확인이면 명령을 추측하지 않고 support 또는 system vendor에 확인합니다.

  7. 격리·preflight를 통과한 뒤 실행합니다

    실습 상황:: 교육용 transcript의 RETEST를 FAIL로 바꾸거나 원인을 추측하지 말고, 원본 log에서 확인할 항목·재시험 승인 순서·복귀 금지 조건·support로 넘길 증거를 판정문으로 작성합니다. 수행 지시:: 브라우저에서는 아래 명령과 교육용 transcript를 읽고 판정문을 작성합니다. 실제 장비에는 명령을 보내지 않습니다. 별도 재현은 대상 제품의 현재 공식 문서, 승인 package, console, 작업 창과 rollback을 갖춘 격리 환경에서만 수행합니다.

  8. 제품별 명령을 실행합니다

  9. PASS·FAIL·RETEST와 증거를 판독합니다

    이 transcript는 공개 문서의 결과 항목을 학습하도록 정규화한 교육용 result fixture이며 실제 장비 출력이 아닙니다. 교육용으로 정규화한 transcript에서 prerequisite path는 보이지만 도구가 RETEST banner를 냈으므로, 원인을 추측하지 않고 summary.json과 개별 test log의 Test·Virtual ID·Notes를 확인해야 한다는 점을 판정해야 합니다.

  10. 판정·증거에 따라 복구하거나 이관합니다

    실행이 중단되면 노드 격리를 유지하고 log를 회수합니다. DGX Spark 공개 절차는 중단 뒤 power cycle을 요구하므로 해당 제품에서만 그 지침을 따릅니다. RETEST 원인을 복구하거나 support 지시를 받은 뒤 재시험하고, 종료 후에는 제품별 순서로 service와 Secure Boot 설정을 복원한 다음 DCGM·대표 workload·오류 delta를 다시 확인하고 마지막에 scheduling을 엽니다. 복구 뒤에는 같은 identity와 기준선으로 DCGM·대표 workload·오류 counter를 다시 확인합니다. Field Diagnostic 한 줄만으로 복귀나 RMA를 승인하지 않습니다.

개념 해설 01

GPU host는 기준선과 부하 후 error delta로 인수합니다

Baseline(기준선): 변경 전후를 비교할 수 있도록 대상·버전·조건·상태를 함께 기록한 증거입니다.

host acceptance는 inventory, health, memory/compute 부하, GPU 간 통신과 network/storage locality를 정해진 순서로 검증합니다. stress test 한 번의 성공은 간헐 error나 복구 가능성을 보장하지 않습니다.

baseline과 시험 조건이 고정되어야 변경 전후 차이를 해석할 수 있습니다. DCGM 진단, 대표 CUDA workload, NCCL 결과와 kernel Xid·ECC counter delta를 한 run ID로 묶습니다.

진단이 실패하면 자동으로 같은 시험을 반복해 통과시키지 않습니다. 첫 실패의 log와 환경을 보존하고 hardware·driver·thermal·fabric 경계를 하나씩 좁힙니다.

교육 사례에서 첫 진단은 실패하고 재시도는 통과했습니다. 마지막 결과만 남기면 간헐 오류를 숨기게 됩니다. 첫 실패의 GPU UUID, 온도, Xid와 test 입력을 보존하고 동일 조건에서 재현 여부를 조사합니다. 통과 횟수보다 실패 원인을 설명하고 다시 발생하지 않는지 검증하는 일이 인수의 근거가 됩니다.

GPU inventory·DCGM 진단·kernel Xid·ECC·대표 workload를 기준선과 부하 뒤 값으로 비교해 Go/No-Go를 판정하는 표
그림 읽는 법 왼쪽 배지 1에서 5까지가 확인 순서입니다. 첫 열은 확인 항목과 명령, 둘째 열은 변경 전 기준선, 셋째 열은 부하·진단 뒤에 다시 읽는 값, 넷째 열은 delta와 판정입니다. 같은 run ID 안에서 같은 명령으로 두 번 읽어야 넷째 열의 비교가 성립합니다. 진단 실패·새 Xid·ECC 증가 중 하나라도 있으면 아래 No-Go 상자대로 run ID directory를 보존하고 node를 scheduling에서 제외합니다. Go 상자는 하나의 evidence directory에 무엇을 남겨야 인수인지를 적은 성공 기준입니다. 마지막 상자는 첫 진단 실패를 재시도 통과로 덮으면 간헐 오류가 숨는다는 교육 사례입니다. 이 표는 시간 비율이나 물리 배선을 그린 그림이 아니라 확인 항목과 판정 기준만 나타냅니다. 도표의 식별자·수치·상태 문자열은 저자 구성 교육용 예시입니다. 자료: NVIDIA DCGM User Guide · NVIDIA DCGM Diagnostics를 바탕으로 저자 구성.
왜 이런가
baseline과 시험 조건이 고정되어야 변경 전후 차이를 해석할 수 있습니다. DCGM 진단, 대표 CUDA workload, NCCL 결과와 kernel Xid·ECC counter delta를 한 run ID로 묶습니다.
언제 문제가 되는가
진단 실패·Xid·ECC 증가 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
DCGM diagnostic level과 workload는 GPU를 사용합니다. production job이 없는 승인된 maintenance window에서 thermal/power 한계를 확인하고 실행합니다.
직접 확인하는 방법
run ID 아래 GPU UUID와 software revision을 고정합니다. DCGM discovery와 diagnostic 결과 전체를 보존합니다.
이 절을 정리하면identity·진단 JSON·workload 조건·성능·error delta와 명시적 Go/No-Go를 하나의 evidence directory에 남기면 성공입니다.
개념 해설 02

Field Diagnostic 결과를 복귀·재시험·RMA 증거로 연결합니다

Field Diagnostic(현장 진단)은 제품별 공식 package와 절차로 GPU hardware 상태를 종합 판정하고 support 또는 RMA(Return Merchandise Authorization, 제조사 반품·교체 승인) 검토에 필요한 증거를 만드는 진단입니다. DCGM health 진단과 Field Diagnostic, 증상 triage는 서로 대체하는 같은 단계가 아닙니다.

실행 파일·매체·옵션은 지원 사건, system model과 문서 version에 묶입니다. 전용 부팅 매체를 요구하는 제품도 있고 설치 package를 사용하는 제품도 있으므로 특정 제품의 매체 절차나 공개되지 않은 level 옵션을 모든 GPU에 일반화하지 않습니다.

현재 공개된 DGX Spark 절차에서는 package와 자동 설치되는 core dependency뿐 아니라 별도 설치가 필요한 DOCA OFED, kernel-mft-dkms의 mst_pci·mst_pciconf module, ConnectX-7 도구와 Secure Boot 상태를 확인합니다. 모두 준비된 뒤 TTY mode로 전환해 제품 package의 partnerdiag --field를 실행합니다. 결과 directory에는 개별 test log, run log, output log와 summary.json이 남으며 PASS·FAIL·RETEST banner를 다음 행동과 연결합니다.

이 절의 실행 예시는 NVIDIA DGX Spark 공개 문서에 한정됩니다. 다른 GPU server나 add-in board는 system vendor가 지정한 package·매체·옵션·지원 조건을 먼저 확인하고, 문서가 없거나 대상 model이 다르면 명령을 실행하지 않은 채 미확인으로 보고합니다.

교육용 fixture에서는 승인 package와 prerequisite path를 확인했지만 실행 결과가 RETEST banner입니다. banner만 보고 원인을 만들지 않고 첫 log와 summary.json의 Test·Virtual ID·Notes를 보존한 뒤 support와 제품별 지시에 따라 재시험 조건을 확정해야 합니다.

preflight 여섯 칸의 명령과 기대 출력, 제품별 partnerdiag 실행, PASS·FAIL·RETEST banner별 다음 행동
그림 읽는 법 위에서 아래로 읽습니다. 위 여섯 칸은 실행 전에 확인하는 preflight이며 칸마다 명령과 기대 출력이 함께 적혀 있습니다. 여섯 칸 중 하나라도 충족되지 않으면 가운데 실행 상자로 내려가지 않습니다. 가운데 상자는 TTY mode 전환과 partnerdiag --field 실행, 결과 directory에 남는 log 목록입니다. 아래 세 칸은 결과 banner별 다음 행동이며 교육용 fixture의 결과는 RETEST 칸에 적힌 값입니다. RETEST를 PASS나 FAIL로 바꿔 기록하지 않고 summary.json과 개별 test log의 Test·Virtual ID·Notes를 먼저 읽습니다. 마지막 상자는 하지 않는 것과 중단·복구 순서를 정리합니다. 이 도표는 DGX Spark 공개 문서의 예시이며 다른 제품은 system vendor가 지정한 package·매체·옵션이 우선합니다. 도표의 package version·경로·상태 문자열은 저자 구성 교육용 예시입니다. 자료: NVIDIA DGX Spark Field Diagnostics User Guide · NVIDIA DGX Spark Support — Field Diagnostic Software · NVIDIA GPU Debug Guidelines를 바탕으로 저자 구성.
왜 이런가
현재 공개된 DGX Spark 절차에서는 package와 자동 설치되는 core dependency뿐 아니라 별도 설치가 필요한 DOCA OFED, `kernel-mft-dkms`의 `mst_pci`·`mst_pciconf` module, ConnectX-7 도구와 Secure Boot 상태를 확인합니다. 모두 준비된 뒤 TTY mode로 전환해 제품 package의 `partnerdiag --field`를 실행합니다. 결과 directory에는 개별 test log, run log, output log와 `summary.json`이 남으며 PASS·FAIL·RETEST banner를 다음 행동과 연결합니다.
언제 문제가 되는가
대상·package·권한 불일치 또는 유효하지 않은 결과 조건이면 결과를 유효한 hardware 판정으로 사용하지 않습니다.
초보자가 자주 하는 오해
위 명령은 현재 DGX Spark 공개 문서의 예시이며 상태를 바꾸고 GPU를 점유합니다. 브라우저 실습에서는 실행하지 않습니다. 다른 제품에 복사하거나, 임의의 level·run-on-error 옵션을 만들거나, FAIL을 얻기 위해 반복 실행하지 않습니다.
직접 확인하는 방법
system model·serial, GPU UUID·PCI address와 support 사건 번호를 같은 run ID에 고정합니다. 명령·시작/종료 시각·중단 여부와 전체 log directory·summary.json을 원본 그대로 보존합니다.
이 절을 정리하면PASS는 log를 보존하고 제품별 복원·host acceptance를 마친 뒤에만 복귀 후보로 삼습니다. FAIL은 격리를 유지한 채 identity·package·summary·test log·system 증거를 support 또는 system vendor에 넘기고 원인을 단정하지 않습니다. RETEST는 첫 결과를 보존하고 Notes와 지원 지시로 재시험 조건을 확정한 뒤 같은 승인 절차로 재시험하면 성공입니다.

CHAPTER 1 / 10

기준선에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. run ID 아래 GPU UUID와 software revision을 고정합니다. 2. DCGM discovery와 diagnostic 결과 전체를 보존합니다. 3. 대표 workload의 입력·시간·온도 조건과 성능 분포를 기록합니다. 4. 시험 전후 ECC·Xid·throttle counter delta를 비교합니다.

CHAPTER 2 / 10

health 시험의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
dcgmi discovery --list
dcgmi diag -r 2 -j
journalctl -k --since '-30 min' | grep -Ei 'NVRM|Xid'
nvidia-smi --query-gpu=uuid,ecc.errors.uncorrected.volatile.total --format=csv

CHAPTER 3 / 10

통신 부하의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
8 GPUs found.
Overall Result: Pass
# kernel log: no matching Xid entries
uuid, ecc.errors.uncorrected.volatile.total
GPU-..., 0

CHAPTER 4 / 10

인수·복구의 진행과 중단을 결정합니다

CHAPTER 5 / 10

GPU host 검증과 rollback의 복구를 재검증합니다

Field Diagnostic으로 RMA 증거 만들기

CHAPTER 6 / 10

제품·package 승인을 먼저 고정합니다

Field Diagnostic을 시작하기 전에 다음 증거를 같은 run ID에 묶습니다. 항목 하나라도 미확인이면 명령을 추측하지 않고 support 또는 system vendor에 확인합니다.

1. system model·serial, GPU UUID·PCI address와 support 사건 번호를 같은 run ID에 고정합니다. 2. 제조사가 승인한 package 이름·version·출처·hash와 대상 model 일치를 기록합니다. 3. scheduler 차단, workload·GPU process 종료, baseline, console·작업 창과 rollback 준비를 확인합니다. 4. 명령·시작/종료 시각·중단 여부와 전체 log directory·summary.json을 원본 그대로 보존합니다. 5. DCGM·kernel Xid/ECC·BMC sensor·증상 재현과 system-level 원인 점검을 Field Diagnostic 결과에 연결합니다.

CHAPTER 7 / 10

격리·preflight를 통과한 뒤 실행합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
sudo mokutil --sb-state
dpkg -l | grep -E 'dgx-spark-fieldiag|doca-ofed|kernel-mft-dkms'
which fio memtester stress-ng
which ofed_info opensm ibstat mlxlink
modinfo -F filename mst_pci
modinfo -F filename mst_pciconf
nvidia-smi --query-compute-apps=pid,process_name --format=csv,noheader
교육용 예상 출력 · 실제 측정값 아님
SecureBoot disabled
ii  dgx-spark-fieldiag  TRAINING-APPROVED-VERSION  arm64
ii  doca-ofed             TRAINING-APPROVED-VERSION  arm64
ii  kernel-mft-dkms        TRAINING-APPROVED-VERSION  all
/usr/bin/fio
/usr/bin/memtester
/usr/bin/stress-ng
/usr/bin/ofed_info
/usr/sbin/opensm
/usr/bin/ibstat
/usr/bin/mlxlink
/lib/modules/training-kernel/updates/dkms/mst_pci.ko
/lib/modules/training-kernel/updates/dkms/mst_pciconf.ko
# nvidia-smi compute applications: none

CHAPTER 8 / 10

제품별 명령을 실행합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
sudo init 3
cd /opt/nvidia/dgx-spark-fieldiag
sudo ./partnerdiag --field

CHAPTER 9 / 10

PASS·FAIL·RETEST와 증거를 판독합니다

교육용 예상 출력 · 실제 측정값 아님
FIELD_DIAGNOSTIC_BANNER=RETEST
LOG_DIRECTORY=/opt/nvidia/dgx-spark-fieldiag/dgx/logs-20260901-103000
SUMMARY=/opt/nvidia/dgx-spark-fieldiag/dgx/logs-20260901-103000/summary.json
TEST=training-test-id
VIRTUAL_ID=training-virtual-id
NOTES=retest requested; inspect the original test log

PASS:: 도구가 PASS banner로 분류한 실행 결과입니다. 첫 증상이 사라졌거나 모든 software 원인이 배제되었다는 뜻은 아니므로 복원 뒤 host acceptance가 필요합니다. FAIL:: 하나 이상의 test가 FAIL로 분류된 결과입니다. dependency·configuration·software·hardware 경계를 banner 한 줄로 단정하지 않고 노드 격리와 원본 log를 유지한 채 system 증거와 함께 support 또는 system vendor에 전달합니다. RETEST:: 도구가 RETEST banner로 분류한 결과입니다. PASS나 FAIL로 바꾸어 기록하지 않고 summary.json과 개별 test log의 Test·Virtual ID·Notes를 확인한 뒤 support와 제품별 지시에 따라 재시험합니다.

CHAPTER 10 / 10

판정·증거에 따라 복구하거나 이관합니다

CONCRETE CASES

제공된 DCGM 진단과 NCCL 결과에서 failure domain을 분류하고 rollback 또는 hardware escalation을 선택합니다.

진단이 실패하면 자동으로 같은 시험을 반복해 통과시키지 않습니다. 첫 실패의 log와 환경을 보존하고 hardware·driver·thermal·fabric 경계를 하나씩 좁힙니다.

잘못된 대응과 확인할 경계

DCGM diagnostic level과 workload는 GPU를 사용합니다. production job이 없는 승인된 maintenance window에서 thermal/power 한계를 확인하고 실행합니다. 위 명령은 현재 DGX Spark 공개 문서의 예시이며 상태를 바꾸고 GPU를 점유합니다. 브라우저 실습에서는 실행하지 않습니다. 다른 제품에 복사하거나, 임의의 level·run-on-error 옵션을 만들거나, FAIL을 얻기 위해 반복 실행하지 않습니다.

실패 시 run ID directory를 보존하고 node를 scheduling에서 제외합니다. 이전 driver/image로 rollback하거나 hardware owner에게 UUID·Xid·sensor·재현 조건을 전달한 뒤 같은 plan으로 재시험합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다. 실행이 중단되면 노드 격리를 유지하고 log를 회수합니다. DGX Spark 공개 절차는 중단 뒤 power cycle을 요구하므로 해당 제품에서만 그 지침을 따릅니다. RETEST 원인을 복구하거나 support 지시를 받은 뒤 재시험하고, 종료 후에는 제품별 순서로 service와 Secure Boot 설정을 복원한 다음 DCGM·대표 workload·오류 delta를 다시 확인하고 마지막에 scheduling을 엽니다. 복구 뒤에는 같은 identity와 기준선으로 DCGM·대표 workload·오류 counter를 다시 확인합니다. Field Diagnostic 한 줄만으로 복귀나 RMA를 승인하지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 제공된 DCGM 진단과 NCCL 결과에서 failure domain을 분류하고 rollback 또는 hardware escalation을 선택합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 진단 실패·Xid·ECC 증가 조건이 보이면 다음 변경으로 넘어가지 마십시오. 실습 상황:: 교육용 transcript의 RETEST를 FAIL로 바꾸거나 원인을 추측하지 말고, 원본 log에서 확인할 항목·재시험 승인 순서·복귀 금지 조건·support로 넘길 증거를 판정문으로 작성합니다. 수행 지시:: 브라우저에서는 아래 명령과 교육용 transcript를 읽고 판정문을 작성합니다. 실제 장비에는 명령을 보내지 않습니다. 별도 재현은 대상 제품의 현재 공식 문서, 승인 package, console, 작업 창과 rollback을 갖춘 격리 환경에서만 수행합니다.

8 GPUs found.
Overall Result: Pass
# kernel log: no matching Xid entries
uuid, ecc.errors.uncorrected.volatile.total
GPU-..., 0

값 자체를 외우는 것이 아니라 모든 기대 GPU가 동일 revision에서 health 시험을 통과하고 새 치명 오류가 없는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

SecureBoot disabled
ii  dgx-spark-fieldiag  TRAINING-APPROVED-VERSION  arm64
ii  doca-ofed             TRAINING-APPROVED-VERSION  arm64
ii  kernel-mft-dkms        TRAINING-APPROVED-VERSION  all
/usr/bin/fio
/usr/bin/memtester
/usr/bin/stress-ng
/usr/bin/ofed_info
/usr/sbin/opensm
/usr/bin/ibstat
/usr/bin/mlxlink
/lib/modules/training-kernel/updates/dkms/mst_pci.ko
/lib/modules/training-kernel/updates/dkms/mst_pciconf.ko
# nvidia-smi compute applications: none

이 출력은 공개 문서의 확인 항목을 학습하도록 정규화한 교육용 preflight fixture이며 실제 장비 출력이 아닙니다. Secure Boot가 disabled이고 승인 package·core/CX-7 binary·두 MFT module 경로가 모두 보이며 active compute application이 없어야 합니다. 하나라도 충족되지 않으면 여기서 중단하고 다음 명령을 실행하지 않습니다.

FIELD_DIAGNOSTIC_BANNER=RETEST
LOG_DIRECTORY=/opt/nvidia/dgx-spark-fieldiag/dgx/logs-20260901-103000
SUMMARY=/opt/nvidia/dgx-spark-fieldiag/dgx/logs-20260901-103000/summary.json
TEST=training-test-id
VIRTUAL_ID=training-virtual-id
NOTES=retest requested; inspect the original test log

이 transcript는 공개 문서의 결과 항목을 학습하도록 정규화한 교육용 result fixture이며 실제 장비 출력이 아닙니다. 교육용으로 정규화한 transcript에서 prerequisite path는 보이지만 도구가 RETEST banner를 냈으므로, 원인을 추측하지 않고 summary.json과 개별 test log의 Test·Virtual ID·Notes를 확인해야 한다는 점을 판정해야 합니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

DCGM diagnostic level과 workload는 GPU를 사용합니다. production job이 없는 승인된 maintenance window에서 thermal/power 한계를 확인하고 실행합니다. 위 명령은 현재 DGX Spark 공개 문서의 예시이며 상태를 바꾸고 GPU를 점유합니다. 브라우저 실습에서는 실행하지 않습니다. 다른 제품에 복사하거나, 임의의 level·run-on-error 옵션을 만들거나, FAIL을 얻기 위해 반복 실행하지 않습니다.

KEY TERMS

이번 단원 핵심 용어

Baseline(기준선)
변경 전후를 비교할 수 있도록 대상·버전·조건·상태를 함께 기록한 증거입니다.
Field Diagnostic(현장 진단)
제품별 공식 package와 절차로 hardware 상태를 종합 판정하고 support 또는 RMA 검토에 필요한 증거를 만드는 진단입니다.
RMA(Return Merchandise Authorization, 제조사 반품·교체 승인)
제조사 또는 system vendor가 진단 증거를 검토해 반품·교체를 승인하는 절차입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

격리·복귀·재시험·RMA evidence package의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

DECISION ACTIVITY

driver update 뒤 8개 GPU 중 1개가 nvidia-smi에서 사라졌습니다. 첫 대응은?

먼저 필요한 증거와 중단 기준을 적은 뒤 판단을 선택하십시오.

답 선택

THREE-LEVEL ASSESSMENT

기본 원리에서 운영 판단까지

답을 제출하면 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

기본 문제 1

nvidia-smi의 CUDA Version 표기가 뜻하는 것은?

답 선택
적용 문제 2

GPU와 NIC의 locality를 확인하는 이유는?

답 선택
종합 문제 3

Field Diagnostic 결과가 RETEST입니다. RMA 요청 전에 할 일은?

답 선택

LEARNING RECORD

본문·판단 활동·모든 해설을 확인했나요?

완료 기록은 이 브라우저에만 저장됩니다.