CXL Type 1·2·3 디바이스 분류 — Cache·Accelerator·Memory

#한 줄 요약

“같은 CXL 링크라도 어떤 프로토콜 조합을 쓰는지에 따라 완전히 다른 디바이스가 됩니다.” — Type 1은 NIC·HBA가 host 메모리를 캐시, Type 2는 GPU·NPU가 host와 양방향 캐시 공유, Type 3는 메모리 expander. 각 유형은 대표 사례·트래픽 패턴·Linux 인식 경로가 다릅니다.

Ch 10에서 프로토콜 메시지를 봤습니다. 같은 메시지라도 Type 1·2·3 디바이스가 어떻게 사용하는지가 완전히 다릅니다. 이 장은 디바이스 유형 분류와 실 제품 매핑을 정리합니다.

#세 유형의 핵심 차이

CXL은 지원하는 프로토콜 조합으로 디바이스 유형을 정의합니다.

핵심 결정 변수는 어느 방향의 cache coherency가 필요한가입니다.

• Type 1: device → host 캐시 (network packet 메타데이터 등)
• Type 2: 양방향 (GPU shared workload)
• Type 3: host → device (메모리 확장)

#Type 1 — Cache-only Accelerator

Type 1은 자체 메모리 없는 가속기입니다. host 메모리를 cache해서 빠르게 접근합니다.

NIC 시나리오 (packet metadata가 host DRAM 0x1000에 있는 경우):

Type 1은 양산 사례가 아직 적은 영역입니다. 시장의 SmartNIC·DPU 제품 다수가 PCIe 기반에 머무르고, CXL.cache로의 전환은 2025+ 점진 진행 중입니다. 후보 제품군:

이 카테고리들이 CXL Type 1으로 전환될 가능성이 거론되지만 실제 spec 지원·양산은 product별로 다름. 도입 검토 시 해당 제품의 CXL 1.1/2.0 지원 여부를 데이터시트로 확인해야 합니다.

Type 1의 가치는 host RAM의 hot region을 device 측에 prefetch해 PCIe round-trip을 회피하는 것입니다. 네트워크 라우팅 테이블·flow state 같은 hot metadata에 효과적인 영역입니다.

#Type 2 — Accelerator with Memory

Type 2는 자체 HBM/DRAM을 가진 가속기입니다. GPU·NPU·FPGA 가속기가 여기 속합니다.

LLM inference 시나리오 (Type 2 GPU + HBM):

Type 2의 핵심은 cache coherency가 양방향이라는 점. host도 GPU HBM을 직접 load/store할 수 있고, GPU도 host RAM을 캐시할 수 있습니다. Bias 전환으로 coherency overhead를 phase별로 최적화.

대표 사례 (CXL 모드 또는 호환성 명시된 제품 위주):

NVIDIA의 경우 Hopper/Blackwell은 NVLink 중심. CXL 모드 지원 여부와 범위는 제품 변종·시점별로 다름. AMD MI300X는 원래부터 CXL 기반이라 AMD EPYC + Instinct 조합에서 자연스러운 흐름.

#Type 3 — Memory Expander

Type 3은 순수 메모리 디바이스입니다. DRAM 모듈을 PCIe 너머로 노출합니다.

Memory Expander 시나리오 — HDM Decoder가 SPA 0x80_0000_0000을 mem0에 매핑한 경우:

Type 3의 핵심은 device 측 cache 없음. 모든 cache는 host CPU의 L1·L2·L3에 있고, coherency 관리도 host가 단독으로 합니다. 그래서 Type 3는 가장 단순하고 가장 흔합니다.

대표 사례:

Ch 9에서 봤듯 Samsung·SK Hynix 두 한국 회사가 HBM 시장 우위를 CXL Type 3에 확장하는 중입니다.

#Linux 인식 경로 — 유형별

Linux는 어떤 드라이버를 binding하느냐로 유형을 구분합니다.

1
# Type 3 — 가장 흔한 path
2
$ ls /sys/bus/cxl/devices/
3
mem0/         # cxl_mem 드라이버
4
decoder0.0/   # HDM Decoder
5
region0/      # 사용자가 생성한 region
6

7
# Type 2 — accelerator + memory
8
$ ls /sys/bus/cxl/devices/
9
mem0/         # CXL.mem 영역
10
dev0/         # accelerator (vendor-specific driver)

Type 1은 보통 별도 sysfs 노출 없음 — vendor 전용 드라이버가 CXL.cache를 내부 사용하고 기존 PCI subsystem에 기존 device처럼 노출합니다.

#트래픽 패턴 비교

같은 PCIe 5.0 x16 링크에서 유형별 트래픽 특성:

Type 2가 가장 동적입니다 — phase별로 트래픽이 완전히 달라집니다.

#자주 하는 실수

#”Type 3가 Type 2보다 항상 단순하다”

디바이스 구현은 그렇지만 운영은 다릅니다. Type 3는 대량 메모리 관리·tiered memory·NUMA 통합이 복잡합니다. Type 2는 coherency가 복잡한 대신 사용 패턴이 명확(GPU 같은 컴퓨트). 운영 복잡도가 반드시 디바이스 복잡도와 일치하지 않습니다.

#”Type 1 NIC = 무조건 빠름”

Cache hit rate가 충분히 높을 때만입니다. 불규칙한 packet metadata access는 cache miss → host 라운드트립이라 오히려 느려질 수 있음. 워크로드 access pattern 분석이 Type 1 도입 전 필수입니다.

#”NVIDIA GPU는 NVLink만 쓴다”

GH200·B200부터 CXL 모드 지원. NVLink 도메인 밖(non-NVIDIA host)에서는 CXL Type 2로 동작합니다. NVIDIA 전유물이 아닙니다.

#”Type 3 디바이스에 CXL.cache 트래픽이 보이면 이상”

맞습니다. Type 3은 CXL.io + CXL.mem만 사용. CXL.cache 트래픽이 보이면 spec 위반 또는 firmware bug입니다. cxl event-log로 추적.

#”MI300X와 Hopper는 같은 카테고리”

아닙니다. MI300X는 처음부터 Type 2로 설계됐고, Hopper는 NVLink 기본·CXL Type 2 옵션. 운영 시 CXL 모드 활성화 여부에 따라 트래픽 특성이 다릅니다.

#정리

• CXL 디바이스는 지원 프로토콜 조합으로 Type 1·2·3 세 유형으로 나뉩니다.
• Type 1은 cache-only — NIC·DPU가 host 메모리를 캐시. CXL.io + CXL.cache.
• Type 2는 memory 가진 accelerator — GPU·NPU. 양방향 cache-coherent. 세 프로토콜 다 사용.
• Type 3는 memory expander — DRAM 모듈을 PCIe 너머로 노출. CXL.io + CXL.mem.
• Linux는 cxl_mem·vendor-specific 드라이버로 유형을 sysfs path에 노출합니다.
• 트래픽 패턴은 유형별로 매우 다르며, Type 2의 phase별 동적 패턴이 가장 복잡합니다.
• 한국 메모리 두 회사가 Type 3 시장 선두권이며, Type 2에는 Sapeon·Rebellions가 진입.

#다음 편

Ch 12: 메모리 풀링과 데이터센터 토폴로지에서는 디바이스 한 대에서 데이터센터 전체 토폴로지로 시야를 넓힙니다. CXL Switch·Pooling·Fabric·GFAM이 어떻게 multi-host 메모리 공유를 가능하게 하는지, 그리고 시리즈 마무리까지.

#관련 항목

• Ch 9: CXL.mem 분석 — HBM·GDDR·DDR 다음의 메모리 계층
• Ch 10: CXL.mem 프로토콜 분해
• Ch 12: 메모리 풀링과 데이터센터 토폴로지 (다음 편)
• Embedded Performance Engineering Ch 29: CXL Interconnect 분석
• Modern Embedded Recipes Ch 149: PCIe → CXL 진화