CXL.mem 분석 — HBM·GDDR·DDR 다음의 메모리 계층

#한 줄 요약

“HBM은 대역폭을 풀고, DDR은 용량을 풀지만, PCIe 너머의 메모리는 둘 다 못 풉니다.” — CXL.mem은 PCIe 5.0/6.0 위에 cache-coherent 프로토콜을 얹어 호스트 메모리 컨트롤러가 외부 디바이스의 DRAM을 native load/store로 접근하게 합니다. HBM이 on-package 64~192 GB에 머무는 동안, CXL.mem은 card 한 장당 256 GB~2 TB를 50~150 ns 추가 지연에 풀어 줍니다.

Ch 8에서 LLaMA 70B inference에 780 GB 메모리가 필요하다는 걸 봤습니다. H100 5장의 HBM3을 다 묶어도 480 GB입니다. 모자랍니다. PCIe 너머로 DRAM을 끌어와 이 간극을 메우는 길이 CXL.mem입니다. 이 장은 CXL.mem이 메모리 계층의 어디에 끼는지, 어떤 지연·대역폭 비용을 치르는지를 정리합니다.

#메모리 계층의 새 자리

기존 메모리 계층은 세 단이었습니다.

지연·대역폭·용량의 한 자리수씩 차이가 네 단계에 걸쳐 있습니다. 그런데 DDR과 SSD 사이에 큰 간극이 있습니다. 수십 µs의 NAND는 load/store로 못 씁니다. page fault·DMA·드라이버 호출이 끼어듭니다.

CXL.mem은 이 간극을 채웁니다.

CXL.mem은 DDR과 SSD 사이에 지연이 두 배쯤 큰 새 단을 만듭니다. load/store 의미를 잃지 않고 용량을 한 자리수 키우는 자리입니다.

#PCIe 위에 load/store를 얹는 길

CXL의 핵심은 PCIe 물리 계층 재사용입니다. CXL 1.1/2.0은 PCIe 5.0 (32 GT/s) PHY 위에, CXL 3.x는 PCIe 6.0 (64 GT/s) PHY 위에 세 프로토콜을 다중화합니다.

같은 링크에서 세 프로토콜이 시분할로 흐릅니다. CXL.mem의 M2S Req·S2M NDR/DRS 메시지는 *cache line 단위(64 B)*로 DRAM에 read/write를 일으킵니다.

단계별 흐름:

핵심: CPU의 load instruction이 MMU 변환 → 메모리 컨트롤러 → CXL link → CXL.mem device를 거쳐 64 B 라인 한 줄을 가져옵니다. 드라이버 호출 없음. DMA 셋업 없음. NVMe SSD와는 완전히 다른 의미입니다.

이게 가능한 이유는 *호스트의 메모리 컨트롤러가 CXL Root Port를 DDR DIMM과 같은 등급으로 취급하기 때문입니다. HDM Decoder가 물리 주소 일부 범위를 CXL device에 매핑합니다.

#지연·대역폭 실측

같은 PCIe 링크라도 Gen 5 x16과 Gen 6 x16의 차이는 큽니다.

프로토콜 오버헤드가 15~20% 정도 빠집니다. CXL.mem의 transaction overhead와 flow control credit 관리가 들어가서입니다.

지연은 링크 거리·flit 처리 단계·DDR 자체 지연의 합입니다.

Direct attached가 DDR보다 2배쯤 느립니다. Switch 1단이 들어가면 3배. NUMA의 remote 노드 접근(140~180 ns)보다도 살짝 느린 영역입니다.

CXL이 DRAM 대체가 아니라 DRAM의 다음 tier인 이유입니다.

#현세대 디바이스 — 누가 만들고 있나

CXL Type 3 메모리 디바이스는 2024년부터 양산에 들어갔습니다.

특히 Samsung CMM-D와 SK Hynix Niagara는 한국 두 회사의 HBM 너머 메모리 전략의 핵심입니다. HBM 시장의 90%를 가진 두 회사가 CXL 시장에서도 선두권을 노립니다.

Astera Labs Leo는 fabless 모델로 Micron·Samsung DRAM을 2 TB까지 묶어 single CXL card로 제공합니다. Meta·Microsoft Azure 데이터센터에 2024년부터 배치되고 있습니다.

#어디서 쓰면 효과가 크나

CXL.mem의 *지연 페널티(2배)*와 *용량 확장(10배+)*의 트레이드오프가 가치 있는 워크로드는 제한적입니다.

잘 맞는 경우

• LLM inference KV cache — 순차 access가 많아 지연에 덜 민감, 용량 폭증 (Ch 8에서 본 640 GB)
• In-memory database (SAP HANA, Redis) — cold tier를 CXL.mem에 두고 hot tier는 DDR
• 대규모 컨테이너 호스트 — memory overcommit 대신 CXL pool에서 동적 할당
• 과학 계산 (FEM, CFD) — checkpoint·intermediate data를 load/store로 접근

잘 안 맞는 경우

• HPC tight loop — 지연에 민감, HBM/L3가 답
• Training의 weight·activation — 대역폭이 우선, HBM이 답
• graphics·real-time rendering — frame-rate 의존, GDDR이 답

핵심은 지연 200~400 ns에 견디는 워크로드인가입니다.

#OS·소프트웨어 통합

CXL.mem은 load/store가 native로 가능하지만 OS가 인식하고 배치를 결정해야 합니다.

Linux CXL 서브시스템 (kernel 6.0+)

1
sysfs:
2
  /sys/bus/cxl/devices/
3
    ├── root0/           # CXL Root
4
    ├── port0/           # Upstream port
5
    ├── decoder0.0/      # HDM decoder (physical address → device)
6
    ├── mem0/            # Memory device
7
    └── region0/         # 묶인 메모리 영역 (e.g., interleave)
8

9
명령:
10
  cxl list -RT          # 전체 토폴로지
11
  cxl create-region -d decoder0.0 ...   # region 생성
12
  daxctl list           # DAX 디바이스 (RAM 대신 mmap)

CXL 메모리는 두 가지 모드로 호스트에 노출됩니다.

tiered memory 자동화는 Linux NUMA balancing + Promotion/Demotion 데몬이 page activity를 보고 hot page를 DDR로, cold page를 CXL.mem으로 옮깁니다. Meta의 Transparent Page Promotion 패치가 mainline 6.5에 들어갔습니다.

#HBM과 어떻게 공존하나

같은 가속기 보드에 HBM과 CXL.mem이 함께 있는 그림이 2025~2026년 표준입니다.

가정 시스템 구성 — Blackwell-class GPU + CXL pool:

HBM은 weight가 들어가고, CXL은 KV cache pool이 들어갑니다. *Ch 8의 LLaMA 70B (780 GB)*는 HBM 한 장으로는 못 풀던 문제가 CXL 추가로 해결됩니다. 데이터센터는 동일 GPU·다른 CXL 양으로 워크로드별 SKU를 만들 수 있습니다.

#자주 하는 실수

#”CXL.mem은 DRAM을 대체한다”

그렇지 않습니다. 지연이 2~4배 큽니다. DDR DIMM은 socket당 6 TB까지 가는데도 살아남는 이유는 80~100 ns 지연 때문입니다. CXL.mem은 DDR을 대체하는 게 아니라, DDR 너머의 확장입니다.

#”CXL = NVMe와 비슷한 거다”

전혀 다릅니다. NVMe는 block 단위 I/O, 드라이버 호출, page fault입니다. CXL.mem은 cache line 단위 load/store, 드라이버 없음, MMU 변환만입니다. 지연 자리수가 다릅니다. NVMe는 µs, CXL은 ns.

#”CXL.mem은 HBM의 대체”

반대입니다. HBM은 대역폭, CXL은 용량입니다. 완전 보완 관계입니다. HBM이 있으면 CXL이 더 잘 활용되고, CXL이 있으면 HBM에 대역폭만 집중할 수 있습니다.

#”CXL 1.1과 2.0과 3.0은 다 호환된다”

제한적입니다. 디바이스가 backward compat은 보장하지만, switch·pooling·fabric은 2.0/3.x 전용 기능입니다. CXL 1.1 디바이스는 direct attach만 가능합니다. 시스템 설계 시 프로토콜 버전을 정확히 매칭해야 합니다.

#한국 메모리 산업의 위치 — 다시

Ch 1에서 봤듯 HBM은 한국 두 회사가 90% 점유합니다. CXL.mem 시장은 2024~2025년 막 시작된 영역이라 점유율 데이터가 아직 빈약하지만 공급 측 우위가 그대로 이어질 가능성이 큽니다.

CXL.mem은 PCIe·CXL 인터페이스 IP와 DRAM 모듈을 모두 가진 회사가 우위입니다. DRAM 시장의 한국 우위가 CXL.mem 시장으로 자연 확장되는 구조입니다. 차세대로는 HBM과 CXL을 통합한 패키지 형태가 각사 로드맵에서 거론됩니다.

#정리

• CXL.mem은 PCIe 5.0/6.0 위에 cache-coherent load/store를 얹은 프로토콜입니다.
• DDR DIMM과 SSD 사이의 간극에 지연 150300 ns, 대역폭 30120 GB/s, 용량 256 GB~2 TB의 새 tier를 만듭니다.
• 호스트의 HDM Decoder가 물리 주소 일부를 CXL device에 매핑해 드라이버 없이 load/store가 가능합니다.
• HBM 대체가 아닙니다. HBM은 대역폭, CXL은 용량으로 완전 보완 관계입니다.
• LLM inference의 KV cache pool, in-memory DB의 cold tier, 컨테이너 호스트의 overcommit이 가장 잘 맞는 워크로드입니다.
• Linux는 kernel 6.0+에서 CXL 서브시스템과 NUMA balancing으로 자동 tiering을 지원합니다.
• 디바이스 시장은 Samsung CMM-D·SK Hynix Niagara·Astera Labs Leo·Micron Expander로 2024년부터 양산에 들어갔고, HBM 시장의 한국 우위가 CXL.mem으로 자연 확장되고 있습니다.

#다음 편

Ch 10: CXL.mem 프로토콜 분해에서는 M2S·S2M 메시지가 어떻게 흐르는지, HDM Decoder가 어떻게 주소 범위를 매핑하는지, BI·Snoop Filter가 cache coherency를 유지하는 방식을 본격적으로 본격적으로 분해합니다.

#관련 항목

• Ch 8: NPU·GPU에서의 HBM 활용 — KV cache 폭증 문제, CXL.mem이 푸는 자리
• Ch 5: 메모리 대역폭 병목 분석 — Roofline에서 CXL.mem의 자리
• Ch 10: CXL.mem 프로토콜 분해 (다음 편)
• Ch 11: CXL Type 1·2·3 디바이스 분류
• Ch 12: 메모리 풀링과 데이터센터 토폴로지