GPU 오케스트레이션을 위한 Kubernetes: 수천 대 GPU 클러스터 관리

2025년 12월 8일 업데이트

2025년 12월 업데이트: Kubernetes 1.31+의 Dynamic Resource Allocation(DRA)이 이제 GA되어 세밀한 GPU 파티셔닝과 타임 슬라이싱이 가능해졌습니다. NVIDIA GPU Operator 24.6+는 Blackwell 지원과 개선된 MIG 관리 기능을 추가했습니다. Kueue(Kubernetes 네이티브 작업 큐잉)가 AI 워크로드를 위한 프로덕션 성숙도에 도달하고 있습니다. Run:ai와 CoreWeave가 Kubernetes에서 50,000개 이상의 GPU 클러스터를 시연하고 있습니다. 멀티 클러스터 페더레이션 도구(Liqo, Admiralty)가 크로스 클라우드 GPU 오케스트레이션을 가능하게 합니다. 멀티 테넌트 추론 배포를 위한 vGPU 지원이 개선되고 있습니다.

OpenAI는 여러 Kubernetes 클러스터에 걸쳐 25,000개의 GPU를 오케스트레이션하여 GPT 모델을 훈련하며, GPU 장애를 자동으로 처리하고 워크로드를 실시간으로 재조정하며 평균 2.5시간마다 발생하는 하드웨어 장애에도 불구하고 97% 활용률을 유지하는 커스텀 오퍼레이터를 사용합니다.¹ 이 회사의 인프라 팀은 대규모 수정 없이는 바닐라 Kubernetes가 약 5,000노드에서 붕괴된다는 것을 발견했고, 계층적 클러스터 페더레이션, 커스텀 스케줄링 알고리즘, 각각의 30,000달러짜리 H100을 개별 추적이 필요한 귀중한 자원으로 취급하는 GPU 인식 오토스케일링을 구현해야 했습니다. 대규모 GPU 관리는 CPU 오케스트레이션과 근본적으로 다릅니다—분산 훈련 중 GPU 장애는 수백만 달러의 컴퓨팅 시간을 낭비할 수 있으며, NVLink로 연결된 GPU를 분리하는 잘못된 스케줄링은 8배의 성능 저하를 야기합니다. Kubernetes에서 수천 대의 GPU를 성공적으로 오케스트레이션하는 조직들은 베어메탈 관리 대비 35% 향상된 활용률, 60% 빠른 배포 시간, 90% 감소된 운영 오버헤드를 보고합니다.²

Kubernetes는 88%의 시장 점유율로 컨테이너 오케스트레이션을 지배하지만, GPU 지원은 늦게 도착했고 대규모에서는 여전히 어려움이 있습니다.³ 2019년에 출시된 NVIDIA GPU Operator는 마침내 Kubernetes에 엔터프라이즈급 GPU 관리를 가져왔으며, 동적 드라이버 설치, 자동 디바이스 플러그인 배포, GPU 상태 모니터링과 같은 기능을 가능하게 했습니다. Kubernetes에서 AI 워크로드를 실행하는 조직들은 디바이스 플러그인 구성, 노드 어피니티 규칙, 토폴로지 인식 스케줄링, 단일 팀이 GPU 리소스를 독점하는 것을 방지하는 리소스 쿼터를 다루어야 합니다. 그러나 GPU 오케스트레이션을 위한 Kubernetes를 마스터한 조직들은 수천 대의 GPU를 단일 프로그래밍 가능한 리소스 풀로 취급하여, 기존 HPC 스케줄러로는 불가능한 활용률과 운영 효율성을 달성할 수 있습니다.

GPU 디바이스 플러그인 아키텍처

Kubernetes 디바이스 플러그인 프레임워크는 클러스터 전반에 걸쳐 GPU 검색, 할당, 상태 모니터링을 가능하게 합니다:

NVIDIA GPU Device Plugin은 Kubernetes와 NVIDIA GPU 간의 주요 인터페이스 역할을 합니다.⁴ 이 플러그인은 모든 GPU 노드에서 DaemonSet으로 실행되며, GPU를 kubelet에 스케줄 가능한 리소스로 등록합니다. 초기화 중에 플러그인은 NVIDIA Management Library(NVML)를 쿼리하여 사용 가능한 GPU, 메모리 용량, 컴퓨팅 기능, 인터커넥트 토폴로지를 검색합니다. 플러그인은 nvidia.com/gpu 리소스 이름을 사용하여 Kubernetes 스케줄러에 GPU를 알리며, 파드가 표준 리소스 사양을 통해 GPU를 요청할 수 있게 합니다.

디바이스 플러그인 등록 흐름: 1. 플러그인이 시작되고 NVML을 통해 로컬 GPU를 검색 2. /var/lib/kubelet/device-plugins/의 Unix 소켓을 통해 kubelet에 등록 3. 고유한 디바이스 ID로 사용 가능한 GPU를 알림 4. 컨테이너 GPU 할당을 위한 Allocate() RPC 구현 5. GPU 상태를 모니터링하고 kubelet에 장애 보고 6. 파드 종료 시 GPU 정리 처리

Multi-Instance GPU(MIG) 지원은 A100 및 H100 GPU를 격리된 인스턴스로 파티셔닝할 수 있게 합니다.⁵ 각 MIG 인스턴스는 Kubernetes에 별도의 GPU로 나타나 세밀한 리소스 할당을 가능하게 합니다. 디바이스 플러그인은 인스턴스의 생성, 삭제, 할당을 처리하며 MIG 프로파일을 관리합니다. 조직들은 더 작은 워크로드를 위해 활용도가 낮은 GPU를 파티셔닝하여 7배 향상된 GPU 활용률을 달성합니다. MIG 구성은 노드를 드레인하지 않고는 파티셔닝 모드를 변경할 수 없으므로 신중한 계획이 필요합니다.

대안 디바이스 플러그인은 벤더 다양성을 제공합니다: - AMD Device Plugin은 MI250X와 같은 ROCm 지원 GPU를 지원 - Intel Device Plugin은 Intel GPU와 Gaudi 가속기를 관리 - Xilinx FPGA Device Plugin은 FPGA 리소스를 오케스트레이션 - Google TPU Device Plugin은 GKE 클러스터용

GPU 워크로드를 위한 스케줄링 전략

효과적인 GPU 스케줄링은 성능을 유지하면서 활용률을 극대화합니다:

Gang Scheduling은 분산 훈련 작업이 요청된 모든 GPU를 동시에 받도록 보장합니다. Gang 스케줄링 없이 부분적인 리소스 할당은 교착 상태를 유발합니다—작업은 절대 사용 가능해지지 않는 나머지 GPU를 영원히 기다립니다. Volcano 및 Apache YuniKorn과 같은 Kubernetes 스케줄러 플러그인은 PodGroups를 통해 Gang 스케줄링을 구현합니다.⁶ 작업은 최소 GPU 요구 사항을 지정하고, 스케줄러는 모든 리소스를 할당하거나 전체 작업을 대기열에 넣습니다. Gang 스케줄링은 클러스터 활용률을 10-15% 감소시키지만 훈련 작업 기아 상태를 방지합니다.

토폴로지 인식 스케줄링은 하드웨어 인터커넥트를 기반으로 GPU 배치를 최적화합니다. NVLink로 연결된 GPU는 PCIe를 통한 32GB/s에 비해 600GB/s 대역폭을 달성합니다.⁷ 스케줄러는 노드 토폴로지를 검사하여 빠른 인터커넥트를 가진 GPU에 관련 파드를 배치합니다. NVIDIA GPU Feature Discovery는 어피니티 규칙을 가능하게 하는 토폴로지 정보로 노드에 레이블을 지정합니다. 잘못된 토폴로지 결정은 통신이 많은 워크로드에서 3-8배의 성능 저하를 유발합니다. 토폴로지 인식은 작업당 8개 이상의 GPU에서 중요해집니다.

Bin Packing vs Spreading: Bin packing은 더 적은 노드에 워크로드를 통합하여 캐시 지역성을 개선하고 네트워크 트래픽을 줄입니다. Spreading은 더 나은 장애 허용성과 열 관리를 위해 노드 전반에 작업을 분산합니다. 최적의 전략은 워크로드 특성에 따라 달라집니다—훈련 작업은 bin packing의 이점을 얻고 추론은 spreading을 선호합니다. 동적 전략은 클러스터 활용률과 워크로드 믹스에 따라 조정됩니다.

우선순위 및 선점: 프로덕션 워크로드는 개발 작업보다 높은 우선순위를 받습니다. 스케줄러는 리소스가 부족해지면 낮은 우선순위 파드를 선점합니다. 신중한 우선순위 구성은 연구 작업이 프로덕션 추론을 차단하는 것을 방지합니다. 선점 체크포인팅은 훈련 진행이 손실되지 않도록 보장합니다. 우선순위 클래스는 시스템 크리티컬(1000000)에서 개발(100)까지 범위가 있습니다.

공정 공유 및 쿼터: 리소스 쿼터는 단일 팀이 GPU를 독점하는 것을 방지합니다. 계층적 쿼터는 팀별 하위 쿼터와 함께 조직 전체 제한을 가능하게 합니다. 공정 공유 스케줄링은 시간에 걸쳐 공평한 리소스 분배를 보장합니다. 더 적은 리소스를 소비하는 사용자는 향후 버스트 용량을 위한 크레딧을 축적합니다. Kueue와 같은 큐 시스템은 정교한 승인 제어와 함께 작업 큐잉을 제공합니다.

스케일링 고려사항

Kubernetes를 수천 대의 GPU로 스케일링하려면 아키텍처 수정이 필요합니다:

클러스터 크기 제한: 단일 Kubernetes 클러스터는 etcd 성능이 저하되기 전에 최대 5,000노드를 지원합니다.⁸ API 서버 부하는 워치 메커니즘으로 인해 노드 수에 따라 이차적으로 증가합니다. 컨트롤러 매니저 조정 루프는 1,000노드 이상에서 느려집니다. 네트워크 정책은 대규모에서 다루기 어려워집니다. 대부분의 조직은 운영 안정성을 위해 클러스터를 500-1,000 GPU 노드로 제한합니다.

멀티 클러스터 페더레이션: 대규모 배포는 페더레이션을 통해 관리되는 여러 Kubernetes 클러스터를 사용합니다. Admiralty 또는 Virtual Kubelet은 크로스 클러스터 스케줄링을 가능하게 합니다. Flux 또는 ArgoCD와 같은 GitOps 도구는 클러스터 간 구성을 동기화합니다. 서비스 메시 기술은 크로스 클러스터 네트워킹을 제공합니다. 페더레이션은 복잡성을 추가하지만 단일 클러스터 제한을 넘어 수평 스케일링을 가능하게 합니다.

계층적 리소스 관리: 워크로드 클러스터를 제어하는 관리 클러스터로 클러스터를 계층적으로 구성합니다. 관리 클러스터는 컨트롤 플레인 컴포넌트와 스케줄링 로직을 실행합니다. 워크로드 클러스터는 복잡한 컨트롤러 없이 GPU 파드를 호스팅합니다. 계층적 설계는 장애의 영향 범위를 줄입니다. 관심사의 명확한 분리는 문제 해결을 단순화합니다.

AI 워크로드를 위한 Custom Resource Definitions(CRDs): - TrainingJob: 분산 훈련 사양 정의 - InferenceService: 모델 서빙 배포 관리 - GPUPool: 논리적 GPU 그룹화 표현 - Checkpoint: 훈련 상태 지속성 처리 - ModelVersion: 모델 반복 및 계보 추적

스케일을 위한 성능 최적화: - 사용하지 않는 어드미션 웹훅을 비활성화하여 API 지연 시간 감소 - 균등한 분산을 위한 파드 토폴로지 스프레드 제약 구현 - 컨테이너 이미지용 로컬 SSD 사용으로 네트워크 병목 현상 방지 - 보장된 CPU 할당을 위한 CPU 매니저 활성화 - 대규모 모델 메모리 요구 사항을 위한 huge pages 구성

모니터링 및 관찰 가능성

포괄적인 모니터링은 수백만 달러의 GPU 유휴 시간을 방지합니다:

NVIDIA Data Center GPU Manager(DCGM)는 표준 Kubernetes 모니터링을 통해 사용할 수 없는 GPU 특정 메트릭을 제공합니다.⁹ DCGM은 SM 활용률, 메모리 대역폭, 온도, 전력 소비, ECC 오류를 포함한 100개 이상의 메트릭을 내보냅니다. Prometheus 통합은 장기 메트릭 저장 및 알림을 가능하게 합니다. Grafana 대시보드는 전체 플릿에 걸쳐 GPU 성능을 시각화합니다. 커스텀 알림은 장애가 발생하기 전에 활용도가 낮은 GPU, 열 스로틀링, 하드웨어 저하를 감지합니다.

Kubernetes 모니터링을 위한 주요 GPU 메트릭: - GPU 활용률: 활성 SM의 백분율(목표 >90%) - 메모리 활용률: 할당된 GPU 메모리 대 사용 가능한 메모리 - 전력 소비: 스로틀링을 나타내는 실제 대 TDP - 온도: GPU 및 메모리 온도 - PCIe 대역폭: GPU로/로부터의 데이터 전송률 - NVLink 트래픽: GPU 간 통신 대역폭 - 훈련 메트릭: 손실 곡선, 그래디언트 노름, 학습률 - 추론 메트릭: 초당 요청, P99 지연 시간, 배치 크기

분산 트레이싱은 여러 GPU와 노드에 걸쳐 요청을 추적합니다. OpenTelemetry 계측은 훈련 단계 시간, 데이터 로딩 지연 시간, 체크포인트 기간을 캡처합니다. Jaeger 또는 Tempo는 분산 트레이스 저장 및 분석을 제공합니다. 트레이스와 메트릭 간의 상관관계는 성능 병목 현상을 식별합니다. 엔드 투 엔드 가시성은 평균 해결 시간을 70% 단축합니다.

로그 수집은 수천 개의 GPU 파드에서 로그를 중앙 집중화합니다. Fluentd 또는 Fluent Bit은 최소한의 오버헤드로 컨테이너 로그를 수집합니다. Elasticsearch는 자동 인덱싱 및 보존 정책으로 로그를 저장합니다. Kibana는 전체 클러스터에서 로그 검색 및 분석을 가능하게 합니다. 일관된 형식의 구조화된 로깅은 문제 해결을 단순화합니다. 시스템적 문제를 나타내는 오류 패턴에 대해 알림을 설정합니다.

Introl은 전 세계 서비스 지역에서 GPU 오케스트레이션을 위한 Kubernetes 클러스터를 배포하고 관리하며, 10,000개 이상의 GPU 배포에 대한 전문성을 보유하고 있습니다.¹⁰ 당사의 플랫폼 엔지니어링 팀은 최적의 GPU 활용률을 위한 커스텀 오퍼레이터와 스케줄링 개선 사항을 구현했습니다.

프로덕션 배포 패턴

Anthropic의 훈련 클러스터 아키텍처: - 규모: 8개의 Kubernetes 클러스터에 걸쳐 4,000개의 GPU - 토폴로지: 중앙 스케줄러가 있는 계층적 페더레이션 - 스토리지: 훈련 데이터용 분산 Lustre 파일시스템 - 네트워킹: 노드당 200Gbps의 RoCE v2 패브릭 - 스케줄링: 토폴로지 인식을 갖춘 커스텀 Gang 스케줄러 - 모니터링: 15초 스크래프 간격의 DCGM + Prometheus - 결과: 94% GPU 활용률, 50% 훈련 시간 단축

Uber의 추론 플랫폼: - 워크로드: 일일 5억 건의 예측 - 인프라: 20개 지역에 걸쳐 2,000개의 T4 GPU - 오케스트레이션: 서버리스를 위한 Knative가 있는 Kubernetes - 오토스케일링: 트래픽 패턴 기반 예측 스케일링 - 로드 밸런싱: 최소 지연 시간 라우팅이 있는 Envoy 프록시 - 최적화: 모델 캐싱으로 콜드 스타트를 2초로 단축 - 성과: 이전 아키텍처 대비 65% 비용 절감

Spotify의 하이브리드 훈련-추론: - GPU: 3,000개의 혼합 V100/A100/T4 플릿 - 스케줄링: 개발용 타임 슬라이스 공유 - 격리: 멀티 테넌트 보안을 위한 Kata 컨테이너 - Cos

[번역을 위해 콘텐츠 잘림]