MLOps 09 - GPU 인프라와 스케일링 - 재영의 기술 블로그

왜 ML 워크로드는 다른 인프라를 요구하는가?

웹 서비스를 운영하는 인프라와 모델을 학습시키는 인프라는 요구 사항이 근본적으로 다르다. 웹 서비스는 수많은 작은 요청을 빠르게 처리하는 것이 핵심이다. 반면 모델 학습은 대량의 행렬 연산을 장시간 수행하는 작업이며, 이 과정에서 CPU의 순차 처리 방식으로는 현실적인 시간 안에 완료하기 어려운 경우가 많다.

GPU가 ML 워크로드에 필수적인 이유는 아키텍처의 차이에 있다. CPU는 소수의 고성능 코어로 복잡한 논리 연산을 처리하는 데 최적화되어 있다. GPU는 수천 개의 단순한 코어로 동일한 연산을 대량의 데이터에 동시에 적용하는 병렬 처리에 특화되어 있다. 딥러닝의 핵심 연산인 행렬 곱셈은 본질적으로 병렬화 가능한 작업이기 때문에, GPU에서 수십에서 수백 배의 속도 향상을 얻을 수 있는 것이다.

GPU 스케줄링의 복잡성

GPU를 팀에 할당하는 것은 CPU 리소스를 관리하는 것보다 훨씬 까다롭다. GPU는 고가의 자원이며, 유휴 상태로 두는 것 자체가 큰 비용 낭비이다. 그렇다고 하나의 GPU를 여러 워크로드가 동시에 사용하는 것은 메모리 격리와 성능 간섭 문제 때문에 쉽지 않다.

학습 워크로드와 추론 워크로드의 특성도 상이하다. 학습은 대량의 GPU 메모리를 장시간 점유하는 반면, 추론은 상대적으로 적은 메모리를 짧은 시간 동안 사용한다. 이 두 가지 워크로드를 같은 클러스터에서 효율적으로 스케줄링하려면 단순한 리소스 할당 이상의 전략이 필요하다.

NVIDIA의 MIG(Multi-Instance GPU)나 타임 슬라이싱 같은 기술이 등장한 것은 이러한 문제를 해결하기 위해서이다. 하나의 물리 GPU를 여러 논리 GPU로 분할하거나, 시간 단위로 공유하여 활용률을 높이는 접근이다.

Kubernetes에서의 GPU 관리

Kubernetes가 ML 인프라의 표준 오케스트레이터로 자리 잡은 데에는 이유가 있다. 컨테이너 기반의 워크로드 격리, 선언적 리소스 관리, 자동 스케줄링이 ML 워크로드의 복잡한 요구 사항과 잘 맞기 때문이다.

Kubernetes에서 GPU를 사용하려면 몇 가지 추가 구성이 필요하다. NVIDIA GPU Operator는 GPU 드라이버, 컨테이너 런타임, 디바이스 플러그인을 자동으로 설치하고 관리한다. 디바이스 플러그인은 GPU를 Kubernetes의 리소스로 등록하여, 파드가 nvidia.com/gpu: 1과 같은 선언만으로 GPU를 요청할 수 있게 한다.

apiVersion: v1
kind: Pod
metadata:
  name: training-job
spec:
  containers:
  - name: trainer
    image: training:latest
    resources:
      limits:
        nvidia.com/gpu: 2
  nodeSelector:
    gpu-type: a100

노드 셀렉터나 어피니티 규칙을 활용하면 특정 GPU 타입을 가진 노드에 워크로드를 배치할 수 있다. A100이 필요한 대규모 학습 작업과 T4로 충분한 추론 작업을 구분하여 스케줄링하는 것이다.

분산 학습 전략

모델의 크기가 단일 GPU 메모리를 초과하거나, 학습 시간을 단축해야 할 때 분산 학습이 필요해진다. 분산 학습은 크게 두 가지 접근 방식으로 나뉜다.

데이터 병렬(Data Parallelism)은 동일한 모델을 여러 GPU에 복제하고, 데이터를 나누어 각 GPU가 서로 다른 배치를 처리한 후 그래디언트를 집계하는 방식이다. 구현이 비교적 단순하고 대부분의 모델에 적용할 수 있다는 장점이 있다.

모델 병렬(Model Parallelism)은 모델 자체를 여러 GPU에 나누어 배치하는 방식이다. 단일 GPU에 올릴 수 없는 초대형 모델을 학습할 때 사용된다. 파이프라인 병렬과 텐서 병렬로 세분화되며, 구현 복잡도가 높지만 LLM 학습에서는 필수적인 기법이 되었다.

전략	적용 시점	복잡도
데이터 병렬	배치 크기를 키우거나 학습 시간 단축	낮음
모델 병렬 (파이프라인)	모델이 단일 GPU 메모리 초과	중간
모델 병렬 (텐서)	초대형 모델의 레이어 분할	높음
하이브리드	대규모 LLM 학습	매우 높음

PyTorch의 DistributedDataParallel(DDP), DeepSpeed, FSDP 같은 라이브러리가 이러한 분산 학습의 구현을 추상화하여, 엔지니어가 통신 프로토콜의 세부 사항을 직접 다루지 않아도 되게 한다.

비용 최적화

GPU 인프라는 비용이 크다. A100 한 장의 클라우드 시간당 비용이 일반 CPU 인스턴스의 수십 배에 달하기 때문에, 비용 최적화가 단순한 절약이 아니라 프로젝트의 실행 가능성을 좌우하는 문제가 된다.

스팟 인스턴스(또는 프리엠티블 인스턴스)는 유휴 GPU 용량을 할인된 가격에 사용하는 방식이다. 비용을 60~90% 절감할 수 있지만, 언제든 인스턴스가 회수될 수 있다는 제약이 있다. 학습 중 체크포인트를 주기적으로 저장하고, 회수 시 자동으로 새 인스턴스에서 재개하는 내결함성 설계가 필수적인 것이다.

오토스케일링은 GPU 노드를 워크로드 수요에 따라 동적으로 확장하고 축소하는 접근이다. Kubernetes의 Cluster Autoscaler나 Karpenter를 활용하면, 학습 작업이 큐에 쌓일 때 자동으로 GPU 노드를 추가하고, 작업이 완료되면 노드를 제거하여 비용을 최소화할 수 있다. GPU 노드는 프로비저닝 시간이 길기 때문에, 예측 기반 스케일링을 병행하는 것이 지연을 줄이는 데 효과적이다.

클라우드와 온프레미스의 선택

GPU 인프라를 클라우드에서 운영할 것인지, 온프레미스로 구축할 것인지는 조직의 규모와 워크로드 특성에 따라 달라진다.

클라우드는 초기 투자 없이 필요한 만큼 GPU를 사용할 수 있고, 최신 GPU에 즉시 접근할 수 있다는 장점이 있다. 워크로드가 간헐적이거나 규모를 예측하기 어려운 초기 단계에서는 클라우드가 합리적인 선택이다. 반면 GPU 사용량이 일정 수준을 넘어 지속적으로 유지되는 조직에서는 온프레미스가 장기적으로 비용 효율적일 수 있다. 다만 하드웨어 유지보수, 드라이버 관리, 물리적 인프라 운영이라는 추가적인 엔지니어링 부담이 수반된다.

많은 조직이 하이브리드 접근을 채택하는 이유가 여기에 있다. 기본적인 GPU 용량은 온프레미스로 확보하고, 피크 수요는 클라우드에서 처리하는 구조이다. Kubernetes가 이 하이브리드 구성을 가능하게 하는 핵심 기술이 되는 셈이다.

다음 포스트에서는 MLOps 플랫폼 구축을 살펴본다.