GPU 클라우드 환경에서의 회복탄력적 AI 운영 : 훈련 및 추론을 위한 견고한 아키텍처와 전략 신정규 CEO 래블업 주식회사 

• GPU 클라우드 인프라 발전 및 AI 붐 • GPU 급성장에 따른 인프라 문제점 • AI 훈련 및 추론 작업의 핵심 회복탄력성 과제 • 기술 및 해결 전략 • Backend.AI 사례를 통한 견고한 아키텍처 소개 개요 

• GPU 클라우드의 시작 – 2010년대 초반: AWS 최초 GPU 인스턴스 제공 (Tesla M2050) – 초기 목적: HPC 및 과학 계산 분야 • 딥러닝 혁신 – 2012년 AlexNet 이후 주목받기 시작 – GPU 기반 딥러닝 급성장으로 수요 폭증 – 2017년부터 GPU만을 다루는 클라우드들 등장 – NVIDIA K80, V100 등 • 2020년대 – NVIDIA K80, V100, T4, A100, H100 등이 주로 사용 – OpenAI와 마이크로소프트: GPU 10,000개 이상 사용 슈퍼컴퓨터 구축 – 분산된 클라우드 클러스터 전반에서 수천대의 GPU를 병렬활용하는 것이 일반화됨 – "GPU-as-a-Service” 시장 형성 및 확대 GPU 클라우드 인프라의 진화 

• 급격한 GPU 인프라의 확장이 가져온 문제 및 트레이드오프 문제점 막대한 전력 소모와 열 발생 관련 기술 및 인프라의 부재 첨단 냉각 기술의 필요성 공랭, 수냉, 액침 냉각 등 전력망과 수자원의 부담 가중 전력계통 문제 냉각용 냉수 수급 문제 탄소 발자국 전력 소비에 의한 탄소 배출 GPU 자체의 제조및 폐기 짧은 주기의 신제품 수명주기 관리 문제 전력 소모와 냉각 부담 환경적 영향 하드웨어 이질성과 불안정성 비용 및 효율성 인프라 확대 비용 높은 지속 비용 비효율과 유휴자원 분산 훈련의 병목 발생 유휴시간 문제 효율과 안정성 사이의 딜레마 다양한 세대의 혼합 운용 T4, L40s, A100, H100… 동일 GPU 내의 성능 편차 제조 편차 및 부스트 클럭 GPU 장애 높은 연간 고장율 

• GPU의 막대한 전력 소모 문제: – 최신 GPU (NVIDIA H100/B100): 최대 400~1000W – 수천 대 이상의 클러스터는 수 메가와트 단위 소모 • 데이터센터 전력 소비량의 급증 – 2022년 데이터센터 전력 소비량 460 TWh ✓ 프랑스의 국가 연간 소비량 (463TWh)과 비슷 – 2026년까지 1,050 TWh 돌파 예상 ✓ 세계 5위 국가 (일본-러시아 사이) 의 전력 소비 규모 • 냉각 부담 증가 – 고급 냉각 방식 필수 요구 (액침 냉각, 수냉식) – NVIDIA Blackwell 아키텍처: 수냉식 냉각을 기본으로 요구 – 데이터센터 전력 1kWh당 냉각수 약 2리터 소모 • 전력망과 수자원에 부담을 주어 지속 가능성의 문제를 야기함 문제점 – 전력 및 냉각 이슈 문제점 

• AI 훈련의 큰 탄소 발자국 – GPT-3 모델 훈련 시 1,287 MWh 의 전력을 소비: 552톤의 CO₂ 발생 추산 – 미국 가정 120가구 연간 전력 소비량과 동일 • 짧은 주기의 모델 업데이트로 환경부담 가중 – 대략 6주마다 새로운 성능의 모델이 등장하고 있음 • GPU 제조 및 폐기의 환경 비용 증가 – 높은 에너지 소모, 자원 채굴 문제, 전자 폐기물 발생 • 해결책 – 재생에너지 사용 확대, 효율적 냉각, 적절한 GPU 수명 주기 관리 등 – 그러나 세계적 경쟁 심화로 아무것도 하지 못하고 있음 문제점 – 환경적 영향 문제점 

• GPU 인프라 구축의 높은 비용 문제 – 도입, 전력, 냉각 및 유지보수 비용 높음 • 대규모 GPU 클러스터의 자원 낭비 문제 – 작업 부하의 불균형으로 GPU 에너지의 최대 30% 낭비 • 과잉자원 vs. 부족자원 딜레마 – 과잉 투자는 자본 낭비, 부족 시 성능 저하 – 감가상각 기간 안에 이윤 구간에 도달할 수 있는가? • 지속적인 GPU 과부하 사용으로 하드웨어 수명 단축 – GPU의 수명은 CPU보다 훨씬 짧음 • 극단적인 고밀도 환경의 트레이드오프 – 전력/냉각 인프라의 한계로 장비를 낮은 클럭으로 운용하거나 – 안정성을 위한 마진을 남겨야 하는 상황 문제점 – 비용과 효율성 트레이드오프 문제점 

• GPU 하드웨어 간 성능 편차 – 제조상의 미세 차이로 최대 20% 성능 차이 발생 가능 – 동적 전력 관리로 인한 부스트 클럭등의 영향 발생 • 동기화 분산 훈련 시 가장 느린 GPU가 전체 병목 유발 – All-reduce 알고리즘의 특징 – “꼬리 현상”: 변동성으로 인한 작업 스케줄링 난도 고도화 • 신규 아키텍처와의 통합 – 소프트웨어 최적화 및 상호운용성 문제로 인한 안정성 확보 시간 • GPU 하드웨어 및 초고속 스토리지 등의 이질성을 고려한 고도화된 스케줄링이 필요 문제점 – 하드웨어 편차와 불안정성 문제점 

• GPU 장애 빈발 현상: – 대형 클러스터에서 메모리 오류, GPU 다운 현상 빈번 • 실제 사례 – Meta의 16,384 H100 GPU 클러스터 ✓ 54일간 훈련에서 총 419회 작업 중단 발생 ✓ 장애의 30% GPU 하드웨어, 17% HBM 메모리 오류 – Delta NVIDIA Ampere 장애 통계 ✓ 메모리 오류: 평균 지속시간 및 발생 빈도가 가장 높음 – 연간 기준 환산하면 GPU당 약 9%의 연고장 확률 • 체크포인트가 필수적이지만 추가 부하 발생 – 모델 크기가 커지고 분산 시스템의 규모가 커짐에 따라 그라디언트 저장에도 시간이 걸림 문제점 – GPU 장애와 작업 중단 이벤트 코드 약어 분류 발생건수 MTBE 에러간 평균시간 (노드당 시간) 지속시간 평균 (초) XID 31 MMU Error Hardware 18876 4.48 2.85 XID 48 DBE Memory 32 2639.71 0.14 XID 63 RRE Memory 95 889.17 0.12 XID 64 RRF Memory 35 2413.45 8.88 XID 74 NVLink Error Interconnect 2987 28.28 0.76 XID 79 GPU Fallen Hardware 31 2724.86 2.71 XID 94 Contained Memory 28 3016.81 0.12 XID 95 Uncontained Memory 38905 2.17 860.24 XID 119 GSP Hardware 2136 39.55 12.14 XID 122 PMU SPI Hardware 128 659.93 0.05 NVIDIA Ampere 장애 통계[1] [1] S. Cui et al., arXiv:2503.11901 문제점 

• 스케줄링 복잡성 증가 – GPU 성능의 가변성, 객체 특징 및 장애 여부 – 하나의 워크로드에 들어가는 4자리 수의 장비 • 기존 정적 스케줄링의 명확한 한계 – 변화 상황에 적응 어려움 • 실시간 GPU 상태 모니터링 통한 동적·적응적 스케줄링의 대두 – 사전 장애 탐지 및 실시간 작업 재분배 필요 – 장애 발생이 어쩔 수 없다면 최소 죽지는 않게 하자 – 비싼 자원을 최대한 활용하는 법에 대한 연구 문제점 – 불확실성 하의 스케줄링 문제점 

• 하나의 GPU를 여러 작업이 공유하는 분할 GPU 운영 방식 증가 – NVIDIA MIG ✓ 하드웨어를 8개의 파티션으로 설계하고, 정적으로 파티션을 나누어 여러개의 GPU처럼 보이도록 나눔 – NVIDIA MPS ✓ 하나의 프로세스가 GPU 자원 전체에 대한 권한 확보 후 여러 워크로드를 대신하여 동작 – NVIDIA vGPU ✓ VMWare 기반에서 하드웨어가 분할 기능을 지원하는 경우 시분할 방식으로 워크로드 지원 – Backend.AI Fractional GPU ✓ 장치 드라이버 가상화 기반으로 격리된 여러 워크로드에 가상 기기 제공 • 멀티테넌시의 문제 – 문제 발생 시 다른 사용자에게 영향 발생이 가능함 • 강력한 하드웨어·소프트웨어적 격리 메커니즘이 요구됨 – 하드웨어 예시: NVIDIA의 MIG – 소프트웨어 예시: Backend.AI 의 Fractional GPU 가상화 기술 문제점 – GPU 멀티테넌시와 장애 격리 문제점 

• 대부분의 클러스터 도구들은 health check 지원 • GPU 상태 실시간 체크 필수 (ECC 오류, 온도, 커널 상태) – NVIDIA: DCGM 라이브러리 ✓ 성능이 하락하는 단점이 있어 프로덕션에 사용 어려움 • 장애 노드 자동 배제 및 작업 재할당 시나리오 – 즉시 정상 노드로 작업 이전 – 장애 노드 수리 전까지 자동 격리 • 실제 적용 사례 – Kubernetes 에서의 장애 복구 시나리오 ✓ 컨테이너 기술의 성격상 GPU 기기가 바뀌는 상황에서의 GPU 장애 복구에 대해서는 더딘 진전 – AWS ParallelCluster ✓ 고성능 컴퓨팅용 클러스터의 디플로이 시나리오용 – 모든 방법은 하드웨어 여유 풀을 두고 운영해야 함 해결책 – 자동 장애 탐지 및 처리 해결책 

• 분산 학습에서 GPU 자원을 동적으로 조정 – 훈련 중 노드 추가/삭제 가능, 작업 중단 불필요 – 일반적으로 GPU 갯수를 All-reduce 과정에서 동적으로 줄이는 방식으로 구현 • GPU 장애 및 클라우드 자원 회수 상황에서의 지속적 운영 – PyTorch Elastic, Uber Horovod + Ray 등의 기술 사용 – TorchElastic: 워커 노드의 사망 및 추가 투입을 일부 지원 PoC, TorchX로 일부 반영 • 저렴한 클라우드 스팟 인스턴스 효율적 활용 시나리오 – 데이터 크기가 크지 않은 경우 유용함 – 데이터 및 모델 사이즈가 큰 경우, 스팟 인스턴스를 훈련용으로 사용하기 어려움 – 고속 데이터 네트워크 구성 및 GPU-GPU 네트워크 사용 불가능 해결책 – 탄력적(Elastic) 훈련 해결책 

• 정기 체크포인트의 필요성 – 장시간 실행되는 딥러닝 훈련에서 필수적인 요소 – 주기적으로 모델 가중치(weight) 및 옵티마이저 상태를 스냅샷(snapshot) 형태로 저장 – 체크포인트 빈도 vs 성능 부하 트레이드오프 존재 • 멀티 GPU 환경에서는 동기화된 체크포인트가 필수적 – 로컬 스토리지로의 체크포인팅 및, 전체 그라디언트 체크포인팅이 별도로 이루어져야 함 • 고속 스토리지 솔루션 기반의 복구 시간 단축 – 로컬 스토리지: RAID 구성 NVMe ✓ 레퍼런스 아키텍처의 예: DGX H100의 스크래치 디스크 – 네트워크 스토리지: GPUDirect Storage (NVIDIAI Magnum IO) ✓ 지원 벤더들을 사용하는 경우에 적용 가능 ✓ Weka, DDN, VAST Data 등 해결책 – 분산 훈련시의 체크포인트 기반 복구 • 장점 및 한계 – 장애 자체를 방지하지는 못하지만, 장애로 인한 데이터 손실과 연산 손실 최소화 – 작업 중단으로 인한 서비스 지연 및 비용 증가 문제를 현저히 완화 – 너무 자주 저장할 경우, 체크포인트 저장에 따른 부하 발생 – 저장 빈도와 성능 사이의 적절한 균형 필요 해결책 

• 추론(Inference) 환경에서의 체크포인트 적용 – 일반적인 마이크로서비스는 상태가 없음: 별도 체크포인트 필요하지 않음 – 긴 상호작용이 필요한 대화형 모델 서비스(예: ChatGPT 등)의 경우 필요한 경우들 존재 • 컨텍스트가 있는 추론 서비스의 대응 방법들 – 세션의 대화 컨텍스트나 모델 상태를 주기적으로 체크포인트로 저장 ✓ 인스턴스 장애 시 컨텍스트 복원을 통해 서비스 연속성 확보 가능 ✓ 사용자 경험에 영향을 최소화하는 장애 대응 가능 – 클라이언트에 컨텍스트를 동시에 보관 ✓ 브라우저의 여러 스토리지 기능을 사용하여 컨텍스트를 보관하고, 매 쿼리마다 발송 – 게이트웨이 서버에서 컨텍스트 관리 ✓ 현재 대부분의 추론 서비스들 ✓ 게이트웨이 서버는 GPU를 사용하지 않으므로 상대적으로 저렴함 해결책 – 추론 측면에서의 복구 해결책 

• 모델 샤딩(Sharding) – 대규모 모델 및 데이터셋을 GPU 여러 대에 나누어 배분하여 병렬 처리 – 모델 병렬(Model Parallelism): 각 GPU가 모델의 다른 층을 담당 – 파이프라인 병렬(Pipeline Parallelism): 순차적인 연산 흐름을 GPU별로 나눠 처리 • 내구성 측면에서의 구조적 장점 – 파이프라인 병렬 학습에서 특정 GPU 장애 발생 시 ✓ 예비 GPU 노드가 해당 단계를 즉시 대체 가능 ✓ 또는 남은 GPU들이 해당 단계의 연산을 임시 분담 → 작업 지속 가능 – GPU 하나의 장애가 전체 훈련 중단으로 이어지지 않음 • 모델 중복화(Replication)를 통한 추론 서비스 안정성 확보 – 동일한 모델을 여러 GPU에 유지 → 페일오버(Failover) 시 즉시 전환 가능 – 한 GPU가 다운되면, 복제된 GPU가 즉시 요청을 처리하여 서비스 중단 방지 ✓ 금융, 의료 등 무중단이 중요한 분야에서 유용하게 활용 – 단점: 추가 자원 소모 및 비용 증가 → 적용 대상에 따라 선택적 사용 필요 해결책 – 회복탄력성을 높이는 모델 샤딩 및 중복화 해결책 

• 연구 단계의 아이디어: 계산 중복 기반의 오류 탐지 – 훈련 단계에서 일부 연산을 중복 수행하여 결과를 비교 – 이상값 발생 시 다수 합의 기반으로 오류 감지 및 수정 ✓ 실무 적용은 제한적 (연산량 및 비용 증가) • ZeRO와 같은 최적화 기반 분산 샤딩 – ZeRO (Zero Redundancy Optimizer) (Microsoft) ✓ 모델의 가중치, 그래디언트, 옵티마이저 상태를 GPU에 분산 저장 및 계산 – 장점 ✓ GPU 하나의 실패가 전체 훈련이 아닌, 해당 데이터 일부에만 영향 ✓ 장애 발생 시 해당 부분만 복구하여 빠른 재시작 가능 • 샤딩과 중복화의 회복탄력성 측면 활용 – 원래는 자원 효율성과 확장성을 위해 도입된 기법들이지만, – 작업 단위의 세분화 및 복원성 향상으로 회복탄력성까지 강화 – AI 훈련 및 추론의 중단 없는 연속성을 위한 핵심 전략으로 발전 중 해결책 – 분산 샤딩 및 중복화 연구들 해결책 

• GPU 상태 이상 시 작업을 즉시 재할당 가능 – Straggler 기법: 상태 나쁜 GPU에서 즉각적으로 작업 이동 – 과열로 인한 성능저하, 저성능 GPU 개체들이 몰린 워크로드 할당 시나리오 회피 등 • GPU 작업의 라이브 마이그레이션 한계 존재 – NCCL: GPU마다 UUID가 있고, 이 값으로 GPU를 관리 – GPU가 교체되거나, VM이 마이그레이션 되면 해당 값이 바뀐다 ✓ 가상의 UUID를 줄 수도 있겠지만… 다양한 문제가 발생함 – 실질적 대안: 체크포인트 기반 빠른 재시작 • 지능적 로드밸런싱으로 성능 저하 방지 – 최고의 방법은, 훈련 및 인퍼런스를 돌리기 전에 모든 기기에 대한 성능, 내구성 지표 및 편차 분석을 미리 수행해야 함 해결책 – 동적 자원 재배치 해결책 

• 중요한 AI 서비스에는 하드웨어 수준의 이중화 구성 필수 – 장애 즉시 대체 투입 가능한 예비 자원 유지 – 재해 복구 모델 ✓ 데이터 자체의 여분 (훈련 데이터셋 복제 보관) ✓ 네트워크 여분(이중화된 경로 구성)을 인프라 레벨에서 적용 • 그러나… – GPU: 지금까지 존재한 연산기 중 가장 비싼 물건 – 크리티컬한 분야가 아닌 경우 실질적으로 이중화 구성이 어렵다 – 이중화를 해도 잡 미러링등이 돌지 않기 때문에 효용성이 없음 • 추론: 멀티클라우드, 멀티존 구성으로 재해 복구 가능 – 미리 스페어로 준비한 예비 하드웨어 그룹 사용 – 비용 부담은 크지만 서비스 연속성 크게 향상 • 고려점: 최악의 상황, 최대의 성능 – 유휴 자원을 많이 확보해두면 비효율이 증가하고 – 최대 성능만 노리면 작은 변동에 취약해짐 해결책 – 인프라 차원의 이중화 해결책 

• 장애 발생 시 자동으로 작업 우회하는 미들웨어 활용 – 기본: 하드웨어를 실시간 우회하기 ✓ 오류 징후(예: ECC 오류 증가)가 보일 경우, 그 GPU에서 돌고 있던 컨테이너나 작업을 선제적으로 다른 GPU로 옮기는 결정 – 하드웨어 장애 발생시 마스킹을 통해 더이상의 워크로드 할당을 차단 – 장애가 난 하드웨어에서의 작업이 재시작으로 복구가 가능한 경우 정상 하드웨어를 할당하고 재시작 – 재시작 실패시 작업 재시도 및 장애 발생 노드로의 워크로드 요청 라우트를 변경 • 예: Backend.AI Continuum의 경우 – 클라우드 장애 시 자동으로 온프레미스 환경으로 전환 – 사용자에게 장애 인식 불필요, 서비스 연속성 유지 가능 해결책 – 내결함성 미들웨어 해결책 

• 드라이버 수준 가상화 – 독자적 GPU 분할 가상화 기술로 정확한 자원 할당 및 관리 – 강력한 분할 격리로 멀티테넌트 환경 신뢰성 확보 • 장애 대응 예: GPU 메모리 / 스트림 멀티프로세서에서의 일부 장애 발생 – 메모리가 갑자기 일부 줄어든 경우 – 해당 영역을 제외하고 Fractional GPU를 생성 및 할당 – 이후 해당 GPU에 더이상의 워크로드를 할당하지 않고, 교체 요청 로그 송신 • 비교: CUDA MPS – 장애 발생시 동일 GPU에 할당된 다른 워크로드로 장애 전파 – 워크로드 오류 발생시 해당 오류의 장애 또한 동일 GPU의 다른 워크로드로 전파 • GPU 활용률 증가 – 기존 대비 2~3배 이상 활용률 증가 사례 Backend.AI 사례 – GPU 분할 가상화 기반 오류 격리 Backend.AI 사례 

• Sokovan 오케스트레이터의 스마트 동적 스케줄링 – GPU 노드 상태 실시간 모니터링 및 대응 – 장애 노드 자동 격리 및 즉시 작업 재할당 – 다단계(Multi-level) 방식의 구조 ✓ 전체 GPU 단위뿐 아니라 fractional GPU 단위까지도 할당을 최적화하고, NUMA 구성까지 인지하여 성능을 극대화 • 스케줄러 수준의 부하 재분배 – 한 GPU에 추론 요청이 몰려 지연이 커지기 시작하면 일부 트래픽을 자동으로 덜 바쁜 GPU로 넘겨줌 – 멀티 리전 클라우드 및 하이브리드 클라우드 환경에서 원활한 자원 이동 구현 ✓ 에너지 수급 측면에서 특정 데이터센터의 전력/열 여유가 부족할 경우 ✓ 일부 워크로드를 지리적으로 다른 센터나 엣지로 이동시키는 것을 장기적으로 검토 • 필요성 – SPOF 제거: 중앙 집중식 AI 서비스의 경우 부하가 많거나 연결 차단시 동작이 불가능한 경우들이 생김 – 멀티리전: 여러 GPU 클라우드 리전으로 위험 분산 및 지연율 개선의 필요성 – 하이브리드 클라우드: 민감 데이터가 로컬 영역을 벗어날 수 없는 경우 (개인정보 보호 규정) – 포터블 AI: 오프라인 또는 공백이 있는 시나리오에서 지속적인 AI 운영의 필요성 Backend.AI 사례 – 동적 스케줄링 및 장애 처리 Backend.AI 사례 

• 미션 크리티컬 AI 운영을 위한 지능형 페일오버 시스템 – 클라우드 API 서비스 + Backend.AI 클러스터 + LLM 라우터 – 자동 전환이 가능한 듀얼 모드 AI 인프라 • 클라우드 장애 발생 시 작업을 자동으로 온프레미스 GPU로 전환 – 정상 상태에서는 모든 AI 연산이 클라우드 GPU에서 처리 – Continuum이 클라우드 엔드포인트의 네트워크 단절이나 응답 불가 상태를 감지하면, 자동으로 그 요청들을 온프레미스 Backend.AI 인스턴스로 우회 • AI 워크로드의 스마트한 오케스트레이션 – 클라우드 API 중단 시 로컬 AI로 자동 페일오버 – 민감한 데이터를 온프레미스 AI로 선택적 라우팅 – 중요한 AI 서비스를 위한 제로 다운타임 보장 • 예시: 스마트시티 교통제어 AI – 평소에는 클라우드에서 돌다가 – 인터넷 문제로 클라우드에 접근할 수 없게 되더라도, Continuum이 즉각 로컬 GPU 서버로 추론 작업을 전환하여 서비스 중단 없이 신호 제어나 모니터링이 계속되도록 동작 Backend.AI 사례 – Continuum 하이브리드 장애 대응프록시 Backend.AI 사례 

• GPU 클라우드 인프라는 AI에 필수적이지만 운영상 엄청난 도전에 직면해 있음 • 회복탄력적 운영은 소프트웨어와 하드웨어의 통합 이해가 필요 – 유연성, 체크포인팅, 장애 격리, 동적 자원 할당 등 • Backend.AI: 설계상의 세심한 선택 – Sokovan: GPU 및 AI 워크로드에 특화한 오케스트레이터+스케줄러 – Fractional GPU: 장치 드라이버 수준에서의 가상화 구현 – 이를 통해 고성능, 고가용성, 고효율성 및 대규모 시스템에서의 회복탄력성 동시 달성 • 지속 가능하고 내결함성이 보장된 GPU 기반의 AI 인프라 기술 혁신 진행 결론 및 향후 전망 

감사합니다. 신정규 [email protected] facebook/Jeongkyu.shin 

Q&A GPU 클라우드 환경에서의 회복탄력적 AI 운영