XCENA bets on CXL memory with compute baked in, CEO explains

XCENA is a South Korean startup focusing on CXL memory pooling and sharing with computational memory technology. The company was founded in early 2022 as MetisX, then rebranded as XCENA at the end of 2024. XCENA is relatively new to us, though we noted it did win the FMS 2025 Best of Show Award for the most innovative computational memory technology with its MX1 offering. This integrates thousands of RISC-V cores and vector engines for parallel execution adjacent to the memory, a technique called near-data processing. It accelerates and offloads tasks, such as AI inference work and general analytics, from a host CPU.

We had the opportunity to find out more via an email interview with CEO and co-founder Jin Kim.

Blocks & Files: Why did you and your co-founders in South Korea – CPO Harry Juhyun Kim and CTO Kim DoHun – found MetisX in 2022? What was your technology background?

Jin Kim: We founded XCENA because it was becoming clear that AI infrastructure was hitting a memory wall, not a compute limit. CPU and GPU performance kept improving, but memory capacity, bandwidth, and data movement were becoming primary bottlenecks. 

The founding team came from SK Hynix and Samsung, with deep experience across memory, system architecture, and semiconductor design. We spent years together working on memory-centric technologies at SK Hynix and saw that CXL created a real opportunity to address these bottlenecks.

XCENA, or MetisX at the time, was started to address that gap directly by building a more efficient and smarter memory layer for modern AI workloads.

Blocks & Files: What was your thinking about providing differentiation and separate technology from other CXL memory suppliers such as Panmnesia, Israel's UnifabriX, Astera Labs, Fadu, Samsung, SK Hynix and Marvell? Where was the gap in the market that you could fill better than them?

Jin Kim: The CXL ecosystem is quite diverse today, with different companies solving different parts of the stack. Some players, like Panmnesia or UnifabriX, are focused more on fabric and switching, enabling connectivity across systems. Others, like Astera Labs and Marvell, are building controllers primarily focused on memory expansion. And companies like Samsung, SK Hynix, and Fadu are key memory and storage providers, which we see more as partners than direct competitors.

We saw the gap at the memory layer. However, the real opportunity was adding compute close to where the data resides.

Most solutions at the time focused on expanding memory capacity or improving connectivity. But the core inefficiency in AI systems was and still is data movement. 

Our approach was to combine memory expansion with additional features like near-data processing and what we call an InfiniteMemory architecture. With near data processing, we added compute so users could process data where it lives. With InfiniteMemory, users can extend memory capacity to SSD scale, far beyond traditional limits.

From there we focused on filling the gap by reducing data movement and scaling memory even more cost-effectively by leveraging SSDs as an additional memory layer. 

Blocks & Files: How was MetisX funded?

Jin Kim: We started with a seed round in early 2022, raising about KRW 8.5 billion (~$6 million USD) from a group of Korean venture investors. That early funding was largely driven by the team's background in memory and semiconductor architecture, as well as the potential of CXL as a new system-level technology.

Our Series A in 2024 was approximately KRW 60 billion (~$44 million), which brought our total funding to around KRW 68.5 billion (~50 million) and valued the company at roughly KRW 250 billion (~$167 million). That round allowed us to move from architecture and prototyping into product development, silicon execution, and ecosystem engagement.

Currently, we are in the process of raising a Series B round to support scaling customer deployments, expand go-to-market efforts, and engage more closely with customers and partners using MX1 prototypes, while also advancing next-generation computational memory products.

Blocks & Files: Why was the MetisX name changed to XCENA in December 2024?

Jin Kim: “MetisX” originally reflected our focus on intelligent memory. As the company evolved, we started to see that improving memory alone wasn't enough, and that the overall memory architecture needed to change as the datacenter scene was constantly being reshaped. It became clear that what we were building had grown beyond that initial scope.

“XCENA” better captured that direction. The “X” stands for transformation, and “CENA” comes from the Latin Scena, meaning “scene.” Together, it reflects our goal of transforming the computing landscape with intelligent memory.

More specifically, we saw the industry shifting from CPU- and GPU-centric architectures toward data- and memory-centric systems, especially with technologies like CXL. The new name better aligned with that transition.

It reflects a shift toward building a broader memory-centric computing platform.

Blocks & Files: How do you view CXL and its future?

Jin Kim: AI is rapidly increasing model sizes and context lengths, and memory is becoming the primary bottleneck. The challenge is no longer compute, it's how efficiently systems can store, access, and move large volumes of data.

CXL addresses this by enabling memory to scale beyond traditional limits, allowing it to be pooled, shared, and used more efficiently across systems. Traditional server architectures weren't designed for terabyte-scale datasets. High-bandwidth memory helps, but it's still expensive and limited in capacity.

CXL introduces a different model, where memory is decoupled from compute, enabling much larger effective capacity across systems. It also enables architectures such as MX1, which brings computation closer to data and reduces unnecessary data movement.

We're still early, but the direction is clear. As AI workloads grow, efficiency will be defined by how memory is structured and utilized, not just compute performance. With next-generation CPU platforms beginning to support CXL 3.x, adoption will accelerate, and CXL is set to become a foundational layer for more scalable and cost-efficient datacenter architectures.

Blocks & Files: Tell me about your computational product please? Isn't it sufficient to provide memory pooling without adding computational memory? Why don't you let the servers do computation with XCENA providing memory pooling and sharing transparently?

Jin Kim: Memory pooling solves the capacity problem, but not all of the data movement issues.

In many AI and data workloads, a significant amount of time and energy is spent moving data between memory, CPUs, and GPUs. Simply pooling memory increases capacity, but the system still has to move large volumes of data back and forth, which becomes a bottleneck.

Our approach is to combine pooling with near-data processing. MX1 integrates memory expansion with embedded RISC-V compute, allowing operations like vector search and analytics to run directly on the data. The goal isn't to replace CPUs or GPUs, but to offload memory-intensive work, reducing data movement and improving performance and efficiency.

In the end, pooling is necessary, but not sufficient. You also need to reduce the cost of moving data and MX1 is designed to address that.

Blocks & Files: What is the purpose of the CXL software you have created?

Jin Kim: CXL introduces new challenges in how memory is managed and used at scale. Our focus is making that complexity easy for developers to adopt in practice.

XCENA provides a full-stack SDK with multi-level APIs, simulation tools, and drivers for major operating systems. Developers can start by using it as a memory expander and then enable compute offload as needed.

High-level APIs allow existing AI, analytics, and vector workloads to run without major rewrites, while low-level device APIs give teams precise control over data placement and job execution. This makes CXL memory easy to integrate into existing software stacks, without requiring new programming models or vendor-specific ecosystems.

The SDK also supports applications such as data analytics, vector database acceleration, and KV cache offloading, enabling developers to leverage computational memory with minimal changes to existing systems.

In short, the goal is to make CXL memory actually usable in real workloads.

Blocks & Files: How does CXL memory pooling relate to a GPU server's high-bandwidth memory (HBM)? Is CXL memory pooling and sharing only applicable to x86 servers?

Jin Kim: HBM and CXL memory serve different roles in AI infrastructure.

HBM provides high bandwidth but is limited in capacity, so it's best suited for compute-heavy work like prefill during inference, where GPUs handle most of the work. As models and context windows grow, especially with KV cache, the bottleneck shifts to the decode stage, which is more memory-bound. This is where CXL becomes important.

CXL enables large, shared memory pools beyond GPU memory, allowing KV cache to be reused across workers instead of GPU having to recompute the cache every time. This reduces pressure on GPUs, improves latency, and lowers cost per token.

At the system level, this means HBM supports compute that need high bandwidth but less capacity, while CXL provides more capacity and sharing at scale.

Also, CXL is not limited to x86. As long as the server platform supports CXL 3.x, memory pooling and sharing can be applied, whether it's x86, ARM, or other architectures.

Blocks & Files: How do you see CXL technology contributing to AI training and inferencing?

Jin Kim: CXL plays a role across the AI pipeline, but its impact is most visible in data-heavy stages rather than pure compute.

For training, a big part of the challenge is still data preparation. Frameworks like Spark or Velox must process large volumes of data before training even begins, which creates memory pressure and a lot of data movement. CXL, especially with MX1, lets you offload those analytics workloads to its RISC-V cores, reducing unnecessary data transfers.

For inference, the bottleneck shifts to memory-heavy workloads like vector databases, RAG, and KV cache. MX1 can directly accelerate vector databases by running search and filtering close to the data, improving latency and throughput. For KV cache, the benefit is more about capacity and sharing as GPU memory doesn't have enough capacity to support KV reuse.

So, at a high level, CXL, especially MX1, helps by reducing how much data needs to move around the system, which is becoming one of the biggest constraints in AI today.

Blocks & Files: How do you view CXL Memory and composable systems, such as those espoused by Liqid?

Jin Kim: We see CXL memory and composable systems as part of the same broader shift toward more flexible, memory-centric infrastructure.

Instead of tying memory to a single server, the idea is to pool it and share it across systems so you can use it more efficiently. CXL makes that possible, and composable infrastructure is really the way CXL gets implemented at the system level.

Compared to network-based approaches like RDMA, CXL works closer to the hardware with cache coherency, which helps to reduce overhead and improve performance, especially for memory-heavy workloads.

We’re also working to ensure our solutions fit naturally into that ecosystem. For example, we're looking to integrate with CXL pooling platforms so our devices can operate in CXL switching environments, giving customers flexibility to deploy both direct-attached and composable configurations.

Overall, this is the direction the industry is heading—more flexible systems, better resource utilization, and a more efficient way to scale AI infrastructure.

Blocks & Files: What is your business (e.g. funding) and technology roadmap for the next 12 to 24 months?

Jin Kim: On the business side, we're currently in the process of raising a Series B round. That will primarily go toward scaling customer deployments, expanding our go-to-market efforts, and engaging more closely with customers and partners around the current MX1 prototype.

On the technology side, our near-term focus is getting the production version of MX1 ready over the next year and working closely with customers to bring it into real deployments.

In parallel, we're already looking ahead to the next generation of products. That includes exploring how different open interconnect standards evolve, whether that's CXL, UALink, or others, and making sure we're aligned with where the ecosystem is heading.

Over the next 12 to 24 months, the focus is on getting MX1 into production while preparing for what's next, as the ecosystem evolves quickly and open interconnect protocols continue to develop.