본문으로 건너뛰기

NVIDIA GPU 스택

2026-03-20 작성2026-07-19 수정21분 읽기

NVIDIA GPU 소프트웨어 스택은 Kubernetes 환경에서 GPU를 운영하기 위한 계층 구조로 구성됩니다.

계층역할핵심 컴포넌트
인프라 자동화GPU 드라이버, 런타임, 플러그인을 선언적으로 관리GPU Operator (ClusterPolicy CRD)
모니터링GPU 상태 수집 및 Prometheus 메트릭 노출DCGM, DCGM Exporter
파티셔닝단일 GPU를 여러 워크로드가 공유MIG, Time-Slicing
추론 최적화데이터센터 규모 LLM 서빙Dynamo, KAI Scheduler

이 문서는 각 컴포넌트의 아키텍처와 설계 판단 기준을 다룹니다. GPU 노드 프로비저닝(Karpenter), 스케일링(KEDA), 비용 최적화는 GPU 리소스 관리를 참조하세요.

GPU Operator 아키텍처​

개념​

GPU Operator는 ClusterPolicy CRD 하나로 GPU 스택 전체를 번들링하는 오케스트레이션 레이어입니다. 각 컴포넌트를 독립적으로 enable/disable할 수 있으며, 노드가 추가될 때 자동으로 GPU 환경을 구성합니다.

GPU Operator v26.3.2 (2026.06 기준)
컴포넌트버전역할
GPU Operatorv26.3.2GPU 스택 라이프사이클 관리
NVIDIA Driver580.126.20GPU 커널 드라이버
DCGMv4.5.2-1GPU 모니터링 엔진
DCGM Exporterv4.5.3-4.8.2Prometheus 메트릭 노출
Device Pluginv0.19.2K8s GPU 리소스 등록
GFDv0.19.2GPU 노드 레이블링
MIG Managerv0.14.2MIG 파티션 자동 관리
Container Toolkit (CDI)v1.19.1컨테이너 GPU 런타임

v26.3.2 주요 신기능: Kubernetes 1.36 지원, DCGM Exporter Pod 메타데이터 필드(enablePodLabels/enablePodUID), DCGM Exporter 커스텀 어노테이션, NRI Plugin CRI-O 1.34+ 지원. 참고: Blackwell GB200 NVL4 지원과 CDI-by-default는 v26.3.0에서, HPC Job Mapping은 v25.10.x에서, CDMM은 v25.3.2 시대 드라이버 레벨 기능에서 각각 도입되었습니다.

컴포넌트 구조​

각 컴포넌트의 역할:

  • Driver DaemonSet: GPU 커널 드라이버를 노드에 설치. AL2023/Bottlerocket에서는 AMI에 사전 설치되어 있으므로 enabled: false
  • Container Toolkit (CDI): 컨테이너 런타임에 GPU 디바이스를 주입. CDI(Container Device Interface) 기반으로 런타임 독립적
  • Device Plugin: nvidia.com/gpu 확장 리소스를 kubelet에 등록. kube-scheduler가 GPU Pod를 배치할 수 있게 함
  • GFD (GPU Feature Discovery): GPU 모델, 드라이버 버전, MIG 프로필 등을 노드 레이블로 노출. nodeSelector/nodeAffinity에 활용
  • NFD (Node Feature Discovery): 하드웨어 피처(CPU, PCIe, NUMA 등)를 노드 레이블로 노출
  • MIG Manager: ConfigMap 기반으로 MIG 프로필을 자동 적용. 노드 레이블 변경 시 재구성
  • DCGM Exporter: DCGM 메트릭을 Prometheus 형식으로 노출

EKS 환경별 GPU Operator 구성​

환경DriverToolkitDevice PluginMIG비고
EKS Auto Mode❌ (AWS 자동)❌ (AWS 자동)❌ (레이블로 비활성화)❌DCGM/NFD/GFD 정상 동작
Karpenter (Self-Managed)❌ (AL2023 AMI)❌ (AL2023 AMI)✅✅완전 지원
Managed Node Group❌ (AL2023 AMI)❌ (AL2023 AMI)✅✅완전 지원
Hybrid Node (온프레미스)✅ (필수)✅ (필수)✅✅GPU Operator 필수
AMI별 GPU Driver 제약
  • AL2023 / Bottlerocket: GPU 드라이버가 AMI에 사전 설치. driver와 toolkit 모두 enabled: false 필수
  • EKS Auto Mode: AWS가 드라이버를 자동 관리. Device Plugin은 노드 레이블 nvidia.com/gpu.deploy.device-plugin: "false"로 비활성화

EKS Auto Mode에서의 GPU Operator​

Auto Mode에서는 AWS가 GPU 드라이버와 Device Plugin을 관리하지만, GPU Operator 설치가 여전히 유용한 경우가 있습니다.

  • DCGM Exporter: GPU 메트릭 수집 (Auto Mode 자체는 DCGM을 제공하지 않음)
  • GFD/NFD: GPU 모델별 노드 레이블링으로 nodeSelector 활용
  • KAI Scheduler: ClusterPolicy에 의존하는 프로젝트와의 호환성
# Auto Mode NodePool — Device Plugin만 레이블로 비활성화
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-auto-mode
spec:
  template:
    metadata:
      labels:
        nvidia.com/gpu.deploy.device-plugin: "false"
    spec:
      requirements:
        - key: eks.amazonaws.com/instance-family
          operator: In
          values: ["p5", "p4d"]
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

Auto Mode용 Helm values는 Device Plugin을 전역 활성화한 채 노드 레이블로 선택 비활성화합니다.

# Auto Mode용 GPU Operator Helm values
driver:
  enabled: false          # AWS가 AMI에 사전 설치
toolkit:
  enabled: false          # AWS가 AMI에 사전 설치
devicePlugin:
  enabled: true           # 전역 활성화, 노드 레이블로 선택적 비활성화
dcgmExporter:
  enabled: true
  serviceMonitor:
    enabled: true
nfd:
  enabled: true
gfd:
  enabled: true

Karpenter 노드 전용 GPU Operator 구성​

Karpenter(Self-Managed) 노드에서는 MIG Manager까지 포함한 전체 스택을 활성화하되, nodeSelector로 Auto Mode 노드를 제외합니다.

# helm install gpu-operator nvidia/gpu-operator -f values.yaml
driver:
  enabled: false          # AL2023: AMI 사전 설치
toolkit:
  enabled: false          # AL2023: AMI 사전 설치
devicePlugin:
  enabled: true
  nodeSelector:
    gpu-operator: enabled
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
migManager:
  enabled: true
  nodeSelector:
    gpu-operator: enabled
  config:
    name: mig-parted-config
    default: "all-balanced"
dcgmExporter:
  enabled: true
  serviceMonitor:
    enabled: true
    interval: 15s
  nodeSelector:
    gpu-operator: enabled
nfd:
  enabled: true
gfd:
  enabled: true
  nodeSelector:
    gpu-operator: enabled
operator:
  nodeSelector:
    node-type: gpu-inference  # Karpenter NodePool 레이블
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  defaultRuntime: containerd

핵심 설정 포인트:

  • nodeSelector: gpu-operator: enabled — Auto Mode 노드 제외
  • driver/toolkit: false — AL2023 AMI에 사전 설치
  • migManager: true — Karpenter 노드에서 MIG 기능 활용

DCGM 모니터링​

개요​

NVIDIA DCGM(Data Center GPU Manager)은 GPU 상태를 수집하고 Prometheus로 메트릭을 노출하는 모니터링 엔진입니다. GPU Operator가 DCGM Exporter를 DaemonSet으로 자동 배포합니다.

배포 방식 선택​

항목내용
리소스 효율노드당 1개 인스턴스 — 오버헤드 최소
관리GPU Operator가 자동 관리
메트릭 범위노드의 모든 GPU 메트릭 수집
적합 환경프로덕션 환경 (대부분의 경우)

주요 GPU 메트릭​

메트릭설명활용
DCGM_FI_DEV_GPU_UTILGPU 코어 사용률 (%)HPA/KEDA 트리거
DCGM_FI_DEV_MEM_COPY_UTIL메모리 대역폭 사용률 (%)메모리 병목 감지
DCGM_FI_DEV_FB_USED / FB_FREE프레임버퍼 사용량/여유량 (MB)OOM 방지, 용량 계획
DCGM_FI_DEV_POWER_USAGE전력 사용량 (W)비용 및 열 관리
DCGM_FI_DEV_GPU_TEMPGPU 온도 (C)열 스로틀링 방지
DCGM_FI_DEV_SM_CLOCKSM 클럭 속도 (MHz)성능 모니터링

Prometheus 연동 개념​

DCGM Exporter는 :9400/metrics 엔드포인트로 Prometheus 형식의 메트릭을 노출합니다. GPU Operator 설치 시 dcgmExporter.serviceMonitor.enabled=true를 설정하면 ServiceMonitor가 자동 생성됩니다.

수집 체인:

GPU Hardware → DCGM Engine → DCGM Exporter (:9400) → Prometheus → Grafana/KEDA

핵심 설계 결정:

  • 수집 주기: 15초 (기본값). LLM 서빙에서는 10초로 단축 권장
  • 메트릭 필터링: /etc/dcgm-exporter/dcp-metrics-included.csv로 필요한 메트릭만 수집하여 카디널리티 제어
  • Pod-GPU 매핑: DCGM_EXPORTER_KUBERNETES=true 설정 시 pod, namespace, container 레이블이 메트릭에 추가

GPU 파티셔닝 전략​

MIG (Multi-Instance GPU)​

MIG는 Ampere/Hopper/Blackwell 아키텍처 GPU(A100, H100, H200, B200)를 최대 7개의 하드웨어적으로 독립된 GPU 인스턴스로 분할합니다. 각 MIG 인스턴스는 독립된 메모리, 캐시, SM(Streaming Multiprocessor)을 가지므로 워크로드 간 간섭 없이 안정적인 성능을 보장합니다.

MIG의 핵심 가치:

  • 하드웨어 격리: 메모리, SM, L2 캐시가 완전히 분리되어 QoS 보장
  • 동시 실행: 여러 추론 워크로드가 성능 저하 없이 동시 실행
  • GPU Operator 자동 관리: MIG Manager가 ConfigMap 기반으로 프로필 자동 적용

A100 40GB MIG 프로필:

프로필메모리SM 수용도참고 처리량
1g.5gb5GB14소형 모델 (3B 이하)~20 tok/s
1g.10gb10GB14소형 모델 (3B-7B)~25 tok/s
2g.10gb10GB28중형 모델 (7B-13B)~50 tok/s
3g.20gb20GB42중대형 모델 (13B-30B)~100 tok/s
4g.20gb20GB56대형 모델 (13B-30B)~130 tok/s
7g.40gb40GB84전체 GPU (70B+)~200 tok/s
참고 처리량 측정 조건

위 "참고 처리량" 수치는 Llama 2 계열 기준 BF16, Batch=1, Prompt 512 / Output 128 토큰, vLLM v0.22+ 구성에서의 내부 측정 예시값입니다. 실제 처리량은 모델, 양자화(FP8/INT8/AWQ), Batch 크기, 시퀀스 길이, TP/PP 구성에 따라 크게 달라지므로 배포 전 자체 벤치마크로 검증하세요.

MIG 프로필 관리:

GPU Operator의 MIG Manager는 노드 레이블(nvidia.com/mig.config)을 감시하여 MIG 프로필을 자동 적용합니다. ConfigMap에 프로필을 정의하고, 노드 레이블을 변경하면 MIG Manager가 GPU를 재구성합니다.

# MIG 프로필 ConfigMap (mig-parted 형식)
apiVersion: v1
kind: ConfigMap
metadata:
  name: default-mig-parted-config
  namespace: gpu-operator
data:
  config.yaml: |
    version: v1
    mig-configs:
      all-1g.5gb:          # 7개 소형 인스턴스
        - devices: all
          mig-enabled: true
          mig-devices:
            "1g.5gb": 7
      mixed-balanced:      # 혼합 구성
        - devices: all
          mig-enabled: true
          mig-devices:
            "3g.20gb": 1
            "2g.10gb": 1
            "1g.5gb": 2
      single-7g:           # 단일 대형
        - devices: all
          mig-enabled: true
          mig-devices:
            "7g.40gb": 1

Pod에서 MIG 디바이스를 사용할 때는 nvidia.com/mig-<profile> 리소스를 요청합니다.

resources:
  requests:
    nvidia.com/mig-1g.5gb: 1
  limits:
    nvidia.com/mig-1g.5gb: 1

Time-Slicing​

Time-Slicing은 시간 기반으로 GPU 컴퓨팅 시간을 분할하여 여러 Pod이 동일 GPU를 공유합니다. MIG와 달리 모든 NVIDIA GPU에서 사용 가능하지만, 워크로드 간 메모리 격리가 없습니다.

구성 방법:

GPU Operator의 ClusterPolicy에서 ConfigMap을 참조하여 Time-Slicing을 활성화합니다.

# Time-Slicing ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4    # 각 GPU를 4개 Pod이 공유

Pod에서는 일반 GPU 요청과 동일하게 nvidia.com/gpu: 1을 요청합니다. Time-Slicing이 활성화된 노드에서는 GPU 조각이 할당됩니다.

MIG vs Time-Slicing 비교​

항목MIGTime-Slicing
격리 수준하드웨어 격리 (메모리, SM, 캐시)소프트웨어 시분할 (격리 없음)
지원 GPUA100, H100, H200, B200모든 NVIDIA GPU
최대 분할7개 인스턴스제한 없음 (성능 저하 비례)
성능 예측보장됨 (QoS)동시 워크로드 수에 따라 변동
메모리 안전OOM이 다른 인스턴스에 영향 없음OOM이 다른 워크로드에 영향
적합 환경프로덕션 추론, 멀티 테넌트개발/테스트, 배치 추론
Time-Slicing 성능 특성
  • 컨텍스트 스위칭 오버헤드: 약 1% 수준으로 미미
  • 동시 실행 성능 저하: GPU 메모리와 컴퓨팅을 공유하므로 동시 워크로드 수에 따라 50-100% 성능 저하
  • 메모리 격리 없음: 한 워크로드의 OOM이 다른 워크로드에 영향
  • 적합: 배치 추론, 개발/테스트 환경 | 부적합: 실시간 추론(SLA), 고성능 학습

Dynamo: 데이터센터 규모 추론 최적화​

개요​

NVIDIA Dynamo는 데이터센터 규모의 LLM 추론을 최적화하는 오픈소스 프레임워크입니다. vLLM, SGLang, TensorRT-LLM을 백엔드로 지원합니다. 독립 벤치마크(SemiAnalysis InferenceX)에서 DeepSeek R1을 GB200 NVL72 + Dynamo(Disaggregated Serving + wide expert parallelism)로 서빙 시 Dynamo 미적용 B200 시스템 대비 GPU당 처리량 최대 7배를 기록했습니다(하드웨어가 다른 비교). NVIDIA 자체의 Disaggregated vs Aggregated 동일 하드웨어 비교는 1.4x~2.5x 수준입니다. Flash Indexer는 KV cache-aware 라우팅용 글로벌 인덱서(170M ops/s)로 Baseten 사례 기준 TTFT 2배 개선 효과가 보고되었습니다. NVIDIA Run:ai(2024-12-30 인수 완료)는 스케줄러 코어로 KAI Scheduler(Apache 2.0, 2025-04 오픈소스화)를 사용합니다.

Dynamo v1.2.x (2026.06 기준)
  • 서빙 모드: Aggregated + Disaggregated 동등 지원
  • 핵심 기술: Flash Indexer, NIXL, KAI Scheduler, Planner, EPP
  • 배포 방식: Kubernetes Operator + CRD (DGDR, DGD)
  • 최신 버전: v1.2.1 (2026-06-13), multimodal serving, KV routing 개선
  • 라이선스: Apache 2.0
  • 레포: ai-dynamo/dynamo

핵심 아키텍처​

Dynamo는 Aggregated Serving과 Disaggregated Serving 모두 지원합니다. Disaggregated 모드에서는 Prefill(프롬프트 처리)과 Decode(토큰 생성)를 분리하여 독립 스케일링합니다.

핵심 컴포넌트​

컴포넌트역할이점
Disaggregated ServingPrefill/Decode 워커 분리각 단계별 독립 스케일링, GPU 활용 극대화
Flash IndexerRadix tree 기반 worker별 KV cache 인덱싱Prefix 매칭 최적화, KV 재사용률 극대화
KVBMGPU → CPU → SSD 3-tier 캐시메모리 효율 극대화, 대규모 컨텍스트 지원
NIXLNVIDIA Inference Transfer LibraryGPU 간 KV Cache 초고속 전송 (NVLink/RDMA). Dynamo, llm-d, production-stack, aibrix 등이 공통 사용
PlannerSLO 기반 오토스케일링Profiling → SLO 목표 기반 자동 Prefill/Decode 스케일링
EPPEndpoint Picker ProtocolK8s Gateway API와 네이티브 통합
AIConfigurator자동 TP/PP 추천모델 크기, GPU 메모리, 네트워크 토폴로지 기반 최적 병렬화

llm-d와의 선택 가이드​

llm-d와 Dynamo는 모두 LLM 추론 라우팅/스케줄링을 담당하며, 라우팅 레이어에서 경쟁하므로 선택하여 사용합니다.

llm-d:    Client → llm-d Router → vLLM Workers
Dynamo:   Client → Dynamo Router → Prefill Workers → (NIXL) → Decode Workers
항목llm-dDynamo
아키텍처Aggregated + DisaggregatedAggregated + Disaggregated (동등 지원)
KV Cache 라우팅Prefix-awarePrefix-aware + Flash Indexer (radix tree)
KV Cache 전송NIXLNIXL (NVLink/RDMA)
Pod 스케줄링K8s 기본 스케줄러KAI Scheduler (GPU-aware)
오토스케일링HPA/KEDA 연동Planner (SLO 기반) + KEDA/HPA
백엔드vLLMvLLM, SGLang, TRT-LLM
복잡도낮음 — 기존 vLLM에 라우터 추가높음 — 전체 서빙 스택 교체
성숙도v0.5+v1.0 GA
시나리오추천
기존 vLLM에 라우팅만 추가llm-d
소규모~중규모 (GPU 8개 이하)llm-d
Gateway API 기반 K8s 네이티브llm-d
대규모 (GPU 16개+), 처리량 극대화Dynamo
긴 컨텍스트 (128K+) 워크로드Dynamo (3-tier KV cache)
빠른 도입, 낮은 운영 복잡도llm-d
마이그레이션 경로

llm-d로 시작해서 규모가 커지면 Dynamo로 전환하는 것이 현실적입니다. 둘 다 vLLM 백엔드와 NIXL KV 전송을 공유합니다. 핵심 차이는 Dynamo의 Flash Indexer, KAI Scheduler, Planner입니다. Dynamo 1.0은 llm-d를 내부 컴포넌트로 통합할 수 있어, 완전한 대안이라기보다 상위 집합으로 볼 수도 있습니다.

KAI Scheduler​

KAI Scheduler는 NVIDIA의 GPU-aware Kubernetes Pod 스케줄러입니다. 기본 kube-scheduler와 달리 GPU 토폴로지(NVLink, PCIe), MIG 슬라이스, Gang Scheduling을 인식하여 최적의 Pod 배치를 결정합니다.

핵심 기능​

기능설명
GPU Topology AwarenessNVLink/PCIe 연결 구조를 인식하여 통신 비용 최소화
MIG-aware SchedulingMIG 슬라이스를 개별 스케줄링 단위로 인식
Gang Scheduling분산 학습에서 모든 Pod가 동시에 배치되도록 보장
Fair-share Scheduling네임스페이스/팀별 GPU 할당량 관리
Preemption우선순위 기반 Pod 교체

설계 고려사항​

  • ClusterPolicy 의존: KAI Scheduler는 GPU Operator의 ClusterPolicy가 설치되어 있어야 동작합니다
  • EKS Auto Mode: GPU Operator 설치 후 Device Plugin만 레이블로 비활성화하면 KAI Scheduler 사용 가능
  • kube-scheduler와의 관계: KAI Scheduler는 kube-scheduler를 대체하지 않고, GPU 워크로드에 대해서만 스케줄링을 위임받는 Secondary Scheduler로 동작
KAI Scheduler ≠ 오토스케일링

KAI Scheduler는 Pod를 어떤 노드에 배치할지 결정하는 스케줄러입니다. Pod 수를 늘리는 오토스케일링(KEDA/HPA)이나 노드를 추가하는 프로비저닝(Karpenter)과는 별개의 역할입니다.

관련 문서​

참고 자료​