
LIQID 블로그: AI 클러스터의 진정한 병목 현상은 '메모리 벽'입니다 (번역)
요약
AI 클러스터의 성능 병목 현상이 GPU 성능이 아닌 메모리 공급 속도(Memory Wall)에 있음을 지적합니다. 메모리 부족 시 발생하는 NVMe 스토리지로의 데이터 퇴피와 레이턴시 문제를 해결하기 위해 메모리 풀링 기술의 필요성을 강조합니다.
핵심 포인트
- AI 추론의 핵심 병목은 GPU 성능이 아닌 메모리 대역폭과 용량임
- DRAM 용량 초과 시 NVMe 사용으로 인해 약 500배의 레이턴시 발생
- 단순 서버 증설은 메모리 사이로화와 낮은 이용률을 초래함
- 메모리 풀링 도입 시 달러당 토큰 생성 수를 50% 향상 가능
본 기사는 LIQID사의 공식 블로그 기사 *"The Memory Wall Is the Real Bottleneck in Your AI Cluster"*의 일본어 해설 기사입니다. LLM 추론 기반에서의 「GPU 스타베이션 (GPU Starvation)」 원인과, 이를 근본적으로 해결하는 「메모리 풀링 (Memory Pooling)」 기술에 대해 해설합니다.
- AI 추론의 병목 현상은 GPU 성능이 아니라 데이터 공급 속도(메모리 벽 (Memory Wall))인 경우가 많다. - 장문 컨텍스트 처리(128K 등)나 에이전트형 워크로드에서는 CPU 측의 DRAM 상에 방대한 **KV 캐시 (KV Cache)**나 메타데이터가 생성된다. - 용량 부족으로 NVMe 스토리지로 퇴피(evacuation)되면, **약 500배 정도의 레이턴시 페널티 (Latency Penalty)**가 발생하여 GPU가 데이터 대기 상태(GPU 스타베이션)에 빠진다. - 단순한 서버 증설은 「DRAM의 사이로화 (Siloing)」를 초래하여, 전체 메모리 이용률이 30~50%로 저조해진다. 이는 비용과 전력 효율을 악화시킨다. - 메모리 풀링 (Memory Pooling) (LIQID EX-5410C 등)을 도입함으로써, 앱을 변경하지 않고도 네이티브 DRAM 수준의 속도로 메모리를 동적 할당할 수 있게 되어, 달러당 토큰 생성 수를 50% 향상할 수 있다.
추론 클러스터의 성능이 정체될 때, 많은 경우 「GPU를 증설하자」라거나 「최신 GPU로 교체하자」라고 생각하기 쉽습니다. 하지만 에이전트형 워크로드의 데이터 패스를 따라가 보면, 원인은 GPU 자체가 아니라 GPU에 충분한 데이터를 공급하지 못해 데이터 대기(GPU 스타베이션) 상태에 빠져 있는 것에 있습니다.
최신 LLM 추론 시스템에서는 다음과 같은 데이터가 CPU 측의 DRAM 상에 유지됩니다.
- 장문 컨텍스트 처리용 KV 캐시 (KV Cache)
- 어텐션 (Attention) 상태 및 메타데이터
- 임베딩 (Embedding) 스토어
- 에이전트의 도구 호출 상태
예를 들어, 70B (700억 파라미터) 모델로 128K 토큰의 컨텍스트를 처리하는 경우, 활성 컨텍스트 1건당 약 70GB에 달하는 KV 캐시가 생성됩니다. 병렬로 에이전트를 구동하면 메모리 수요는 승수적으로 불어납니다.
기존 서버에서는 제공할 수 있는 DRAM이 물리적인 제약(DIMM 슬롯 수나 CPU 핀 수)으로 인해 CPU당 1~2TB가 한계인 경우가 많이 보였습니다.
DRAM 용량이 넘치면 데이터는 NVMe 스토리지로 퇴피됩니다. 토큰 생성 루프 도중에 발생하는 500배의 레이턴시 페널티는 아무리 고성능 GPU라 하더라도 은닉할 수 없습니다. 결과적으로 배치 사이즈 (Batch Size)는 축소되고, Tensor Core의 가동률은 저하되며, 토큰당 소비 전력이 급증합니다.
메모리 부족에 대한 기존의 대책은 「서버를 늘리는 것」이었습니다. 하지만 이 접근 방식은 AI 워크로드에 있어 비효율적인 과거의 대책이 되어가고 있습니다.
- 불필요한 리소스 증가: 서버를 1대 추가할 때마다 불필요한 CPU, 전력, 냉각 오버헤드가 발생.
- 메모리의 사이로(섬)화: 장치 내에 고정된 1~2TB 정도의 DRAM이 개별적으로 존재.
- 낮은 가동률: 각 서버가 피크 부하에 맞춰 메모리를 탑재하기 때문에, 플릿 (Fleet) 전체의 평균 메모리 이용률은 30~50% 정도.
⚠️
문제의 본질
문제는 메모리 용량 그 자체의 부족이 아니라, 메모리의 배치와 할당 방법에 있습니다. 시스템 전체에는 충분한 메모리가 존재함에도 불구하고, 각 서버에 분산·고정되어 있기 때문에 옆 노드에서 GPU 스타베이션이 일어나고 있어도 유연하게 대응할 수 없습니다.
이 과제에 대한 구조적 접근 방식이 **메모리 풀링 (Memory Pooling)**입니다.
오픈 인터커넥트 (Open Interconnect) 규격을 기반으로 메모리를 서버 외부에 배치하고, 고속·저지연 패브릭 (Fabric)을 통해 연결합니다. 메모리는 각 장치에 고정된 속성이 아니라, 「패브릭이 필요한 곳으로 동적으로 할당하는 풀링된 리소스 (Pooled Resource)」로 진화합니다.
LIQID가 제공하는 메모리 풀링 패브릭 「EX-5410C」의 주요 특징은 다음과 같습니다.
- 대용량 풀: 1 시스템당 최대 100TB의 DRAM을 풀링 가능
- 노드 간 공유: 최대 32대의 서버 노드 간 공유
- 초저지연: 약 **200나노초 (ns)**의 액세스 레이턴시 (네이티브 DRAM과 동등)
- 투명한 동작: OS로부터는 일반적인 메모리로 인식되므로, 기존 소프트웨어 (LLM 추론 기반, DB, 스케줄러)의 변경은 불필요
예를 들어, 특정 노드가 긴 문맥 추론 (Long Context Inference)을 위해 6TB의 메모리를 필요로 하는 경우, 공유 풀 (Shared Pool)에서 동적으로 할당되며, 작업이 완료된 후에는 다시 풀로 반환되어 재사용됩니다.
나아가, Kubernetes, Slurm, OpenShift, Ansible과 연동함으로써 스케줄러의 실행 주기에 맞춘 실시간 할당이 가능해집니다.
| 평가 지표 | 기존의 고정 구성 | LIQID 메모리 풀링 도입 후 |
|---|---|---|
| 스토리지 퇴피 페널티 (Storage Eviction Penalty) | NVMe 퇴피 (500배 지연) 발생 | 항상 고속 메모리 유지로 페널티 제로 |
| 배치 크기 (Batch Size) | 최소화 | 4~8배 확대 |
| 와트당 토큰 생성 수 | 기준값 | 2배 향상 |
| 달러당 토큰 생성 수 | 기준값 | 50% 향상 |
| 메모리 이용률 | 30~50% (과잉 투자) | 공유 풀화를 통해 최적화 |
GPU가 데이터 대기로 인해 공회전하는 시간이 사라지고, 본래의 계산 처리에 모든 사이클을 소비할 수 있게 되므로, GPU 이용률과 비용 효율성이 대폭 개선됩니다.
LIQID의 메모리 풀링은 이미 운영 환경에서 실제 운용이 시작되었습니다.
또한, CXL 컨소시엄이 책정하고 있는 CXL 3.0 / 3.1 로드맵에서는 여러 랙(Rack)에 걸친 메모리 풀링의 실현을 목표로 하고 있습니다. 이를 통해 현재의 랙 단위 공유 메모리 아키텍처는 랙 열(Rack Row) 전체로 확장될 전망입니다.
'메모리 벽 (Memory Wall)'은 회피책을 모색해야 하는 제약 사항이 아닙니다. 애플리케이션 계층에 전혀 손을 대지 않고도, 오픈 표준 (Open Standard) 위에서 해결할 수 있는 기결된 아키텍처 과제입니다.
2026~2027년의 인프라 전략을 검토함에 있어, 단순히 메모리 확보를 위해 서버를 계속 증설하는 것이 아니라, 메모리 풀링을 통한 아키텍처 최적화를 검토하는 것이 중요해질 것으로 보입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기