NVIDIA Rubin CPX 설명 — Inference Prefill/Deocode 분리를 통한 AI 추론 최적화 아키텍처, Inference 인프라 TCO( 최적화 가능할까?

https://nvidianews.nvidia.com/news/nvidia-unveils-rubin-cpx-a-new-class-of-gpu-designed-for-massive-context-inference

NVIDIA Unveils Rubin CPX: A New Class of GPU Designed for Massive-Context Inference

 

최근 업무상 NVIDIA Rubin CPX에 대해서 공부할 일이 있었는데요, 공부했던 내용을 이번 포스팅에서 정리해보려고 합니다.

 

우선, NVIDIA에서 공개한 Rubin CPX는 Inference 할 때, 하나의 Chip에서 Prefill과 Decode를 모두 처리하던 기존 GPU 구조와 달리, 두 영역을 구분하여 처리할 수 있는 구조이며, Prefill은 Rubin CPX 에서, Deocode는 R200에서 수행됩니다.

 

이렇게 분리하여 처리하는 이유는 모델 추론 비용과 처리량을 개선하기 위함이며, 큰 특징으로는 R200은 HBM을 사용하지만 CPX는 HBM 없이 GDDR 기반으로 동작합니다. 즉, CPX는 고비용의 HBM을 사용하지 않습니다.

 

추가로 공부한 내용에 대해서는 아래 순서대로 내용을 정리하여 Rubin CPX와 이를 사용한 Vera Rubin NVL144 CPX 플랫폼에 대해서 살펴보도록 하겠습니다.

1. Prefill/Decode의 원리
2. Rubin CPX의 아키텍처
3. Vera Rubin NVL144 CPX 플랫폼
4. 경쟁 칩과의 차별점
5. NVIDIA 소프트웨어 역할
6. 구조적 효용성과 고려해야 할 리스크

 

---

1. Prefill과 Decode: 어떤 역할을 하고 왜 요구사항이 다를까

LLM 추론은 크게 Prefill과 Decode라는 두 단계로 이루어집니다.

Prefill 단계

• 사용자가 보낸 긴 Prompt 전체를 모델에 한 번에 넣고, 모든 레이어를 통과시키며 Key/Value(KV) Cache를 생성하는 과정
• 연산량 대부분이 대형 행렬 곱이므로 FLOPS 중심 Compute-bound
• 동일 파라미터를 여러 번 재사용하기 때문에 메모리 대역폭 요구는 상대적으로 낮음

Decode 단계

• Prefill에서 만든 KV Cache를 기반으로 토큰을 하나씩 생성하는 과정
• 매 토큰 생성 시마다 전체 KV Cache를 다시 읽어야 함
• Compute에 비해 Memory bandwidth가 부족
• 따라서 메모리가 Bottleneck인 Memory-bound

따라서 두 단계의 메모리 요구사양이 다름

• Prefill → Compute 성능이 중요 (저렴한 GDDR7도 충분)
• Decode → KV Cache 접근이 핵심 (HBM 같은 초고속·Low latency 메모리가 필요)
• 즉, Prefill은 FLOPS/$가 중요하고, Decode는 Memory BW/$가 중요

---

2. Rubin CPX: Prefill 전용 GPU

NVIDIA Rubin CPX는 이 문제를 해결하기 위해 만들어진 Prefill에만 최적화된 전용 GPU

주요 사양

• 128GB GDDR7 (HBM 없음)
• NVFP4 기준 최대 30 PFLOPS
• 단일 대형 다이 구조
• PCIe Gen6 중심 스케일아웃
• 높은 Attention 성능 (GB300 대비 3배 개선)

동작 방식: Prompt가 들어오면?

1. 사용자의 긴 Prompt가 입력
2. NVIDIA Runtime이 이 입력을 Prefill 요청으로 인식하고 CPX로 라우팅
3. CPX가 전체 Prompt를 고속으로 연산하여 KV Cache를 생성
4. 이 KV Cache는 시스템 패브릭(InfiniBand 또는 Spectrum-X)을 통해 R200 GPU의 HBM 영역으로 전송
5. R200은 이 KV Cache를 기반으로 토큰을 한 개씩 생성(Decode)
6. 여러 사용자 요청이 들어오면, CPX는 Prefill을 쌓아 보내고 R200 클러스터는 이들을 배치해 Decode하며 throughput을 극대화

---

3. Vera Rubin NVL144 CPX 플랫폼: Long-Context AI를 위한 랙스케일 컴퓨터

아래 그림은 NVIDIA가 제시한 정답 Vera Rubin NVL144 CPX라는 랙스케일 플랫폼

특징

• CPX + R200 + Vera CPU가 통합된 NVIDIA MGX 기반 랙 시스템
• 총 8 ExaFLOPS AI 성능
• 100TB Fast Memory, 1.7 PB/s 메모리 대역폭
• 기존 GB300 NVL72 대비 7.5배 성능 향상

용도

• Million-token 코딩 모델
• 1시간 비디오(약 1M token) 처리 모델
• 장기 대화 에이전트
• 멀티모달 생성 모델

 

 

---

4. Google TPU / AMD MI400 / Meta MTIA와의 차이

Google TPU

• TPU v5p/v5lite 모두 통합형 Compute+메모리 아키텍처
• 대규모 mesh를 활용하지만 Prefill/Decode를 칩 레벨에서 분리한 구조는 없음

AMD MI400 (MI350·MI400 세대)

• HBM 기반 통합형 구조 유지
• 한 GPU로 모든 단계 처리
• CPX처럼 저비용 Prefill 전용 칩은 없음

Meta MTIA

• Meta 내부용 inference ASIC
• 효율성은 높지만, 역시 Prefill 전용 하드웨어 분리 전략은 없음

결론

경쟁사들은 모두 “통합형 칩 + SW 최적화” 전략이고,
NVIDIA의 Rubin CPX만 "Prefill/Decode 분리형 아키텍처"

 

---

5. Prefill–Decode의 데이터 플로우 관리

다만 이 구조가 작동하기 위해서는 아래 작업이 필수로 보임.

• 어느 요청이 Prefill인지 구분하고,
• Prefill을 CPX로 보내고, 생성된 KV Cache를 R200으로 옮기고,
• 여러 사용자 요청의 KV Cache를 R200에서 혼합·스케줄링하고,
• 네트워크·대역폭·메모리 위치까지 고려하여 최적 배치하고...

즉, Prefill 과 Deocde 사이에 관리해주는 SW가 없으면 구현되기 어려우나,

서비스 제공자가 직접 구현할 필요는 없도록 NVIDIA가 이를 처리하기 위해 다음 스택을 제공함.

 NVIDIA Dynamo

• Prefill/Decode 분리형 Inference 스케줄링 담당
• KV Cache 라우팅 및 배치까지 통합 관리

TensorRT-LLM + Triton + NIM

• 모델 샤딩, 서빙, KV Cache 관리
• CPX와 R200 간 데이터 이동을 자동화

정리하면

Prefill–Decode 분리는 HW 개념이지만 실제 제어는 NVIDIA SW가 전부 맡는 구조이며,
고객은 이에 대한 고민없이 사용하면 되는 것으로 보임

---

6. 이 구조가 가져오는 효용성과, 마냥 좋지만은 않은 이유

(1) 구조적 장점

• TCO 절감
  • 비싼 HBM GPU를 Prefill에 쓰지 않음
  • Decode용 R200에는 HBM을 집중 배치
• 성능 향상
  • CPX는 Compute를 100% 가까이 활용
  • R200은 BW-bound 디코드를 안정적으로 처리
• Throughput 극대화
  • 여러 사용자의 Prefill 결과(KV)를 R200에서 섞어 처리 가능
  • 장기적으로 “토큰 처리량 = 서비스 매출” 구조에 최적화

(2) 비즈니스적 효용

• LLM API 기반 비즈니스에서 CAPEX → 토큰 생산력 극대화
• Long-context 모델을 상용 환경으로 끌어올릴 수 있는 구조
• 비디오·코딩·에이전트 같은 Inference Workload가 매우 Heavy한 고부가 서비스에 유리할 것으로 보임

(3) 하지만 리스크를 생각해보면

1. SW Lock-in 강화
   • Prefill/Decode 분리를 NVIDIA만 할 수 있으므로 HW+SW 수직 통합 종속성이 매우 커짐
   • NVIDIA에서 SW가격을 올리면 과연 TCO에서 이득일수 있을까..?
2. 구조적 복잡성 증가
   • 잘 설계하면 효율적이지만 잘못 설계하면 오히려 비효율 발생
   • CPX:R200 비율, 네트워크 대역폭, 스케줄링이 모두 최적화되어야 함
3. 워크로드 민감도
   • Long-context에 최적화된 구성
   • 반대로, 짧은 쿼리/짧은 응답 위주 서비스에는 장점이 거의 없음
4. 경쟁사 대응 변수
   • TPU/MI400/MTIA가 유사 구조를 채용할 가능성 존재하며, 이 경우 NVIDIA Chip 대비 저렴하게 구현할 것으로 보임

---

결론

Rubin CPX는 기존 GPU가 하나의 칩으로 Prefill과 Decode를 모두 처리하던 구조적 한계를 처음으로 분리한 아키텍처로, Prefill은 GDDR7 기반 CPX가, Decode는 HBM 기반 R200이 맡는 방식으로 LLM 추론 비용을 크게 낮출 수 있다는 점이 가장 큰 특징입니다. 

 

다만 이러한 구조가 안정적으로 동작하려면 Prefill–Decode 간 워크로드 분배, KV Cache 처리 정책, SLA(Service Level Agreement) 운영 전략 등 서비스 제공자 수준에서 정교한 설계가 필수적입니다. 즉, NVIDIA가 기술적 기반은 제공하지만 실제 효율은 서비스 운영 품질에 따라 달라질 수 있다는 점에서 여전히 고려해야 할 과제가 남아 있습니다.

 

그럼에도 고비용 HBM 의존도를 줄일 수 있다는 점에서 CPX는 기존 인프라 구조를 재편할 수 있는 잠재력이 충분해 보입니다.