GPU 메모리 스왑으로 성능은 유지하면서 모델 배포 비용 절감하기

거대 언어 모델(LLM)을 배포할 때는 두 가지 과제가 동시에 발생합니다. 높은 수요 속에서도 빠른 응답성을 보장해야 하고, 동시에 GPU 비용도 관리해야 한다는 점입니다. 많은 조직은 보통 다음과 같은 선택지 사이에서 고민하게 됩니다:

1. 최악의 트래픽 상황에 대비해 GPU가 장착된 다수의 복제본을 배포하고, 대부분의 시간은 유휴 상태로 두면서도 높은 하드웨어 비용을 감수한다.
2. 트래픽 급증 시 빠르게 스케일업하지만, 사용자들이 지연 문제를 겪게 만든다.

두 가지 접근 모두 이상적이지 않습니다. 첫 번째는 예산을 낭비하고, 두 번째는 사용자 경험을 해칩니다.

NVIDIA Run:ai GPU 메모리 스왑(모델 핫스와핑이라고도 불림)은 GPU 메모리 제약을 해결하고 자동 확장의 효율성을 높임으로써 추론 워크로드에서 GPU 활용도를 극대화하도록 설계된 새로운 혁신 기술입니다.

왜 모델 핫스와핑인가?

모델 핫스와핑은 모델 서빙에서 리소스를 더 유연하게 관리할 수 있는 방식입니다. 이 기술을 사용하면 여러 모델이 GPU 용량을 초과하더라도 동일한 GPU를 공유할 수 있습니다. 동작 방식은 다음과 같습니다:

1. 동적 메모리 오프로딩(Dynamic memory offloading): 일정 시간 동안 요청을 받지 않는 모델은 GPU 메모리를 차지하지 않고 CPU 메모리로 이동합니다.
2. 빠른 재활성화(Rapid activation): 요청이 들어오면 해당 모델은 즉시 GPU 메모리로 다시 불러와 지연을 최소화합니다.
3. 더 많은 모델, 더 적은 하드웨어: 여러 모델이 동일한 하드웨어를 공유할 수 있어 항상 켜져 있는 머신의 수를 크게 줄일 수 있습니다. 또한 서버(CPU 프로세스)는 GPU에서 스왑아웃된 상태에서도 계속 활성화되어 있기 때문에, 이미 초기화된 서버를 그대로 활용해 복제본을 빠르게 다시 활성화할 수 있습니다.

핫스와핑을 통해 조직은 예측하기 어려운 워크로드를 효율적으로 처리하면서도 과도한 리소스 할당에 따른 불필요한 비용을 피할 수 있습니다.

GPU 메모리 스왑 벤치마킹: 성능 검증

GPU 메모리 스왑의 성능을 보여주기 위해, 실제 LLM 배포 시나리오를 시뮬레이션했습니다.

테스트한 모델

• Meta Llama 3.1 8B Instruct (FP32: ~32 GB)
• Mistral-7B (FP32: 27.5 GB)
• Falcon-11B (FP32: 41.83 GB)

하드웨어 및 소프트웨어 환경

• GPU: NVIDIA L40S (48 GB), PCIe Gen4 x8로 연결, 이론적 최대 대역폭의 절반으로 제한
• 인스턴스 유형: AWS g6e.4xlarge
• 스케줄러: NVIDIA Run:ai Scheduler (v2.19)
• 추론 엔진: vLLM 0.6.4 (기본 설정)
• 서버 이미지는 노드에 사전 로드되어 있으며, 모델 웨이트는 EBS 스토리지에 캐시되어 모든 시나리오에서 네트워크 트래픽 오버헤드가 없습니다.

지표

• TTFT(Time to First Token): 첫 요청이 서버에 도달한 시점부터 모델이 첫 토큰을 생성할 때까지의 시간. 워밍업 단계를 비활성화해 프로덕션 환경을 시뮬레이션했으며, vLLM의 공식 벤치마킹 스크립트를 사용했습니다.

입력 조건

• 프롬프트 길이: 128 토큰과 2,048 토큰, 모델은 EOS 토큰에서 중지.

세 가지 배포 시나리오에서 지연 시간과 효율성 비교

다음 세 가지 시나리오를 평가했습니다:

1. 제로에서 스케일업(Scale from zero): 모델을 처음부터 로드할 때 TTFT(Time to First Token) 측정
2. 단일 GPU에서 모델 간 GPU 메모리 스왑: CPU 메모리에서 GPU 메모리로 모델을 다시 불러올 때 TTFT 측정
3. 기준선(Baseline, 웜 모델): 모델이 이미 GPU 메모리에 적재되어 있는 상태에서 TTFT 측정

1. 제로에서 스케일업 — 긴 지연

제로에서 스케일업은 파드를 초기화하고, 모델을 GPU에 로드한 뒤 첫 요청을 처리하는 과정을 포함합니다. 예상대로 초기화 오버헤드로 인해 가장 높은 TTFT가 발생했습니다.

작은 모델의 경우에도 TTFT가 꾸준히 140초를 넘었고, 약간 더 큰 모델은 200초 이상으로 늘어나 최대 208초에 달했습니다. 이러한 지연은 실시간 애플리케이션에는 사실상 불가능에 가까워, 프로덕션 환경에서 제로에서 스케일업하는 방식의 비효율성을 잘 보여줍니다.

2. GPU 메모리 스왑 — 최적의 효율성

이번 테스트에서는 모델을 CPU 메모리에 두고, 요청이 들어오면 GPU 메모리로 동적으로 스왑했습니다. 두 가지 모델 그룹을 테스트했으며, 첫 번째 그룹은 Llama 3.1 8B와 Mistral-7B, 두 번째 그룹은 Llama 3.1 8B와 Falcon-11B로 구성되었습니다. 순서는 다음과 같습니다:

1. 첫 번째 모델에 요청을 보내면, 해당 모델이 GPU 메모리로 스왑되어 로드됩니다. 이때 TTFT를 기록합니다.
2. 모델이 작업을 마치고 CPU 메모리로 다시 자동 스왑된 후, 두 번째 모델에 요청을 보냅니다. 이 모델도 GPU 메모리로 스왑되며, TTFT가 기록됩니다.

참고: GPU 메모리 스왑 방식에서는 TTFT가 PCI 대역폭과 CPU ↔ GPU 메모리 간 모델 스왑 속도에 의해 결정됩니다.

표 2. Mistral-7b 및 Llama 3.1 8B 명령어에 따른 GPU 메모리 스왑 결과

표 3: Falcon-11b 및 Llama 3.1 8B 명령어 집합을 사용한 GPU 메모리 스왑 결과

두 조합—Llama 3.1 8B Instruct + Mistral-7B, Llama 3.1 8B Instruct + Falcon-11B—모두 모델과 입력 크기에 관계없이 일관된 결과를 보였습니다. 예상대로 Falcon-11B는 Mistral-7B보다 메모리 사용량이 크기 때문에 TTFT가 약간 더 길게 나타났지만, 그 차이는 약 0.5초로 매우 작아 실제 환경에서 충분히 수용 가능한 범위였습니다.

실험 결과, 입력 시퀀스 길이에 따라 TTFT는 단 23초 수준으로, 제로에서 스케일업했을 때와 비교하면 모델 유형과 입력 길이에 따라 약 5066배의 성능 향상이 있었습니다.

3. 기준선 성능 — 웜 모델, 높은 비용

기준선을 확인하기 위해, 이미 GPU 메모리에 완전히 적재된 모델의 TTFT를 측정했습니다. 이는 지연 시간 측면에서 이론적으로 가장 이상적인(best-case) 시나리오를 나타냅니다.

표 4. Llama 3.1 8B Instruct, Mistral-7B 및 Falcon-11B를 사용한 베이스라인으로서의 Warm 모델 성능

웜 모델은 거의 즉각적인 응답을 제공하지만, 모델이 항상 GPU에 상주해야 하므로 GPU를 전용으로 할당해야 합니다. 여러 모델이나 복제본을 동시에 운영할 경우, 수요가 낮은 시간에도 GPU가 비효율적으로 사용되기 때문에 비용이 크게 증가하게 됩니다.

성능 저하 없는 비용 효율성

GPU 메모리 스왑은 성능과 비용 사이에서 최적의 균형을 제공합니다. TTFT를 단 몇 초 수준으로 줄여주기 때문에, 기업은 더 적은 수의 GPU로 워크로드를 통합하면서도 엄격한 SLA를 유지할 수 있습니다. 이는 효율성과 안정성을 모두 보장합니다. 항상 GPU에 상주하는 웜 모델 대비, 약간의 지연만 감수하면 상당한 비용 절감 효과를 얻을 수 있습니다.

NVIDIA Run:ai Model Streamer는 제로에서 스케일업하는 경우 TTFT를 수십 초 줄여주지만, GPU 메모리 스왑은 이를 한 단계 더 발전시켜 10초 미만의 TTFT를 달성하며, SLA 요구가 높은 애플리케이션에도 적합합니다.

GPU 메모리 스왑을 활용하면 GPU 효율성을 극대화하고, 유휴 비용을 최소화하며, 사용자가 기대하는 빠른 응답성을 유지할 수 있습니다. GPU 메모리 스왑의 실제 동작을 확인하고 NVIDIA Run:ai가 어떻게 AI 인프라를 혁신할 수 있는지 더 알아보시려면 문의해 주세요.