南韩新秀XCENA：CXL计算内存革新数据处理

阅读收获

• 架构优化路径：掌握CXL计算内存如何通过NDP消除Shuffle开销，实现1节点顶10节点，指导数据中心从Scale-out向高密度Scale-up转型，降低TCO。
• 软硬协同实践：理解Gluten+Velox+Substrait集成Spark的机制，直接处理Parquet/Arrow格式，提升向量/图任务效率，适用于AI RAG管道部署。
• 任务定位策略：辨识“惊人并行”负载的最佳硬件——RISC-V矢量引擎在PB级CXL池中执行简单扫描，释放CPU/GPU专注复杂逻辑。
• 生态分层洞察：评估SSD-backed热冷数据调度价值，推动异构内存管理，防范厂商锁定风险。

全文概览

在AI时代，大规模数据分析正面临“内存墙”严峻挑战：传统存算分离架构下，GPU饥饿于数据加载，频繁的磁盘溢写（Spill）和节点间Shuffle导致性能边际递减。你是否好奇，为什么单节点内存容量不足会放大整个集群的TCO？XCENA的MX1方案提供答案：它将CXL 3.0内存扩展与数千RISC-V核心、TFLOPS矢量引擎深度融合，实现近内存计算（Near-Memory Computing）。

MX1硬件支持1TB DDR5 + SSD-backed扩展，协议兼容HDM-DB和反向缓存一致性，确保主机-设备数据同步。软件栈从Kernel Driver到PXL API，覆盖SQL、向量搜索、图遍历，支持Spark+Gluten+Velox无缝集成，将解压/排序等任务下沉内存端，降低CPU利用率90%。这不仅是内存扩展，更是“移动计算而非数据”的范式转变：从Scale-out集群转向高密度Scale-up单节点，节省空间/能耗，优化Lakehouse-RAG工作流。

面对AI数据湖的爆炸增长，这种存算一体架构能否重塑数据中心？它如何应对CXL延迟（170-250ns）高于本地DRAM的痛点？本文剖析MX1全栈，揭示行业从互联向计算框架的跃迁。

👉 划线高亮 观点批注

MX1：CXL 内存 + 数据处理（CXL Memory + Data Processing）计算存储解决方案。主要内容分为硬件架构与软件框架两大板块

1. 硬件架构 (Novel CXL Hardware)

图片左侧展示了 MX1 硬件实物图及其核心规格：

• 计算核心： 搭载了 1000s of Custom RISC-V Cores（数千个定制 RISC-V 核心）以及 TFLOPS Vector Engine（万亿次浮点运算矢量引擎），强调了其强大的近内存计算（Near-Memory Computing）能力。
• 内存规格： 支持 DDR5 x 4Ch（4通道 DDR5），容量约为 1TB。
• 互联协议： 明确标注支持 CXL 3.0 HDM-DB（Host-Managed Device Memory with Dirty-Bit），并具备 Back-invalidation Cache Coherence（反向作废缓存一致性），这是 CXL 3.0 协议中确保主机与设备间内存数据同步的关键特性。
• 扩展性： 提及 SSD-backed CXL Expansion，暗示该设备可能支持通过 SSD 进行内存池化扩展。

2. 软件框架 (Rich Software Framework)

右侧展示了从底层驱动到上层应用的完整栈架构：

• 工具链 (SDK层)： 包含 IDE、模拟器 (Simulator)、编译器 (Compiler) 和 C/C++ 库。
• API 分层： Data Specific API： 面向特定应用（如 SQL、向量搜索、图遍历）。
  • Abstracted Runtime API： 提供并行编程抽象（如 MapReduce、GAS、CCL）。
  • Low Level Device API： 显式控制数据移动（datamove）、任务启动（job launch）和同步（sync）。
  • Kernel Driver： 负责设备管理。
• 应用领域： 覆盖了表格 (Table)、向量 (Vector)、关键词 (Keyword)、图 (Graph) 以及多模态/多智能体 (Multi-Modal / Multi-Agent) 等大规模数据处理场景。

CXL扩展DRAM 已经从传统互联方案过渡到新的计算框架，从越来越多的厂商PR材料来看，基于CXL扩展的大内存体系能够给AI数据堆栈提供更接近数据的处理管道，这是站在互联角度所看不到的；与此相比，在追求绝对带宽效率的互联场景，仍然是路漫漫其修远兮

图片通过一个循环流向图和三个关键技术模块，详细描述了现代 AI 与数据工作流（AI/ML Workflows）之间的共生关系，强调了 AI 已成为当今数据的最大消费者

• AI 与数据架构的深度融合： 图片明确指出“最大的表和湖仓是为 AI 而建的”。这表明现代存储架构（如 Lakehouse）的设计目标已经从单纯的业务报表转向支持大规模 AI 训练和推理。
• RAG 成为标准 AI 工作流的一部分： 通过将 Vector Database 与 Model 交互并列，强调了在生成式 AI 时代，实时数据检索（RAG）与模型推理同等重要，这要求存储系统具备极高性能的向量处理能力。
• 数据加载（Data Loading）是性能瓶颈： 特别提到了“Feeding GPUs”，暗示了在 AI 工作流中，如何高效地将大规模数据从湖仓加载到算力单元（GPU）是当前技术面临的关键挑战，涉及延迟控制和复杂的数据排序逻辑。

Cite

专业词汇对照：

• Lakehouse: 湖仓一体（结合了数据湖的灵活性和数据仓库的管理能力）。
• Embeddings: 嵌入（将高维数据映射为低维向量的过程）。
• ETL: 提取、转换、加载（数据集成过程）。
• RAG: 检索增强生成。

图片深入探讨了大规模数据分析在传统架构下遇到的性能挑战，核心在于内存效率低下和横向扩展带来的边际效应递减

1. 传统“存算分离”架构面临内存墙挑战： 在大规模数据分析中，计算节点的本地内存容量限制了处理能力。一旦发生内存不足，频繁的磁盘溢写（Disk Spill）和跨网络的数据洗牌（Shuffle）成为了性能的致命伤。
2. 工作负载不确定性导致资源利用率低下： 由于不同分析任务对内存需求的剧烈波动，传统的固定配置模式被迫走向“过度配置”。这揭示了行业对动态、可扩展的共享内存资源池（如通过 CXL 技术实现）的迫切需求。
3. Shuffle 开销限制了扩展规模： 图片强调了分布式系统在扩展时的“边际收益递减”。当计算集群规模扩大时，节点间数据交换的复杂度成为了主要瓶颈，传统的分布式文件系统（DFS）难以有效缓解这种高并发、低延迟的数据交换压力。

Cite

专业词汇对照：

• OOM (Out of Memory): 内存溢出/耗尽。
• Spill: 溢写（内存数据暂存至磁盘）。
• Shuffle: 洗牌/数据重组（分布式计算中节点间交换数据的过程）。
• Scaling-out: 横向扩展/水平扩展。

图片展示了针对前述大规模数据分析挑战的提议解决方案。通过视觉对比，提出了一个核心设想：用单点的高密度架构替代庞大的服务器集群

• 从横向扩展（Scale-out）到垂直整合（Scale-up）的思维转变： 针对上一张图中提到的“集群 Shuffle 开销”和“边际收益递减”问题，XCENA 提出的方案是：通过提高单节点的计算与内存密度，消除节点间的网络通信壁垒。这意味着复杂的数据分析任务可以在同一个高带宽、一致性的内存池中完成，而不需要跨网络交换数据。
• 数据中心效率的极致提升： 如果 1 个节点等效于 10 个节点（1:10 的压缩比），这意味着：
  • 空间节省： 机架空间占用减少 90%。
  • 能耗降低： 减少了 10 台服务器所需的风扇、电源适配器以及交换机端口的功耗。
  • 管理简化： 运维人员面对的是更少的硬件实体和更简单的网络拓扑。
• 计算存储（Computational Storage）的价值体现： 这里的“高密度”不仅指内存容量，更强调了第一张图提到的 RISC-V 矢量引擎。这种“存算一体”的单节点能够处理原本需要 10 台普通服务器分布式处理的任务量，核心在于将计算力直接置于 PB 级数据的边缘。

让计算和内存彻底分离开来。其实谷歌早在多年前就已经提出了这样的想法。现在来看，这一数据中心基础设施的架构迁移有了更紧迫且落地的场景

图通过一个二维坐标轴对不同的计算任务进行了分类，旨在定位 XCENA 的 CXL 计算内存 在整个计算生态中的位置

• 精准定位“受限于内存”的任务： XCENA 认为其技术的最佳应用场景是那些“计算简单但数据量极大”的任务。在这种场景下，传统 CPU 浪费了太多能力在复杂的指令调度上，而 GPU 的 HBM 容量又不足。CXL 计算内存在此处可以提供“在大规模数据池中直接进行简单并行计算”的最优解。
• 存算分离与近存计算的互补性： 图片展示了三种存储层次的共存：通用 CPU 处理复杂逻辑，GPU 处理密集矩阵运算，而 XCENA 的 CXL 计算内存 则处理海量的非结构化数据分析（如向量搜索）。这构成了一个完整的异构计算版图。
• 对“惊人并行”任务的硬件优化： 标题中提到的 "Embarrassingly Parallel"（惊人并行）是指那些可以轻易拆分成数千个独立子任务的工作负载。结合第一张图提到的“数千个 RISC-V 核心”，XCENA 的策略是通过极多的小核心直接在 CXL 内存边上处理这些简单任务，从而规避将数据搬运到 CPU 或 GPU 的高昂开销。

XCENA 如何超越传统的 CXL 内存扩展器，构建一个完整的计算存储生态系统

• 分层价值主张 (Tiered Value Proposition)： XCENA 明确将其产品定义为 “不仅仅是另一个 CXL 内存扩展器”。它在提供基础的 DRAM 扩展功能之上，叠加了“PB 级扩展能力”和“近内存计算引擎”，构建了竞争护城河。
• 存算一体带来的 TCO 优势： 通过在内存扩展卡上集成计算引擎，该方案试图打破传统的“CPU 为中心”架构。右侧提到的 “Lower CPU Util” 是关键点，这意味着用户可以用更便宜、核心数更少的 CPU 来完成同等规模的数据分析任务，从而显著降低 TCO（总拥有成本）。
• 异构内存分层架构： 图中提到的 “SSD-backed Expansion” 揭示了一种冷热数据管理策略：热数据驻留在 DRAM，温/冷数据驻留在 SSD，但统一映射在 CXL 内存地址空间中。这种设计在保证 PB 级海量容量的同时，利用板载计算引擎抵消了 SSD 带来的延迟增加。

数据分层调度系统在 CXL 的计算体系中将发挥重要的价值，是基于OS还是中间件来实现这一调度系统，目前仍然不明朗，这是GPU/ASIC 所不擅长的

图通过对比“传统 CXL 内存”与“带 NDP（近数据处理）功能的 CXL 内存”，直观展示了近内存计算的技术优势

• 解决 CXL 的“延迟负债”： CXL 内存由于物理链路和协议转换，延迟（170-250ns）高于本地 DRAM（80-140ns）。XCENA 的核心思路是：既然搬运数据慢，那就不搬运数据，而是将指令下发到内存端执行，从而从逻辑上抵消了访问延迟。
• 大幅降低数据中心带宽压力： 在传统模式下，为了从 1TB 原始数据中筛选出 1GB 的有效结果，必须搬运整 1TB 数据。而通过 NDP (近数据处理)，数据在内存卡内完成筛选，总线上只跑那 1GB 的结果。这不仅节省了功耗，还释放了昂贵的 CXL 链路带宽。
• 计算重心的转移： 通过集成的数千个 RISC-V 核心，CXL 存储设备转变为一个主动计算单元。这种架构特别适合“数据密集型”任务，让 CPU 从繁琐的数据扫描、过滤等简单并行任务中解脱出来，专注于更复杂的决策控制。

图通过一个具体的 SQL 查询案例，详细展示了 Spark 生态如何与 XCENA MX1 硬件进行深度的软硬协同

• 无缝对接主流大数据生态： XCENA 并没有要求用户重写代码，而是通过 Gluten + Velox 这套开源路径，将 MX1 硬件透明地接入 Spark 环境。这意味着存量的大数据任务可以几乎无成本地迁移到这种 CXL 计算内存架构上。
• 存内处理（In-Memory Processing）的具象化： 图片清晰展示了数据在 CXL DRAM 内部的演变过程。关键在于：解压、解码和排序这三个最消耗 CPU 的步骤全都在 MX1 设备内部完成。主机（CPU）只负责高层级的调度，而不参与大规模的数据搬运和扫描，这验证了前几张 PPT 提到的“降低 CPU 占用率”。
• 列式存储格式（Arrow/Parquet）的硬件加速： MX1 特意优化了对 Parquet 和 Apache Arrow 格式的支持。由于 AI 和现代分析引擎大多采用列式存储，这种在硬件层直接处理 Arrow 缓冲区的能力，极大提升了从原始存储到计算可用数据之间的转换效率。

图通过高度抽象的层级图，展示了主机（Host）与 MX1 设备之间三种不同的交互模式，体现了“以数据为中心”的演进过程

1. 从“存取”到“指令下发”的跨越： XCENA 提供了一个分层化的接口。对于简单任务，可以使用标准的 Load/Store；但为了实现极致性能，它鼓励开发者通过 PXL API 将整个计算内核发送到数据所在的位置执行。这完美诠释了标题“移动计算而非数据”。
2. 标准化生态的深度集成 (Substrait + Arrow)： XCENA 选择了 Substrait（跨语言查询计划描述格式）和 Apache Arrow（内存列式格式）作为其核心协议。这使得 MX1 不再是一个孤立的硬件黑盒，而是一个能够理解通用查询逻辑的智能节点，极大降低了集成难度。
3. 硬件级的数据格式转换： MX1 在内存端直接完成从磁盘存储格式（Parquet）到内存分析格式（Arrow）的转换。这一步骤在传统架构中通常会消耗 CPU 30%-50% 的时钟周期。在 MX1 内部完成转换，意味着 CPU 接收到的直接就是“开箱即用”的高质量结构化数据。

这张图揭示了 XCENA 的野心：定义 CXL 时代的计算标准。通过引入 PXL API，他们正在试图建立一种类似于存储界的 CUDA 的开发范式。在数据中心，这种架构将原本属于“I/O 密集型”的分析任务转化为了“近存并行计算”任务，是解决大规模湖仓一体化架构性能瓶颈的终极武器。

其实英伟达的Bluefield DPU在做类似的加速计算场景。讲道理，它是很容易将CXL内存分级扩展到英伟达的加速计算中的，只不过英伟达有意想做更大的底层创新，将其NVLink的优势进一步扩展，而不是采用行业内生态更加成熟的CXL体系。英伟达的路可以说是更彻底，但是其生态成熟度仍有待考量

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. CXL计算内存的近数据处理能否彻底解决AI数据加载瓶颈，还是需依赖OS/中间件调度来优化PB级分层？
2. 在NVIDIA NVLink与CXL生态竞争中，MX1式存算一体方案如何平衡开放性和性能，落地数据中心需克服哪些互连挑战？
3. 从Scale-up高密度转向，如何评估其对传统DFS/Shuffle依赖的分布式系统的影响，是否会加速行业并购整合？

原文标题：How CXL Computational Memory Will Revolutionize Data Processing

Notice：Human's prompt, Datasets by Gemini-3-Pro

#FMS25 #CXL内存扩展

---【本文完】---

丰子恺-护生画集-风雨之夜的候门者