More Performance From Every Byte: How Full-Stack Codesign Solves AI’s Memory Challenge

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

NVIDIA는 HBM 증설만으로는 해결하기 어려운 AI 추론의 메모리 압박에 대응해, 하드웨어와 소프트웨어의 풀스택 공동 설계로 메모리 계층 전체의 활용도와 달러당 처리량을 높인다고 설명한다.

📌 핵심 요약

• 수조 개 매개변수를 가진 모델, 일부 경우 최대 300만 토큰을 처리하는 에이전트 작업, RAG가 모델 가중치와 KV 캐시를 저장하는 HBM의 부담을 늘리고 있으며, 메모리 공급 제약과 가격 상승도 단기적으로 이어질 것으로 전망된다.
• HBM 용량을 늘려도 메모리 대역폭과 연산 자원을 공유하는 사용자가 증가하면 응답시간 요구를 충족하기 어려운 메모리 월에 도달한다. NVIDIA는 GPU HBM, CPU 메모리, 로컬 SSD, 공유 스토리지에 데이터를 적절히 배치하는 접근을 제시한다.
• NVFP4는 FP8 대비 모델 가중치와 KV 캐시의 저장 공간을 줄이며, NVL72에서는 모델 가중치를 최대 72개 GPU에 분산해 GPU별 HBM에 KV 캐시와 동시 사용자를 위한 여유를 확보할 수 있다.
• NVIDIA Vera CPU와 NVIDIA Dynamo, NVIDIA CMX는 비활성 컨텍스트의 대기·이동·재사용을 지원한다. RAG에서는 NVIDIA Nemotron Retriever가 임베딩을 줄이고 NVIDIA cuVS가 CPU와 스토리지에서 인덱스를 구축·제공해 지식베이스가 HBM을 차지하지 않도록 한다.
• NVIDIA가 제시한 SemiAnalysis AgentX DeepSeek V4 Pro 결과에서 GB300 NVL72는 사용자당 초당 100토큰 조건으로 H200보다 달러당 처리량이 최대 10배 높고 GPU당 HBM은 약 2배다. Vera Rubin NVL72는 사용자당 초당 125토큰 조건으로 GB300 NVL72보다 달러당 처리량이 최대 30배 높고 GPU당 HBM은 약 3% 증가했다.

🧩 주요 포인트

1. HBM 용량과 대역폭의 제약 → 저장 공간 확대의 효과는 응답시간 요구와 데이터 공급 속도를 함께 충족할 때 실현된다.
2. NVFP4 압축·NVL72 분산·비활성 컨텍스트 이동·RAG 인덱스의 HBM 외부 배치 → 서로 다른 메모리 점유 원인을 줄여 활성 추론에 사용할 HBM을 확보한다.
3. GPU당 HBM 증가율을 크게 웃도는 달러당 처리량 향상 → AI 팩토리의 성과는 메모리 용량과 함께 전력 예산 및 응답시간 요구 안에서 생산하는 유용한 토큰으로 평가해야 한다는 주장이다.

🧠 상세 정리

1. 에이전트 추론이 키우는 HBM 압박

모델 규모와 컨텍스트 길이가 커지고 에이전트 애플리케이션이 확산되면서 GPU 메모리 수요가 늘고 있으며, 원문은 공급 제약과 가격 상승도 단기적으로 지속될 것으로 전망한다. 최첨단 모델은 학습한 정보를 담는 매개변수가 수조 개에 이르고, 추론 중에는 이 가중치와 각 요청의 문맥을 유지하는 KV 캐시가 HBM 용량을 놓고 경쟁한다. 에이전트 작업은 모델 호출과 도구 호출을 반복하면서 이전 문맥을 이어 가며, 일부 경우 최대 300만 토큰을 처리해 요청별 작업 메모리가 시간이 지날수록 커진다. RAG 역시 관련 기업 정보를 프롬프트에 추가하므로 처리하고 보존해야 하는 컨텍스트를 늘린다. NVIDIA는 메모리 파트너와 협력해 HBM3e와 HBM4를 가속 컴퓨팅 스택에 최초로 도입했다고 밝히면서도, 대응의 핵심을 GPU·CPU·네트워킹·스토리지·소프트웨어의 공동 설계에 둔다.

2. HBM 증설의 한계와 메모리 계층의 필요성

AI 팩토리의 메모리 계층에서 HBM은 가장 빠르고 비싸며 수요가 집중되는 영역이고, 그 아래에는 CPU 메모리, 로컬 SSD, 공유 스토리지가 자리한다. 아래 계층으로 내려갈수록 속도와 맞바꾸어 더 큰 용량과 낮은 비트당 비용을 얻는다. 원문은 HBM을 창고, 메모리 대역폭을 하역장에 비유하며, 창고가 커져도 하역장이 처리할 수 있는 물량이 그대로라면 데이터 이동과 응답이 느려질 수 있다고 설명한다. HBM 증설로 KV 캐시와 동시 사용자를 늘리더라도 각 사용자는 같은 연산 자원과 메모리 대역폭을 공유하므로, 결국 데이터 공급이 연산 수요를 따라가지 못하는 메모리 월에 도달할 수 있다. 응답시간 요구 때문에 추가 용량을 효과적으로 활용하지 못하면 비용과 전력 소비만 늘어난다. 따라서 당장 사용하는 데이터는 GPU 가까이에 두고, 대기 중인 데이터는 더 저렴한 계층으로 옮겼다가 필요하기 전에 돌려보내는 운영이 중요하다는 논리다.

3. 가중치 압축과 최대 72개 GPU 분산

NVIDIA는 먼저 모델 가중치의 크기를 줄이고 여러 GPU에 나누어 저장해 HBM 부담을 낮춘다. NVFP4는 NVIDIA Hopper 플랫폼에서 가능한 최저 정밀도인 FP8보다 가중치 저장에 필요한 공간을 줄이는 형식이다. 원문은 Black Forest Labs의 FLUX.2 [klein], Thinking Machines Lab의 Inkling, Reflection의 Beam 1.0, Meta의 Meta Muse Spark, StepFun의 Step 5 Preview, NVIDIA Nemotron 3.5 Super VL이 NVFP4 체크포인트로 출시됐다고 소개한다. NVIDIA는 이를 더 빠르고 메모리 효율적인 추론을 위한 4비트 정밀도 채택이 모델 개발자 사이에서 확대되는 근거로 제시한다. NVL72 시스템에서는 가중치를 최대 72개 GPU에 분산할 수 있어 각 GPU가 보관하는 모델의 몫이 줄고, 그만큼 KV 캐시와 동시 사용자 처리에 쓸 HBM이 늘어난다.

4. KV 캐시 압축과 비활성 컨텍스트의 이동·재사용

KV 캐시에 NVFP4를 적용하면 FP8보다 점유 공간이 줄어 더 많은 컨텍스트를 HBM에 유지할 수 있다. NVIDIA Vera CPU는 도구 실행을 빠르게 해 도구 호출 중 KV 캐시가 비활성 상태로 머무는 시간을 줄이고, NVIDIA Rubin GPU와 NVLink-C2C로 연결된 대용량 LPDDR 메모리를 통해 일시 중단된 컨텍스트가 가까이에서 대기하도록 지원한다. NVIDIA Dynamo는 사용 중이 아닌 컨텍스트를 HBM보다 비트당 비용이 훨씬 낮은 NVIDIA CMX 컨텍스트 메모리 스토리지로 옮기고, 다시 사용하기 전에 반환한다. CMX는 로컬 SSD와 달리 서버 간에 공유되며, 기업용 스토리지와 달리 수명이 짧은 컨텍스트에 불필요한 장기 데이터 보호의 부가 부담을 생략한다. 원문이 제시한 CMX 파트너는 Cloudian, DDN, Dell Technologies, Everpure(이전 Pure Storage), HPE, IBM, NetApp, VAST, WEKA다. Dynamo의 KV Cache Reuse는 GPU 메모리·CPU 메모리·스토리지에 걸친 KV 캐시를 시스템 전체의 자원으로 관리해, 한 번 계산한 컨텍스트를 시스템에서 재사용하도록 연결한다.

5. RAG 임베딩 축소와 인덱스의 HBM 외부 배치

RAG는 기업 문서를 의미 기반 검색에 사용할 수 있는 수치 표현인 임베딩으로 바꾸고, 이를 검색 가능한 인덱스로 구성한다. NVIDIA는 Nemotron Retriever 모델이 더 작은 임베딩으로 더 높은 검색 정확도를 제공한다고 설명한다. NVIDIA cuVS 라이브러리는 이 인덱스를 CPU와 스토리지에 걸쳐 구축하고 제공할 수 있게 해, 지식베이스 자체가 HBM을 점유하지 않도록 한다. 모델의 컨텍스트에는 필요한 문서 구절만 들어가므로, 기업 지식을 검색하는 과정과 GPU에서 실제로 처리하는 문맥의 저장 위치를 구분할 수 있다. 원문은 이러한 RAG 처리와 가중치 압축, 비활성 컨텍스트 이동이 결합되면 가중치와 유휴 문맥에 묶이는 HBM이 줄어들고 동시 사용자 처리에 사용할 여유가 커진다고 설명한다.

6. 세대별 성과와 유용한 토큰 중심의 평가

NVIDIA는 플랫폼 세대가 바뀌면서 초당 토큰의 달러당 처리량이 GPU당 HBM 용량보다 훨씬 빠르게 증가했다고 주장한다. SemiAnalysis AgentX DeepSeek V4 Pro 워크로드에서 GB300 NVL72는 사용자당 초당 100토큰 조건으로 H200 플랫폼보다 달러당 처리량이 최대 10배 높았으며, GPU당 HBM 용량은 약 2배였다. 사용자당 초당 125토큰 조건에서는 Vera Rubin NVL72가 GB300 NVL72보다 달러당 처리량이 최대 30배 높았고, GPU당 HBM 용량은 약 3% 늘었다. 두 비교는 기준 플랫폼과 사용자당 처리 속도 조건이 다르며, 제시된 처리량 향상은 각각 최대치다. 원문은 AI 팩토리 운영자에게 중요한 기준을 전력 예산과 사용자 응답시간 요구를 지키면서 얼마나 많은 유용한 토큰을 제공하는지로 제시한다. 와트당 초당 토큰이 늘면 같은 전력으로 더 많은 작업과 매출을 얻고 토큰당 비용을 낮출 수 있으며, NVIDIA는 풀스택 공동 설계가 각 메모리 바이트의 유용한 작업량을 늘려 이러한 효과를 낸다고 설명한다.

🧾 핵심 주장 / 시사점

• 메모리 계층의 가치는 단순히 데이터를 더 많이 담는 데 그치지 않는다. 활성 데이터와 대기 데이터를 구분하고 필요한 시점에 GPU로 복귀시키는 능력이 HBM의 실질적인 활용도를 좌우한다.
• 가중치, KV 캐시, RAG 데이터는 HBM을 점유하는 이유가 서로 다르다. 원문이 제시하는 풀스택 공동 설계는 압축·분산·이동·검색 위치 조정을 각각의 점유 원인에 연결한다.
• 제시된 세대별 결과는 메모리 용량 증가만으로 달러당 처리량 향상을 설명하기 어렵다는 NVIDIA의 주장을 뒷받침한다. 다만 두 비교의 사용자당 토큰 속도와 기준 플랫폼이 다르므로 각 수치를 해당 조건과 함께 해석해야 한다.

✅ 액션 아이템

• 모델 가중치와 KV 캐시의 HBM 점유를 줄이는 방안으로 NVFP4 적용과 NVL72의 최대 72개 GPU 분산 활용을 검토한다.
• 비활성 컨텍스트에는 NVIDIA Vera CPU·NVIDIA Dynamo·NVIDIA CMX를, RAG 인덱스에는 NVIDIA cuVS를 활용하는 메모리 배치를 검토한다.
• GB300 NVL72와 Vera Rubin NVL72의 달러당 처리량을 각각 사용자당 초당 100토큰·125토큰 조건 및 전력 예산·응답시간 요구와 함께 평가한다.

❓ 열린 질문

• HBM 용량을 늘릴 때 메모리 대역폭과 응답시간 요구는 동시 사용자 수의 실질적인 한계를 어떻게 결정하는가?
• NVFP4와 NVL72 분산, NVIDIA Dynamo·NVIDIA CMX의 비활성 컨텍스트 이동은 각각 HBM 여유 확보에 얼마나 기여하는가?
• GB300 NVL72의 최대 10배와 Vera Rubin NVL72의 최대 30배 달러당 처리량 향상은 각각 사용자당 초당 100토큰·125토큰 조건 밖에서도 유지되는가?