AI

CXL이란? Compute Express Link 완벽 정리 | 메모리 풀링·KV Cache 오프로딩·RDMA 차이까지

marvin-jung 2026. 5. 15. 21:40
반응형
SMALL
CXL이란? Compute Express Link 완벽 정리 | 메모리 풀링·KV Cache 오프로딩·RDMA 차이까지
CXL(Compute Express Link)은 PCIe 5.0/6.0 위에 캐시 일관성을 얹은 차세대 메모리 인터커넥트 표준입니다. CXL 1.1·2.0·3.x 버전별 차이, CXL.io/CXL.cache/CXL.mem 프로토콜, 메모리 풀링과 Stranded Memory, LLM KV Cache 오프로딩에서 RDMA와 CXL의 Tail Latency 차이, 그리고 삼성·SK하이닉스 CMM 등 주요 플레이어 동향까지 한 번에 정리했습니다.
TECH NOTE · 2026
PCIe 위에 캐시 일관성을 얹은 표준 메모리 프로토콜. 일부 영역에서는 의미 있는 변화를 만들고 있고, 다른 영역에서는 아직 갈 길이 남아 있습니다.
메타·마이크로소프트·삼성·SK하이닉스 등이 CXL 생태계에 투자하고 있는 것은 사실입니다. 다만 모든 시나리오에서 즉각적인 효과가 나오는 것은 아닙니다. 이 글에서는 CXL이 무엇을 시도하고 있는지, 어떤 영역은 이미 양산 가능하고 어떤 영역은 여전히 PoC 단계인지를 구분해서 정리합니다.
1. 들어가며, CXL은 왜 등장했나

지난 30년간 컴퓨팅 시스템의 발목을 잡아온 가장 익숙한 문제 중 하나가 메모리 벽(Memory Wall)입니다. CPU 성능 향상 속도에 비해 DRAM 용량과 대역폭의 발전이 느렸고, LLM(거대 언어 모델)의 확산은 이 격차를 더욱 두드러지게 만들었습니다.

대형 모델 한 번을 추론하는 데에 수백 GB의 메모리가 필요하고, 컨텍스트가 길어질수록 KV Cache가 GPU의 HBM(High Bandwidth Memory)을 빠르게 잠식합니다. HBM은 비싸고 용량이 제한적이며, SSD나 네트워크 너머로 옮기면 성능 대가가 따릅니다.

이러한 상황에서 거론되는 후보 기술 중 하나가 CXL(Compute Express Link)입니다. 일부에서는 "PCIe 5.0 위에 얹은 또 하나의 프로토콜에 불과하다"는 평가도 나옵니다. 물리 계층은 분명히 PCIe와 동일합니다. 다만 그 위에 흐르는 시맨틱이 달라서, 로드/스토어(load/store) 시맨틱과 캐시 일관성을 제공한다는 차별점이 있습니다. 이 차이가 메모리 풀링이나 이종 가속기 협업 같은 영역에서 새로운 설계 옵션을 열어줍니다.

JARGON BUSTER
잠깐, "시맨틱(semantic)"이 뭔가요?

"시맨틱"이라는 단어가 어렵게 들리지만, 풀어 쓰면 그냥 "어떤 방식으로 다루느냐" 정도의 의미입니다. 같은 데이터 접근이라도 어떤 약속·문법으로 주고받느냐에 따라 시맨틱이 달라지고, 이 글에서 자주 비교되는 두 가지가 있습니다.

📚 메모리 시맨틱 (load/store)
CPU가 메모리 주소에 직접 읽고 씁니다. 책장에 손 뻗어 책 꺼내듯 한 번의 명령(mov·load·store)으로 끝납니다. 코드 한 줄로 표현됩니다.
📨 메시지 시맨틱 (send/recv)
"이 데이터 주세요" 요청을 패킷으로 보내고 응답을 기다립니다. 도서관 사서에게 부탁하듯 절차가 따릅니다. RPC 호출이나 RDMA Read/Write가 대표 예입니다.
메모리 시맨틱 (CXL · 로컬 DRAM)
// 한 줄로 끝. CPU가 알아서 처리 int x = array[i];
메시지 시맨틱 (RDMA · 분산 KV)
// 요청·전송·대기·수신 절차 rdma_post_read(qp, addr, len); poll_completion(cq); parse(buffer);

CXL의 핵심은 원격에 있는 메모리도 마치 로컬 메모리처럼 load/store 한 줄로 다룰 수 있게 한다는 점입니다. 반면 RDMA는 빠르긴 해도 결국 메시지 시맨틱이라 매번 송수신 절차가 따릅니다. KV Cache처럼 작은 단위로 빈번하게 접근하는 워크로드에서 이 절차가 누적되면 무시할 수 없는 차이가 생깁니다.

이 글에서 다루는 내용
CXL의 본질(프로토콜 3종), 버전별 진화(1.1 → 3.x), CXL이 풀려고 하는 두 문제(Stranded Memory와 KV Cache), RDMA 오프로딩과의 비교, 응용 분야의 성숙도, 주요 플레이어, 그리고 가장 중요한 부분인 현실적 한계와 채택을 가로막는 요인들까지 정리합니다.
2. CXL의 본질, 프로토콜 3종 세트

CXL을 한 줄로 요약하면 다음과 같습니다. "PCIe 5.0/6.0의 물리 계층을 그대로 사용하면서, 그 위에 캐시 일관성을 가진 메모리 시맨틱 프로토콜을 올린 표준."

이를 구성하는 세 가지 서브 프로토콜이 있고, 디바이스 종류에 따라 셋 중 일부만 사용합니다.

CXL.io
I/O Discovery & Config
PCIe와 거의 동일한 역할을 합니다. 디바이스 발견, 초기화, 인터럽트 등 기본 I/O 기능을 담당하며, 모든 CXL 디바이스가 지원합니다.
CXL.cache
Device → Host Memory
디바이스(가속기 등)가 호스트 CPU의 메모리를 일관성 있게 캐싱합니다. 가속기와 CPU가 같은 메모리 공간을 공유하는 효과를 냅니다.
CXL.mem
Host → Device Memory
호스트 CPU가 디바이스에 붙은 메모리에 직접 로드/스토어로 접근합니다. 메모리 확장과 풀링 시나리오의 핵심 프로토콜입니다.
디바이스 타입 (Type 1, 2, 3)

위 세 프로토콜의 조합에 따라 CXL 디바이스는 세 가지 타입으로 나뉩니다.

타입 사용 프로토콜 대표 예시
Type 1 CXL.io + CXL.cache 스마트NIC, 캐시 일관성이 필요한 가속기 (자체 메모리 없음)
Type 2 CXL.io + CXL.cache + CXL.mem GPU, FPGA 등 자체 메모리를 가진 가속기 (양방향 일관성)
Type 3 CXL.io + CXL.mem 메모리 확장기, 메모리 풀링 노드. 현재 양산이 가장 활발한 카테고리

본 글에서 주로 이야기할 메모리 풀링과 KV Cache 오프로딩 시나리오는 대부분 Type 3 디바이스를 가정합니다. CXL.mem만으로 호스트 CPU가 외부 메모리를 비교적 일관된 방식으로 사용할 수 있게 됩니다.

3. CXL의 진화 (1.1에서 3.2까지)

CXL은 2019년 인텔이 주도해 컨소시엄을 만든 이후 꾸준히 스펙을 발전시켜 왔습니다. 다만 스펙 발표와 실제 양산·배포 사이에는 항상 시차가 존재합니다.

CXL 1.0 / 1.1
2019 · PCIe 5.0 기반
최초 스펙. 단일 호스트와 단일 디바이스의 직결(Direct Attach)만 지원. Type 1/2/3 디바이스 정의. 메모리 확장의 첫걸음.
CXL 2.0
2020 · 스위칭과 풀링 도입
CXL Switch가 도입되어 단일 호스트가 여러 디바이스에 접근 가능. 메모리 풀링의 토대 마련. 다만 한 번에 한 호스트만 특정 메모리 영역에 접근 가능(MLD 모드 제한).
CXL 3.0
2022 · PCIe 6.0, 패브릭 정의
대역폭 두 배(64GT/s). 다단(multi-level) 스위칭과 패브릭 토폴로지 지원. 메모리 공유(Memory Sharing) 명시. 다만 스펙 정의 시점과 실제 상용 스위치 등장 사이에는 수년의 간격이 있습니다.
CXL 3.1
2023 · 보안과 신뢰성
Trusted Execution Environment(TEE) 지원, 패브릭 관리 개선, GFAM(Global Fabric Attached Memory) 정의. 데이터센터 운영 관점의 요구사항 반영.
CXL 3.2
2024 · 운영 기능 추가
호스트와 디바이스 간 모니터링 강화, 메모리 RAS 개선, OS 친화적 관리 기능 추가. 양산 디바이스가 점차 늘어나는 단계.
한 가지 흐름으로 정리
CXL 1.x는 "내 서버 안의 메모리를 늘리는" 직결 기술, 2.0은 "여러 디바이스를 풀로 묶는" 시작점, 3.x는 "여러 호스트가 패브릭으로 메모리를 공유하는" 확장형 비전입니다. 다만 비전과 양산 시점은 다릅니다. 2026년 현재 시장에서 의미 있게 확산되고 있는 것은 1.1과 2.0의 일부 시나리오입니다.
4. CXL이 풀려고 하는 두 가지 문제

CXL이 데이터센터에서 검토되는 이유는 크게 두 가지 흐름과 맞물립니다. 둘 다 CXL 단독으로 해결되는 문제는 아니지만, CXL이 의미 있게 기여할 수 있는 영역들입니다.

문제 1. Stranded Memory

현대 클라우드 데이터센터의 비효율 중 하나로 꼽히는 것이 스트랜디드 메모리(Stranded Memory)입니다. 마이크로소프트 애저(Azure)가 발표한 분석에 따르면, 평균적으로 서버 메모리의 약 25% 정도가 사용되지 못한 채 묶여 있다고 합니다.

~25%
Azure 기준
평균 Stranded 비율
~50%
서버 BoM에서
DRAM 비중
한 자릿수%
초기 분석 기준
예상 TCO 절감
랙 단위
현실적
풀링 도메인

발생 이유는 단순합니다. VM(가상머신)을 띄울 때 CPU 코어와 메모리는 같은 서버에서 함께 할당되어야 하는데, CPU가 먼저 차거나 메모리가 먼저 차는 불균형이 자주 일어납니다. 이 격차가 곧 "버려지는 메모리"입니다.

CXL 메모리 풀링은 이에 대한 한 가지 해법으로 제시됩니다. 메모리를 서버 밖으로 분리해 풀로 묶고 호스트에 동적으로 할당하면 사용률을 끌어올릴 수 있습니다. 다만 풀링이 실제로 효과를 내려면 워크로드 패턴, 스케줄러, 패브릭 거리 등 여러 조건이 맞아야 하며, 모든 데이터센터에서 동일한 효과가 나오는 것은 아닙니다.

문제 2. AI 추론의 메모리 압박

두 번째 흐름은 LLM 추론입니다. 모델 파라미터 자체가 거대해졌고, 긴 컨텍스트 추론에서는 KV Cache가 토큰 길이에 비례해 커집니다.

KV Cache 메모리 부담의 규모감
대형 모델, 긴 컨텍스트, 동시 사용자 수가 늘어날수록 KV Cache가 차지하는 메모리가 빠르게 증가합니다. 모델·구현·양자화 방식에 따라 차이가 크지만, 동시 사용자 수십~수백 명 규모에서 GPU HBM만으로 감당하기 어려워지는 지점이 분명히 존재합니다. 어떤 식으로든 오프로딩이 필요해지는 셈입니다.

이 KV Cache를 어디로 옮길 것인지에 대한 답은 한 가지가 아닙니다. CPU DRAM, NVMe SSD, RDMA 원격 노드, CXL 메모리 모두가 후보이며, 각각 장단점이 있습니다. CXL은 그중 하나의 선택지로 검토되고 있습니다.

5. RDMA 오프로딩과 CXL 메모리 풀, 어떻게 다른가

KV Cache 오프로딩의 맥락에서 자주 비교되는 것이 RDMA 기반 분산 캐시와 CXL 메모리 풀입니다. 둘이 경쟁 관계라기보다는, 서로 다른 위치를 지향한다는 표현이 더 정확합니다.

RDMA의 자리, 이미 검증된 해법

RDMA는 InfiniBand나 RoCE(RDMA over Converged Ethernet) 환경에서 광범위하게 쓰이는 기술입니다. CPU 개입 없이 원격 노드의 메모리에 읽고 쓸 수 있고, HPC와 AI 트레이닝 클러스터에 인프라가 깔려 있습니다. 일부 LLM 사업자(예: DeepSeek 류의 분산 캐시)는 KV Cache를 RDMA 기반 분산 KV 스토어로 오프로딩하는 방식을 채택해 왔으며, 실제로 잘 동작합니다.

RDMA의 약점, Tail Latency 변동성

RDMA는 결국 네트워크 위에서 동작하기 때문에 P99·P99.9 같은 꼬리 분포에서 변동이 큰 편입니다. 네트워크 혼잡, 패킷 드롭, RNIC 큐잉 등 변동 요인이 다수 존재합니다. RoCE 환경에서 PFC, ECN 튜닝이 어긋나면 P99.9가 밀리초 단위로 튀기도 합니다.

메모리 접근 레이턴시 비교
대략적인 레퍼런스 값입니다. 실제 수치는 구성과 부하에 따라 달라집니다.
로컬 DRAM
~80~100ns
NUMA 원격
~140~180ns
CXL 메모리(Type 3)
~200~300ns
RDMA(P50, IB)
~1.5~3μs
RDMA(P99, RoCE)
~20~50μs
RDMA(P99.9)
~수백μs+
NVMe SSD
~10~100μs

LLM 추론은 자기회귀(autoregressive) 디코딩 구조상 매 토큰마다 KV Cache를 읽습니다. 한 번의 응답에 메모리 접근이 직렬로 누적되기 때문에, 꼬리 분포가 사용자 체감 응답 시간에 영향을 줍니다. 이 영역에서 CXL의 좁은 레이턴시 분포가 의미를 갖는 경우가 있습니다.

RDMA 기반 KV Cache 오프로딩
  • 기존 IB/RoCE 인프라 재활용
  • 운영 노하우와 도구가 풍부함
  • 대용량 풀 구성과 스케일아웃이 자유
  • 이미 양산 환경에서 검증
  • 꼬리 분포(P99.9) 변동이 큼
  • 네트워크 혼잡에 민감
  • 스위치·RNIC 튜닝 비용
  • RPC/메시지 시맨틱(load/store 아님)
CXL 메모리 풀
  • 로드/스토어 시맨틱(코드 변경 적음)
  • 레이턴시 분포가 좁은 편
  • 캐시 일관성 보장
  • OS가 NUMA처럼 처리 가능
  • 현실적으로 단일 랙 스케일
  • 스위치·컨트롤러 생태계 초기
  • 패브릭 거리 늘면 레이턴시 증가
  • 3.x 멀티 호스트는 본격 도입 전
  • 도구·운영 노하우 부족
정리
RDMA가 "원격 메모리에 메시지로 빠르게 접근하는 기술"이라면, CXL은 "원격 메모리를 로컬처럼 로드/스토어로 다루는 기술"입니다. 둘은 경쟁이라기보다 보완 관계로 자리 잡고 있고, 실제로 많은 빅테크는 둘을 계층적으로 함께 사용하고 있습니다.
현실의 답, 계층화된 KV Cache

현장에서는 한쪽만 고집하기보다 계층화된 KV Cache 시스템을 구성하는 사례가 많습니다. GPU HBM이 가장 뜨거운 데이터, 호스트 DRAM과 CXL 메모리가 그 다음 계층, RDMA로 묶인 원격 노드와 NVMe가 가장 차가운 계층을 담당하는 식입니다.

GPU HBM
~1ns 클래스
~80GB/GPU
로컬 DRAM
~100ns
~수 TB/노드
CXL 메모리 풀
~250ns
~수 TB~수십 TB/랙
RDMA 원격 노드
~3μs (P50)
대규모 스케일
NVMe / 분산 스토리지
~수십μs
사실상 무한
6. CXL 응용 분야, 성숙도 구분해서 보기

CXL이 거론되는 응용 분야는 폭이 넓지만, 모두가 같은 성숙도에 있는 것은 아닙니다. 양산 단계에 가까운 것과 아직 연구·PoC 수준인 것을 구분해서 보아야 합니다.

이미 양산·도입 가능 초기 도입 단계 연구·미래 시나리오
01
양산 가능
메모리 확장 (Memory Expander)
서버 1대당 DIMM 슬롯 한계를 넘어 CXL Type 3로 추가 메모리를 붙입니다. CXL 도입에서 가장 먼저 손에 잡히는 시나리오입니다.
02
초기 도입
메모리 풀링 (Memory Pooling)
여러 호스트가 공통 메모리 풀에서 동적으로 할당받습니다. 일부 하이퍼스케일러가 도입을 진행 중이며, 일반 시장 확산은 진행 중입니다.
03
미래 시나리오
메모리 공유 (Memory Sharing)
CXL 3.0 이후 정의된 기능. 여러 호스트의 일관성 있는 동시 접근. 상용 스위치와 호스트 지원이 충분히 성숙해야 가능한 영역입니다.
04
초기 도입
티어드 메모리 (Tiered Memory)
로컬 DRAM은 핫 데이터, CXL 메모리는 웜 데이터. OS의 자동 페이지 마이그레이션과 결합되어야 효과가 분명해집니다.
05
초기 도입
LLM KV Cache 오프로딩
긴 컨텍스트 추론에서 GPU HBM 부담을 덜기 위한 옵션 중 하나. RDMA, NVMe 오프로딩과 경쟁하며 자리를 찾는 단계입니다.
06
초기 도입
인메모리 DB 가속
SAP HANA, Redis 등 인메모리 DB의 데이터셋이 단일 서버 한계를 넘는 경우 검토 대상. 다만 워크로드의 캐시 미스 패턴이 결정적입니다.
07
미래 시나리오
캐시 일관 가속기
Type 1/2 디바이스로 GPU·FPGA·DPU가 호스트 메모리와 협업. 현재는 NVIDIA NVLink/UVM 등 벤더 솔루션이 더 우세합니다.
08
미래 시나리오
컴포저블 인프라
CPU·메모리·가속기를 패브릭에서 자유 조합. 비전은 매력적이지만 표준 도구·운영 모델·보안 모델이 더 성숙해야 합니다.
09
초기 도입
PMEM 시장의 후계 후보
옵테인 단종 이후 빈자리에 CXL 기반 NV-DRAM 모듈이 시도되고 있습니다. 다만 PMEM 자체의 시장이 크지 않았다는 점도 고려해야 합니다.
7. 주요 플레이어, 누가 무엇을 하는가

CXL 컨소시엄에는 주요 반도체·클라우드 회사가 폭넓게 참여합니다. 다만 참여와 양산·실배포는 별개의 문제입니다. 역할별로 정리하면 다음과 같습니다.

CPU 호스트
Intel · AMD · ARM 진영
(Sapphire Rapids 이후 본격 지원)
메모리 모듈
Samsung · SK Hynix · Micron
(CXL DRAM 모듈 출시·양산)
CXL 컨트롤러
Astera Labs · Marvell · Montage
· Microchip · Rambus
CXL 스위치
XConn · Marvell · Microchip
(2.0 양산, 3.x는 진행 중)
하이퍼스케일러
Microsoft · Meta · Google
(자체 풀링 아키텍처 연구·도입)
서버 OEM
Dell · HPE · Lenovo · Supermicro
(CXL 1.1/2.0 플랫폼 출시)
소프트웨어 / OS
Linux 커널 · VMware · Red Hat
(NUMA·tiering 통합 진행 중)
국내 메모리 기업
Samsung CMM-D · SK Hynix CMM
(메모리 모듈 분야 적극 대응)

국내 메모리 반도체 기업은 CXL 모듈 영역에서 적극적으로 대응하고 있습니다. 삼성전자는 CMM-D(CXL Memory Module – DRAM)로 EDSFF 폼팩터의 CXL 메모리 모듈을 공개해 왔고, SK하이닉스도 CMM 시리즈와 자체 컨트롤러 개발을 진행하고 있습니다. 다만 모듈 양산이 곧바로 수익으로 이어지려면 채택 시장(서버 OEM·하이퍼스케일러)의 본격 도입이 뒤따라야 합니다. 이 부분은 아직 진행 중인 과제입니다.

8. CXL의 한계와 도전과제

CXL이 가진 잠재력만큼이나, 도입을 검토하는 입장에서 짚고 가야 할 한계가 분명히 있습니다. 오히려 이 부분이 글의 균형을 위해 더 중요한 대목입니다.

레이턴시, 가깝지만 로컬은 아니다

CXL 메모리는 로컬 DRAM 대비 약 2~3배의 레이턴시를 가집니다. 200~300ns 수준은 RDMA에 비하면 좋아 보이지만, 캐시 미스가 많은 워크로드에서는 분명히 체감되는 차이입니다. 핫 데이터를 로컬에, 콜드 데이터를 CXL로 분리하는 OS·런타임 차원의 티어링 기술이 받쳐줘야 합니다.

패브릭이 길어질수록 페널티

CXL 3.x로 멀티 호스트, 멀티 스위치 구성을 하면 홉이 늘어나고 레이턴시도 올라갑니다. 현실적으로 CXL은 단일 랙(Rack-scale) 도메인에 가장 적합하며, 데이터센터 전체를 패브릭으로 묶는 시나리오는 아직 검토 단계입니다.

생태계 성숙도와 SW 레디니스

2026년 시점에서 CXL 1.1·2.0 디바이스는 양산되고 있지만, 3.x 스위치, 멀티 호스트 풀링, 메모리 공유는 일부 하이퍼스케일러의 자체 솔루션이나 PoC 수준입니다. OS·하이퍼바이저·런타임 단의 통합도 진행 중이며, 도구·운영 노하우가 충분히 쌓이는 데에 시간이 더 필요합니다.

경쟁 솔루션의 발전

CXL의 효용을 절대화해서는 안 됩니다. HBM 자체의 용량 증가(HBM3, HBM4), GPU 직접 메모리 공유(NVLink, NVL72), 더 빠른 NVMe, 전용 분산 KV 시스템 등 경쟁·보완 솔루션도 동시에 발전하고 있습니다. 어떤 워크로드에서는 굳이 CXL을 쓰지 않는 것이 더 빠르고 단순합니다.

비용과 공급망

CXL 컨트롤러, 리타이머, 스위치 칩은 아직 비싸고 공급사가 제한적입니다. 단순 메모리 확장 시나리오라면 일반 RDIMM이 비용 효율이 더 좋은 경우도 많습니다. 풀링과 공유로 사용률을 끌어올릴 때 비로소 TCO 우위가 발생하는데, 이것이 가능하려면 운영 측면의 변화가 함께 따라와야 합니다.

실제 채택 속도

CXL 컨소시엄 발표와 산업계 분위기에 비해 실제 양산 채택 속도는 더딘 편입니다. 하이퍼스케일러조차 자체 풀링 아키텍처를 도입한 사례는 제한적이고, 일반 엔터프라이즈로 확산되려면 더 많은 검증과 비용 하락이 필요합니다.

한 줄 정리
CXL은 "지금 바로 모든 서버를 갈아엎으라"는 기술이 아닙니다. 특정 워크로드(메모리 사용률이 낮은 클라우드 풀, 대형 KV Cache가 필요한 추론 등)에서 의미 있는 효과가 기대되는 기술이며, 도입은 점진적·선별적이어야 합니다.
9. 마치며, 잠재력과 현실의 거리

다시 첫 질문으로 돌아가 보겠습니다. "PCIe 5.0 위에 얹은 프로토콜인데 왜 주목받는가?"

답은 두 가지로 나눠 보아야 합니다. 한편으로 CXL은 "메모리를 서버에서 분리하라"는 디스어그리게이션(disaggregation) 흐름의 표준 인터페이스입니다. CPU와 메모리가 한 보드에 묶여 있어야 한다는 30년의 통념이 AI 시대에 흔들리고 있고, CXL은 그 변화를 매개할 후보 기술 중 하나입니다.

다른 한편으로, CXL이 그 비전을 단번에 실현하지는 못합니다. 양산 단계에 와 있는 것은 일부 시나리오뿐이고, 실제 채택 속도는 컨소시엄 발표보다 느립니다. 경쟁·보완 기술도 함께 발전하고 있고, 워크로드에 따라 더 단순한 해법이 더 적합한 경우도 많습니다.

RDMA가 "원격 메모리에 메시지로 접근"하는 길을 열었다면, CXL은 "원격 메모리를 로컬처럼 로드/스토어로 다루는" 길의 표준화를 시도하고 있습니다. 둘은 경쟁이 아니라 각자의 자리에서 보완하는 방향으로 정착하고 있고, 실제 빅테크의 KV Cache 시스템도 양쪽을 함께 사용하는 계층적 설계를 택합니다.

2026년의 CXL은 아직 "가능성이 분명하지만 갈 길이 남아 있는" 기술입니다. 향후 2~3년이 양산 채택의 분기점이 될 가능성이 높고, 이 시기에 모듈·컨트롤러·스위치·소프트웨어 생태계가 어떻게 맞물려 발전하느냐가 관건입니다. 과대평가도 과소평가도 곤란합니다. 워크로드에 맞게 균형감 있게 도입하는 자세가 가장 중요합니다.

관련해서 더 다룰 만한 주제
· CXL과 NVMe의 경계 (Memory Semantic SSD)
· 리눅스 커널의 Memory Tiering(MGLRU·DAMON)과 CXL 통합
· CXL.cache 기반 협업과 NVLink·UVM의 비교
· CXL 3.x 멀티 호스트 메모리 공유의 일관성 모델
· 삼성·SK하이닉스 CMM 모듈 라인업 비교
TAGS
#CXL #ComputeExpressLink #메모리풀링 #KVCache #RDMA #TailLatency #LLM추론 #PCIe #데이터센터아키텍처 #메모리반도체
반응형
LIST