top of page

OpenAI CXL HBM Replacement Doubts Expose AI Memory's Real Tradeoff

2 hours ago
12 min read

OpenAI has reportedly rejected the CXL HBM replacement thesis, despite mounting pressure to reduce the cost and scarcity of high-bandwidth memory. An OpenAI accelerator researcher said he had not found a compelling CXL use case for running AI models. An Intel architecture executive separately argued that CXL works better as a storage supplement than an HBM substitute.

Those comments challenge a tempting idea for AI infrastructure buyers. Compute Express Link, or CXL, lets processors access additional memory through a coherent interconnect. It promises larger capacity, shared pools, and more flexible resource allocation. However, flexibility does not eliminate the bandwidth demands of active model execution.

The deeper story is not that CXL has failed. It is that CXL and HBM solve different parts of the memory problem. HBM keeps frequently accessed data close to an accelerator at very high bandwidth. CXL can expand capacity and move colder data into a less expensive tier.

That distinction puts pressure on memory suppliers, accelerator designers, and cloud operators to build smarter hierarchies. The central contest is therefore not CXL versus HBM as interchangeable products. It is replacement economics versus the physical requirements of moving data fast enough to keep expensive AI processors working.

OpenAI CXL HBM Replacement Claims Meet a Bandwidth Test

The reported OpenAI and Intel comments narrow CXL’s role without making the technology irrelevant.

The remarks came during an AI Infrastructure Summit panel on September 16, 2026, in Santa Clara, California. Financial News reported that Daniel Morris, an OpenAI researcher working on accelerator design, questioned CXL’s usefulness for actual model execution.

“From the standpoint of actually running AI models, I cannot find a use for CXL,” Morris reportedly said. He identified one possible role: holding inactive information that large models rarely access.

Vidhya Thyagarajan, Intel’s head of system-on-chip architecture, reportedly offered a similar distinction. Memory pooling through CXL can be useful, she said, but it does not replace HBM. She characterized CXL as a supplement to secondary storage.

The most important part of Intel’s reported position concerned data movement. Information traveling between a GPU and CXL-connected memory is “by no means as fast as HBM,” according to the translated panel coverage.

The comments deserve careful attribution. They were reported by Korean publications and summarized by TrendForce, rather than published as formal OpenAI or Intel policy statements. The available English Financial News article also identifies itself as an AI-assisted translation.

Neither company has published a benchmark accompanying the remarks. OpenAI has not released a public technical paper proving that CXL lacks useful model-execution workloads. Intel has also remained a major participant in the broader CXL ecosystem.

The comments still matter because they came from specialists responsible for accelerator and system architecture. Their distinction reflects a basic constraint. Capacity and bandwidth are related, but they are not substitutes.

HBM places stacked DRAM close to a processor using a wide interface. That design supports the sustained data movement required by highly parallel accelerators. CXL connects memory and devices through links based on PCI Express technology, prioritizing coherent access and composability.

CXL can make a larger memory pool visible to processors. It cannot automatically make every byte in that pool behave like local HBM. Distance, link width, switching, protocol overhead, and contention still shape effective performance.

That is the tension created by the reported remarks. The industry wants relief from expensive HBM, but the workloads generating that demand remain sensitive to memory throughput.

The CXL HBM replacement argument therefore fails when it assumes equal performance from unequal memory locations. A more credible argument begins by deciding which data must remain close and which data can move farther away.

Why AI Accelerators Still Depend on HBM

HBM remains difficult to replace because AI processors need rapid, repeated access to large working data sets.

Modern accelerators perform many mathematical operations in parallel. Those compute units need a steady supply of model weights, activations, and other intermediate data. If memory cannot deliver information quickly enough, parts of the processor wait instead of calculating.

This condition is commonly called memory-bandwidth pressure. Adding more arithmetic units does not resolve it. The system must expose enough usable bandwidth to keep those units occupied.

Training places especially demanding traffic on memory. Large groups of accelerators repeatedly exchange parameters and intermediate results. HBM’s physical proximity and wide interface make it suited to that sustained movement.

Inference has different patterns, but it has not made bandwidth irrelevant. A deployed model still needs access to weights. Generating each token can require reading substantial amounts of model data, particularly when serving smaller request batches.

Long-context and agentic workloads create another memory problem. They accumulate key-value caches, which preserve attention information from earlier tokens. These caches can become large enough to strain the capacity available beside an accelerator.

CXL addresses that capacity pressure more naturally than the bandwidth requirement. It can expose additional memory and support sharing across hosts or devices. However, moving an actively used cache across a narrower link can introduce a new bottleneck.

The official CXL overview describes three related protocols. CXL.io handles device discovery and management. CXL.cache supports coherent access to processor memory. CXL.mem lets a host access memory attached to a CXL device.

These capabilities support memory expansion, pooling, and sharing. They can reduce stranded capacity, where one server lacks memory while another has unused resources. They can also help operators configure infrastructure around changing workload requirements.

That operational flexibility is valuable. Yet it answers a different question from HBM. CXL asks how more memory can become accessible. HBM asks how enough data can reach a processor every second.

CXL 4.0 improves the answer. The specification doubles the signaling rate from 64 to 128 gigatransfers per second and introduces bundled ports. Bundling can combine device ports to increase connection bandwidth.

The CXL Consortium also says the newer standard adds no protocol latency while increasing the signaling rate. That claim does not mean remote CXL memory has the same end-to-end characteristics as HBM beside an accelerator.

Actual performance includes the memory device, controllers, switches, topology, software placement, and workload access pattern. A faster standard can improve the link without removing every difference in the system.

The CXL 4.0 specification therefore weakens one criticism but does not erase the architectural distinction. CXL bandwidth is improving, while HBM continues to occupy the highest-performance tier.

This explains why the reported OpenAI skepticism matters. OpenAI is designing infrastructure for workloads where accelerator utilization directly affects service capacity and operating efficiency. Slow data movement becomes expensive when it leaves advanced processors idle.

Intel’s reported view carries a different significance. Intel helped establish CXL and continues supporting products and demonstrations around the standard. A narrow assessment from an Intel architect is therefore not a dismissal of CXL itself.

Instead, it suggests that even a major CXL sponsor sees limits to the replacement narrative. Intel can support CXL memory while recognizing that local high-bandwidth memory serves another function.

The Real Contest Is Replacement Versus Tiering

CXL becomes more convincing when it is treated as another memory tier, not as slower HBM.

A tiered architecture places data according to its access frequency and performance requirements. Frequently used information stays in fast, scarce memory. Less active information moves into larger and less expensive capacity.

Processors have relied on this principle for decades. Registers, caches, main memory, and storage balance speed against capacity. AI systems are now extending that hierarchy across accelerators, host memory, shared memory, and flash storage.

The replacement narrative compresses these layers into a misleading comparison. It asks whether CXL can remove HBM from an AI server. The more useful question asks which data must remain in HBM at each stage of a workload.

OpenAI’s reported position leaves room for cold-data storage. Information that a model rarely needs does not always justify residence in scarce HBM. CXL could keep that information accessible without placing it on solid-state storage.

The challenge is prediction. A system must know which information will become active before an accelerator requests it. A late transfer can stall generation and erase the economic benefit of using a cheaper tier.

This is where workload-aware software becomes central. Data placement, prefetching, cache eviction, and scheduling determine whether CXL extends useful capacity or merely adds latency.

SK hynix researchers presented one concrete attempt in June 2026. Their Inference Tiered Memory Expansion architecture places CXL hybrid memory between host memory and flash storage.

The design targets shared context infrastructure for long-context inference. It uses production-grade CXL memory modules, PCIe Gen5 solid-state drives, and an FPGA prototype. The researchers focused on model weights and prefix caches with predictable access patterns.

Their ITME research reported up to a 35.7 percent throughput improvement over conventional CPU offloading. The system used CXL memory as a byte-addressable intermediate layer and proactively moved information from storage.

That result does not contradict the reported OpenAI CXL HBM replacement doubts. ITME does not present CXL as a drop-in replacement for local HBM. It assigns CXL a distinct role between faster memory and slower storage.

The experiment also targets capacity beyond host-memory limits. Its value comes from avoiding slower storage access and simplifying remote expansion, not matching HBM’s bandwidth during every model operation.

This difference is important for interpreting vendor claims. A benchmark can show that CXL improves a system compared with an SSD-based baseline. It does not necessarily show that CXL matches an HBM-only configuration.

CXL can deliver measurable gains when the comparison reflects its intended tier. Researchers using Micron CXL modules with Intel Xeon 6 processors reported another example in 2024.

Their configuration combined eight CXL devices with twelve DDR5 channels. Software interleaved pages across the two memory types. The researchers reported 24 percent higher read-only bandwidth and up to 39 percent higher mixed read-and-write bandwidth.

Across tested high-performance computing and AI workloads, the geometric mean performance improvement was 24 percent. Again, the result measured CXL as an addition to a CPU memory system, not as HBM replacement for GPUs.

These studies support a narrower but practical CXL proposition. CXL can expand capacity, improve aggregate CPU memory bandwidth, and reduce reliance on slower storage. It can also support shared context layers when access patterns allow prefetching.

None of those benefits require CXL to defeat HBM. They require system architects to place it where latency and bandwidth remain acceptable.

Samsung and SK Hynix Face Pressure From Both Directions

Memory suppliers must protect HBM margins while proving that CXL products add value beside their flagship memory.

Samsung Electronics and SK hynix occupy strong positions in the HBM supply chain. Continued accelerator demand gives both companies a reason to invest in higher-capacity and faster HBM generations.

The reported OpenAI and Intel comments reinforce that market. If CXL cannot take over active model memory, accelerator vendors will continue depending on HBM for performance-critical data.

However, a stable HBM role does not produce a static market. AI inference is creating demand for more varied memory systems. Capacity, latency, power, bandwidth, and cost differ across training, interactive inference, batch processing, and context storage.

Samsung and SK hynix therefore have incentives to sell products at several tiers. They can supply HBM near accelerators while developing CXL memory modules for expansion and sharing.

This strategy also protects them if infrastructure spending shifts. Customers seeking lower costs might reduce HBM per system without removing it. Memory vendors can still participate through CXL-attached DRAM and other tiers.

The ITME research illustrates that possibility. SK hynix did not position CXL hybrid memory as a direct HBM substitute. Its architecture inserted another layer into an HBM, DDR, CXL memory, and SSD hierarchy.

That approach turns apparent competition into portfolio expansion. More tiers create more placement decisions, but they also create additional products and software requirements.

Cloud providers face a related pressure. HBM-rich accelerators are valuable only when customers use them efficiently. Reserved capacity, idle memory, and oversized configurations can raise the effective cost of inference.

CXL pooling offers a possible way to allocate some memory more flexibly. A shared pool can reduce stranded capacity when workloads have different peaks. The benefit depends on topology, isolation, software support, and predictable service quality.

Accelerator designers face the hardest tradeoff. They must decide how much local memory to package with each chip. Too little memory constrains models and context. Too much raises package complexity and allocates scarce capacity even when workloads do not use it.

A credible tiered design could let accelerator makers provision HBM for active data and shift colder information elsewhere. However, the hardware needs enough link bandwidth, and the software must move data before it becomes urgent.

Nvidia, AMD, Google, Intel, and custom accelerator teams are all exploring different balances among local memory, networking, and scale-out systems. Their architectures should not be compared through capacity alone.

A server offering more total memory can still deliver worse application performance. Effective throughput depends on how often processors access each tier and whether transfers overlap with useful computation.

This is why CXL adoption will not produce one universal outcome. Database workloads, CPU-based analytics, model serving, training, and retrieval systems have different access patterns. The best hierarchy for one workload can harm another.

CXL’s broader success might therefore occur without a dramatic HBM displacement figure. Adoption could appear through memory expansion modules, composable servers, context stores, and infrastructure with lower storage traffic.

That outcome would disappoint anyone expecting a direct HBM competitor. It would still represent an important change in how AI servers allocate memory.

The Reported Verdict Has Important Limits

Two panel comments cannot settle CXL’s future because standards, products, and AI workloads are still changing.

The first limitation is evidentiary. The strongest statements come from media reports about a conference panel. No recording, transcript, benchmark package, or corresponding OpenAI publication was available in the cited coverage.

Readers should not interpret the comments as proof that every OpenAI workload rejects CXL. Morris reportedly described difficulty finding a practical use for model execution, but the boundaries of that assessment remain unclear.

The statement might refer to current accelerator designs, current software, or a particular class of models. It might not cover context storage, preprocessing, retrieval, checkpointing, or future disaggregated systems.

Intel’s position also requires context. The company supports CXL development and demonstrates memory modes for Xeon processors. Its reported criticism concerns substitution for HBM, not the usefulness of coherent memory expansion.

The second limitation is technical progress. CXL 4.0 doubles the standard’s signaling rate and supports bundled ports. Products implementing those capabilities still need validation under real workloads.

Specification bandwidth is not application bandwidth. Engineers must measure delivered throughput, latency distributions, contention, power consumption, and performance under failures.

The third limitation involves software. Memory tiering only works well when the system places data intelligently. A poor policy can move hot data into a slow tier or waste bandwidth transferring information that will not be used.

Long-context inference could make this problem more manageable in some cases. Prefix caches and model weights can have predictable access patterns. That predictability creates opportunities for prefetching and reuse.

Other workloads remain less forgiving. Irregular access, rapidly changing requests, or strict latency requirements can make remote memory harder to use. Average throughput can also hide severe tail-latency problems.

The fourth limitation is the baseline chosen for each claim. CXL often competes with host DDR or SSD access rather than HBM. A positive result against storage does not establish equivalence with accelerator-local memory.

The opposite mistake is also possible. Showing that CXL cannot match HBM does not prove that it lacks economic value. A lower tier only needs to outperform the alternative available at that tier.

A useful evaluation must therefore define the data, workload, and baseline. It should identify which information resides in HBM, which moves through CXL, and how often transfers delay computation.

Power deserves similar scrutiny. Moving data across a system consumes energy. Larger memory pools can reduce expensive storage operations, but switching and transport also impose costs.

Reliability and isolation matter when memory becomes shared. Operators need predictable failure handling, access control, encryption, observability, and service guarantees. These operational requirements can delay adoption after hardware becomes available.

The CXL Consortium describes reliability, availability, and serviceability improvements in version 4.0. Those features strengthen the infrastructure case, but production evidence remains more important than specification language.

The correct conclusion is therefore narrower than the headline claim. Available evidence supports skepticism about direct CXL substitution for HBM. It does not justify declaring CXL irrelevant to AI infrastructure.

Three Signals Will Show Where CXL Fits Next

The next phase will be decided by production measurements, accelerator integration, and evidence that tiering lowers total inference costs.

The first signal is deployment evidence from hyperscalers and model developers. OpenAI, Microsoft, Google, Meta, Amazon, and other operators can test memory architectures at a scale unavailable to most researchers.

The important disclosures will separate capacity gains from application performance. Useful results should report model throughput, latency, accelerator utilization, and the share of requests accessing CXL memory.

A production deployment for shared context or cold weights would strengthen the tiering thesis. Failure to move beyond storage-like roles would reinforce the reported OpenAI assessment.

The second signal is hardware implementing CXL 4.0 bandwidth and bundled ports. The consortium released CXL 4.0 in November 2025, but specifications precede broadly available platforms.

Upcoming systems must demonstrate how much link bandwidth reaches applications. Vendors also need to show that switching and multi-device configurations preserve predictable latency under load.

Strong results would weaken the idea that CXL is confined to cold storage. They would not automatically establish HBM replacement, since HBM will advance during the same period.

The third signal is independent validation of architectures like ITME. The reported 35.7 percent throughput improvement is promising, but it comes from a specific prototype and baseline.

Independent teams should test different models, context lengths, request patterns, and storage configurations. They should also measure tail latency, energy, software overhead, and recovery behavior.

Replicated gains would show that CXL occupies a useful middle tier for inference. Poor results outside predictable workloads would limit the architecture to specialized deployments.

These signals will also clarify who faces the greatest pressure. HBM suppliers face less immediate substitution risk if local bandwidth remains essential. They still need products for every layer that inference creates.

CXL vendors must stop marketing capacity as if it guarantees performance. Their strongest case will come from complete systems that place data according to measurable access patterns.

AI infrastructure buyers should ask where data lives during each model phase. They should also ask what happens when a supposedly cold object suddenly becomes hot.

The OpenAI CXL HBM replacement debate ultimately exposes a useful correction. Memory architecture is not a contest where one component eliminates every other component. It is an allocation problem shaped by distance, bandwidth, capacity, and software.

Teams evaluating these claims should preserve benchmark details, workload assumptions, and architecture decisions in a searchable engineering knowledge base. The next vendor demonstration should be compared with those assumptions, not with a simplified replacement slogan.

Watch the first independent CXL 4.0 deployments, production context-memory systems, and workload-level cost data. Those results will reveal whether CXL becomes an essential AI memory tier or remains a specialized expansion path.

Give every agent the context to do better work

Connect your agents to the knowledge, decisions, and history already organized in remio.

remio currently supports Windows 10+ (x64) and Macs with Apple silicon.

Your AI Partner at Work
Get more done with remio

Plan. Create. Deliver.
All in one place.

bottom of page