top of page

OpenAI의 CXL HBM 대체 의문, AI 메모리의 실제 트레이드오프 드러내

2시간 전
11분 분량

고대역폭 메모리의 비용과 희소성을 낮춰야 한다는 압력이 커지는 가운데, OpenAI는 CXL이 HBM을 대체할 수 있다는 주장을 받아들이지 않은 것으로 전해졌다. OpenAI의 한 가속기 연구원은 AI 모델 구동에서 CXL의 설득력 있는 활용 사례를 찾지 못했다고 말했다. Intel의 아키텍처 임원도 별도로 CXL은 HBM 대체재라기보다 스토리지 보완재로 더 적합하다고 주장했다.

이 발언들은 AI 인프라 구매자들에게 매력적으로 들릴 수 있는 한 가지 생각에 이의를 제기한다. CXL(Compute Express Link)은 프로세서가 일관성 있는 인터커넥트를 통해 추가 메모리에 접근하도록 한다. 더 큰 용량, 공유 풀, 유연한 리소스 할당을 약속한다. 그러나 이러한 유연성이 실제 모델 실행에 필요한 대역폭 수요를 없애지는 못한다.

더 큰 맥락은 CXL이 실패했다는 이야기가 아니다. CXL과 HBM은 메모리 문제의 서로 다른 부분을 해결한다는 점이다. HBM은 자주 접근하는 데이터를 매우 높은 대역폭으로 가속기 가까이에 둔다. CXL은 용량을 확장하고 접근 빈도가 낮은 데이터를 더 저렴한 계층으로 옮길 수 있다.

이 구분은 메모리 공급업체, 가속기 설계자, 클라우드 사업자에게 더 똑똑한 계층 구조를 구축해야 한다는 압박을 가한다. 따라서 핵심 경쟁은 CXL과 HBM을 서로 대체 가능한 제품으로 보는 데 있지 않다. 값비싼 AI 프로세서를 계속 가동할 만큼 빠르게 데이터를 이동시키기 위한 물리적 요건과 대체 경제성 사이의 경쟁이다.

OpenAI의 CXL HBM 대체 주장은 대역폭 시험대에 올랐다

보도된 OpenAI와 Intel의 발언은 기술의 무관함을 뜻하지 않으면서도 CXL의 역할을 좁힌다.

이 발언은 2026년 9월 16일 미국 캘리포니아주 산타클라라에서 열린 AI Infrastructure Summit 패널에서 나왔다. Financial News는 가속기 설계 업무를 맡은 OpenAI 연구원 Daniel Morris가 실제 모델 실행에서 CXL의 유용성에 의문을 제기했다고 보도했다.

Morris는 보도에 따르면 “실제로 AI 모델을 실행하는 관점에서 CXL의 용도를 찾을 수 없다”고 말했다. 그는 대형 모델이 거의 접근하지 않는 비활성 정보를 보관하는 역할 하나를 가능한 용도로 꼽았다.

Intel의 시스템온칩 아키텍처 책임자 Vidhya Thyagarajan도 보도에 따르면 비슷한 구분을 제시했다. CXL을 통한 메모리 풀링은 유용할 수 있지만 HBM을 대체하지는 못한다는 것이다. 그는 CXL을 보조 스토리지의 보완재로 규정했다.

보도된 Intel 입장에서 가장 중요한 부분은 데이터 이동에 관한 것이었다. 번역된 패널 보도에 따르면 GPU와 CXL 연결 메모리 사이를 이동하는 정보는 “결코 HBM만큼 빠르지 않다.”

이 발언에는 신중한 출처 표기가 필요하다. 이는 공식 OpenAI 또는 Intel 정책 성명이 아니라 한국 언론이 보도하고 TrendForce가 요약한 내용이다. उपलब्ध한 영어 Financial News 기사 역시 AI 지원 번역물임을 밝히고 있다.

두 회사 모두 해당 발언에 수반되는 벤치마크를 공개하지는 않았다. OpenAI는 CXL에 유용한 모델 실행 워크로드가 없다는 점을 입증하는 공개 기술 논문을 발표하지 않았다. Intel 역시 더 넓은 CXL 생태계의 주요 참여자로 남아 있다.

그럼에도 이 발언이 중요한 이유는 가속기 및 시스템 아키텍처를 담당하는 전문가들로부터 나왔기 때문이다. 이들의 구분은 기본적인 제약을 반영한다. 용량과 대역폭은 관련돼 있지만 서로를 대체하지는 않는다.

HBM은 넓은 인터페이스를 사용해 적층 DRAM을 프로세서 가까이에 배치한다. 이 설계는 고도로 병렬화된 가속기에 필요한 지속적인 데이터 이동을 지원한다. CXL은 PCI Express 기술 기반 링크를 통해 메모리와 장치를 연결하며, 일관성 있는 접근과 조합 가능성을 우선시한다.

CXL은 더 큰 메모리 풀을 프로세서에서 볼 수 있게 만들 수 있다. 그러나 해당 풀의 모든 바이트가 로컬 HBM처럼 동작하도록 자동으로 만들지는 못한다. 거리, 링크 폭, 스위칭, 프로토콜 오버헤드, 경합은 여전히 실효 성능을 좌우한다.

이것이 보도된 발언이 만들어낸 긴장이다. 업계는 비싼 HBM에서 벗어날 해법을 원하지만, 그러한 수요를 만드는 워크로드는 여전히 메모리 처리량에 민감하다.

따라서 CXL HBM 대체 주장은 성능이 다른 메모리 위치에서 동일한 성능을 가정할 때 성립하지 않는다. 더 설득력 있는 주장은 어떤 데이터를 가까이에 유지해야 하고 어떤 데이터를 더 멀리 옮겨도 되는지 결정하는 데서 출발한다.

AI 가속기가 여전히 HBM에 의존하는 이유

AI 프로세서는 대규모 작업 데이터 세트에 빠르고 반복적으로 접근해야 하므로 HBM은 여전히 대체하기 어렵다.

현대의 가속기는 많은 수학 연산을 병렬로 수행한다. 이 연산 유닛에는 모델 가중치, 활성화 값, 기타 중간 데이터를 꾸준히 공급해야 한다. 메모리가 정보를 충분히 빠르게 전달하지 못하면 프로세서 일부는 계산 대신 대기하게 된다.

이 상태는 일반적으로 메모리 대역폭 압박이라고 불린다. 산술 연산 유닛을 더 추가해도 이를 해결할 수는 없다. 시스템은 이러한 유닛을 계속 활용할 수 있을 만큼 충분한 실사용 대역폭을 제공해야 한다.

학습은 메모리에 특히 높은 트래픽을 유발한다. 대규모 가속기 그룹은 파라미터와 중간 결과를 반복적으로 교환한다. HBM의 물리적 근접성과 넓은 인터페이스는 이런 지속적인 이동에 적합하다.

추론은 패턴이 다르지만 대역폭의 중요성을 없애지는 않았다. 배포된 모델은 여전히 가중치에 접근해야 한다. 특히 더 작은 요청 배치를 처리할 때 각 토큰 생성에는 상당한 양의 모델 데이터를 읽어야 할 수 있다.

긴 컨텍스트와 에이전틱 워크로드는 또 다른 메모리 문제를 만든다. 이들은 이전 토큰의 어텐션 정보를 보존하는 키-값 캐시를 축적한다. 이러한 캐시는 가속기 옆에서 사용할 수 있는 용량에 부담을 줄 만큼 커질 수 있다.

CXL은 대역폭 요구 사항보다 이러한 용량 압박을 더 자연스럽게 해결한다. 추가 메모리를 노출하고 호스트 또는 장치 간 공유를 지원할 수 있다. 그러나 활발히 사용 중인 캐시를 더 좁은 링크로 이동하면 새로운 병목이 생길 수 있다.

공식 CXL 개요는 상호 연관된 세 가지 프로토콜을 설명한다. CXL.io는 장치 검색과 관리를 처리한다. CXL.cache는 프로세서 메모리에 대한 일관성 있는 접근을 지원한다. CXL.mem은 호스트가 CXL 장치에 연결된 메모리에 접근하도록 한다.

이러한 기능은 메모리 확장, 풀링, 공유를 지원한다. 한 서버는 메모리가 부족한데 다른 서버에는 미사용 리소스가 남는 유휴 용량을 줄일 수 있다. 또한 운영자가 변화하는 워크로드 요구에 맞춰 인프라를 구성하도록 도울 수 있다.

이러한 운영 유연성은 가치가 있다. 그러나 이는 HBM이 답하는 질문과는 다르다. CXL은 더 많은 메모리를 어떻게 접근 가능하게 만들지를 묻는다. HBM은 매초 충분한 데이터를 어떻게 프로세서에 전달할지를 묻는다.

CXL 4.0은 이에 대한 답을 개선한다. 이 규격은 신호 전송 속도를 초당 64기가트랜스퍼에서 128기가트랜스퍼로 두 배 높이고 번들 포트를 도입한다. 번들링은 장치 포트를 결합해 연결 대역폭을 높일 수 있다.

CXL Consortium은 최신 표준이 신호 속도를 높이는 동시에 프로토콜 지연 시간을 추가하지 않는다고도 말한다. 이 주장이 가속기 옆의 HBM과 원격 CXL 메모리가 동일한 종단 간 특성을 가진다는 뜻은 아니다.

실제 성능에는 메모리 장치, 컨트롤러, 스위치, 토폴로지, 소프트웨어 배치, 워크로드 접근 패턴이 포함된다. 더 빠른 표준은 링크를 개선할 수 있지만 시스템 내의 모든 차이를 없애지는 못한다.

따라서 CXL 4.0 규격은 한 가지 비판을 약화하지만 아키텍처적 구분을 지우지는 않는다. CXL 대역폭은 개선되고 있지만, HBM은 계속해서 최고 성능 계층을 차지하고 있다.

이것이 보도된 OpenAI의 회의론이 중요한 이유다. OpenAI는 가속기 활용률이 서비스 용량과 운영 효율성에 직접 영향을 미치는 워크로드를 위한 인프라를 설계하고 있다. 고성능 프로세서가 유휴 상태로 남으면 느린 데이터 이동은 비용이 커진다.

Intel의 보도된 견해는 또 다른 의미를 지닌다. Intel은 CXL 정립을 도왔고 해당 표준을 중심으로 한 제품과 시연을 계속 지원하고 있다. 따라서 Intel 아키텍트의 좁은 범위 평가는 CXL 자체를 일축한 것은 아니다.

오히려 이는 주요 CXL 후원사조차 대체 서사의 한계를 인식한다는 점을 시사한다. Intel은 CXL 메모리를 지원하는 동시에 로컬 고대역폭 메모리가 다른 기능을 수행한다는 점을 인정할 수 있다.

진짜 경쟁은 대체가 아니라 계층화다

CXL은 더 느린 HBM이 아니라 또 하나의 메모리 계층으로 볼 때 더욱 설득력 있어진다.

계층형 아키텍처는 접근 빈도와 성능 요구 사항에 따라 데이터를 배치한다. 자주 사용하는 정보는 빠르지만 희소한 메모리에 남는다. 덜 활발한 정보는 더 크고 저렴한 용량으로 이동한다.

프로세서는 수십 년간 이 원칙에 의존해 왔다. 레지스터, 캐시, 주 메모리, 스토리지는 속도와 용량의 균형을 맞춘다. AI 시스템은 이제 이 계층 구조를 가속기, 호스트 메모리, 공유 메모리, 플래시 스토리지 전반으로 확장하고 있다.

대체 서사는 이러한 계층을 오해를 부르는 비교로 압축한다. CXL이 AI 서버에서 HBM을 제거할 수 있는지를 묻는다. 더 유용한 질문은 워크로드의 각 단계에서 어떤 데이터가 HBM에 남아야 하는지다.

OpenAI의 보도된 입장은 저온 데이터 저장의 여지를 남긴다. 모델이 거의 필요로 하지 않는 정보라면 희소한 HBM에 상주할 이유가 항상 있는 것은 아니다. CXL은 해당 정보를 솔리드 스테이트 스토리지에 두지 않으면서도 접근 가능하게 유지할 수 있다.

과제는 예측이다. 시스템은 가속기가 요청하기 전에 어떤 정보가 활성화될지 알아야 한다. 전송이 늦으면 생성이 멈추고 더 저렴한 계층을 사용해 얻은 경제적 이점이 사라질 수 있다.

이 지점에서 워크로드 인지형 소프트웨어가 핵심이 된다. 데이터 배치, 프리페치, 캐시 축출, 스케줄링이 CXL이 유용한 용량을 확장하는지, 아니면 단지 지연 시간을 더하는지를 결정한다.

SK hynix 연구진은 2026년 6월 하나의 구체적인 시도를 제시했다. 이들의 Inference Tiered Memory Expansion 아키텍처는 CXL 하이브리드 메모리를 호스트 메모리와 플래시 스토리지 사이에 배치한다.

이 설계는 긴 컨텍스트 추론을 위한 공유 컨텍스트 인프라를 겨냥한다. 상용급 CXL 메모리 모듈, PCIe Gen5 솔리드 스테이트 드라이브, FPGA 프로토타입을 사용한다. 연구진은 예측 가능한 접근 패턴을 가진 모델 가중치와 프리픽스 캐시에 초점을 맞췄다.

이들의 ITME 연구는 기존 CPU 오프로딩 대비 최대 35.7%의 처리량 향상을 보고했다. 이 시스템은 CXL 메모리를 바이트 주소 지정이 가능한 중간 계층으로 활용하고 스토리지에서 정보를 선제적으로 이동시켰다.

이 결과는 보도된 OpenAI의 CXL HBM 대체 의문과 모순되지 않는다. ITME는 CXL을 로컬 HBM의 드롭인 대체재로 제시하지 않는다. 대신 더 빠른 메모리와 더 느린 스토리지 사이에 CXL의 고유한 역할을 부여한다.

이 실험은 호스트 메모리 한계를 넘어서는 용량도 겨냥한다. 그 가치는 매 모델 연산에서 HBM 대역폭을 맞추는 데 있지 않고, 더 느린 스토리지 접근을 피하고 원격 확장을 단순화하는 데서 나온다.

이 차이는 공급업체의 주장을 해석할 때 중요하다. 벤치마크는 SSD 기반 기준선과 비교해 CXL이 시스템을 개선한다는 점을 보여줄 수 있다. 그러나 CXL이 HBM 전용 구성과 동일한 성능을 낸다는 뜻은 아니다.

CXL은 비교 대상이 의도된 계층을 반영할 때 측정 가능한 향상을 제공할 수 있다. Micron CXL 모듈과 Intel Xeon 6 프로세서를 사용한 연구진은 2024년에 또 다른 사례를 보고했다.

이 구성은 8개의 CXL 장치와 12개의 DDR5 채널을 결합했다. 소프트웨어는 두 메모리 유형 전반에 걸쳐 페이지를 인터리빙했다. 연구진은 읽기 전용 대역폭이 24% 높아졌고, 읽기·쓰기 혼합 대역폭은 최대 39% 높아졌다고 보고했다.

테스트된 고성능 컴퓨팅 및 AI 워크로드 전반에서 기하평균 성능 향상은 24%였다. 다시 말해, 이 결과는 CXL을 GPU용 HBM의 대체재가 아니라 CPU 메모리 시스템에 추가되는 요소로 측정한 것이다.

이러한 연구는 보다 제한적이지만 실용적인 CXL의 가능성을 뒷받침한다. CXL은 용량을 확장하고, CPU 메모리의 총 대역폭을 개선하며, 더 느린 스토리지에 대한 의존도를 낮출 수 있다. 또한 액세스 패턴이 프리페칭을 허용할 경우 공유 컨텍스트 계층도 지원할 수 있다.

이러한 이점 중 어느 것도 CXL이 HBM을 이겨야 성립하는 것은 아니다. 시스템 아키텍트가 지연 시간과 대역폭이 여전히 수용 가능한 위치에 이를 배치하면 된다.

Samsung과 SK hynix, 양방향 압박에 직면

메모리 공급업체는 HBM 마진을 지키는 동시에 자사 주력 메모리와 함께 CXL 제품이 가치를 더한다는 점을 입증해야 한다.

Samsung Electronics와 SK hynix는 HBM 공급망에서 강력한 위치를 차지하고 있다. 지속적인 가속기 수요는 두 회사가 더 큰 용량과 더 빠른 차세대 HBM에 투자할 이유를 제공한다.

보도된 OpenAI와 Intel의 발언은 이러한 시장 구도를 강화한다. CXL이 활성 모델 메모리를 맡을 수 없다면, 가속기 공급업체는 성능이 중요한 데이터에 계속 HBM에 의존하게 된다.

하지만 HBM의 역할이 안정적이라고 해서 시장이 정체되는 것은 아니다. AI 추론은 더 다양한 메모리 시스템에 대한 수요를 만들고 있다. 용량, 지연 시간, 전력, 대역폭, 비용은 학습, 대화형 추론, 배치 처리, 컨텍스트 저장에 따라 달라진다.

따라서 Samsung과 SK hynix는 여러 계층의 제품을 판매할 유인을 갖는다. 가속기 가까이에 HBM을 공급하는 동시에, 확장과 공유를 위한 CXL 메모리 모듈을 개발할 수 있다.

이 전략은 인프라 지출의 방향이 바뀔 경우에도 이들을 보호한다. 비용 절감을 추구하는 고객은 시스템당 HBM 용량을 줄일 수는 있어도 HBM을 완전히 없애지는 않을 수 있다. 메모리 공급업체는 CXL 연결 DRAM과 기타 계층을 통해 계속 참여할 수 있다.

ITME 연구는 이러한 가능성을 보여준다. SK hynix는 CXL 하이브리드 메모리를 HBM의 직접적인 대체재로 포지셔닝하지 않았다. 그 아키텍처는 HBM, DDR, CXL 메모리, SSD로 구성된 계층 구조에 또 하나의 레이어를 추가했다.

이 접근법은 겉보기의 경쟁 관계를 포트폴리오 확장으로 바꾼다. 더 많은 계층은 더 많은 배치 결정을 요구하지만, 추가 제품과 소프트웨어 요구사항도 만들어낸다.

클라우드 제공업체도 비슷한 압박에 직면한다. HBM이 풍부한 가속기는 고객이 이를 효율적으로 사용할 때에만 가치가 있다. 예약 용량, 유휴 메모리, 과도한 구성은 추론의 실질 비용을 높일 수 있다.

CXL 풀링은 일부 메모리를 더 유연하게 할당할 수 있는 방법이 될 수 있다. 워크로드마다 피크 시점이 다를 때 공유 풀은 유휴로 묶이는 용량을 줄일 수 있다. 이 이점은 토폴로지, 격리, 소프트웨어 지원, 예측 가능한 서비스 품질에 달려 있다.

가속기 설계업체는 가장 어려운 절충을 마주한다. 각 칩에 얼마나 많은 로컬 메모리를 패키징할지 결정해야 한다. 메모리가 너무 적으면 모델과 컨텍스트가 제한되고, 너무 많으면 패키지 복잡성이 높아지며 워크로드가 사용하지 않을 때도 희소한 용량이 배정된다.

신뢰할 수 있는 계층형 설계는 가속기 제조업체가 활성 데이터에는 HBM을 제공하고 더 차가운 정보는 다른 곳으로 옮길 수 있게 해준다. 그러나 하드웨어에는 충분한 링크 대역폭이 필요하고, 소프트웨어는 데이터가 긴급해지기 전에 이를 이동시켜야 한다.

Nvidia, AMD, Google, Intel과 맞춤형 가속기 팀은 모두 로컬 메모리, 네트워킹, 스케일아웃 시스템 간의 서로 다른 균형을 탐색하고 있다. 이들의 아키텍처는 용량만으로 비교해서는 안 된다.

총 메모리를 더 많이 제공하는 서버라도 애플리케이션 성능은 더 나쁠 수 있다. 실효 처리량은 프로세서가 각 계층에 얼마나 자주 접근하는지, 그리고 전송이 유용한 연산과 겹치는지에 달려 있다.

이 때문에 CXL 도입이 하나의 보편적인 결과를 낳지는 않을 것이다. 데이터베이스 워크로드, CPU 기반 분석, 모델 서빙, 학습, 검색 시스템은 서로 다른 액세스 패턴을 가진다. 한 워크로드에 최적인 계층 구조가 다른 워크로드에는 해로울 수 있다.

따라서 CXL의 더 광범위한 성공은 HBM을 극적으로 대체하는 수치 없이도 나타날 수 있다. 도입은 메모리 확장 모듈, 컴포저블 서버, 컨텍스트 스토어, 스토리지 트래픽이 낮은 인프라를 통해 드러날 수 있다.

그 결과는 직접적인 HBM 경쟁자를 기대한 사람에게는 실망스러울 수 있다. 그럼에도 AI 서버가 메모리를 할당하는 방식에는 중요한 변화를 의미한다.

보도된 평결에는 중요한 한계가 있다

표준, 제품, AI 워크로드가 계속 변하고 있으므로 패널 발언 두 개만으로 CXL의 미래를 결론낼 수는 없다.

첫 번째 한계는 증거의 문제다. 가장 강한 발언은 컨퍼런스 패널에 관한 언론 보도에서 나왔다. 인용된 보도에서는 녹화본, 전문, 벤치마크 패키지 또는 이에 대응하는 OpenAI 공개 자료를 확인할 수 없었다.

독자는 해당 발언을 모든 OpenAI 워크로드가 CXL을 거부한다는 증거로 해석해서는 안 된다. Morris는 모델 실행에 실용적인 활용처를 찾기 어려웠다고 설명한 것으로 보도됐지만, 그 평가의 범위는 여전히 불분명하다.

이 발언은 현재의 가속기 설계, 현재의 소프트웨어 또는 특정 모델군을 가리킬 수 있다. 컨텍스트 저장, 전처리, 검색, 체크포인팅 또는 향후 분리형 시스템까지 포괄하지 않을 수 있다.

Intel의 입장 역시 맥락이 필요하다. 이 회사는 CXL 개발을 지원하고 Xeon 프로세서용 메모리 모드를 시연하고 있다. 보도된 비판은 HBM 대체 가능성에 관한 것이지, 코히어런트 메모리 확장의 유용성을 부정하는 것은 아니다.

두 번째 한계는 기술 진보다. CXL 4.0은 표준의 신호 전송 속도를 두 배로 높이고 번들 포트를 지원한다. 이러한 기능을 구현하는 제품은 여전히 실제 워크로드에서 검증이 필요하다.

명세상 대역폭이 애플리케이션 대역폭은 아니다. 엔지니어는 실제 제공 처리량, 지연 시간 분포, 경합, 전력 소비, 장애 상황에서의 성능을 측정해야 한다.

세 번째 한계는 소프트웨어다. 메모리 티어링은 시스템이 데이터를 지능적으로 배치할 때만 제대로 작동한다. 부실한 정책은 핫 데이터를 느린 계층으로 옮기거나 사용되지 않을 정보를 전송하는 데 대역폭을 낭비할 수 있다.

긴 컨텍스트 추론은 경우에 따라 이 문제를 더 관리하기 쉽게 만들 수 있다. 프리픽스 캐시와 모델 가중치는 예측 가능한 액세스 패턴을 가질 수 있다. 이러한 예측 가능성은 프리페칭과 재사용의 기회를 만든다.

다른 워크로드는 여전히 관대하지 않다. 불규칙한 액세스, 빠르게 변하는 요청, 엄격한 지연 시간 요구사항은 원격 메모리를 더 어렵게 사용할 수 있다. 평균 처리량은 심각한 테일 레이턴시 문제를 가릴 수도 있다.

네 번째 한계는 각 주장에 선택된 기준선이다. CXL은 HBM보다 호스트 DDR 또는 SSD 액세스와 경쟁하는 경우가 많다. 스토리지 대비 긍정적인 결과가 가속기 로컬 메모리와의 동등성을 입증하지는 않는다.

반대의 실수도 가능하다. CXL이 HBM과 맞먹지 못한다는 점을 보여준다고 해서 경제적 가치가 없다는 뜻은 아니다. 하위 계층은 해당 계층에서 이용 가능한 대안보다 우수하기만 하면 된다.

따라서 유용한 평가는 데이터, 워크로드, 기준선을 정의해야 한다. 어떤 정보가 HBM에 상주하는지, 어떤 정보가 CXL을 통해 이동하는지, 전송이 연산을 얼마나 자주 지연시키는지를 식별해야 한다.

전력도 비슷한 수준의 검토가 필요하다. 시스템 전체에서 데이터를 이동하면 에너지가 소비된다. 더 큰 메모리 풀은 비용이 큰 스토리지 작업을 줄일 수 있지만, 스위칭과 전송에도 비용이 따른다.

메모리가 공유되면 신뢰성과 격리가 중요해진다. 운영자는 예측 가능한 장애 처리, 접근 제어, 암호화, 관측 가능성, 서비스 보장을 필요로 한다. 이러한 운영 요건은 하드웨어가 उपलब्ध해진 뒤에도 도입을 지연시킬 수 있다.

CXL Consortium은 버전 4.0에서 신뢰성, 가용성, 서비스 가능성의 개선을 설명한다. 이러한 기능은 인프라 측면의 근거를 강화하지만, 명세 언어보다 운영 환경의 증거가 더 중요하다.

따라서 올바른 결론은 헤드라인 주장보다 더 제한적이다. 현재 이용 가능한 증거는 CXL이 HBM을 직접 대체할 수 있다는 주장에 대한 회의를 뒷받침한다. 그렇다고 CXL이 AI 인프라와 무관하다고 선언할 근거는 되지 않는다.

CXL의 다음 역할을 보여줄 세 가지 신호

다음 단계는 운영 환경의 측정치, 가속기 통합, 티어링이 총 추론 비용을 낮춘다는 증거에 의해 결정될 것이다.

첫 번째 신호는 하이퍼스케일러와 모델 개발업체의 배포 증거다. OpenAI, Microsoft, Google, Meta, Amazon 및 기타 운영업체는 대부분의 연구자가 접근할 수 없는 규모에서 메모리 아키텍처를 시험할 수 있다.

중요한 공개 자료는 용량 증가와 애플리케이션 성능을 구분해야 한다. 유의미한 결과는 모델 처리량, 지연 시간, 가속기 활용률, CXL 메모리에 접근하는 요청의 비중을 보고해야 한다.

공유 컨텍스트 또는 콜드 가중치를 위한 운영 환경 배포는 티어링 논지를 강화할 것이다. 스토리지와 유사한 역할을 넘어서지 못한다면 보도된 OpenAI의 평가를 뒷받침하게 된다.

두 번째 신호는 CXL 4.0 대역폭과 번들 포트를 구현하는 하드웨어다. 컨소시엄은 2025년 11월 CXL 4.0을 발표했지만, 명세는 광범위하게 이용 가능한 플랫폼보다 앞선다.

향후 시스템은 실제로 얼마나 많은 링크 대역폭이 애플리케이션에 도달하는지 보여줘야 한다. 공급업체는 스위칭과 다중 장치 구성이 부하 상황에서도 예측 가능한 지연 시간을 유지한다는 점도 입증해야 한다.

강력한 결과는 CXL이 콜드 스토리지에만 국한된다는 생각을 약화시킬 것이다. 다만 같은 기간 HBM도 발전할 것이므로, 이것이 자동으로 HBM 대체를 입증하는 것은 아니다.

세 번째 신호는 ITME와 같은 아키텍처에 대한 독립적 검증이다. 보도된 35.7% 처리량 향상은 유망하지만, 특정 프로토타입과 기준선에서 나온 결과다.

독립 팀은 서로 다른 모델, 컨텍스트 길이, 요청 패턴, 스토리지 구성을 시험해야 한다. 또한 테일 레이턴시, 에너지, 소프트웨어 오버헤드, 복구 동작도 측정해야 한다.

재현된 성능 향상은 CXL이 추론을 위한 유용한 중간 계층을 차지한다는 점을 보여줄 것이다. 예측 가능한 워크로드 밖에서 성능이 부진하다면 이 아키텍처는 특수 배포로 제한될 것이다.

이 신호들은 누가 가장 큰 압박을 받는지도 분명히 할 것이다. 로컬 대역폭이 계속 필수적이라면 HBM 공급업체의 즉각적인 대체 위험은 더 낮다. 그럼에도 이들은 추론이 만들어내는 모든 계층을 위한 제품이 필요하다.

CXL 공급업체는 용량이 성능을 보장하는 것처럼 마케팅하는 방식을 멈춰야 한다. 이들의 가장 강력한 근거는 측정 가능한 액세스 패턴에 따라 데이터를 배치하는 완성된 시스템에서 나올 것이다.

AI 인프라 구매자는 각 모델 단계에서 데이터가 어디에 있는지 물어야 한다. 또한 소위 콜드 객체가 갑자기 핫해졌을 때 어떤 일이 일어나는지도 물어야 한다.

OpenAI의 CXL HBM 대체 논쟁은 결국 유용한 수정점을 드러낸다. 메모리 아키텍처는 한 구성 요소가 다른 모든 구성 요소를 제거하는 경쟁이 아니다. 이는 거리, 대역폭, 용량, 소프트웨어에 의해 형성되는 할당 문제다.

이러한 주장을 평가하는 팀은 벤치마크 세부 사항, 워크로드 가정, 아키텍처 결정을 검색 가능한 engineering knowledge base에 보존해야 한다. 다음 공급업체 시연은 단순화된 대체 구호가 아니라 이러한 가정과 비교해야 한다.

최초의 독립적인 CXL 4.0 배포, 운영 환경의 컨텍스트 메모리 시스템, 워크로드 수준의 비용 데이터를 주시해야 한다. 이러한 결과는 CXL이 필수적인 AI 메모리 계층이 될지, 아니면 특수한 확장 경로로 남을지를 보여줄 것이다.

 
 

무료로 시작하세요

개인 지식 관리 기능을 갖춘 로컬 우선 AI 어시스턴트

더 나은 AI 경험을 위해

현재 remio는 Windows 10+ (x64)M-Chip Macs만 지원합니다.

업무를 위한 AI 파트너
remio와 더 많은 일을 해내세요

계획하고, 만들고, 완성하세요
모든 일을 한곳에서

bottom of page