본문으로 건너뛰기

NVIDIA GPU 스택

22분 읽기
AI용 문서 안내

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까지 포함한 전체 스택을 활성화합니다. GPU Operator의 ClusterPolicy는 컴포넌트별 nodeSelector를 받지 않으므로, 특정 노드에서 operand를 선택적으로 비활성화하려면 nvidia.com/gpu.deploy.<component>: "false" 노드 레이블을 사용합니다. Auto Mode 노드에는 이미 Device Plugin 비활성화 레이블(nvidia.com/gpu.deploy.device-plugin: "false")이 적용되어 있으므로, Karpenter 노드에만 전체 스택이 배포됩니다. operand의 GPU 노드 taint 허용은 전역 daemonsets.tolerations로 지정합니다.

# helm install gpu-operator nvidia/gpu-operator -f values.yaml
driver:
  enabled: false          # AL2023: AMI 사전 설치
toolkit:
  enabled: false          # AL2023: AMI 사전 설치
devicePlugin:
  enabled: true           # 전역 활성화, 노드 레이블로 선택적 비활성화
migManager:
  enabled: true
  config:
    name: default-mig-parted-config
    default: "all-balanced"
dcgmExporter:
  enabled: true
  serviceMonitor:
    enabled: true
    interval: 15s
nfd:
  enabled: true
gfd:
  enabled: true
# operand DaemonSet의 toleration은 컴포넌트별이 아닌 전역 설정으로 지정
daemonsets:
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule

핵심 설정 포인트:

  • operand 배치 제어는 컴포넌트별 nodeSelector가 아니라 노드 레이블(nvidia.com/gpu.deploy.<component>: "false")로 수행합니다. ClusterPolicy 템플릿(v25.10.1/v26.3.2 모두)이 컴포넌트 블록의 nodeSelector 값을 렌더링하지 않기 때문입니다.
  • driver/toolkit: false — AL2023 AMI에 사전 설치
  • migManager: true — Karpenter 노드에서 MIG 기능 활용. MIG 리소스 노출 방식은 아래 "MIG Pod 요청"의 mig.strategy 설정에 따릅니다.

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프레임버퍼 사용량/여유량 (MiB)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 보장
  • 동시 실행: 여러 추론 워크로드가 서로 간섭 없이 동시 실행됩니다. 다만 인스턴스별 절대 처리량은 선택한 프로필이 할당하는 SM과 메모리에 의해 제한되므로, 작은 프로필일수록 전체 GPU 대비 처리량이 비례해 낮아집니다
  • GPU Operator 자동 관리: MIG Manager가 ConfigMap 기반으로 프로필 자동 적용

A100 40GB MIG 프로필:

프로필메모리SM 수적합 워크로드 (BF16 가중치 기준)
1g.5gb5GB14≤2B 가중치 또는 짧은 컨텍스트 소형 모델. 7B급은 INT8/FP8 양자화 필요
1g.10gb10GB14≤4B BF16, 또는 7B를 INT8/FP8로 양자화
2g.10gb10GB28≤4B BF16, 또는 7B 양자화. 1g.10gb 대비 SM 2배로 처리량 상향
3g.20gb20GB42≤7B BF16, 또는 13B 양자화
4g.20gb20GB56≤7B BF16, 또는 13B 양자화. 3g.20gb와 동일 메모리, SM만 증가
7g.40gb40GB98≤13B BF16, 또는 30B급 양자화. 전체 A100 자원
모델 적합성 산정 근거

위 "적합 워크로드"는 BF16 가중치가 약 2바이트/파라미터를 차지한다는 전제에서 가중치만의 하한을 보수적으로 추정한 값입니다(KV cache·활성값·단편화는 별도). 예를 들어 70B 모델은 BF16 가중치만 약 140GB가 필요하므로 단일 7g.40gb(40GB) 파티션에 들어가지 않으며, 70B를 단일 A100에서 서빙하려면 다중 GPU 텐서 병렬 또는 강한 양자화가 필요합니다. SM 수는 A100-SXM4-40GB의 MIG 프로필 기준(1g=14 … 7g=98, 7개 슬라이스 × 14 SM)입니다. 실제 처리량은 모델, 양자화(FP8/INT8/AWQ), Batch 크기, 시퀀스 길이, TP/PP 구성, 서빙 엔진 버전에 따라 크게 달라지므로 배포 전 대상 구성에서 자체 벤치마크로 검증하세요. 프로필 간 상대 비교는 SM 수와 메모리가 결정합니다.

MIG 프로필 관리:

GPU Operator의 MIG Manager는 노드 레이블(nvidia.com/mig.config)을 감시하여 MIG 프로필을 자동 적용합니다. ConfigMap에 프로필을 정의하고, 노드 레이블을 변경하면 MIG Manager가 GPU를 재구성합니다. 아래 ConfigMap 이름 default-mig-parted-config는 앞선 Helm values의 migManager.config.name과 일치시킵니다.

MIG 재구성은 비파괴적이지 않습니다

MIG 모드 또는 geometry를 변경하면 MIG Manager가 해당 GPU의 모든 GPU Pod를 종료한 뒤 재구성을 진행합니다(NVIDIA GPU Operator MIG 문서). 재구성 중에는 해당 노드의 GPU 워크로드가 중단되며, 일부 환경(특히 일부 CSP)에서는 노드 재부팅이 필요하므로 사전에 노드를 cordon/drain해야 합니다. 재구성은 실행 중인 사용자 워크로드가 없어야 성공하며, 전제 조건이 충족되지 않으면 nvidia.com/mig.config.state 레이블이 failed로 보고됩니다. 따라서 프로덕션에서는 유지보수 창에서 수행하고, PodDisruptionBudget과 드레이닝 절차를 함께 계획하세요.

# 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 디바이스를 사용하는 방식은 Device Plugin의 mig.strategy 설정에 따라 달라집니다. 이 값은 GPU Operator Helm values에서 mig.strategy로 지정하며, 기본값은 single입니다.

  • mig.strategy: single (차트 기본값): 노드의 모든 GPU가 동일한 단일 프로필로 분할된 경우에 사용합니다. MIG 디바이스가 일반 nvidia.com/gpu 리소스로 노출되므로 Pod는 아래처럼 요청합니다.
# mig.strategy=single — MIG 슬라이스가 nvidia.com/gpu로 노출됨
resources:
  requests:
    nvidia.com/gpu: 1
  limits:
    nvidia.com/gpu: 1
  • mig.strategy: mixed: 한 노드에 서로 다른 프로필이 공존할 때 사용합니다. 이 전략에서만 nvidia.com/mig-<profile> 형식의 프로필별 리소스가 노출되므로, 아래 요청이 유효하려면 Helm values에 mig.strategy=mixed를 설정해야 합니다(앞선 Karpenter values는 mig.strategy를 지정하지 않아 기본값 single로 동작합니다).
# mig.strategy=mixed — 프로필별 명명 리소스가 노출됨
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은 replicas 수만큼 GPU를 오버서브스크립션하여 광고 리소스 개수를 늘릴 뿐, 각 Pod에 고정된 컴퓨팅 조각이나 메모리 쿼터를 보장하지 않습니다. 공유 Pod들은 동일 GPU에서 시분할로 번갈아 실행되며, 메모리와 연산 자원을 경합합니다.

MIG vs Time-Slicing 비교​

항목MIGTime-Slicing
격리 수준하드웨어 격리 (메모리, SM, 캐시)소프트웨어 시분할 (격리 없음)
지원 GPUA100, H100, H200, B200모든 NVIDIA GPU
최대 분할7개 인스턴스replicas 설정값만큼 (하드웨어 분할 아님, 경합 증가)
성능 예측보장됨 (QoS)동시 워크로드 수에 따라 변동
메모리 안전OOM이 다른 인스턴스에 영향 없음OOM이 다른 워크로드에 영향
적합 환경 추천프로덕션 추론, 멀티 테넌트개발/테스트, 배치 추론
Time-Slicing 성능 특성
  • 스케줄링 방식: GPU 컨텍스트를 프로세스 단위로 시분할하여 번갈아 실행합니다. CUDA MPS와 달리 동시 커널 실행이 아니라 시간 분할이므로, 컨텍스트 스위칭 비용과 대기 시간이 추가됩니다.
  • 성능 변동: 처리량과 지연은 동시 실행 워크로드 수와 각 워크로드의 커널 특성에 따라 달라집니다. 오버헤드와 저하 폭은 구성에 따라 크게 달라지므로, 고정된 비율을 보장할 수 없습니다. 대상 워크로드로 직접 측정하세요.
  • 메모리 격리 없음: 메모리 쿼터가 강제되지 않아 한 워크로드의 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 (Gateway API Inference Extension)Inference Scheduler 구현체로, 메트릭 기반으로 요청을 보낼 엔드포인트를 선택. K8s Gateway API Inference Extension과 통합
AIConfigurator자동 TP/PP 추천모델 크기, GPU 메모리, 네트워크 토폴로지 기반 최적 병렬화

llm-d와의 선택 가이드​

llm-d와 Dynamo는 모두 LLM 추론 라우팅/스케줄링을 담당하며 라우팅 레이어에서 기능이 겹칩니다. 다만 서로 완전히 배타적인 선택지는 아닙니다. 둘 다 vLLM 백엔드와 NIXL KV 전송을 공유하며, Dynamo는 llm-d를 내부 컴포넌트로 통합할 수 있어(아래 "마이그레이션 경로" 참조) 상위 집합에 가깝습니다. 아래 표는 각 프로젝트가 강조하는 책임과 성숙도를 비교한 것이며, 선택은 운영 복잡도와 필요한 기능에 따라 결정합니다.

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
소규모 클러스터, 운영 복잡도 최소화 우선llm-d
Gateway API 기반 K8s 네이티브llm-d
대규모 클러스터, 처리량 극대화가 최우선Dynamo
긴 컨텍스트 (128K+) 워크로드Dynamo (3-tier KV cache)
빠른 도입, 낮은 운영 복잡도llm-d

위 "규모" 구분은 고정된 GPU 개수 임계값이 아니라 경험적 지침입니다. 실제 전환 지점은 모델 크기, 트래픽 패턴, 디스어그리게이션 이득, 운영 역량에 따라 달라지므로 대상 환경에서 검증하세요.

마이그레이션 경로

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)과는 별개의 역할입니다.

관련 문서​

참고 자료​