Xcena MX1: 2TB CXL Memory and 1,000+ RISC-V Cores

Xcena MX1: 2TB CXL Memory and 1,000+ RISC-V Cores

Memory capacity is becoming a major constraint in AI infrastructure. As large language models (LLMs), vector databases, and retrieval-intensive workloads expand, adding more processing power alone cannot eliminate the delays and energy costs associated with moving data between memory and compute resources.

South Korean semiconductor startup Xcena is addressing this problem with the MX1, a computational memory device that combines up to 2TB of DDR5, SSD-backed memory capacity, and more than 1,000 custom RISC-V processing cores within a single Compute Express Link (CXL) device.

Presented at Hot Chips 2026, the MX1 combines three capabilities that are usually implemented separately: memory expansion, storage-backed capacity, and near-memory computing. Its purpose is to perform selected data-processing operations close to where the data resides, reducing unnecessary transfers to the host CPU or GPU.

According to Xcena’s reported benchmarks, the MX1 delivers up to 4.7× the throughput and 18.7× the energy efficiency of a host CPU processing data over CXL on selected data analytics workloads.

These results are workload-specific rather than universal performance improvements. The device is designed for operations such as vector search, database filtering, compression, aggregation, and LLM key-value (KV) cache retrieval, where data movement can account for a substantial portion of execution cost.

Xcena plans to begin mass production by the end of 2026, with initial customer revenue targeted for 2027. As of October 2026, the company is supplying prototype samples to memory vendors, CPU vendors, and hyperscalers.

The MX1 illustrates a broader architectural shift: instead of treating memory as a passive resource attached to a processor, future AI systems may increasingly perform computation inside or immediately adjacent to the memory subsystem.

🧠 1. Why AI Infrastructure Needs Computational Memory

#

The memory bottleneck extends beyond capacity

#

Increasing the amount of memory available to a server does not automatically improve application performance.

In many data-intensive workloads, the dominant cost is moving data between storage, memory, and processing units. A CPU or GPU may have substantial arithmetic throughput yet remain underutilized while waiting for data to arrive.

This is particularly relevant to AI inference and database processing.

A large language model can repeatedly access weights and KV-cache data during inference. A vector database may retrieve a large collection of candidate records but require expensive computation on only a subset. A database query may read millions of rows only to discard most of them through filtering.

In these situations, transferring the complete dataset to the host processor can waste bandwidth, power, and execution time.

Xcena’s approach is to move selected processing operations closer to memory, allowing the host CPU and GPU to focus on computation that benefits more directly from their capabilities.

What near-memory computing changes

#

Traditional server architectures separate the processor from its main memory. The CPU executes instructions while accessing data through memory controllers and interconnects.

Near-memory computing changes this arrangement by placing processing resources close to the memory they operate on.

The benefit is not necessarily a higher peak arithmetic rate. It is the ability to reduce unnecessary data movement and exploit the bandwidth available within the memory subsystem.

For example, instead of sending an entire dataset to the host CPU, a memory-side processor can filter the records locally and return only the results required by the application.

The CPU processes less data, the host interconnect carries fewer unnecessary bytes, and the memory-side compute resources perform useful work using local bandwidth.

This design is particularly attractive when an application spends more time moving and filtering data than performing computationally intensive operations on every element.

Why CXL is relevant

#

Compute Express Link is a high-speed interconnect designed to connect CPUs, accelerators, and memory devices using standardized protocols and system-level interfaces.

CXL allows supported devices to expose memory beyond conventional CPU-attached DDR channels. Depending on the device type and platform, CXL can support memory expansion, host-device memory coherency, and more advanced memory-sharing architectures.

The MX1 uses CXL as the connection between the host and its memory-centric processing device.

For an introduction to CXL’s protocol layers and device categories, see CXL Explained: Protocols, Device Types, Versions, and Memory.

⚙️ 2. Xcena MX1 Architecture: DDR5, SSD, and RISC-V

#

The MX1 integrates three main subsystems: high-capacity DDR5 memory, SSD-backed extended capacity, and near-memory processing.

The combination is designed to address different parts of the memory bottleneck without forcing every workload to use the same storage or compute path.

Core architectural specifications

#

These specifications describe the architecture presented by Xcena. Production availability, enabled features, and final product configurations should be confirmed against the shipping specification.

CXL Type 3 with integrated computation

#

CXL Type 3 devices traditionally focus on exposing device-local memory to a host. They are commonly used for memory expansion and, in suitable CXL fabrics, memory pooling.

The MX1 extends this concept by incorporating programmable processing resources alongside the memory.

The device is therefore more than a passive memory expander. It is intended to accelerate selected operations while retaining its role as an additional memory resource.

This creates a hybrid architecture in which the host can access expanded memory while supported workloads execute on the device’s internal processors.

The distinction matters because conventional memory expansion improves capacity but does not automatically reduce the cost of processing data across the host-device interconnect.

Adding compute inside the memory device can reduce the amount of data that must travel back to the host.

More than 1,000 custom RISC-V cores

#

The MX1 uses a large number of small RISC-V processing cores organized into Memory Acceleration Units (MUs).

Rather than relying on a handful of general-purpose CPU cores, the architecture emphasizes parallel execution of data-intensive operations close to memory.

Xcena reports that its custom processors operate at approximately 1.4GHz and are designed to work with integrated vector engines for supported calculations.

The company specifies approximately 3 TFLOPS of FP32/FP16 dot-product throughput for selected workloads. This figure should not be compared directly with the peak throughput of a modern GPU because the architectures, memory systems, and intended operations differ considerably.

The MX1’s value comes from using its internal compute resources to process data without repeatedly moving large datasets over the host connection.

💾 3. InfiniteMemory: Extending DDR5 with SSD-Backed Capacity

#

The MX1’s second major feature is InfiniteMemory, Xcena’s approach to exposing SSD-backed capacity through a byte-addressable CXL memory interface.

This creates a larger logical memory space than the installed DRAM capacity alone.

However, SSD-backed capacity is not equivalent to physical DDR5. The different media have different latency, bandwidth, and endurance characteristics, so the implementation must manage movement between storage and DRAM carefully.

A hybrid DRAM and SSD hierarchy

#

InfiniteMemory uses DRAM to cache frequently accessed 64KB pages backed by SSD storage.

The intended behavior is to keep frequently accessed data in faster memory while allowing less frequently used data to reside in a higher-capacity storage tier.

When an application accesses data that is not currently cached, the device must retrieve the relevant page from SSD storage and populate the DRAM cache as required.

Xcena’s architecture also uses internal mapping structures and firmware running on the memory-side processing resources to support this mechanism.

The benefit is a larger addressable capacity without requiring every byte to be backed by DRAM.

The trade-off is that accesses that miss the DRAM cache can incur substantially higher latency than accesses to resident DDR5.

Why transparent memory management matters

#

A larger memory hierarchy is useful only if software can manage it efficiently.

If applications must manually manage every transition between DDR5 and SSD storage, the programming burden can become substantial. Poor placement decisions can also generate repeated cache misses that undermine performance.

Xcena aims to keep the programming model close to familiar CPU-side memory usage, while its device firmware and software stack manage the underlying capacity tiers.

This requires coordination among virtual-address mappings, page tracking, cache replacement, data movement, and access permissions.

The company identifies unified virtual memory mapping across host memory, device memory, and SSD-backed capacity as one of the most difficult engineering challenges in the architecture.

For developers, this abstraction is important because it can make a large memory resource usable without requiring every application to implement its own storage-tiering system.

InfiniteMemory is not a replacement for high-bandwidth memory

#

The architecture addresses capacity and data-movement efficiency rather than attempting to replace GPU high-bandwidth memory (HBM).

HBM provides extremely high bandwidth close to the accelerator and is well suited to compute-intensive GPU workloads.

CXL-attached memory offers another point in the hierarchy, where additional capacity can be valuable even when access latency is higher than that of local memory.

A practical AI system may therefore use:

• GPU HBM: The hottest model weights, activations, and computation-critical data.
• Host DDR5: General-purpose system memory and frequently accessed working data.
• CXL-attached DDR5: Additional capacity for data that benefits from memory semantics but does not require the lowest possible latency.
• SSD-backed capacity: Larger datasets and colder data that can tolerate additional access latency.

The appropriate placement depends on access patterns, reuse frequency, latency sensitivity, and the overhead of moving data between tiers.

See KAD’s analysis of CXL workloads, KV-cache offloading, memory pooling, and tiering for a deeper explanation of these architectural trade-offs.

📈 4. Benchmark Results: Up to 4.7× Throughput and 18.7× Efficiency

#

Xcena presented MX1 performance measurements at Hot Chips 2026, comparing its device against a host CPU performing data processing over CXL.

The company reported the following peak improvements on selected data analytics kernels.

These are vendor-reported peak results for selected benchmarks, not general performance guarantees for all applications.

The evaluated operations included compression, decompression, Parquet decoding, less-than filtering, LIKE filtering, and aggregation.

These workloads are useful test cases because their performance can depend heavily on memory bandwidth and the ability to process data in parallel.

Why moving computation to memory improves throughput

#

Consider a query that reads a large dataset but ultimately needs only a small fraction of the records.

In a conventional implementation, the host CPU may receive and process substantial amounts of data before filtering out unwanted records.

With near-memory processing, compatible filtering operations can execute close to the stored data. Only the filtered results or other required outputs need to return to the host.

This can reduce traffic over the CXL connection and allow the processing units inside the device to use local memory bandwidth more efficiently.

The gain depends on the operation. Filtering a dataset that eliminates most records may benefit substantially, while a workload that needs every record transferred to the CPU may see a smaller advantage.

The architecture is therefore most compelling when the operation can reduce the volume of data that must cross the host-device boundary.

How to interpret the 18.7× energy-efficiency figure

#

Xcena’s reported 18.7× energy-efficiency improvement is tied to its chosen comparison and selected analytics workloads.

It should not be read as an 18.7× reduction in total server power, nor as a guarantee that every application will consume that much less energy.

The total result depends on what power is included in the baseline, the amount of data transferred, the utilization of the host and device, and the energy required by the storage and memory subsystems.

The most meaningful deployment evaluation would compare complete workloads, including host CPU activity, CXL transfers, device power, SSD accesses, and the time required to finish the task.

🤖 5. AI Applications: Vector Search, KV Cache, and Data Preprocessing

#

The MX1 targets a category of AI workloads where memory access and data filtering can consume significant resources.

Rather than replacing the GPU or CPU, the device is designed to offload selected operations that benefit from processing close to memory.

Vector search and similarity filtering

#

Vector databases store numerical representations of documents, images, and other data. Retrieval systems compare query vectors with stored vectors to identify relevant candidates.

Large vector-search workloads can require scanning and scoring many records, especially when a system needs to search a large collection or filter a broad candidate set.

With near-memory processing, compatible parts of the search pipeline can be executed on the MX1’s internal cores. This can reduce the volume of intermediate data transferred to the host.

The effectiveness depends on the search algorithm, index structure, supported vector operations, and how much of the pipeline can run locally.

The device is not automatically a replacement for a GPU-based vector index or a dedicated search accelerator. Its potential advantage is reducing data movement for workloads suited to memory-side processing.

Database filtering and aggregation

#

Database operations are another natural target.

A query may read a large table, apply predicates, and aggregate results even though only a small portion of the original dataset contributes to the final answer.

Executing supported filtering and aggregation operations close to memory can reduce unnecessary transfers to the CPU.

This is particularly valuable when the data is large, the result is comparatively small, and the processing can be divided efficiently across many small cores.

The benefit depends on the query plan and the overhead of moving data into the device’s processing model. Complex queries with dependencies or unsupported operators may require additional processing on the host.

LLM KV-cache retrieval

#

During LLM inference, the KV cache stores intermediate key and value tensors associated with previously processed tokens.

As context length and concurrency increase, KV-cache capacity can become a major memory-management challenge.

InfiniteMemory provides a way to expose additional storage-backed capacity through a CXL memory interface. The near-memory processing architecture can also perform selected operations on data closer to its location.

For example, an inference system may need to retrieve relevant cached context or score candidate cache entries without transferring all associated metadata and data through the host.

The exact benefit depends on the runtime and cache-management strategy. Placing additional KV-cache data in SSD-backed memory does not make it as fast as GPU HBM or local DDR5, and frequently accessed data must still be managed to avoid expensive storage misses.

The architecture is therefore best understood as an additional memory tier and processing resource, not a universal solution to KV-cache latency.

Why host and GPU compute remain essential

#

The MX1’s more than 1,000 RISC-V cores are designed for parallel data processing rather than to replace the CPUs and GPUs responsible for general-purpose execution and demanding neural-network computation.

The host remains responsible for system control, application orchestration, and work that does not benefit from offloading.

The GPU remains responsible for supported high-throughput matrix operations and model execution.

The MX1 complements both by handling selected memory-oriented operations closer to the data.

This division of responsibility is the defining idea behind computational memory.

🧑‍💻 6. Programming MX1: RISC-V, LLVM, and the PXL Runtime

#

A computational memory device containing more than 1,000 processing cores introduces a substantial software challenge.

Developers need a way to express data-parallel operations, distribute work across the device, manage shared data structures, and synchronize execution without manually coordinating every core.

Xcena’s software model is designed to abstract much of that complexity.

C, C++, and Rust support

#

Xcena uses an LLVM-based toolchain modified to support the custom instructions available on its processing cores.

The development model allows supported kernels to be written in C, C++, or Rust.

The company also provides a software development kit intended to make programming the device familiar to developers accustomed to GPU and parallel-computing environments.

However, a CUDA-like programming model does not imply CUDA binary compatibility. Applications must be compiled and supported through Xcena’s toolchain and runtime rather than assuming that existing CUDA kernels can execute directly on the device.

This distinction matters when evaluating the effort required to port an existing AI or analytics application.

PXL: A MapReduce-style programming framework

#

Xcena developed the Parallel Xceleration Library (PXL) to simplify the management of the MX1’s large number of internal processing cores.

The framework follows a model inspired by distributed database systems and MapReduce-style parallel execution.

Developers define kernels and work units, while the runtime distributes supported tasks across Memory Acceleration Units and coordinates allocation and synchronization.

The goal is to preserve a familiar programming model without requiring the application to explicitly manage thousands of individual processors.

This approach is well suited to data-parallel operations in which large datasets can be divided into independent or loosely coupled tasks.

Examples include filtering, compression, decompression, and aggregation.

Shared virtual address space

#

The shared virtual address-space model is a central part of the design.

The MX1 must coordinate references to host memory, its own DDR5, and SSD-backed InfiniteMemory capacity while maintaining valid mappings for the application.

A unified address model can reduce the need for developers to manage separate pointers and explicit transfers for every memory tier, depending on the supported programming interface.

However, a shared virtual address space does not eliminate physical differences between memory types. The cost of an access still depends on where the data resides and whether a cache hit or storage fetch is required.

Efficient applications must therefore account for locality and access patterns, even when the software exposes a simplified memory abstraction.

SQL and vector-search integrations

#

Xcena is also developing higher-level integrations through its XFLARE analytics library, including support for SQL engines and FAISS-based vector search.

The broader software roadmap includes integrations with Apache Arrow, PyTorch, and vector database frameworks.

These integrations matter because near-memory hardware becomes more useful when developers can access it through existing data-processing and AI software.

A device that delivers strong isolated kernel results but requires extensive custom application development may be difficult to adopt broadly.

The software ecosystem will therefore be a significant factor in determining how useful MX1 becomes in production systems.

🔗 7. CXL 3.2 and PCIe 6.0: The Platform Dependency

#

The MX1’s broader market opportunity depends on the development of the CXL ecosystem.

The device uses CXL 3.2 over PCIe 6.0, providing the interface between the host and its expanded memory and near-memory compute resources.

CXL is designed to preserve useful memory and device semantics across supported interconnects, but the available capabilities depend on the host CPU, firmware, operating system, device, and platform topology.

Why adoption has taken time

#

CXL memory expansion and pooling offer an attractive way to increase memory capacity independently of a single host’s conventional DDR channels.

However, deploying CXL in production requires a compatible platform and software stack. Operators must validate firmware support, memory discovery, operating-system integration, memory placement, error handling, and workload behavior.

CXL 3.x also enables more advanced fabrics and shared-resource architectures, but these capabilities introduce additional management and consistency requirements.

The market must therefore mature across multiple layers, including processors, memory devices, controllers, switches, software, and system administration.

What makes MX1 different from passive memory expansion

#

Conventional CXL Type 3 memory expansion primarily addresses capacity. The host gains access to additional memory, but computation still typically takes place on the host CPU or another accelerator.

MX1 combines that capacity with processing resources inside the memory device.

This gives it a differentiated role in workloads where computation can reduce the amount of data that must cross the CXL connection.

The architecture also introduces more complexity than a passive memory expander. Its internal processors, software runtime, virtual-memory management, and storage-backed capacity must all work reliably together.

The potential payoff is greater than simply adding more memory, but only if applications can use the processing resources efficiently.

Industry comparisons and competing approaches

#

Other companies are also exploring computational memory and memory-side acceleration.

Marvell’s Structera A, for example, combines memory expansion with Arm-based processing for workloads such as vector search and recommendation systems.

Other CXL vendors focus on memory controllers, pooling switches, or shared-memory infrastructure.

These approaches address related problems but do not necessarily offer the same programming model or workload support.

The MX1’s distinguishing feature is its combination of a large number of specialized RISC-V cores, DDR5 expansion, and SSD-backed memory in one device.

Whether this architecture gains broad adoption will depend on customer workloads, performance consistency, total system cost, software integration, and the availability of compatible CXL platforms.

📅 8. Production Plans and Commercial Adoption

#

At Hot Chips 2026, Xcena presented the MX1 architecture and reported its initial performance measurements.

The company is supplying prototype samples to memory manufacturers, CPU vendors, and hyperscale infrastructure providers. It plans to begin mass production by the end of 2026, with initial customer revenue targeted for 2027.

These milestones remain plans rather than evidence of completed mass production or established volume adoption.

What customers need to validate

#

For a product such as MX1, customer evaluation must extend beyond the headline throughput numbers.

Important validation areas include:

• Compatibility with the host CPU, firmware, operating system, and CXL interface.
• Performance of actual database, vector-search, and AI workloads.
• Latency behavior across DRAM-resident and SSD-backed data.
• Programming effort and integration with existing application frameworks.
• Reliability, error handling, and memory protection.
• Power consumption and total system cost.

A computational memory device can show substantial gains in selected benchmarks without delivering the same improvement across every application.

The strongest early use cases will likely be those that share the architecture’s advantages: large datasets, high rates of filtering or reduction, and relatively small result sets compared with the amount of input data.

Why the wider ecosystem matters

#

The long-term success of computational CXL memory depends on more than one vendor’s hardware.

CPU platforms must provide reliable CXL support. System manufacturers need compatible memory and interconnect designs. Operating systems and runtimes must expose the device’s memory and compute capabilities. Application developers need convenient ways to offload appropriate workloads.

If those pieces mature together, computational memory could become a useful component of AI infrastructure alongside CPUs, GPUs, HBM, conventional DDR5, and storage.

If software integration remains difficult or performance benefits are limited to narrow workloads, adoption may remain restricted to specialized deployments.

🌌 Conclusion: From Memory Expansion to Computation Near Data

#

Xcena’s MX1 pushes CXL memory expansion beyond the conventional idea of adding more RAM to a server.

By combining up to 2TB of DDR5, SSD-backed InfiniteMemory, and more than 1,000 custom RISC-V cores, the device aims to process selected workloads near the data instead of repeatedly moving large datasets to a host CPU or GPU.

Xcena’s reported results—up to 4.7× throughput and 18.7× energy efficiency relative to host CPU processing over CXL on selected analytics kernels—illustrate the potential of this approach. They do not establish universal performance gains, and real-world benefits will depend on workload characteristics, software maturity, and the complete system configuration.

For AI infrastructure, the most promising applications include vector search, database filtering, aggregation, preprocessing, and selected KV-cache operations. These workloads can benefit when near-memory processing reduces data movement while preserving the ability to access a larger memory hierarchy.

The main challenge is turning the architecture into an accessible production platform. Xcena must integrate the RISC-V execution environment, virtual-memory model, storage-backed capacity, and application software while relying on a broader CXL ecosystem that is still developing.

The fundamental idea is compelling: not every byte needs to travel to the CPU or GPU before it can be processed. In the emerging AI memory hierarchy, some of the most useful computation may occur much closer to where the data already resides.