CXL과 AI 추론: 알리바바 Beluga가 KV 캐시를 공유 메모리로 바꾼 방법
CXL(Compute Express Link)은 흔히 HBM 부족을 해결할 차세대 메모리로 소개됩니다. 그러나 CXL은 HBM처럼 새로운 메모리 셀을 만드는 기술이 아닙니다. CPU와 가속기, 장치 바깥의 DRAM을 PCIe 물리 계층 위에서 하나의 메모리처럼 연결하는 인터커넥트와 시스템 규약입니다. CXL이 늘리는 것은 GPU 내부 대역폭보다 서버가 접근하고 공유할 수 있는 메모리의 범위입니다.
이 차이를 놓치면 CXL의 역할을 과대평가하게 됩니다. AI 모델의 행렬곱, 어텐션, 학습 중 활성값과 그래디언트처럼 매 순간 읽고 쓰는 데이터는 여전히 HBM에 있어야 합니다. CXL의 자연스러운 자리는 계산이 끝난 뒤 다시 쓸 가능성이 있는 데이터, 특히 여러 요청과 GPU가 재사용하는 KV 캐시와 프리필·디코드 사이의 상태입니다.
알리바바 클라우드 연구진이 2025년 11월 공개하고 SIGMOD 2026에 게재한 Beluga는 이 가설을 상용 CXL 2.0 스위치에서 시험했습니다. 논문의 대표 결과는 RDMA 메모리 풀 대비 평균 TTFT(Time To First Token) 89.6% 감소와 처리량 7.35배입니다. 다만 이는 모든 요청의 평균적인 개선이 아니라, 1차 실행에서 만든 KV 캐시가 2차 실행에서 전부 적중한 장문 프롬프트 조건의 결과입니다. 최초 캐시 적재 구간의 개선은 평균 TTFT 12.4%, 처리량 21.5%였습니다.
따라서 결론은 두 문장으로 압축됩니다. CXL은 AI 연산 자체의 가속 수단이 아니라 웜데이터의 용량과 공유 효율을 높이는 수단입니다. 일반적인 AI 인프라에서는 알고리즘과 소프트웨어 최적화 다음의 조건부 우선순위지만, 반복되는 장문 접두부와 프리필·디코드 분리가 많은 하이퍼스케일 추론에서는 랙 내부 메모리 계층의 높은 우선순위가 될 수 있습니다.
CXL은 메모리가 아니라 메모리로 가는 길입니다
CXL은 PCIe의 물리 계층을 이용하면서 세 프로토콜을 함께 정의합니다. CXL 컨소시엄의 설명에 따르면 CXL.io는 장치 검색·설정·인터럽트와 DMA를, CXL.cache는 장치가 호스트 메모리를 일관성 있게 접근하는 경로를, CXL.mem은 호스트가 장치에 붙은 메모리를 load/store 명령으로 접근하는 경로를 맡습니다.
| 프로토콜 | 접근 방향 | AI 시스템에서의 의미 |
|---|---|---|
| CXL.io | 호스트와 장치의 관리·I/O | 장치 검색, 설정, DMA, 오류 보고 |
| CXL.cache | 장치 → 호스트 메모리 | 가속기가 호스트 메모리를 캐시 일관성 아래 접근 |
| CXL.mem | 호스트 → 장치 메모리 | 확장 DRAM과 메모리 풀을 일반 메모리 주소처럼 접근 |
CXL 1.1은 한 호스트에 메모리 확장 장치를 붙이는 단계였습니다. CXL 2.0은 스위치를 도입해 여러 호스트가 메모리 장치를 풀로 사용할 수 있게 했고, CXL 3.x는 다단 스위치와 패브릭, 장치 간 직접 접근 범위를 넓혔습니다. 2026년 2월 공개된 CXL 4.0 규격은 PCIe 7.0을 바탕으로 최대 전송률을 64GT/s에서 128GT/s로 높이고 여러 업스트림 포트를 논리적으로 묶는 기능을 추가했습니다.
규격의 최신 버전과 실제 설치된 하드웨어는 구분해야 합니다. Beluga가 사용한 것은 CXL 2.0이고, Meta의 생산 시스템 Vistara도 CXL 2.0 기반입니다. CXL 4.0의 문서가 존재한다고 해서 128GT/s 장치와 스위치, CPU와 GPU의 직접 연결이 데이터센터에 배치됐다는 뜻은 아닙니다.
AI 모델의 어느 연산에 CXL이 들어가나
LLM 추론은 크게 프리필과 디코드로 나뉩니다. 프리필은 입력 프롬프트 전체를 병렬 처리해 첫 토큰과 각 토큰의 Key·Value 상태를 만들고, 디코드는 그 KV 캐시를 읽으며 한 토큰씩 생성합니다. 반복되는 시스템 프롬프트, 긴 문서, 멀티턴 대화의 앞부분이 같다면 이전에 계산한 KV를 재사용해 프리필 연산을 건너뛸 수 있습니다.
Beluga의 CXL 메모리 풀은 이 계산과 계산 사이에 들어갑니다. 첫 요청은 GPU HBM에서 프리필을 수행한 뒤 KV 블록을 CXL 풀에 씁니다. 같은 접두부를 가진 다음 요청은 CXL에서 해당 블록을 GPU HBM으로 가져와 프리필의 일부 또는 전부를 생략합니다. 디코드 중 매 토큰의 어텐션이 CXL 메모리를 직접 읽는 구조가 아닙니다. 활성 KV와 모델 가중치는 GPU HBM에 있고, CXL은 재사용할 KV의 외부 보관소와 공유 경로입니다.
AI 연산 단계별로 보면 CXL의 적합도는 크게 다릅니다.
| 연산 단계 | 주 데이터 | 요구 특성 | CXL의 역할과 우선순위 |
|---|---|---|---|
| 학습 순전파·역전파 | 가중치, 활성값, 그래디언트 | TB/s급 대역폭, 낮은 지연, 빈번한 쓰기 | 후순위. 핫 워킹셋은 HBM과 GPU 패브릭이 담당 |
| 옵티마이저 업데이트 | 파라미터·모멘텀 상태 | 큰 용량, 지속적인 읽기·쓰기 | CPU 오프로딩 계층으로 조건부 가능, 연산 경로에는 느림 |
| 데이터·모델 적재 | 학습 데이터, 모델 샤드 | 큰 순차 전송, 용량 | 호스트 DRAM 확장과 스테이징에 유용 |
| 체크포인트 | 모델·옵티마이저 스냅샷 | 큰 용량, 내구성, 장애 복구 | DRAM 버퍼로는 가능하지만 영구 보관은 SSD·스토리지 영역 |
| 추론 모델 가중치 | 매 레이어에서 반복 읽는 텐서 | 매우 높은 읽기 대역폭 | 후순위. 핫 가중치는 HBM, 콜드 전문가는 HBF 등 별도 계층 후보 |
| 프리필 결과·공통 접두부 | 완성된 KV 캐시 | 큰 용량, 재사용, 블록 단위 전송 | 핵심 후보. Beluga가 검증한 영역 |
| 프리필 → 디코드 전달 | 요청별 KV 캐시 | 낮은 전달 지연, 공유 | 핵심 후보. 같은 랙에서 CXL이 RDMA와 경쟁 |
| 디코드 중 활성 KV | 매 토큰마다 읽고 새 KV를 씀 | 지연·대역폭·쓰기 모두 중요 | HBM 우선, CXL은 비활성 블록의 조건부 오버플로 |
| 종료된 대화·콜드 KV | 재사용 확률이 낮은 상태 | 용량과 비용 우선 | SSD·원격 스토리지 우선, CXL은 웜구간에 한정 |
핵심 구분은 데이터의 온도입니다. CXL은 HBM보다 차갑고 SSD보다 뜨거운 데이터, 즉 곧 다시 쓸 가능성이 있지만 GPU마다 복제하기에는 큰 데이터에 적합합니다.
Beluga는 16개 H20과 8TB CXL 풀을 연결했습니다
Beluga는 시뮬레이션이 아니라 상용 부품으로 만든 랙 규모 시험 시스템입니다. 두 서버에 각각 인텔 Xeon Platinum 8575C CPU 2개, DDR5 2TB, NVIDIA H20 96GB GPU 8개와 ConnectX-7 NIC 4개를 설치했습니다. CXL 쪽은 서버마다 PCIe 5.0 x16 어댑터 2개를 쓰고, XConn XC50256 CXL 2.0 스위치 두 칩과 DDR5-4800 256GB 장치 32개로 8TB 풀을 구성했습니다.
| 항목 | Beluga 시험 구성 |
|---|---|
| GPU 서버 | 2대 |
| GPU | 서버당 H20 96GB 8개, 합계 16개 |
| 호스트 DRAM | 서버당 DDR5-4800 2TB |
| RDMA 비교군 | 서버당 ConnectX-7 듀얼포트 200Gbps 4개, 합계 4TB DRAM 풀 |
| CXL 연결 | 서버당 PCIe 5.0 x16 어댑터 2개 |
| CXL 풀 | 8TB, DDR5-4800 256GB 장치 32개 |
| CXL 스위치 | XConn XC50256 CXL 2.0 칩 2개 |
| 논문이 제시한 확장 범위 | 최대 16개 서버, 풀 총 대역폭 1TB/s |
| 공정한 비교를 위한 캐시 용량 | Beluga와 RDMA 모두 2TB로 제한 |
소프트웨어는 vLLM v0.8.5의 prefix caching을 사용했고, 비교군은 MoonCake v3.2와 LMCache v0.3.1, NVIDIA Dynamo v0.4.1입니다. 기본 모델은 양자화하지 않은 Qwen3-32B였습니다. 주 워크로드 LV-Eval의 입력은 모두 1만5천 토큰을 넘었고, 연구진은 2K·4K·8K로 자른 변형도 함께 시험했습니다.
이 조건은 Beluga가 잘하는 문제를 분명하게 보여줍니다. Qwen3-32B 가중치가 GPU당 60.0GB를 차지해 H20에서 KV 캐시에 남은 공간은 28.3GB였고, GPU HBM의 KV 적중률은 최고 14.6%였습니다. 프롬프트가 길수록 재계산 비용과 이동할 KV의 크기가 커지므로 외부 캐시의 가치도 커집니다. 짧은 질의와 접두부 중복이 적은 일반 챗봇 트래픽에 같은 개선 폭을 적용할 수 없는 이유입니다.
7.35배는 모든 캐시가 적중한 2차 실행의 수치입니다
Beluga 논문은 캐시를 만드는 첫 실행과 이미 만들어진 캐시를 읽는 두 번째 실행을 분리했습니다. 첫 실행도 약 30%의 캐시 적중이 있었지만 새 KV를 계산하고 CXL 풀에 써야 했습니다. 두 번째 실행은 모든 KV가 미리 채워져 있어 프리필을 캐시 재사용으로 대체했습니다.
| LV-Eval 결과 | MoonCake, 첫 실행 | Beluga, 첫 실행 | MoonCake, 전량 캐시 적중 | Beluga, 전량 캐시 적중 |
|---|---|---|---|---|
| 평균 TTFT | 19.66초 | 17.22초 | 13.00초 | 1.36초 |
| P99 TTFT | 41.65초 | 44.60초 | 39.91초 | 5.02초 |
| 평균 TPOT | 1.97초 | 1.54초 | 1.10초 | 0.15초 |
| P99 TPOT | 20.84초 | 16.14초 | 10.58초 | 1.34초 |
| 처리량 | 1.02 QPS | 1.24 QPS | 1.54 QPS | 11.32 QPS |
전량 캐시 적중에서는 MoonCake 대비 평균 TTFT가 89.6% 줄고 QPS가 7.35배가 됐습니다. 반면 첫 실행에서는 평균 TTFT가 12.4% 줄고 QPS가 21.5% 늘었습니다. P99 TTFT는 오히려 MoonCake의 41.65초보다 Beluga의 44.60초가 길었습니다. 대표 수치는 CXL의 최대 가능성을 보여주지만, 캐시가 비어 있거나 새 접두부가 많은 트래픽의 결과는 아닙니다.
논문 안에도 숫자 불일치가 있습니다. 초록과 결과 표는 처리량 7.35배를 제시하지만, 서론의 기여 요약은 MoonCake 대비 최대 4.79배라고 적었습니다. 공개된 버전의 본문만으로 두 수치의 차이를 설명하는 별도 조건은 확인되지 않습니다. 따라서 7.35배는 표 5의 전량 캐시 적중 실험값으로 인용할 수 있지만, 논문 전체를 대표하는 단일 일반화 수치로 사용해서는 안 됩니다.
또 하나의 중요한 결과는 블록 크기입니다. vLLM의 기본 KV 블록은 16토큰인데, RDMA 기반 MoonCake는 통신 오버헤드를 줄이기 위해 256토큰 슈퍼블록을 사용했습니다. MoonCake가 16토큰 블록을 그대로 전송하면 캐시 적중 TTFT가 13.0초에서 76.8초로 늘어 최초 재계산보다 느려졌습니다. Beluga는 메모리 주소를 직접 읽고 쓰는 방식으로 16토큰 블록을 유지했습니다. CXL의 장점은 최대 순차 대역폭보다 작고 흩어진 KV 블록을 네트워크 메시지로 포장하지 않는 것에서 더 크게 나타났습니다.
CXL이 RDMA보다 빨랐던 이유는 데이터 경로에 있습니다
RDMA는 원격 서버 메모리를 낮은 지연으로 읽고 쓰는 성숙한 기술입니다. GPUDirect RDMA를 사용하면 NIC가 CPU 복사 없이 GPU 메모리로 직접 전송할 수 있습니다. NVIDIA Dynamo도 분리형 추론에서 프리필 GPU와 디코드 GPU 사이의 KV 전송에 RDMA를 사용합니다.
그러나 원격 KV가 작고 비연속적인 블록으로 흩어져 있으면 요청 준비, 큐 관리, 완료 확인과 동기화의 고정 비용이 커집니다. Beluga 논문의 H20 마이크로벤치마크에서 16KB 전송은 총 10.55마이크로초가 걸렸는데, 실제 데이터 이동은 2.68마이크로초이고 약 8마이크로초가 커널 실행과 동기화였습니다. CXL은 메모리 풀이 주소 공간에 매핑되므로 CUDA 커널이 여러 위치를 한 번에 읽거나 쓸 수 있습니다.
Beluga가 측정한 작은 비연속 KV 읽기에서는 차이가 더 컸습니다. 16토큰을 불러올 때 Llama3-8B는 RDMA 2,670마이크로초와 CXL 97마이크로초, Qwen3-32B는 RDMA 5,260마이크로초와 CXL 211마이크로초였습니다. Qwen3-32B의 CXL 지연이 95.9% 낮았습니다. 반대로 큰 연속 전송에서는 RDMA의 성숙한 대역폭과 GPUDirect 경로가 여전히 강합니다.
제어 경로도 단순해졌습니다. 64바이트 요청의 QD 1에서 Beluga의 CXL-RPC 왕복 지연은 2.11마이크로초, RDMA-RC는 8.39마이크로초, RDMA-UD는 8.83마이크로초였습니다. QD 128의 단일 스레드 처리량은 CXL-RPC 1,213만 ops, RDMA-RC 450만 ops, RDMA-UD 665만 ops였습니다. 다만 연구진은 CXL-RPC의 신뢰성 보장이 RDMA보다 낮고 상위 소프트웨어가 이를 보완해야 한다고 명시했습니다. Beluga는 랙 내부 성능과 비용을 우선한 구현이며 RDMA 전체를 대체하는 시스템이 아닙니다.
현재 CXL 경로도 GPU에는 충분히 빠르지 않습니다
CXL의 약점은 HBM과 비교하면 분명합니다. Beluga의 단일 경로에서 CPU가 CXL을 읽는 속도는 46.2GB/s, 쓰는 속도는 33GB/s였습니다. GPU와 CXL 사이의 실효 대역폭은 26GB/s로, 연구진이 측정한 GPU 자체 PCIe 대역폭 55.4GB/s보다 낮았습니다. HBM의 TB/s급 대역폭과는 비교 범주가 다릅니다.
병목은 CXL 메모리 장치보다 CPU 루트 컴플렉스에 있었습니다. 현재 토폴로지에서 GPU 데이터는 PCIe 스위치, CPU 루트 컴플렉스, CXL 스위치를 차례로 통과합니다. GPU와 CXL 스위치의 직접 연결은 논문이 제시한 미래 구조입니다. 두 GPU·어댑터 경로를 병렬로 사용하면 합산 대역폭이 46GB/s로 늘었고, 32개 메모리 장치에 데이터를 2MB 단위로 인터리빙하자 전량 캐시 적중 QPS가 8.49에서 11.32로 33.2% 증가했습니다. CXL을 꽂는 것만으로 성능이 나오는 것이 아니라 토폴로지와 데이터 배치가 결과를 결정합니다.
CXL 2.0의 다중 호스트 캐시 일관성도 자동이 아니었습니다. 한 호스트의 CPU 캐시에 남은 쓰기 결과를 다른 호스트가 오래된 값으로 읽을 수 있습니다. Beluga는 KV의 한 블록에 쓰기 주체는 하나이고 읽는 주체는 여러 개라는 특성을 이용해, uncacheable 메모리 설정, DDIO 비활성화, non-temporal store와 CLFLUSH를 조합했습니다. CXL이 메모리 주소를 제공해도 공유 상태의 정확성과 장애 복구는 소프트웨어가 책임져야 합니다.
알리바바 실험이 증명한 것과 증명하지 않은 것
Beluga의 가장 강한 증거는 상용 CXL 스위치와 실제 GPU 16개에서 vLLM을 구동했다는 점입니다. FPGA 모형이나 시뮬레이션을 넘어, GPU가 여러 호스트에 공유된 8TB 풀의 KV를 읽고 쓰며 장문 추론의 시간을 줄일 수 있음을 보였습니다. 특히 작은 비연속 블록과 전량 접두부 재사용에서 CXL의 메모리 의미론이 RDMA 메시지 처리보다 유리하다는 결과는 분명합니다.
반대로 다음 항목은 아직 증명되지 않았습니다.
| 확인된 것 | 아직 확인되지 않은 것 |
|---|---|
| 상용 CXL 2.0 스위치 기반 2서버·16GPU 시험 | 알리바바 클라우드의 생산 서비스 배치 규모와 가동률 |
| Qwen3-32B와 장문 LV-Eval에서의 개선 | 여러 모델·GPU·실제 고객 트래픽의 평균 개선 |
| 2TB로 맞춘 MoonCake 대비 결과 | 최신 GPUDirect·NIXL 최적화 RDMA와의 동등 조건 비교 |
| 전량 캐시 적중 시 7.35배 QPS | 낮은 접두부 적중률과 짧은 문맥의 경제성 |
| 랙 내부 CXL-RPC의 낮은 지연 | RDMA 수준의 신뢰성, 장애 격리, 재전송, 멀티테넌시 |
| 8TB 풀의 기능과 접근 가능성 | CXL 3.x·4.0 다단 패브릭의 실제 상호운용성 |
따라서 Beluga의 의미는 CXL이 모든 LLM 서버의 기본 메모리가 됐다는 것이 아닙니다. LLM 추론의 KV 캐시는 블록이 작고 재사용이 많을 때 네트워크 객체보다 공유 메모리 객체로 다루는 편이 유리할 수 있다는 첫 상용 하드웨어 증거에 가깝습니다.
서방 하이퍼스케일러에도 적용할 수 있나
기술적으로는 적용할 수 있습니다. Beluga가 사용한 핵심 부품은 인텔 CPU, NVIDIA GPU, XConn 스위치, PCIe 5.0, vLLM과 CXL 2.0입니다. 중국 고유의 프로토콜이나 가속기를 전제로 하지 않습니다. 프리필과 디코드 분리, 접두부 캐싱, 멀티턴 대화와 RAG의 공통 문서 재사용도 지역과 무관한 추론 문제입니다.
서방권에서 CXL의 생산 배치 가능성은 이미 Meta가 다른 워크로드로 입증했습니다. Meta의 ISCA 2026 논문 Vistara는 자체 CXL 2.0 Type 3 ASIC과 운영체제 메모리 계층화 소프트웨어를 수백만 대 규모의 생산 서버에 배치했다고 보고했습니다. 폐기 예정 서버의 DDR4 DIMM을 재사용해 서버당 로컬 DDR5 768GB에 CXL DDR4 256GB를 더했고, 뜨거운 페이지는 로컬 DRAM에 두고 차가운 페이지를 CXL로 내렸습니다.
Meta에 따르면 전체 서버의 43.7%가 메모리 용량 제약을 받고 있었습니다. Vistara의 CXL 메모리는 읽기 대역폭 48GB/s로 로컬 DDR5의 497GB/s보다 훨씬 낮았고, 대역폭 사용률 60%에서 지연도 로컬 234ns와 CXL 372ns로 차이가 났습니다. 그럼에도 차가운 페이지만 배치해 추천 모델용 ML 파라미터 서버의 서버 수를 25% 줄이고 처리량을 12% 높였으며, 5.1TB 생산 모델에서는 처리량 4%와 컴퓨팅 용량 25% 절감을 보고했습니다.
| 구분 | 알리바바 Beluga | Meta Vistara |
|---|---|---|
| 상태 | 연구용 실제 하드웨어 클러스터 | 수백만 대 규모 생산 배치 보고 |
| CXL 방식 | CXL 2.0 스위치 공유 풀 | CXL 2.0 Type 3 메모리 확장 |
| 주 연산 | GPU LLM 추론 | CPU 중심 추천·데이터·캐시·개발 인프라 |
| 주 데이터 | 반복 접두부의 KV 캐시 | 콜드 페이지, 임베딩·파라미터 샤드 |
| 성능 원리 | 작은 KV의 load/store와 다중 GPU 공유 | 로컬 DRAM에 핫페이지, CXL에 콜드페이지 |
| 대표 효과 | 전량 캐시 적중 시 MoonCake 대비 QPS 7.35배 | ML 파라미터 서버 25% 적은 서버, 처리량 12% 증가 |
| 남은 과제 | 신뢰성·직결 GPU·다양한 트래픽 검증 | GPU LLM KV 캐시에 대한 직접 검증 아님 |
Vistara는 CXL 자체가 서방 하이퍼스케일에 적용 가능하다는 강한 증거입니다. 그러나 Beluga의 LLM KV 결과를 재현한 것은 아닙니다. Meta의 ML 사례는 추천 시스템의 임베딩과 파라미터 서버이며 CPU 메모리 계층화입니다. LLM GPU 클러스터에는 H100·H200·Blackwell의 더 큰 HBM, GPUDirect RDMA, NVLink·NVSwitch와 최적화된 NIXL 경로가 이미 존재합니다. H20과 CPU 바운스가 포함된 MoonCake 비교에서 나온 7.35배는 서방의 최신 가속기와 네트워크에 그대로 옮겨지지 않을 가능성이 큽니다.
적용 여부는 국적보다 토폴로지와 워크로드가 결정합니다. 같은 랙에서 여러 GPU가 긴 공통 접두부를 자주 재사용하고, GPU마다 KV를 복제해 HBM을 낭비한다면 CXL의 조건이 좋습니다. 랙을 넘어서는 전송, 엄격한 장애 격리, 큰 연속 KV 이동이 중심이면 RDMA가 더 자연스럽습니다. CXL과 RDMA를 서로 배타적인 선택보다 랙 내부 웜메모리와 랙 간 네트워크의 두 계층으로 함께 쓸 가능성도 큽니다.
대체 솔루션과의 경쟁은 데이터 온도로 갈립니다
CXL의 경쟁자는 다른 CXL 메모리 업체만이 아닙니다. 같은 메모리 병목을 데이터 크기 자체를 줄이거나, HBM을 효율적으로 배치하거나, 더 빠른 GPU 간 연결과 더 싼 저장장치로 해결할 수 있습니다.
| 해결 경로 | 가장 잘하는 문제 | CXL보다 나은 점 | CXL보다 불리한 점 |
|---|---|---|---|
| GQA·MQA·MLA, KV 양자화·희소화·퇴출 | KV의 바이트와 읽기 자체를 줄임 | 하드웨어 추가 없이 용량·대역폭 동시 절감 | 품질·모델 구조·재학습·커널 지원의 제약 |
| PagedAttention·prefix cache·KV-aware routing | HBM 단편화와 중복 계산 감소 | 기존 GPU에서 즉시 적용 가능 | 물리적 용량과 여러 호스트의 공유 한계 |
| HBM 증설·GPU 추가 | 핫데이터 성능 | 가장 높은 대역폭과 낮은 지연 | 높은 비용, GPU와 HBM 용량의 결합, 유휴 자원 |
| 호스트 DRAM 오프로딩 | 단일 서버의 웜 KV | 기존 하드웨어, 성숙한 소프트웨어 | CPU 메모리 채널과 서버별 용량, 공유 범위 제한 |
| RDMA·GPUDirect·NIXL | 노드·랙 간 KV 전송 | 성숙한 신뢰성, 긴 거리, 큰 연속 전송 | 작은 비연속 블록의 요청·동기화 비용 |
| NVLink·NVSwitch·전용 패브릭 | GPU 간 활성 텐서 이동 | 매우 높은 대역폭, 집단 통신에 적합 | 비싼 폐쇄 토폴로지, 범용 DRAM 풀과 다른 목적 |
| CXL DRAM | 랙 내부 공유 웜 KV와 용량 풀 | load/store, 세밀한 블록, 용량 분리·공유 | HBM보다 느림, GPU 직결·일관성·운영 성숙도 부족 |
| HBF·온패키지 LPDDR | 가속기 가까운 대용량 계층 | CXL보다 짧은 물리 경로와 높은 잠재 대역폭 | 공유·풀링이 어렵고 HBF는 아직 양산 전 |
| SSD·GPU Direct Storage | 콜드 KV와 체크포인트 | 가장 큰 용량과 낮은 GB당 비용 | 마이크로초 이상 지연, 작은 랜덤 접근에 불리 |
첫 번째 경쟁축은 CXL에 데이터를 보내기 전에 데이터 자체를 줄이는 방법입니다. PagedAttention은 KV를 블록으로 나눠 HBM 단편화를 줄이고, GQA·MQA·MLA는 저장할 Key·Value 헤드나 표현을 압축합니다. KV 양자화와 희소 어텐션은 블록당 바이트와 읽을 토큰 수를 줄입니다. 이 방법들은 외부 메모리의 용량뿐 아니라 전송 대역폭도 함께 줄이므로 가장 먼저 검토할 가치가 있습니다. 다만 모델 품질과 커널, 재학습 조건이 따라붙습니다.
두 번째 축은 여러 메모리 계층을 하나의 캐시로 운영하는 소프트웨어입니다. NVIDIA의 KVBM은 GPU HBM, pinned host memory, 원격 RDMA 메모리, 로컬·분산 SSD와 객체 저장소를 하나의 KV 계층으로 다룹니다. CXL은 이 계층 중 웜 DRAM의 구현 방식 하나이며, 캐시 적중 예측과 라우팅, 블록 수명주기 관리 없이 단독으로 효과를 내기 어렵습니다.
세 번째 축은 패키지 안과 밖의 구분입니다. HBF 첫 표준은 NAND를 xPU 패키지 가까이 두어 정적 가중치와 읽기 중심 데이터의 용량을 늘리려는 접근입니다. 삼성 zHBM은 xPU 위에 로직과 DRAM을 쌓아 핫데이터의 대역폭을 높이려는 구조입니다. CXL은 둘보다 느리고 멀지만 여러 서버가 큰 DRAM 풀을 공유하고 용량을 연산칩에서 분리할 수 있습니다. 세 기술은 하나의 선형 속도 계층보다 역할로 나뉠 가능성이 높습니다. zHBM·HBM은 활성 텐서, HBF는 정적 가중치와 읽기 중심 데이터, CXL DRAM은 여러 호스트가 공유하는 웜 KV, SSD는 장기 보관하는 콜드데이터에 각각 적합합니다.
메모리 효율화에서 CXL의 우선순위는 조건부 중상위입니다
CXL을 모든 AI 시스템의 첫 번째 메모리 대안으로 두기는 어렵습니다. 외부 메모리에 쓰기 전에 모델과 KV의 바이트를 줄이고, HBM 할당과 캐시 라우팅을 최적화하는 편이 하드웨어 변경 없이 더 넓은 효과를 냅니다. CXL은 그 뒤에도 남는 공유 가능한 웜데이터의 용량 병목을 해결합니다.
실행 순서는 다음과 같이 잡는 것이 합리적입니다.
| 순서 | 먼저 확인할 질문 | 적합한 해법 |
|---|---|---|
| 1 | 같은 품질에서 KV와 가중치 바이트를 줄일 수 있는가 | GQA·MQA·MLA, 양자화, 희소화, 압축 |
| 2 | HBM 단편화·중복 계산·잘못된 라우팅이 병목인가 | PagedAttention, prefix cache, KV-aware routing, 배칭 |
| 3 | 단일 서버 DRAM으로 충분하고 공유가 필요 없는가 | 호스트 DRAM 오프로딩·NUMA 최적화 |
| 4 | 여러 GPU가 같은 웜 KV를 반복 사용하고 랙 내부 공유가 필요한가 | CXL 확장·풀링의 우선 구간 |
| 5 | 랙 밖 전송과 강한 신뢰성이 필요한가 | RDMA·GPUDirect·NIXL |
| 6 | 데이터가 오래 사용되지 않거나 재사용 확률이 낮은가 | SSD·분산 스토리지 |
워크로드별 우선순위는 더 선명합니다.
장문 RAG·고정 시스템 프롬프트·멀티턴 대화: CXL의 우선순위가 높습니다. 접두부 적중률이 높고 KV가 커서 재계산과 복제 비용이 큽니다.
프리필·디코드 분리형 추론: 같은 랙에서는 높은 후보입니다. 작은 KV 블록과 상태 전달을 load/store로 단순화할 수 있습니다. 랙을 넘으면 RDMA가 우선입니다.
짧은 질의·낮은 접두부 중복: 우선순위가 낮습니다. 캐시를 만들고 외부 메모리에 쓰는 비용을 회수하기 어렵습니다.
학습의 순전파·역전파와 활성 디코드: 후순위입니다. HBM과 GPU 패브릭의 대역폭을 CXL DRAM이 대신할 수 없습니다.
추천 모델·임베딩·CPU 파라미터 서버: 우선순위가 높을 수 있습니다. Meta Vistara가 생산 규모에서 용량 제약과 서버 유휴 자원을 줄인 사례를 제시했습니다.
전체 AI 메모리 효율화의 관점에서 CXL은 첫 번째 수단이 아니라 두 번째 물결의 인프라 수단입니다. 알고리즘과 런타임이 바이트와 중복을 먼저 줄이고, HBM에 남길 핫데이터를 가려낸 뒤, 여러 가속기가 공유할 웜데이터가 충분히 크고 자주 재사용될 때 CXL의 우선순위가 올라갑니다.
실제 채택은 일곱 가지 지표로 판별해야 합니다
Beluga와 같은 CXL KV 풀이 실제 하이퍼스케일 서비스에서 유효한지는 대표 벤치마크보다 다음 지표로 확인해야 합니다.
실제 접두부 적중률: 전량 캐시 적중과 신규 캐시 적재를 분리하고, 시간대별·서비스별 적중률 분포를 공개해야 합니다.
문맥 길이와 블록 크기: 2K·8K·15K 이상에서의 손익분기점과 16·64·256토큰 블록의 성능을 함께 측정해야 합니다.
최신 비교 경로: CPU 바운스가 있는 RDMA뿐 아니라 GPUDirect RDMA, NIXL, 최신 Mooncake·Dynamo와 같은 GPU·네트워크 조건에서 비교해야 합니다.
GPU 세대와 직접 연결: H20뿐 아니라 H100·H200·Blackwell, 더 큰 HBM과 GPU-CXL 직결 토폴로지에서 병목이 어떻게 바뀌는지 확인해야 합니다.
꼬리 지연과 장애 복구: 평균 TTFT뿐 아니라 P99·P999, 스위치와 장치 장애, 재전송, 데이터 일관성과 풀 재구성 시간을 공개해야 합니다.
멀티테넌시와 보안: 호스트와 고객 사이의 메모리 격리, 암호화, 폐기된 KV의 삭제, 주소 공간 권한과 서비스 간 간섭을 검증해야 합니다.
총 시스템 효율: CXL 장치와 스위치 가격만이 아니라 CPU·NIC·케이블·전력·냉각·소프트웨어 운영비, 줄어든 GPU와 서버 수를 함께 계산해야 합니다.
CXL의 자리는 HBM 바깥의 웜메모리입니다
알리바바 Beluga는 CXL이 AI 모델의 어느 곳에서 가치가 생기는지 구체적으로 보여줬습니다. 프리필과 디코드의 행렬 연산을 CXL에서 수행한 것이 아니라, 이미 계산한 장문 접두부의 KV 캐시를 8TB 공유 DRAM에 보관하고 여러 GPU가 작은 블록으로 다시 읽게 했습니다. 전량 캐시 적중 조건에서 RDMA 기반 MoonCake 대비 평균 TTFT 89.6% 감소와 처리량 7.35배가 나온 이유입니다.
동시에 최초 실행의 개선은 평균 TTFT 12.4%와 처리량 21.5%였고, P99 TTFT는 비교군보다 길었습니다. GPU와 CXL 사이 대역폭은 26GB/s에 그쳤으며, CXL 2.0의 다중 호스트 일관성과 CXL-RPC 신뢰성은 소프트웨어 과제로 남았습니다. Beluga는 CXL의 가능성을 증명했지만 알리바바의 생산 배치나 모든 LLM의 우위를 증명하지는 않았습니다.
Meta Vistara는 서방 하이퍼스케일러에도 CXL이 적용 가능하다는 답을 제공합니다. 다만 그 성공 방식은 느린 CXL을 빠른 메모리처럼 쓰는 것이 아니라, 뜨거운 페이지는 로컬 DDR5에 두고 차가운 페이지만 CXL DDR4로 내리는 정확한 계층화였습니다. LLM에서도 같은 원칙이 필요합니다. 활성 가중치와 KV는 HBM, 여러 요청이 다시 쓸 접두부 KV는 CXL, 오래된 상태는 SSD에 둬야 합니다.
CXL의 우선순위는 보편적으로 가장 높지도 낮지도 않습니다. 모델 구조와 런타임으로 줄일 수 있는 바이트를 먼저 줄인 뒤에도, 랙 안의 여러 GPU가 크고 반복되는 웜 KV를 공유해야 한다면 CXL은 RDMA보다 앞설 수 있습니다. 반대로 학습의 핫루프, 짧은 프롬프트, 낮은 캐시 적중률, 랙 간 통신에서는 HBM·전용 패브릭·RDMA와 SSD가 먼저입니다. CXL은 더 빠른 AI 메모리라기보다 비싼 HBM에 무엇을 남길지 결정하게 하는 공유 메모리 계층입니다.
본 글은 2026년 8월 6일 기준 공개된 CXL 규격, 알리바바 클라우드 Beluga 논문, Meta Vistara 논문과 NVIDIA 기술 문서를 바탕으로 작성한 기술·산업 분석입니다. Beluga의 7.35배는 Qwen3-32B, H20 16개, 1만5천 토큰 이상 LV-Eval, 전량 KV 캐시 적중 재실행이라는 특정 조건의 결과입니다. 알리바바의 생산 서비스 배치와 CXL 3.x·4.0 기반 GPU 메모리 풀은 공개 자료로 확인되지 않았습니다. 특정 종목에 대한 투자 판단은 다루지 않습니다.
주요 출처: Beluga 논문 · CXL 4.0 규격 · CXL 2.0 메모리 풀링 설명 · Meta Vistara 논문 · NVIDIA Dynamo RDMA 문서 · NVIDIA KVBM · PagedAttention