GPU가 유휴 상태임에도 AI 클러스터가 실패하는 이유

조직이 AI 인프라를 구축할 때, 대개 GPU가 모든 관심을 받습니다.

팀들은 최신 가속기(accelerators)에 투자하고, 고속 네트워킹(high speed networking)을 추가하며, 학습 작업(training jobs)이 막힘없이 확장되기를 기대합니다. 하지만 많은 AI 클러스터가 강력한 하드웨어를 갖추고 있음에도 실망스러운 성능을 보여줍니다.

놀라운 점은 무엇일까요?

GPU가 종종 유휴(idle) 상태라는 것입니다.

GPU 모니터링 대시보드를 보면 활동이 폭발하는 구간 사이의 사용률(utilization)이 20%, 10%, 심지어 0%까지 떨어지는 것을 볼 수 있습니다. 얼핏 보면 이것이 GPU 문제처럼 보이지만, 대부분의 경우 그렇지 않습니다.

GPU는 그저 기다리고 있는 것입니다.

왜 이런 일이 발생하는지, 그리고 HPC(High Performance Computing) 원칙이 이를 해결하는 데 어떻게 도움이 될 수 있는지 알아보겠습니다.

⸻

GPU는 파이프라인의 일부일 뿐입니다

AI 학습 작업을 조립 라인(assembly line)이라고 생각해보세요.

GPU가 배치(batch)를 처리하기 전에 몇 가지 단계가 반드시 거쳐져야 합니다:

스토리지(storage)에서 데이터를 읽어야 합니다.
파일의 압축 해제(decompression)가 필요할 수 있습니다.
이미지나 텍스트의 전처리(preprocessing)가 이루어져야 합니다.
데이터가 시스템 메모리(system memory)로 복사됩니다.
마지막으로, GPU 메모리(GPU memory)로 전송됩니다.

이 모든 단계가 완료된 후에야 비로소 연산(computation)이 시작될 수 있습니다.

만약 어느 한 단계라도 느려지면, GPU는 처리할 데이터가 없어서 단순히 기다리게 됩니다.

세계에서 가장 빠른 레이싱 카를 샀지만, 아주 작은 정원용 호스로 연료를 공급한다고 상상해 보세요.

차는 느리지 않습니다.

연료 공급이 느린 것입니다.

⸻

GPU가 유휴 상태로 머무는 일반적인 이유

1. 느린 스토리지 성능

대규모 AI 데이터셋은 종종 수백만 개의 작은 파일로 구성됩니다.

스토리지 시스템이 데이터를 충분히 빠르게 전달하지 못하면, GPU는 다음 배치가 준비되기 전에 현재 배치의 처리를 끝내버립니다.

이는 특히 다음과 같은 경우에 흔히 발생합니다:

네트워크 연결 스토리지(network-attached storage)를 사용하는 경우
수백만 개의 아주 작은 파일을 읽는 경우
스토리지 대역폭(bandwidth)을 여러 사용자가 공유하는 경우

그 결과, 값비싼 GPU가 데이터를 기다리며 대기하게 됩니다.

⸻

2. 데이터 로딩이 병목 현상(bottleneck)이 되는 경우

대부분의 딥러닝 프레임워크(deep learning frameworks)는 CPU에서 실행되는 데이터 로더 워커(data loader workers)에 의존합니다.

이 워커들은 다음 작업을 수행합니다:

파일 읽기
이미지 디코딩(decode)
텍스트 토큰화(tokenize)
증강(augmentations) 적용
학습 배치(training batches) 준비

워커(worker)가 너무 적거나 CPU가 과부하 상태라면 GPU 사용률(utilization)이 급격히 떨어집니다.

많은 사람들이 실제 병목 현상(bottleneck)이 CPU에서 발생하고 있음에도 불구하고, 즉시 배치 크기(batch size)를 줄이거나 GPU 설정을 변경하곤 합니다.

⸻

3. CPU가 따라오지 못하는 경우

현대의 GPU는 믿기지 않을 정도로 빠릅니다.

GPU에 데이터를 충분히 빠르게 공급하기 위해서는 강력한 CPU가 필요합니다.

만약 CPU 코어가 전처리(preprocessing) 작업으로 완전히 점유되어 있다면, GPU는 다음 배치(batch)를 기다리며 반복적으로 대기하게 됩니다.

이는 GPU의 성능이 향상될수록 더욱 두드러지게 나타납니다.

아이러니하게도, CPU를 업그레이드하지 않고 GPU만 업그레이드하는 것은 실제로 새로운 병목 현상을 드러낼 수 있습니다.

⸻

4. 저조한 네트워크 성능

분산 학습(distributed training)은 통신(communication)에 크게 의존합니다.

그래디언트(gradients), 파라미터(parameters), 그리고 동기화 데이터(synchronization data)가 노드(node) 사이를 끊임없이 이동합니다.

네트워크가 느리거나 혼잡할 경우:

GPU가 연산을 완료합니다.
동기화를 위해 대기합니다.
다음 반복(iteration)이 시작되기 전에 학습이 정체됩니다.

이것이 바로 InfiniBand, Omni Path, RDMA와 같은 기술들이 AI 클러스터에서 매우 가치 있는 이유입니다.

⸻

5. 작은 배치 크기

때로는 워크로드(workload) 자체가 너무 작을 때가 있습니다.

각 GPU가 아주 적은 양의 작업만 할당받는다면:

연산이 빠르게 종료됩니다.
통신 오버헤드(communication overhead)가 지배적이게 됩니다.
GPU가 연산하는 시간보다 기다리는 시간이 더 많아집니다.

배치 크기를 늘리거나 워크로드 분배를 개선하면 종종 사용률(utilization)이 향상됩니다.

⸻

6. 파일 시스템 경합(Filesystem Contention)

공유 HPC 환경에서는 수십 명 또는 수백 명의 사용자가 동시에 동일한 스토리지에 접근할 수 있습니다.

단일 학습 작업이 테스트 중에 잘 작동하더라도, 실제 운영 워크로드(production workloads)는 다음과 같은 자원을 두고 경쟁할 수 있습니다:

스토리지 대역폭(storage bandwidth)
메타데이터 작업(metadata operations)
공유 파일 시스템 리소스(shared filesystem resources)

경합(contention)이 심해질수록 GPU는 IO를 기다리는 데 더 많은 시간을 소비합니다.

⸻

유휴 GPU의 숨겨진 비용

다음과 같은 조직을 상상해 보십시오:

64개의 GPU 보유
각 GPU의 비용은 수천 달러에 달함
작업이 지속적으로 실행됨

만약 GPU 사용률(utilization)이 평균 40%에 불과하다면, 가용 컴퓨팅 파워의 절반 이상이 사실상 낭비되고 있는 것입니다.

기업들은 종종 더 많은 GPU를 구매하는 방식으로 대응합니다.

실제로 스토리지(storage), 네트워킹(networking), 스케줄링(scheduling) 또는 데이터 파이프라인(data pipelines)을 개선하는 것이 훨씬 적은 비용으로 훨씬 더 큰 성능 향상을 제공할 수 있습니다.

⸻

HPC 관행이 도움이 되는 방법

전통적인 HPC(High Performance Computing)는 수십 년 동안 리소스 병목 현상(bottlenecks)을 다루어 왔습니다.

이와 동일한 많은 원칙들이 AI 워크로드(workloads)를 개선할 수 있습니다.

데이터 지역성(Data Locality) 최적화

가능한 한 자주 사용되는 데이터셋을 컴퓨팅 노드(compute nodes) 근처에 저장하세요.

불필요한 데이터 이동을 줄이면 GPU를 계속 바쁘게 유지할 수 있습니다.

⸻

스토리지 성능 개선

대규모 데이터셋의 경우 병렬 파일 시스템(parallel filesystems), 로컬 NVMe 스토리지 또는 지능형 캐싱(intelligent caching)을 사용하세요.

더 빠른 데이터 액세스는 직접적으로 더 높은 GPU 사용률(utilization)로 이어집니다.

⸻

데이터 로더(Data Loaders) 튜닝

다음 항목들을 실험해 보세요:

워커 프로세스(worker processes) 수
프리페칭(Prefetching)
핀 메모리(Pinned memory)
배치 준비(Batch preparation)

작은 설정 변경만으로도 상당한 개선을 이끌어낼 수 있습니다.

⸻

CPU와 GPU 리소스의 균형

더 많은 GPU가 항상 정답은 아닙니다.

가속기(accelerators)에 지속적으로 데이터를 공급할 수 있도록 CPU가 충분한 코어(cores)와 메모리 대역폭(memory bandwidth)을 확보하고 있는지 확인하세요.

⸻

고속 인터커넥트(Interconnects) 사용

분산 AI 워크로드(Distributed AI workloads)는 낮은 지연 시간(low latency)의 네트워킹으로부터 큰 이득을 얻습니다.

통신 지연(communication delays)을 줄이면 GPU가 계산에 더 많은 시간을 할애할 수 있습니다.

⸻

전체 파이프라인 모니터링

GPU 사용률만 모니터링하는 대신, 다음을 관찰하세요:

CPU 사용률(CPU usage)
디스크 처리량(Disk throughput)
네트워크 대역폭(Network bandwidth)
파일 시스템 지연 시간(Filesystem latency)
메모리 사용률(Memory utilization)
데이터 로딩 시간(Data loading times)

실제 병목 현상은 종종 GPU 외부에서 발생합니다.

⸻

실제 사례

8개의 GPU로 이미지 분류 모델을 학습시키는 클러스터를 가정해 봅시다.

모니터링 결과:

GPU 사용률이 평균 35%에 불과함.
CPU 사용률은 100%에 근접함.
스토리지는 과도한 읽기 활동을 보임.

본능적으로는 GPU를 업그레이드하고 싶을 것입니다.

대신, 팀은 데이터셋을 로컬 NVMe 스토리지로 옮기고 데이터 로더 워커(data loader workers)의 수를 늘립니다.

GPU 사용률이 90% 이상으로 급증합니다.

새로운 GPU는 구매하지 않았습니다.

병목 현상은 결코 가속기(accelerators)의 문제가 아니었습니다.

⸻

마치며

AI 성능은 GPU 그 이상의 문제입니다.

학습 작업 (training job)의 속도는 가장 느린 구성 요소의 속도에 따라 결정됩니다. 스토리지 (Storage), CPU, 네트워킹 (networking), 파일 시스템 (filesystems), 그리고 데이터 파이프라인 (data pipelines) 모두가 전체 성능에 기여합니다.

GPU가 유휴 (idle) 상태로 보일 때, 그것들은 대개 시스템의 나머지 부분들이 따라잡기를 기다리고 있는 것입니다.

가속기 (accelerators)에만 집중하는 것이 아니라 전체 인프라 (infrastructure)를 이해하는 것이, 잘 설계된 AI 클러스터와 활용되지 못하는 고가의 하드웨어 집합을 구분 짓는 차이점입니다.

다음에 누군가가 _"우리 GPU는 느려요"_라고 말한다면, 더 자세히 살펴보십시오.

GPU는 그저 다른 모든 요소들을 기다리고 있는 것일지도 모릅니다.