Build1 distinct publisher3 min readPublished
MX1 puts 3,072 in-order RISC-V cores and up to 2TB of DDR5 behind a CXL 3.2 link, betting that bandwidth-bound inference work is cheaper to run on the card than to drag across 128GB per second of host interface.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Start with the throughput figure, because it tells you what the card is for. XCENA reports roughly 3 TFLOPS of dot-product throughput through the vector engines, and says outright that this is a qualified measure, not comparable with a general-purpose accelerator rating [8]. Do the division. Three TFLOPS spread over 3,072 cores at 1.1GHz is about 0.9 FLOP per core per cycle [1]. For cores advertised with vector engines, that is thin. Either the published number comes from one specific kernel rather than a peak, or the vector units are narrow. Both readings land in the same place: this device is not sold on arithmetic, it is sold on traffic it removes from the link.
The link is the invisible constraint behind the whole design [6]. XCENA targets analytics kernels, vector search, memory compression and KV-cache handling, all cases where working on the card cuts transfers over CXL [9]. That is a coherent shopping list. It is also a narrow one, and the narrowness is the honest part of the pitch.
The rack number deserves the same treatment. A 20TB pool assembled from cards holding up to 2TB each is ten cards [2][13], and 2.7TB per second divided across ten devices is 270GB per second each [2]. That is more than double the 128GB per second a CXL 3.2 x8 host interface provides [6]. So the pool figure cannot be host-visible bandwidth. It is aggregate media-side or switch-side capability, which is the relevant number when your kernel runs on the card, and the wrong one when your kernel runs on the GPU.
The part I would want to try first is the addressing. Host applications and MX1 can operate on the same virtual addresses, which reduces pointer translation and copying [10]. Offload to a device normally means marshalling into a device buffer and rewriting pointers, which is where most near-data projects quietly die. If a pointer in a host-side index is still valid on the card, a vector-search probe or a KV-cache lookup can be handed across as it stands. Around that, XCENA ships C/C++ and Rust support, drivers, simulation tools and a MapReduce-style runtime called the Parallel Xceleration Library [11]. That is the right set of things to build, and it is a lot of code for a company that reported more than 90 staff across Pangyo and Sunnyvale in May [18], funded by a $135 million Series B the same month [15].
Samsung and XCENA reported results from two selected AI workloads, and neither has published an independent reproduction [14]. Treat those as claims about someone else's workload. For a retrieval-augmented generation figure to transfer, your working set has to exceed host DRAM so a pooled tier is the real alternative rather than a bigger server, your retrieval kernel has to be bandwidth-bound rather than latency-bound, and your access pattern has to hit the DDR5 cache often enough to keep the SSD tier out of your tail latency. XCENA concedes the last point directly: the usefulness of Infinite Memory depends on whether caching and prefetching can hide the SSDs' higher latency for a given workload [7].
Kim's argument to TechCrunch in May was that CPUs and GPUs got smarter over the decades and memory never did [16]. MX1 turns that into something you can put in a slot and profile, which is a better position than a whitepaper and some distance short of a product you can schedule against.
Ranked by verification strength, evidence, and original report placement.
Samsung and XCENA reported results from two selected AI workloads, but have not published independent reproductions of those tests.
Jin Kim and XCENA used Hot Chips 2026 on August 25 to demonstrate a memory expansion card that can execute selected jobs itself.
MX1 combines up to 2TB of DDR5, SSD-backed memory and 3,072 small RISC-V cores on silicon manufactured with Samsung Electronics' 4nm process.
MX1's 3,072 in-order RISC-V cores run at 1.1GHz; groups of 32 cores form clusters, four clusters make a 128-core subsystem, and the chip has 24 subsystems that can accept separate jobs.
Chips and Cheese reported power consumption of 40 watts for the compute chip and about 90 watts for a board populated with four DIMMs.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 30, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Memory is 30% of hyperscaler capex, and the cheapest fix is the DDR4 you already own1 distinct publisher
product
Half the incident clock goes to search, and telemetry tools cannot read the answer1 distinct publisher
invest
IIF pins the won's July break from the yen on Samsung and SK hynix fab spending1 distinct publisher
invest
Muan County takes its seat, and an 800 trillion won fab cluster gets a committee date1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific numbers, single lineage
The hardware description is precise enough to argue with — 24 subsystems, 40 watts for the compute die, an x8 link rated at 128GB per second — and that precision is real value. But trace any figure back and it ends at the same place: a Hot Chips stage, reported by Chips and Cheese and ServeTheHome, describing slides authored by the two companies selling the card. There is no third-party silicon in hand, no reproduction of the retrieval or long-context runs, and no named customer.
Ten cards on a demo bench
Every MX1 we can account for is in a test rig: ten in the retrieval demo, five per server in the long-context run. There is a rebrand, a funded team of ninety-odd, and a reference design that pools cards behind a CXL switch — and no shipping product, no pilot, no cloud instance, no distributor. Adoption at this point is working silicon in front of an audience.
The multiples travel; the caveats don't
Runtimewire hedges more than most: it labels the 3 TFLOPS figure a dot-product number, notes both AI tests were the cases most flattering to the design, and flags that the analytics energy comparison excluded idle power. The gap sits one level above the reporting, in the numbers being hedged. '64 times the query throughput' against a host CPU baseline the vendor chose is the sort of figure that outlives its footnotes, and a 3.35-fold inference gain measured on the workload the card was built for is not the same claim as a general speedup.
Samsung sits on three sides
Samsung fabricated the 4nm die, sells the DDR5 that fills the card, and gains if CXL pools become a standing line item in AI racks — and it ran the benchmarks. XCENA, five months past a $135 million round, needs a reason for hyperscalers to accept a fourth programmable device per server. Neither party has an interest in publishing the workload where near-memory processing loses, and the two they did publish are the ones the architecture was designed for.
Engineering checks out; consequence doesn't
Confidence lands mid-scale for a split reason. The technical account survives inspection — cores, clock and throughput reconcile, and the pool arithmetic exposes rather than hides the host-bandwidth ceiling — so we trust what the card is. Whether it matters commercially rests on one outlet's read of a conference, with the power estimate for a pooled rack resting on an assumption nobody has confirmed. A second independent teardown, or one named evaluator, would move this a long way.