추론 콜드 스타트를 40배 단축: 진정한 서버리스 GPU를 위한 엔지니어링

현재 AI 시대에서 추론에 대한 수요는 극도의 변동성을 특징으로 합니다. 예측 가능하고 안정적인 학습 워크로드와 달리, 추론은 외부 사용자 행동에 의해 좌우되어 급증하는 수요 패턴을 보입니다. 엔지니어에게 이는 서비스 품질(QoS)과 비용 사이의 긴장을 야기합니다: 피크를 처리하기 위해 GPU를 과다 할당하면 형편없는 "GPU 할당 활용도"가 발생하고, 할당이 부족하면 지연이 급증하고 503 오류가 발생합니다.

‘진정한 서버리스’ GPU를 구현하려면 요청에서 실행 중인 복제본으로 스케일링하는 시간이 분에서 초로 줄어야 합니다. Modal은 네 가지 핵심 최적화—클라우드 버퍼, 맞춤형 지연 파일 시스템(FUSE), CPU 체크포인트/복원, CUDA 체크포인트/복원—를 구현하여 콜드 스타트를 최대 40배(약 2,000초에서 50초) 단축했습니다.

1. 인스턴스 할당을 핫 경로에서 제거

스케일링에서 첫 번째 병목은 새로운 가상 머신을 시작하고 상태 검사를 수행하는 데 소요되는 시간으로, 몇 분이 걸릴 수 있습니다. Modal은 다수의 애플리케이션이 공유하는 유휴 상태의 건강한 GPU 클라우드 버퍼를 유지함으로써 이를 핵심 경로에서 제거합니다.

새 복제본을 이러한 사전 워밍된 유닛에 스케줄링하고 버퍼를 비동기적으로 보충함으로써 시스템은 초기 할당 지연을 없앱니다. 이는 Google의 GLOP 솔버를 사용한 선형 프로그래밍 문제로 관리되며, 비용, 요청된 용량, 관찰된 클라우드 제공자 공급량을 균형 있게 맞춥니다.

핵심적으로, 이 접근 방식은 적극적인 GPU 상태 검사를 포함합니다. GPU는 표준 서버 하드웨어보다 더 자주 고장나기 때문에 Modal은 두 단계의 상태 검사를 구현합니다: 부팅 시 짧은 활성 검사와 주간 주기로 수행되는 보다 집중적인 진단(dcgmi diag 등).

2. ImageFS를 통한 지연 컨테이너 로딩

표준 컨테이너 시작은 루트 파일 시스템 데이터를 기가바이트 단위로 가져오고 압축 해제해야 하는 필요성 때문에 병목이 됩니다. Modal은 libfuse로 구축된 맞춤 파일 시스템 ImageFS를 사용해 컨테이너 실행기를 이미지 전달과 분리함으로써 이를 해결합니다.

지연 로딩 및 콘텐츠 주소 지정

ImageFS는 전체 이미지를 로드하는 대신 시작 시 메타데이터(인덱스)만 로드하며, 이는 100ms 미만이 걸립니다. 실제 파일 내용은 애플리케이션이 요청할 때 지연 로드됩니다. 대부분의 컨테이너는 파일 시스템의 큰 부분(예: 로케일이나 시간대 데이터)에 접근하지 않으므로 이미지의 대부분이 실제로 전송되지 않습니다.

접근되는 데이터를 최적화하기 위해 Modal은 계층형 콘텐츠 주소 지정 캐시를 사용합니다:

  • 페이지 캐시: 가장 빈번한 히트에 대해 마이크로초 수준 지연.
  • 로컬 SSD: 일반적으로 사용되는 콘텐츠에 대한 고처리량 스토리지.
  • 지역 CDN/Blob 스토리지: 데이터 롱테일에 대한 무한 용량.

경로 기반 또는 레이어 기반 캐시 대신 콘텐츠 주소 지정을 사용함으로써 Modal은 서로 다른 이미지 간에 공유되는 바이트가 어느 레이어에 있든 한 번만 저장되도록 보장합니다.

3. CPU 스냅샷으로 호스트 시작 가속

컨테이너가 시작된 후에도 애플리케이션은 초기화가 필요합니다. 파이썬 중심 AI 스택에서는 간단한 import torch만으로도 수천 개의 시스템 호출과 몇 초의 오버헤드를 발생시킬 수 있습니다.

Modal은 이를 우회하기 위해 **체크포인트/복원(C/R)**을 활용합니다. gVisor의 runsc 런타임을 사용해 Modal은 컨테이너를 상태 머신으로 취급합니다. 프로세스의 힙, 스레드 상태, 파일 디스크립터 테이블 등을 포함한 메모리 스냅샷을 생성하고 디스크에 저장합니다.

새 복제본이 필요할 때 시스템은 이 스냅샷을 메모리로 직접 복원합니다. 이는 애플리케이션을 준비된 상태로 "빠르게 앞당겨" 호스트 측 시작 시간을 약 10배 감소시킵니다. 다만, 스냅샷은 기본 CPU 명령 집합과 호환되어야 하며(예: 특정 AWS 인스턴스 유형에서 지원되지 않는 명령 회피) 합니다.

4. CUDA 체크포인트로 디바이스 초기화 제거

마지막이자 종종 가장 중요한 병목은 GPU 측 초기화입니다. 이는 두 가지 주요 작업을 포함합니다:

  1. 가중치 로딩: 수십억 개의 파라미터를 스토리지에서 GPU VRAM으로 이동.
  2. 추론 엔진 설정: CUDA 그래프 캡처 또는 Torch 컴파일러 실행과 같은 연산 집약적 작업.

가중치 로딩은 주로 네트워크/디스크 속도에 제한된 처리량 병목인 반면, 엔진 설정은 연산 병목입니다. Modal은 최신 Nvidia 드라이버 기능을 활용해 디바이스 메모리를 호스트 메모리로 체크포인트합니다.

호스트 측과 디바이스 측 스냅샷을 결합함으로써 Modal은 전체 CUDA 컨텍스트를 복원할 수 있습니다. vLLM이나 SGLang과 같은 LLM 서버에서는 부팅 지연이 크게 감소합니다. 예를 들어 1 GiB 모델 테스트에서 스냅샷을 활성화했을 때 vLLM 부팅 지연이 평균 약 95초에서 약 13초로 감소했습니다.

지연 감소 요약

최적화 대상 구성 요소 지연 영향
Cloud Buffers 머신 관리 분 → 초
ImageFS (FUSE) 로컬 SSD / 네트워크 분 → 초
CPU Snapshots CPU / RAM 수십 초 → 초
CUDA Snapshots GPU / VRAM 분 → 수십 초

실제 적용 사례: Reducto

이러한 최적화는 피크 대비 평균 비율이 높은 워크로드가 효율적으로 스케일하도록 합니다. 문서 처리 플랫폼인 Reducto는 비전-언어 모델을 사용해 방대한 기업 데이터셋을 처리합니다. 이들의 워크로드는 촉박한 마감에 맞추기 위해 짧은 시간 동안 수천 개의 GPU로 스케일링이 필요합니다. GPU 메모리 스냅샷을 활용함으로써 Reducto는 콜드 스타트를 약 70초에서 약 12초로 줄였으며, 비용이 많이 드는 유휴 용량을 유지하지 않고도 "킬로-GPU" 워크로드를 진정한 서버리스 방식으로 운영할 수 있게 되었습니다.

기술적 반론 및 고려사항

Modal 접근 방식은 매우 효과적이지만, 커뮤니티는 몇 가지 기술적 트레이드오프를 지적했습니다:

  • FUSE 오버헤드: libfuse 사용은 사용자와 커널 공간 사이에 추가 컨텍스트 스위치를 발생시킵니다. 이는 처리량 중심 AI 워크로드에서는 무시할 수 있지만, 지연에 민감한 파일 작업에서는 병목이 될 수 있습니다.
  • 스냅샷 취약성: 메모리 스냅샷은 호스트 환경에 매우 민감합니다. 특정 CPU 명령을 가진 머신에서 만든 스냅샷은 해당 명령이 없는 머신에서 복원할 수 없으며, 이로 인해 이기종 클러스터에서는 여러 스냅샷이 필요합니다.
  • 멀티 GPU 복잡성: 멀티 GPU 프로그램을 스냅샷하는 것은 도전적입니다. nccl과 같은 통신 라이브러리는 일시 중지를 위해 설계되지 않았으며 복원 과정에서 교착 상태가 발생할 수 있습니다.

Sources