GPU Observability

개발자의 desktop 에서 Nsight Compute 한 번 띄우면 보이는 정보 — kernel duration, occupancy, memory throughput — 를 production cluster 에서 실시간으로 streaming 으로, workload 를 멈추지 않고, 그리고 다른 사용자의 코드에 대해서도 보고 싶다. 이 욕구가 GPU observability 의 출발점이다.

강의가 던지는 두 개의 질문은 이렇다.

1. NVIDIA 가 이미 깔아둔 telemetry stack (CUPTI, NVTX, DCGM, Nsight) 위에 무엇이 더 필요한가 — 그리고 왜 production 에서는 그것들만으로 부족한가.
2. eBPF 라는 Linux 의 검증된 사용자공간/커널 hook 메커니즘이 GPU 에 어떻게 옮겨갈 수 있는가 — driver 내부를 바꾸지 않으면서.

Yusheng 의 입장은 실용주의다. CUDA driver 의 internals 를 다 이해하지 않아도, 올바른 hook point 를 잡으면 production 에서 의미 있는 신호를 뽑을 수 있다. 그 hook point 가 어디인지, 그리고 어떤 hook 이 어떤 질문에 답하는지를 정리하는 것이 이 강의의 본론이다.

그래서 이 강의의 끝에서 손에 잡혀 있어야 하는 건 4개 layer 의 observability stack(driver hook, CUPTI activity, NVTX range, application metric)과, 각 layer 가 어떤 질문에 답하는지의 매핑이다.

대부분의 production GPU 모니터링은 세 단계로 끝난다 — nvidia-smi, DCGM, 그리고 가끔 Nsight Systems. 이 셋이 각자 어디까지 보여주고 어디서부터 보이지 않는지를 정리하면 빈 자리가 자연스럽게 드러난다.

nvidia-smi 와 DCGM 이 보여주는 것은 본질적으로 aggregate metric 이다 — GPU 전체의 SM utilization, memory utilization, power. 한 process 가 점유한 만큼 다른 process 가 비어 있는지, 어떤 kernel 이 SM 을 점유했는지는 알 수 없다. “GPU 가 80% 바쁘다” 는 사실로부터 “내 코드의 어디가 80% 를 만드는가” 까지의 거리가 production 에서 가장 흔한 빈 자리다.

또 하나의 한계 — multi-tenant 환경. cluster 안에서 다른 팀의 binary 가 도는 경우, 그 binary 에 NVTX 도 없고 CUPTI callback library 도 안 attach 돼 있다. 외부에서 그 process 를 들여다봐야 하는데, 이건 본질적으로 OS-level instrumentation 의 영역이다 — eBPF 가 CPU 쪽에서 풀던 문제와 같다.

eBPF 는 Linux 커널 안에서 안전하게 검증된 작은 프로그램을 hook point 마다 실행하게 해주는 frame. 그 추상을 GPU 로 옮기는 두 갈래가 있다 — 사용자공간 VM (bpftime) 과 driver 내부 struct_ops hook (gpu_ext).

eBPF 가 강력하다고 해서 NVTX/CUPTI 를 대체하지 않는다. 강의의 메시지는 합치는 쪽이다 — 가장 풍부한 의미론은 application 이 알고, 가장 넓은 커버리지는 eBPF 가 준다. 둘을 같은 timeline 위에 정렬해야 production 의 “왜” 가 풀린다.

# 학습 step 마다 의미 있는 region 을 찍는 표준 패턴
import nvtx
import torch

@nvtx.annotate("train.step")
def step(batch):
    with nvtx.annotate("forward"):
        loss = model(batch)
    with nvtx.annotate("backward"):
        loss.backward()
    with nvtx.annotate("optim"):
        opt.step(); opt.zero_grad()
    return loss

대규모 학습은 거의 항상 multi-GPU + multi-node. 한 노드의 GPU profile 만 봐서는 — 어느 NCCL allreduce 가 다른 rank 의 stragger 때문에 길어졌는지 결정이 안 난다. 분산 환경의 observability 는 cross-rank correlation 이 추가되는 새 차원.

강의에서 정리되는 패턴은 두 단계.

1. 각 rank 가 같은 schema 의 trace 를 emit — NVTX range, CUPTI event, eBPF event 가 모두 동일한 timestamp epoch 와 동일한 metric 이름을 쓰도록 통일.
2. 중앙에서 collective op 단위로 align — 같은 NCCL allreduce 의 시작 / 끝 marker 를 모든 rank 에서 모아 비교. 가장 늦게 도착한 rank 가 stragger.

구체적인 실현은 보통 — 각 노드에서 bpftime agent 가 돌면서 launch / NCCL ioctl / NVTX 를 수집, OpenTelemetry 또는 Prometheus 로 export, 중앙 dashboard 에서 rank 별 lane 으로 시각화. 이 stack 의 어느 부분이든 NVIDIA 가 직접 제공하지 않는다는 점이 강의의 큰 메시지 — third-party tooling 의 자리가 진짜로 비어 있다.

Yusheng 이 maintain 하는 eunomia-bpf org 안의 repo 들은 무작위가 아니라 한 stack 의 다른 layer들이다. 어떤 repo 가 어디 위치하는지를 정리하면 강의 본문이 절반은 풀린다.

이 repo 들의 관계를 한 문장으로 — “llvmbpf 가 컴파일하고, bpftime 이 사용자공간에서 실행하고, gpu_ext 가 driver 안 hook 점을 노출하고, agentsight 가 LLM 시대의 새 application”. observability stack 의 기반과 응용을 같은 author 가 한 묶음으로 깔고 있다.

stack 의 가치를 검증하는 가장 좋은 방법은 — 이 stack 이 없었다면 어떻게 풀었을까 를 물어보는 것. 두 개의 대표적 case.

네 case 의 공통점 — 코드를 수정하지 않고도 답이 나오는 자리. 이 “zero instrument” 가 production observability 의 진짜 가치다. 개발자가 손을 댈 수 있는 자리에서는 NVTX 가 가장 풍부하지만, 손이 안 닿는 자리에서는 eBPF 가 유일한 답.

eBPF stack 이 모든 것을 대체하지 않는다. 도구 별로 강점과 한계를 표로 정리해두면 어느 자리에 어떤 도구를 쓸지 결정이 빨라진다.

실전 결정의 한 가지 트릭 — “dev 에서 reproduce 가 되는가” 를 첫 분기로 쓴다. 된다면 Nsight Systems 한 번 띄우는 게 항상 최선. 안 된다면 (production-only 버그) eBPF stack 으로 넘어간다. 두 stack 을 같은 schema 로 emit 하도록 정렬해두면 dev 에서의 직관이 production 으로 이전된다.

eBPF GPU stack 은 실제 production 에 깔아보면 몇 개의 만성적 문제가 있다. 강의에서 명시되지 않았더라도 — repo 의 issue / paper limitations 에서 일관되게 언급되는 것들.

• permission — uprobe 와 kernel hook 모두 root 또는 CAP_BPF 가 필요. multi-tenant cloud 에서 항상 가능한 건 아니다.
• NVIDIA driver 버전 lock — gpu_ext 는 특정 driver 버전 (예: v575.57.08) 에 묶여 있다. driver upgrade 와 함께 fork 도 따라가야 한다.
• PTX injection 의 ABI 불안정성 — eBPF → PTX 경로는 GPU arch 별 SASS 차이를 흡수해야 한다. Hopper 와 Blackwell 의 변화가 큼.
• overhead — kernel launch 마다 추가 hook 이 박히면, launch-bound 작은 커널이 모인 학습 루프에서는 통계적 신호로도 보일 수 있다. sampling 모드 와 aggregate 모드를 분리하는 게 중요.
• closed-source kernel 모듈 — NVIDIA 가 닫힌 모듈을 쓰는 segment 에서는 gpu_ext 의 hook 점이 적용되지 않는다.

자막이 실패한 강의이지만 — 발표자의 repo 와 paper 가 stack 의 모양을 충분히 드러낸다. 다시 돌아왔을 때 빠르게 복원해야 하는 사실들.

손에 새기기 — 실습 시퀀스

1. NVTX baseline — 자기 학습 루프에 nvtx.annotate 를 forward / backward / optim 에 박고 Nsight Systems 로 한 step 의 timeline 을 본다. 의미론적 분해가 timeline 위에서 보이는지 확인.
2. CUPTI 만의 시점 — 같은 코드에 NVTX 를 빼고 CUPTI 만으로 같은 trace 를 떠본다. “어디가 mlp 인지”가 안 보인다는 사실을 직접 체감.
3. bpftime 설치 — 데스크탑 환경에서 bpftime 을 설치하고 단순한 uprobe 로 cuLaunchKernel 의 호출 횟수를 기록. CUDA app 를 수정하지 않고 신호가 나오는지 검증.
4. UVM oversubscribe 재현 — 작은 GPU 에 큰 모델을 올려 OOM 직전까지 가는 toy scenario. nvidia-smi 와 gpu_ext trace 를 동시에 보고 page fault 패턴 비교.
5. cross-rank align — 2 rank 학습에서 NCCL allreduce 의 시작/끝을 양쪽 rank 에서 모아 같은 epoch 으로 정렬. 더 늦게 도착하는 rank 가 어느 단계에 묶여 있었는지 분석.

L098 의 4-layer stack 은 다른 GPU Mode 강의들의 도구를 모두 한 timeline 위로 끌어올 수 있는 frame. 어느 강의가 어느 layer 와 매핑되는지를 묶어둔다.

자막이 실패한 강의라 노트의 많은 부분이 발표자의 repo 와 관련 paper 로부터 재구성됐다. 채워야 할 빈 자리들을 명시.

• 강의에서 직접 보여준 demo — 발표 안에서 어떤 case 를 라이브로 시연했는지가 자막 실패로 확인 안 됨. 비디오 재시청 필요. (확인 필요)
• 구체적 overhead 수치 — bpftime uprobe 가 launch-bound 학습에서 throughput 에 몇 % 영향을 주는지 — 강의에서 숫자로 제시했을 가능성 있음. (확인 필요)
• Blackwell / B200 위에서의 PTX injection 실증 — Hopper / Ampere 까지는 repo issue 에서 확인 가능, Blackwell 은 진행 중. (확인 필요)
• cross-rank dashboard 의 구체적 구성 — Prometheus exporter 인지 OpenTelemetry 인지, 또는 자체 viewer 인지. (확인 필요)
• agentsight 와의 통합 — LLM agent observability 가 GPU stack 과 어디서 만나는지 — 이 강의에서 직접 다뤘을 가능성 있음. (확인 필요)