Split View: GPU Software Engineer 합격 가이드: CUDA 아키텍처부터 vGPU/MIG, InfiniBand, K8s GPU 스케줄링까지 시스템 최적화 완전 정복

SM (Streaming Multiprocessor)
├── CUDA Cores (INT32 + FP32)
│   └── H100: SM당 128개 FP32 코어
├── Tensor Cores
│   └── H100: SM당 4세대 Tensor Core (FP8 지원)
├── RT Cores (Ray Tracing, 데이터센터에선 미사용)
├── Warp Scheduler (4개)
│   └── 각 스케줄러가 독립적으로 warp 디스패치
├── Register File (256KB per SM in H100)
├── Shared Memory / L1 Cache (통합, 최대 228KB)
├── Load/Store Units
├── Special Function Units (SFU)
│   └── sin, cos, exp 등 초월함수 계산
└── Texture Units

Grid (전체 작업)
├── Block 0
│   ├── Warp 0  (Thread 0~31)   → 같은 명령어 동시 실행
│   ├── Warp 1  (Thread 32~63)  → 같은 명령어 동시 실행
│   └── Warp N  ...
├── Block 1
│   ├── Warp 0
│   └── ...
└── Block M

// 나쁜 예: Warp Divergence 발생
__global__ void kernel(float* data, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx % 2 == 0) {
        data[idx] = expensive_operation_A(data[idx]);
    } else {
        data[idx] = expensive_operation_B(data[idx]);
    }
    // Warp 내 짝수/홀수 스레드가 다른 분기 → 순차 실행
}

// 좋은 예: 같은 Warp 내 스레드가 같은 분기를 타도록 설계
__global__ void kernel_optimized(float* data, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    int warp_id = idx / 32;
    if (warp_id % 2 == 0) {
        data[idx] = expensive_operation_A(data[idx]);
    } else {
        data[idx] = expensive_operation_B(data[idx]);
    }
    // 같은 Warp의 모든 스레드가 같은 분기
}

NVLink 토폴로지 (DGX H100 기준):
GPU 0 ←── NVLink 4.0 (900GB/s) ──→ GPU 1
  │                                    │
  NVSwitch (완전 연결)               NVSwitch
  │                                    │
GPU 2 ←── NVLink 4.0 (900GB/s) ──→ GPU 3
  │                                    │
  ...           8-GPU 완전 연결         ...
GPU 6 ←── NVLink 4.0 (900GB/s) ──→ GPU 7

총 대역폭: 8 GPU x 900GB/s = 7.2TB/s (양방향)

메모리 계층 (빠름 → 느림):

1. Register (가장 빠름)
   ├── 용량: 스레드당 최대 255개 (32비트)
   ├── 지연: ~1 cycle
   ├── 대역폭: 무한 (ALU에 직접 연결)
   └── 특징: 컴파일러가 자동 할당, 초과 시 local memory로 spill

2. Shared Memory
   ├── 용량: SM당 48KB ~ 228KB (설정 가능)
   ├── 지연: ~5 cycles (register 대비 ~5x 느림)
   ├── 대역폭: ~19TB/s (H100 기준)
   ├── 특징: 같은 Block 내 스레드 간 공유
   └── 주의: Bank Conflict 발생 가능

3. L1 Cache
   ├── Shared Memory와 통합 (설정으로 비율 조절)
   ├── H100: Shared Memory + L1 = 228KB per SM
   └── 자동 캐시, 프로그래머가 직접 제어하지 않음

4. L2 Cache
   ├── 용량: H100 = 50MB (전체 SM 공유)
   ├── 지연: ~200 cycles
   └── A100: 40MB, Blackwell: 최대 128MB

5. Global Memory (HBM)
   ├── 용량: 40GB ~ 192GB
   ├── 지연: ~600 cycles (register 대비 ~600x 느림)
   ├── 대역폭: 2.0 ~ 8.0 TB/s (세대별)
   └── 모든 스레드에서 접근 가능

Arithmetic Intensity (산술 강도) = FLOPs / Bytes Accessed

H100 기준:
- Peak Compute: 989 TFLOPS (FP16 Tensor)
- Peak Memory BW: 3.35 TB/s

균형점 (Roofline 분석):
  989 TFLOPS / 3.35 TB/s = 295 FLOPs/Byte

→ 산술 강도가 295보다 낮으면 Memory-Bound
→ 산술 강도가 295보다 높으면 Compute-Bound

실제 예시:
- 벡터 덧셈: 1 FLOP / 12 Bytes = 0.08 → 극도로 Memory-Bound
- 행렬 곱셈 (NxN): 2N FLOPs / 8 Bytes ≈ O(N) → N이 크면 Compute-Bound
- Transformer Attention: 보통 Memory-Bound (특히 추론 시)

// 좋은 예: Coalesced Access (연속 접근)
// Thread 0 → data[0], Thread 1 → data[1], ..., Thread 31 → data[31]
__global__ void coalesced(float* data) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    float val = data[idx];  // 128-byte 트랜잭션 1개
}

// 나쁜 예: Strided Access (비연속 접근)
// Thread 0 → data[0], Thread 1 → data[32], ..., Thread 31 → data[31*32]
__global__ void strided(float* data, int stride) {
    int idx = (blockIdx.x * blockDim.x + threadIdx.x) * stride;
    float val = data[idx];  // 32개의 개별 트랜잭션!
}

Shared Memory 뱅크 구조 (4바이트 단위):
Bank 0: addr 0, 128, 256, ...
Bank 1: addr 4, 132, 260, ...
Bank 2: addr 8, 136, 264, ...
...
Bank 31: addr 124, 252, 380, ...

Bank Conflict 예시:
Thread 0 → Bank 0 (addr 0)
Thread 1 → Bank 0 (addr 128)  ← 같은 뱅크! 충돌
→ 2-way bank conflict: 2배 느려짐

회피 방법: 패딩 추가
__shared__ float tile[32][33];  // 33으로 패딩 (32 대신)
// 열 접근 시 Bank Conflict 회피

CUDA 실행 모델:

Grid (1개)
├── Block (0,0)  ──  Block (1,0)  ──  Block (2,0)
├── Block (0,1)  ──  Block (1,1)  ──  Block (2,1)
└── Block (0,2)  ──  Block (1,2)  ──  Block (2,2)

각 Block:
├── Thread (0,0) ... Thread (15,0)
├── Thread (0,1) ... Thread (15,1)
└── Thread (0,15) ... Thread (15,15)

제약:
- Block당 최대 1024 스레드
- Block 차원: 최대 (1024, 1024, 64)
- Grid 차원: 최대 (2^31-1, 65535, 65535)

#include <stdio.h>
#include <cuda_runtime.h>

// GPU 커널 함수
__global__ void vectorAdd(const float* A, const float* B, float* C, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx < n) {
        C[idx] = A[idx] + B[idx];
    }
}

int main() {
    int n = 1 << 20;  // 1M 원소
    size_t size = n * sizeof(float);

    // 호스트 메모리 할당
    float *h_A = (float*)malloc(size);
    float *h_B = (float*)malloc(size);
    float *h_C = (float*)malloc(size);

    // 초기화
    for (int i = 0; i < n; i++) {
        h_A[i] = 1.0f;
        h_B[i] = 2.0f;
    }

    // 디바이스 메모리 할당
    float *d_A, *d_B, *d_C;
    cudaMalloc(&d_A, size);
    cudaMalloc(&d_B, size);
    cudaMalloc(&d_C, size);

    // 호스트 → 디바이스 복사
    cudaMemcpy(d_A, h_A, size, cudaMemcpyHostToDevice);
    cudaMemcpy(d_B, h_B, size, cudaMemcpyHostToDevice);

    // 커널 실행
    int blockSize = 256;
    int gridSize = (n + blockSize - 1) / blockSize;
    vectorAdd<<<gridSize, blockSize>>>(d_A, d_B, d_C, n);

    // 디바이스 → 호스트 복사
    cudaMemcpy(h_C, d_C, size, cudaMemcpyDeviceToHost);

    // 검증
    printf("C[0] = %f (expected 3.0)\n", h_C[0]);

    // 메모리 해제
    cudaFree(d_A); cudaFree(d_B); cudaFree(d_C);
    free(h_A); free(h_B); free(h_C);
    return 0;
}

#define TILE_SIZE 32

__global__ void matMul(const float* A, const float* B, float* C, int N) {
    __shared__ float tileA[TILE_SIZE][TILE_SIZE];
    __shared__ float tileB[TILE_SIZE][TILE_SIZE];

    int row = blockIdx.y * TILE_SIZE + threadIdx.y;
    int col = blockIdx.x * TILE_SIZE + threadIdx.x;
    float sum = 0.0f;

    for (int t = 0; t < (N + TILE_SIZE - 1) / TILE_SIZE; t++) {
        // Global Memory → Shared Memory 로드
        if (row < N && t * TILE_SIZE + threadIdx.x < N)
            tileA[threadIdx.y][threadIdx.x] = A[row * N + t * TILE_SIZE + threadIdx.x];
        else
            tileA[threadIdx.y][threadIdx.x] = 0.0f;

        if (col < N && t * TILE_SIZE + threadIdx.y < N)
            tileB[threadIdx.y][threadIdx.x] = B[(t * TILE_SIZE + threadIdx.y) * N + col];
        else
            tileB[threadIdx.y][threadIdx.x] = 0.0f;

        __syncthreads();  // Block 내 모든 스레드 동기화

        for (int k = 0; k < TILE_SIZE; k++)
            sum += tileA[threadIdx.y][k] * tileB[k][threadIdx.x];

        __syncthreads();
    }

    if (row < N && col < N)
        C[row * N + col] = sum;
}

# 기본 상태 확인
nvidia-smi

# 1초 간격 모니터링
nvidia-smi dmon -s pucvmet -d 1

# GPU 프로세스 상세 정보
nvidia-smi pmon -d 1

# 쿼리 포맷 (스크립트에서 활용)
nvidia-smi --query-gpu=timestamp,gpu_bus_id,utilization.gpu,utilization.memory,memory.used,memory.total,temperature.gpu,power.draw --format=csv -l 1

# MIG 상태 확인
nvidia-smi mig -lgi
nvidia-smi mig -lci

# GPU 토폴로지 확인 (NVLink 연결 상태)
nvidia-smi topo -m

# ECC 에러 확인
nvidia-smi --query-gpu=ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total --format=csv

# 전체 애플리케이션 프로파일링
nsys profile --stats=true -o report python train.py

# CUDA API 호출 + GPU 커널 + 메모리 전송 추적
nsys profile --trace=cuda,nvtx,osrt -o detailed_report python train.py

# 결과 시각화 (GUI)
nsys-ui report.nsys-rep

# 특정 커널 상세 분석
ncu --target-processes all --set full -o kernel_report python train.py

# 특정 커널만 프로파일링
ncu --kernel-name "volta_sgemm" --launch-count 10 -o sgemm_report ./my_app

# 주요 메트릭 확인
ncu --metrics sm__throughput.avg.pct_of_peak_sustained_active,dram__throughput.avg.pct_of_peak_sustained_active ./my_app

# DCGM 시작
sudo systemctl start nvidia-dcgm

# 헬스 체크
dcgmi health -g 0 -c

# 진단 실행 (Level 3: 가장 상세)
dcgmi diag -r 3 -g 0

# 메트릭 수집 (Prometheus 연동)
dcgm-exporter &
# http://localhost:9400/metrics 로 Prometheus가 수집

GPU Utilization 낮음 (<50%)
├── CPU 병목?
│   ├── 데이터 로딩이 느림 → num_workers 증가, prefetch
│   ├── 전처리가 무거움 → DALI (GPU 전처리) 사용
│   └── Python GIL → 멀티프로세싱
├── 메모리 전송 병목?
│   ├── PCIe 대역폭 포화 → GPU Direct 활용
│   └── 불필요한 CPU-GPU 복사 → 고정 메모리(pinned memory) 사용
├── 작은 커널 + 큰 오버헤드?
│   ├── 커널 런치 오버헤드 → CUDA Graph 사용
│   └── 동기화 과다 → 비동기 실행 최적화
├── 배치 크기가 작음?
│   └── GPU를 충분히 채우지 못함 → 배치 증가 또는 Gradient Accumulation
└── 통신 오버헤드? (분산 학습)
    ├── AllReduce 시간이 김 → NCCL 튜닝
    └── 네트워크 병목 → InfiniBand 확인

Type 1 (Bare-metal):           Type 2 (Hosted):
┌─────────────────┐            ┌─────────────────┐
│   VM1    VM2    │            │   VM1    VM2    │
│ ┌─────┐┌─────┐ │            │ ┌─────┐┌─────┐ │
│ │Guest││Guest│ │            │ │Guest││Guest│ │
│ │ OS  ││ OS  │ │            │ │ OS  ││ OS  │ │
│ └─────┘└─────┘ │            │ └─────┘└─────┘ │
│  Hypervisor     │            │  Hypervisor     │
│  (ESXi, KVM)   │            │  (VirtualBox)   │
│  Hardware       │            │  Host OS        │
└─────────────────┘            │  Hardware       │
                               └─────────────────┘

IOMMU 없이 (안전하지 않음):
VM → (가상 주소) → 물리 메모리 (직접 접근 → 다른 VM 메모리 침범 가능)

IOMMU 있을 때 (안전):
VM → (가상 주소) → IOMMU 변환 → (물리 주소, 격리됨)
                     └── DMA 요청도 격리!

# IOMMU 그룹 확인
find /sys/kernel/iommu_groups/ -type l

# 커널 부팅 파라미터 확인
cat /proc/cmdline | grep iommu
# intel_iommu=on 또는 amd_iommu=on 이어야 함

# IOMMU 그룹별 디바이스 확인
for g in /sys/kernel/iommu_groups/*/devices/*; do
    echo "IOMMU Group $(basename $(dirname $(dirname $g))):"
    lspci -nns $(basename $g)
done

PCI Passthrough 아키텍처:

Host (Linux + KVM)
├── GPU 0 → VFIO 드라이버 바인딩 → VM1 (직접 접근)
├── GPU 1 → VFIO 드라이버 바인딩 → VM2 (직접 접근)
├── GPU 2 → NVIDIA 드라이버 → Host 사용
└── GPU 3 → NVIDIA 드라이버 → Host 사용

# 1. IOMMU 활성화 (GRUB)
# /etc/default/grub 에 추가:
# GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt"

# 2. GPU의 PCI ID 확인
lspci -nn | grep NVIDIA
# 41:00.0 3D controller [0302]: NVIDIA Corporation A100 [10de:20b2]

# 3. VFIO 드라이버에 바인딩
echo "10de 20b2" > /sys/bus/pci/drivers/vfio-pci/new_id
echo "0000:41:00.0" > /sys/bus/pci/devices/0000:41:00.0/driver/unbind
echo "0000:41:00.0" > /sys/bus/pci/drivers/vfio-pci/bind

# 4. QEMU/KVM에서 VM 시작 시 디바이스 추가
# -device vfio-pci,host=41:00.0

vGPU 아키텍처:

Physical GPU (A100-80GB)
├── vGPU Instance 1 (A100-4C, 4GB) → VM1
├── vGPU Instance 2 (A100-4C, 4GB) → VM2
├── vGPU Instance 3 (A100-8C, 8GB) → VM3
└── ... (남은 용량만큼 추가 가능)

시간 분할:
t=0ms  [VM1 실행] → t=16ms [VM2 실행] → t=32ms [VM3 실행] → ...

# vGPU 스케줄러 유형
Equal Share:
  - 모든 vGPU에 동일 시간 할당
  - 공정하지만 우선순위 설정 불가

Fixed Share:
  - vGPU 프로필 크기에 비례하여 시간 할당
  - 4GB vGPU: 8GB vGPU = 1:2 시간

Best Effort:
  - 유휴 vGPU의 시간을 활성 vGPU에 재분배
  - 가장 효율적이지만 성능 예측이 어려움

MIG 아키텍처 (A100-80GB):

전체 GPU: 108 SM, 80GB HBM2e
├── MIG Instance 1 (7g.80gb): 98 SM, 80GB  ← 거의 전체 (단독 사용)
또는
├── MIG Instance 1 (4g.40gb): 56 SM, 40GB
├── MIG Instance 2 (3g.40gb): 42 SM, 40GB
또는
├── MIG Instance 1 (3g.40gb): 42 SM, 40GB
├── MIG Instance 2 (2g.20gb): 28 SM, 20GB
├── MIG Instance 3 (1g.10gb): 14 SM, 10GB
├── MIG Instance 4 (1g.10gb): 14 SM, 10GB
또는 (최대 분할)
├── MIG Instance 1~7 (1g.10gb): 각 14 SM, 각 10GB (x7)

# MIG 활성화
sudo nvidia-smi -i 0 -mig 1

# 사용 가능한 MIG 프로필 확인
nvidia-smi mig -lgip

# GPU Instance 생성
sudo nvidia-smi mig -i 0 -cgi 9,14,14,14  # 3g.40gb + 1g.10gb x3

# Compute Instance 생성
sudo nvidia-smi mig -i 0 -cci

# 현재 MIG 상태 확인
nvidia-smi mig -lgi
nvidia-smi mig -lci

# MIG 인스턴스 삭제
sudo nvidia-smi mig -i 0 -dci
sudo nvidia-smi mig -i 0 -dgi

# MIG 비활성화
sudo nvidia-smi -i 0 -mig 0

# MIG 설정 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: mig-parted-config
  namespace: gpu-operator
data:
  config.yaml: |
    version: v1
    mig-configs:
      all-1g.10gb:
        - device-filter: ["0x20B210DE"]
          devices: all
          mig-enabled: true
          mig-devices:
            "1g.10gb": 7
      mixed-config:
        - device-filter: ["0x20B210DE"]
          devices: all
          mig-enabled: true
          mig-devices:
            "3g.40gb": 1
            "1g.10gb": 4

SR-IOV 구조:

Physical NIC (ConnectX-7)
├── PF (Physical Function): 호스트 드라이버 관리
├── VF 0 (Virtual Function) → VM1 (직접 할당, 네이티브 성능)
├── VF 1 → VM2
├── VF 2 → VM3
└── ... (최대 128개 VF)

장점:
- 가상 브릿지 없이 VM이 NIC에 직접 접근
- 네이티브에 가까운 네트워크 성능
- CPU 오버헤드 최소화

GPU Direct RDMA 조합:
VM 내 GPU ←→ VF(SR-IOV NIC) ←→ InfiniBand ←→ 원격 GPU
   (PCIe 직접)  (SR-IOV 바이패스)  (RDMA)

# KubeVirt VM에 GPU PCI Passthrough
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: gpu-vm
spec:
  running: true
  template:
    spec:
      domain:
        devices:
          hostDevices:
            - name: gpu
              deviceName: nvidia.com/A100
        resources:
          requests:
            memory: '32Gi'
            cpu: '8'
      volumes:
        - name: rootdisk
          containerDisk:
            image: quay.io/containerdisks/ubuntu:22.04

# KubeVirt VM에 vGPU 할당
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vgpu-vm
spec:
  template:
    spec:
      domain:
        devices:
          gpus:
            - name: vgpu
              deviceName: nvidia.com/NVIDIA_A100-4C
        resources:
          requests:
            memory: '16Gi'

InfiniBand 속도 진화:
SDR  (2001):   10 Gbps
DDR  (2005):   20 Gbps
QDR  (2008):   40 Gbps
FDR  (2011):  56 Gbps
EDR  (2014): 100 Gbps
HDR  (2018): 200 Gbps
NDR  (2022): 400 Gbps
XDR  (2024): 800 Gbps
GDR  (2026): 1.6 Tbps (예정)

InfiniBand 패브릭 구조:

Leaf Switch (ToR)
├── HCA (Host Channel Adapter) ─ Server 1 [GPU 0~7]
├── HCA ─ Server 2 [GPU 0~7]
├── HCA ─ Server 3 [GPU 0~7]
└── HCA ─ Server 4 [GPU 0~7]

Spine Switch
├── Leaf Switch 1
├── Leaf Switch 2
├── Leaf Switch 3
└── Leaf Switch 4

관리 요소:
- Subnet Manager (OpenSM): LID 할당, 라우팅 테이블 관리
- LID (Local ID): 서브넷 내 주소 (16비트)
- GID (Global ID): 글로벌 주소 (128비트, IPv6 유사)
- GUID (Globally Unique ID): 하드웨어 고유 식별자

TCP/IP 전송 (기존):
App → Socket API → TCP/IP Stack (커널) → NIC Driver → NIC → 네트워크
                   ↑ CPU 개입 (복사, 체크섬, 세그먼테이션)

RDMA 전송:
App → RDMA Verbs → NIC (직접) → 네트워크
       ↑ Zero-copy, CPU 바이패스

// ibverbs 기반 RDMA Write 예시 (단순화)
#include <infiniband/verbs.h>

// 1. 디바이스 열기
struct ibv_context *ctx = ibv_open_device(dev);

// 2. Protection Domain 생성
struct ibv_pd *pd = ibv_alloc_pd(ctx);

// 3. 메모리 등록 (NIC가 직접 접근할 수 있도록)
struct ibv_mr *mr = ibv_reg_mr(pd, buf, size,
    IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE);

// 4. Queue Pair 생성
struct ibv_qp *qp = ibv_create_qp(pd, &qp_init_attr);

// 5. RDMA Write (원격 메모리에 직접 쓰기)
struct ibv_send_wr wr;
wr.opcode = IBV_WR_RDMA_WRITE;
wr.wr.rdma.remote_addr = remote_addr;
wr.wr.rdma.rkey = remote_key;
ibv_post_send(qp, &wr, &bad_wr);

일반 경로 (GPU Direct 없이):
GPU0 → PCIe → Host Memory → NIC → 네트워크 → NIC → Host Memory → PCIe → GPU1
       (복사1)              (복사2)         (복사3)              (복사4)

GPU Direct RDMA:
GPU0 → PCIe → NIC → 네트워크 → NIC → PCIe → GPU1
       (직접)                        (직접)
CPU 바이패스, 복사 횟수 2배 감소

일반 스토리지 접근:
NVMe → Host Memory (bounce buffer) → GPU Memory
       CPU 개입, 2번 복사

GPU Direct Storage:
NVMe → GPU Memory (직접)
       CPU 바이패스, 1번 복사

사용 사례: 대규모 데이터셋 로딩 (체크포인트 복구, 데이터 전처리)

# NCCL 환경 변수 설정 (분산 학습)
export NCCL_IB_HCA=mlx5_0,mlx5_1  # InfiniBand HCA 지정
export NCCL_IB_GID_INDEX=3         # RoCE v2 GID 인덱스
export NCCL_SOCKET_IFNAME=eth0     # 제어 채널 인터페이스
export NCCL_DEBUG=INFO             # 디버그 로깅

# NCCL 토폴로지 파일 (GPU-NIC 매핑 최적화)
export NCCL_TOPO_FILE=/path/to/topo.xml

# NCCL AllReduce 벤치마크
/usr/local/nccl-tests/build/all_reduce_perf -b 8 -e 1G -f 2 -g 8

# 대역폭 테스트
# 서버: ib_write_bw --size=65536
# 클라이언트: ib_write_bw --size=65536 <server_ip>

# 레이턴시 테스트
# 서버: ib_write_lat
# 클라이언트: ib_write_lat <server_ip>

# 결과 예시 (NDR 400Gbps):
# Bandwidth: ~48 GB/s (이론 50 GB/s)
# Latency: ~0.6 us

# Mellanox NIC PFC 설정
mlnx_qos -i eth0 --pfc 0,0,0,1,0,0,0,0
# Priority 3에만 PFC 활성화 (RoCE 트래픽)

# DSCP → Priority 매핑
mlnx_qos -i eth0 --trust dscp

대규모 InfiniBand 패브릭에서 ECMP:

Server A ─── Leaf 1 ─┬─ Spine 1 ─┬─ Leaf 3 ─── Server C
                      ├─ Spine 2 ─┤
                      ├─ Spine 3 ─┤
                      └─ Spine 4 ─┘

→ 4개의 동일 비용 경로를 로드 밸런싱
→ 해시 기반 (소스/목적지 LID) 분산
→ Adaptive Routing (AR): 혼잡 상태에 따라 동적 경로 변경

GPU Operator 컴포넌트:

GPU Operator
├── NVIDIA Driver (DaemonSet)
│   └── 커널 모듈 자동 빌드/설치
├── NVIDIA Container Toolkit
│   └── 컨테이너 런타임에 GPU 지원 추가
├── NVIDIA Device Plugin
│   └── K8s에 GPU 리소스 등록
├── DCGM Exporter
│   └── GPU 메트릭 → Prometheus
├── MIG Manager
│   └── MIG 프로필 자동 적용
├── GPU Feature Discovery (GFD)
│   └── 노드에 GPU 라벨 자동 추가
└── NVIDIA Validator
    └── 설치 상태 검증

# Helm으로 GPU Operator 설치
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator \
  --create-namespace \
  --set driver.enabled=true \
  --set mig.strategy=mixed \
  --set dcgmExporter.enabled=true

# Pod에 GPU 할당
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
    - name: cuda-container
      image: nvcr.io/nvidia/cuda:12.3.0-runtime-ubuntu22.04
      resources:
        limits:
          nvidia.com/gpu: 2 # GPU 2장 요청
      command: ['nvidia-smi']

# GPU Time-Slicing ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        renameByDefault: false
        failRequestsGreaterThanOne: false
        resources:
          - name: nvidia.com/gpu
            replicas: 4  # 1 GPU를 4개로 분할 (시간 분할)

DGX H100 GPU 토폴로지:
GPU0 ─ NVLink ─ GPU1 (같은 NVSwitch 도메인)
GPU2 ─ NVLink ─ GPU3 (같은 NVSwitch 도메인)
GPU4 ─ NVLink ─ GPU5 (같은 NVSwitch 도메인)
GPU6 ─ NVLink ─ GPU7 (같은 NVSwitch 도메인)

GPU0 ─ PCIe ─ GPU4 (다른 도메인, PCIe 연결)

→ 4-GPU 학습 시: GPU0,1,2,3 (NVLink 연결) >> GPU0,2,4,6 (PCIe 연결)

# Topology-aware scheduling을 위한 NodeSelector
apiVersion: v1
kind: Pod
metadata:
  name: distributed-training
spec:
  nodeSelector:
    nvidia.com/gpu.product: 'NVIDIA-H100-80GB-HBM3'
    nvidia.com/gpu.count: '8'
  containers:
    - name: trainer
      resources:
        limits:
          nvidia.com/gpu: 4

# Volcano를 사용한 Gang Scheduling
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: distributed-training
spec:
  minAvailable: 4 # 최소 4개 Pod 동시 스케줄링
  schedulerName: volcano
  tasks:
    - replicas: 4
      name: worker
      template:
        spec:
          containers:
            - name: trainer
              image: training-image:latest
              resources:
                limits:
                  nvidia.com/gpu: 8 # 노드당 8 GPU

Bin-packing (자원 밀집):
Node1: [GPU0 사용, GPU1 사용, GPU2 사용, GPU3 빈]
Node2: [GPU0 빈, GPU1 빈, GPU2 빈, GPU3 빈]
→ 장점: 유휴 노드 전원 절약, 자원 효율성
→ 단점: 핫스팟 발생 가능

Spread (분산):
Node1: [GPU0 사용, GPU1 빈, GPU2 사용, GPU3 빈]
Node2: [GPU0 사용, GPU1 빈, GPU2 사용, GPU3 빈]
→ 장점: 부하 분산, 장애 격리
→ 단점: 자원 파편화

# GFD가 추가하는 노드 라벨 예시
nvidia.com/gpu.product=NVIDIA-A100-SXM4-80GB
nvidia.com/gpu.count=8
nvidia.com/gpu.memory=81920
nvidia.com/cuda.driver.major=535
nvidia.com/mig.strategy=mixed
nvidia.com/gpu.family=ampere
nvidia.com/mig-1g.10gb.count=4
nvidia.com/mig-3g.40gb.count=1

# DCGM Exporter DaemonSet (GPU Operator에 포함)
# Prometheus ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: dcgm-exporter
spec:
  selector:
    matchLabels:
      app: nvidia-dcgm-exporter
  endpoints:
    - port: metrics
      interval: 15s

# GPU 활용률
DCGM_FI_DEV_GPU_UTIL             # SM 활용률 (%)
DCGM_FI_DEV_MEM_COPY_UTIL        # 메모리 대역폭 활용률 (%)

# 메모리
DCGM_FI_DEV_FB_USED              # 사용 중인 프레임버퍼 (MB)
DCGM_FI_DEV_FB_FREE              # 여유 프레임버퍼 (MB)

# 온도/전력
DCGM_FI_DEV_GPU_TEMP             # GPU 온도 (C)
DCGM_FI_DEV_POWER_USAGE          # 전력 사용량 (W)

# 에러
DCGM_FI_DEV_XID_ERRORS           # XID 에러 코드
DCGM_FI_DEV_ECC_SBE_VOL_TOTAL    # Single-bit ECC 에러
DCGM_FI_DEV_ECC_DBE_VOL_TOTAL    # Double-bit ECC 에러

# PCIe
DCGM_FI_DEV_PCIE_TX_THROUGHPUT   # PCIe 전송 처리량
DCGM_FI_DEV_PCIE_RX_THROUGHPUT   # PCIe 수신 처리량

# Prometheus Alert Rules
groups:
  - name: gpu-alerts
    rules:
      - alert: GPUMemoryAlmostFull
        expr: DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE) > 0.95
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'GPU memory usage above 95%'

      - alert: GPUThermalThrottling
        expr: DCGM_FI_DEV_GPU_TEMP > 85
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: 'GPU temperature exceeds 85C'

      - alert: GPUXIDError
        expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: 'GPU XID error detected'

# PyTorch Automatic Mixed Precision (AMP)
import torch
from torch.cuda.amp import autocast, GradScaler

model = MyModel().cuda()
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)
scaler = GradScaler()

for data, target in dataloader:
    optimizer.zero_grad()

    # FP16으로 Forward Pass
    with autocast():
        output = model(data.cuda())
        loss = criterion(output, target.cuda())

    # Loss Scaling + Backward Pass
    scaler.scale(loss).backward()
    scaler.step(optimizer)
    scaler.update()

# DeepSpeed ZeRO Stage 3 설정
# ds_config.json
{
    "zero_optimization": {
        "stage": 3,
        "offload_optimizer": {
            "device": "cpu",
            "pin_memory": true
        },
        "offload_param": {
            "device": "cpu",
            "pin_memory": true
        },
        "overlap_comm": true,
        "contiguous_gradients": true,
        "sub_group_size": 1e9,
        "reduce_bucket_size": "auto",
        "stage3_prefetch_bucket_size": "auto",
        "stage3_param_persistence_threshold": "auto",
        "stage3_max_live_parameters": 1e9,
        "stage3_max_reuse_distance": 1e9
    },
    "bf16": {
        "enabled": true
    },
    "train_batch_size": "auto",
    "train_micro_batch_size_per_gpu": "auto"
}

ZeRO 메모리 분할:

ZeRO Stage 0 (기본):
GPU0: [Model] + [Gradient] + [Optimizer State]
GPU1: [Model] + [Gradient] + [Optimizer State]
→ 모든 GPU에 전체 복제

ZeRO Stage 1 (Optimizer 분할):
GPU0: [Model] + [Gradient] + [Optimizer 1/2]
GPU1: [Model] + [Gradient] + [Optimizer 2/2]
→ 메모리 ~1.5x 절약

ZeRO Stage 2 (+ Gradient 분할):
GPU0: [Model] + [Gradient 1/2] + [Optimizer 1/2]
GPU1: [Model] + [Gradient 2/2] + [Optimizer 2/2]
→ 메모리 ~2x 절약

ZeRO Stage 3 (+ Model 분할):
GPU0: [Model 1/2] + [Gradient 1/2] + [Optimizer 1/2]
GPU1: [Model 2/2] + [Gradient 2/2] + [Optimizer 2/2]
→ 메모리 ~N배 절약 (N = GPU 수)

Data Parallelism:
입력 데이터를 N등분하여 N개 GPU에서 동일 모델 학습
→ AllReduce로 그래디언트 동기화
→ 통신량: O(model_size)

Tensor Parallelism:
하나의 레이어(행렬)를 N등분하여 N개 GPU에 분배
→ Forward/Backward 각 레이어마다 통신 필요
→ GPU 간 고속 통신(NVLink) 필수

Pipeline Parallelism:
모델의 레이어를 N등분하여 N개 GPU에 순차 배치
→ 마이크로배치를 파이프라인으로 처리
→ 버블(유휴 시간) 최소화가 핵심

3D Parallelism (LLM 학습):
Data Parallel x Tensor Parallel x Pipeline Parallel
예: 256 GPU = 32 DP x 4 TP x 2 PP

# TensorRT를 통한 모델 최적화 (Python API)
import tensorrt as trt

logger = trt.Logger(trt.Logger.WARNING)
builder = trt.Builder(logger)
network = builder.create_network(
    1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)
)
parser = trt.OnnxParser(network, logger)

# ONNX 모델 파싱
with open("model.onnx", "rb") as f:
    parser.parse(f.read())

# 빌드 설정
config = builder.create_builder_config()
config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 << 30)  # 1GB
config.set_flag(trt.BuilderFlag.FP16)  # FP16 양자화 활성화

# 엔진 빌드
engine = builder.build_serialized_network(network, config)

Triton 아키텍처:
Client → HTTP/gRPC → Triton Server
                      ├── Model Repository
                      │   ├── model_a/ (TensorRT)
                      │   ├── model_b/ (ONNX Runtime)
                      │   └── model_c/ (Python Backend)
                      ├── Scheduler
                      │   ├── Dynamic Batching
                      │   └── Sequence Batching
                      ├── Model Ensemble
                      │   └── 전처리 → 모델 → 후처리 파이프라인
                      └── Metrics (Prometheus)

# Triton 모델 설정 (config.pbtxt)
name: "my_model"
platform: "tensorrt_plan"
max_batch_size: 64

input [
  {
    name: "input"
    data_type: TYPE_FP16
    dims: [ 3, 224, 224 ]
  }
]

output [
  {
    name: "output"
    data_type: TYPE_FP16
    dims: [ 1000 ]
  }
]

dynamic_batching {
  preferred_batch_size: [ 16, 32, 64 ]
  max_queue_delay_microseconds: 100
}

instance_group [
  {
    count: 2
    kind: KIND_GPU
    gpus: [ 0 ]
  }
]

from vllm import LLM, SamplingParams

# vLLM 서버 시작
llm = LLM(
    model="meta-llama/Llama-3-70B",
    tensor_parallel_size=4,      # 4 GPU Tensor Parallel
    gpu_memory_utilization=0.9,  # GPU 메모리 90% 사용
    max_model_len=8192,
    dtype="bfloat16",
)

# 핵심 최적화 기술:
# 1. PagedAttention: KV Cache를 페이지 단위로 관리 (메모리 효율)
# 2. Continuous Batching: 요청을 동적으로 배치에 추가/제거
# 3. Prefix Caching: 공통 프리픽스의 KV Cache 재사용

[성능 문제 진단 플로우차트]

1. nvidia-smi 확인
   ├── GPU Util < 30%
   │   ├── CPU/IO 병목 가능성 높음
   │   │   ├── top/htop 확인 → CPU 100%? → 데이터 로딩 최적화
   │   │   └── iostat 확인 → 디스크 I/O? → NVMe/GDS 사용
   │   └── 커널이 너무 작음 → CUDA Graph, 배치 증가
   ├── GPU Util > 90%, 성능 낮음
   │   ├── Memory-Bound 가능성
   │   │   ├── Nsight Compute → Memory Throughput 확인
   │   │   └── Memory Coalescing 패턴 점검
   │   └── Warp Divergence 가능성
   │       └── Nsight Compute → Warp Stall Reasons
   └── GPU Util 불규칙 (오르락내리락)
       ├── 동기화 병목 → 비동기 실행 최적화
       └── 통신 병목 (분산) → NCCL 프로파일링

2. 분산 학습 병목
   ├── NCCL AllReduce 시간 확인
   │   ├── Nsight Systems에서 NCCL 영역 확인
   │   └── 통신/연산 비율 분석
   ├── InfiniBand 대역폭 확인
   │   └── ib_write_bw 벤치마크
   └── GPU 토폴로지 확인
       └── nvidia-smi topo -m

# GPU 디바이스 정보
lspci -vv -s $(lspci | grep NVIDIA | head -1 | awk '{print $1}')

# GPU 드라이버 버전
cat /proc/driver/nvidia/version

# CUDA 버전
nvcc --version

# GPU 메모리 사용량 상세
nvidia-smi --query-gpu=memory.used,memory.free,memory.total --format=csv

# GPU 프로세스별 메모리
nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory --format=csv

# PCIe 대역폭 확인
nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.width.current --format=csv

# GPU 클럭 정보
nvidia-smi --query-gpu=clocks.current.graphics,clocks.current.memory,clocks.max.graphics,clocks.max.memory --format=csv

# dmesg에서 GPU 관련 메시지
dmesg | grep -i -E "nvidia|nvrm|gpu|xid"

# InfiniBand 상태 확인
ibstat
ibstatus
ibv_devinfo

# RDMA 디바이스 확인
rdma link show
rdma resource show

# NIC 상태
ethtool -i mlx5_core0
mlxlink -d /dev/mst/mt4125_pciconf0 -m

# 커널 모듈 상태
lsmod | grep nvidia
lsmod | grep mlx
lsmod | grep vfio

# NUMA 토폴로지 (GPU-CPU 친화도)
numactl --hardware
lstopo --of ascii
nvidia-smi topo -m

# XID 에러 모니터링
dmesg -w | grep "NVRM: Xid"

# 예시 출력:
# NVRM: Xid (PCI:0000:41:00): 79, pid=0, GPU has fallen off the bus
# NVRM: Xid (PCI:0000:41:00): 48, pid=12345, DBE (double bit error)

# GPU hang 시 리셋 시도
nvidia-smi --gpu-reset -i 0

# 드라이버 재로드 (모든 GPU 프로세스 종료 필요)
# 1. GPU 사용 프로세스 확인
fuser -v /dev/nvidia*

# 2. 프로세스 종료
kill -9 <pid>

# 3. 드라이버 언로드/로드
sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia
sudo modprobe nvidia

# 완전히 안 되면
sudo systemctl restart nvidia-persistenced

# PyTorch에서 OOM 발생 시 디버깅

# 메모리 사용량 확인
import torch
print(f"Allocated: {torch.cuda.memory_allocated()/1e9:.2f} GB")
print(f"Reserved:  {torch.cuda.memory_reserved()/1e9:.2f} GB")
print(f"Max Allocated: {torch.cuda.max_memory_allocated()/1e9:.2f} GB")

# 메모리 스냅샷 (상세 분석)
torch.cuda.memory._record_memory_history(max_entries=100000)
# ... 학습 코드 실행 ...
snapshot = torch.cuda.memory._snapshot()
torch.cuda.memory._dump_snapshot("memory_snapshot.pickle")
# https://pytorch.org/memory_viz 에서 시각화

# ECC 에러 확인
nvidia-smi --query-gpu=ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total,ecc.errors.corrected.aggregate.total,ecc.errors.uncorrected.aggregate.total --format=csv

# Retired Pages 확인
nvidia-smi --query-retired-pages=gpu_uuid,retired_pages.address,retired_pages.cause --format=csv

# RMA 판단 기준:
# - Uncorrected (Double-bit) ECC 에러가 반복 발생
# - Retired Pages가 임계치 초과 (보통 60+ pages)
# - XID 48이 여러 번 발생
# - GPU가 bus에서 분리됨 (XID 79)

# 온도 모니터링
nvidia-smi --query-gpu=temperature.gpu,temperature.memory --format=csv -l 1

# 전력 제한 확인/설정
nvidia-smi --query-gpu=power.limit,power.default_limit,power.max_limit --format=csv
sudo nvidia-smi -pl 300  # 전력 제한을 300W로 설정

# 클럭 속도 확인 (Throttling 시 감소)
nvidia-smi --query-gpu=clocks.current.graphics,clocks.max.graphics --format=csv

# Throttling 원인 확인
nvidia-smi --query-gpu=clocks_throttle_reasons.active --format=csv

프로젝트 구성:
cuda-matmul-benchmark/
├── src/
│   ├── naive_matmul.cu          # Naive 구현
│   ├── tiled_matmul.cu          # Shared Memory 타일링
│   ├── wmma_matmul.cu           # Tensor Core (WMMA API)
│   └── cublas_matmul.cu         # cuBLAS 래퍼
├── benchmark/
│   ├── run_benchmarks.sh
│   └── plot_results.py          # 결과 시각화
├── profiles/
│   ├── nsight_systems/
│   └── nsight_compute/
└── README.md

프로젝트 구성:
mig-k8s-multitenant/
├── infra/
│   ├── gpu-operator-values.yaml
│   ├── mig-config.yaml
│   └── monitoring/
│       ├── dcgm-dashboard.json    # Grafana 대시보드
│       └── alert-rules.yaml       # Prometheus 알람
├── workloads/
│   ├── inference-deployment.yaml  # MIG 1g.10gb 추론
│   ├── training-job.yaml          # MIG 3g.40gb 학습
│   └── notebook-statefulset.yaml  # MIG 2g.20gb Jupyter
├── scheduler/
│   ├── gang-scheduling.yaml       # Volcano 설정
│   └── priority-classes.yaml
└── docs/
    ├── architecture.md
    └── benchmark-results.md

프로젝트 구성:
distributed-training-profiler/
├── benchmarks/
│   ├── nccl_allreduce.sh          # NCCL 벤치마크
│   ├── ib_bandwidth.sh            # InfiniBand 대역폭
│   └── multi_node_training.py     # 실제 학습 스크립트
├── profiling/
│   ├── nsight_distributed.sh      # 분산 환경 프로파일링
│   └── nccl_debug_analysis.py     # NCCL 로그 분석
├── optimization/
│   ├── nccl_env_tuning.sh         # NCCL 환경 변수 최적화
│   └── topology_optimization.py   # GPU-NIC 토폴로지 최적화
└── results/
    ├── scaling_efficiency.png     # 스케일링 효율 그래프
    └── communication_breakdown.png # 통신 시간 분석