H3：CXL内存池化：架构演进与实践挑战

阅读收获

• 拓扑重构逻辑：理解内存从“服务器附属”变为“独立池化资源”后，数据中心物理拓扑、逻辑拓扑和可靠性拓扑将如何系统性重构
• 性能与实现细节：掌握5TB内存共享的物理实现方案（20个E3.S模块 + CXL Switch），以及120 GB/s带宽、2亿IOPS的性能数据背后的技术支撑
• 落地关键挑战：识别CXL内存池化在处理器寻址差异化、SRIS时钟配置、固件与系统全栈协同等方面的核心挑战
• 技术演进方向：理解CXL正从“能连通”转向“可管理”，以及PCIe 7.0时代硅光子互连的演进趋势

全文概览

数据中心正面临内存扩展的“物理墙”困境——传统服务器架构中内存与CPU紧耦合，导致内存成为稀缺资源且利用率低下。在大模型训练、内存数据库等内存密集型场景下，这一矛盾尤为突出。

H3 Platform在FMS25上展示的可组合CXL基础架构，提供了一种全新的解题思路：通过CXL技术将内存从服务器中彻底解耦，构建独立的“内存机箱”，实现多主机共享5TB内存池。该方案可提供高达120 GB/s的聚合带宽和2亿随机读取IOPS，性能已接近本地DDR水平。

然而，内存池化不仅是硬件创新，更带来数据中心拓扑的根本性重构：从“孤岛式”架构转向“织网式”架构，NUMA层级更加复杂，单点故障域也发生转移。本文将深入解析CXL内存池化的架构逻辑与落地挑战，为存储架构师提供部署参考。

👉 划线高亮 观点批注

图片展示了由 H3 Platform 提出的 可组合 CXL 基础架构 (Composable CXL Infrastructure)。该架构通过物理解耦（Disaggregated）的方式，实现了计算、存储（内存）和加速资源的池化与灵活调度

• 资源彻底解耦与池化： 该架构通过 CXL (Compute Express Link) 技术将内存从传统的服务器限制中剥离出来，形成了独立的“内存机箱”。这意味着内存不再被固化在特定的 CPU 插槽下，而是作为一个独立的、可由多个计算节点共享和动态按需分配的资源池。
• 高密度的内存扩展能力： 图中展示的单机箱支持多达 22 个 E3.S 规格的内存模块。通过这种高密度的 CXL 内存池，数据中心可以突破单台服务器物理插槽的限制，实现 PB 级的内存容量扩展，特别适用于内存驱动型应用（如大模型训练、内存数据库等）。
• 软件定义的织网管理 (Fabric Management)： 核心架构强调了“Fabric management”的作用。通过 CXL 交换机和管理系统的协同，系统可以实现“可组合性” (Composability)，即根据不同业务负载的需求，通过软件定义的方式快速将内存资源拨付给特定的计算节点，显著提高资源的利用率并降低 TCO。

当内存扩展成为数据中心独立服务器机型，对现有数据中心拓扑会产生哪些影响？

1. 物理拓扑：从“孤岛式”转向“织网式（Fabric）”

传统中，内存通过并行总线与 CPU 紧耦合，每个服务器为孤岛。

• 拓扑重构： CXL 交换机引入 “内存织网层（Memory Fabric Layer）”，内存机箱成网络节点。
• 级联关系： 服务器经高密度线缆（如 CDFP）连 CXL 交换机，再至内存机箱，类似低延迟内存版 SAN。

2. 逻辑拓扑：NUMA 距离的复杂化

现有仅“本地”与“远端（跨插槽）”之分。

• 多层级内存： 独立内存服务器增更远层级，延迟高于本地 DDR 但低于 NVMe。
• 地址空间统一： 支持 SPA 跨机箱映射，需“织网管理器”动态管理逻辑连接。

3. 扩展性拓扑：实现非对称的“解耦扩容”

传统扩内存需买整台服务器，浪费资源。

• 独立演进： 计算与内存节点不同比例扩展，如一集群挂五内存机箱。
• 机架密度： 调整功率模型，混布高功耗计算与低功耗高密度内存节点。

4. 可靠性拓扑：单点故障域的转移

• 爆炸半径： 内存损仅一服务器宕机。
• 风险挑战： CXL 交换机或内存机箱成 SPOF，掉线致多计算节点崩溃。需冗余路径（Dual-homing）和多控制器。

图详细展示了如何通过物理组件将多个主机连接到统一的 CXL 内存池，实现最大 5TB 的内存共享

• 实现跨节点的内存资源池化： 该图片展示了一个具体的物理实现方案，通过 CXL 交换机将 20 个 E3.S 模块整合在一起，支持最多 4 台主机共同访问这个高达 5TB 的内存池。这解决了传统服务器“内存孤岛”的问题，让内存可以像存储一样被多个节点访问。
• PCIe 5.0 物理链路的高效利用： 方案采用了 PCIe 5.0 x16 通道配合 CDFP 线缆和 Retimer 技术。这说明 CXL 在当前阶段高度依赖 PCIe 的物理基础设施，通过 Retimer 解决了高速信号长距离（1 米）传输的物理挑战，确保了连接的稳定性。
• 非缓存一致性的共享模式： 这是一个非常关键的技术细节。由于标注了“无硬件缓存一致性”，该方案更倾向于作为一种高带宽、低延迟的解耦内存池，用于不需要频繁硬件锁同步的大规模数据交换或大容量内存扩展场景。用户在使用该方案时，需要在软件层面考虑数据的一致性维护。

随着物理链路从 PCIe 5.0 逐渐升级到 6.0、7.0，现有链路基础设施需要做哪些升级改造？

• 容错机制的权重提升： 5.0 以前是“保证不丢信号”，6.0 以后是“在充满误码的信号中通过 FEC 纠错还原数据”。这意味着基础设施的逻辑复杂度（延迟管理）将面临巨大挑战。
• 铜退光进的临界点： 在 PCIe 7.0 时代，传统的铜缆（Copper）在 1 米距离下的损耗几乎是不可接受的。CXL 基础设施的下一次大升级极有可能是向硅光子互连的全面迁移。
• 成本与功耗的重估： 每一次物理链路的代际升级，都会带来 Retimer 数量和 PCB 层数的增加，这直接拉高了内存机箱的硬件成本和静态功耗。

图片通过表格形式列出了实现 CXL 内存共享集群的具体硬件参数与配置建议

• 基于最新平台的实战规格： 该配置明确指向了 Intel Granite Rapids (GNR) 平台，这表明 CXL 共享内存技术正紧随最新的 CPU 架构演进。本地 DDR5 与远端 CXL 内存的结合，展示了典型的层级化存储（Tiered Memory）部署模式。
• 对称性集群设计： 通过 4 主机端口对 4 台服务器的 1:1 连接，以及对本地内存一致性的要求，体现了该集群在物理链路和逻辑资源分配上的对称性。这种对称性有助于简化软件定义存储（SDS）层面的内存地址管理。
• 大容量内存扩展： 该方案成功将 5TB 的内存资源池化并共享。通过将 20 个 256GB 的模块整合，验证了 CXL 在扩展内存容量（Capacity Expansion）和提高资源利用率方面的核心价值，为内存密集型集群提供了标准化的配置参考。

随着接入计算节点不断增加，大容量内存节点的机头PCIe 引脚数量是否会成为系统瓶颈？

• 引脚是芯片级的瓶颈，而非系统级的瓶颈： 单个控制器的引脚确实有限，但通过 CXL Switch 的层级化堆叠，系统可以突破单芯片引脚的限制，支持数十甚至上百个计算节点的接入。
• 带宽竞争（Oversubscription）取代引脚成为新瓶颈： 随着接入节点增加，虽然通过交换机解决了“连不连得上”的问题，但新的挑战变成了“带宽够不够分”。如果 8 个节点共享一个 x16 的上行带宽，就会出现收敛比过高带来的性能下降。
• 向硅光子迁移： 展望未来（PCIe 7.0 时代），行业正在尝试将电引脚转换为 光纤接口（Optical I/O）。光纤的传输密度远高于铜引脚，这可能从根本上解决“引脚挤不下”的物理矛盾。

图片通过数据图表和详细列表，展示了四台服务器连接 CXL 内存池时的随机读取 (Random Read) 性能表现

• 卓越的聚合性能与扩展性： 该 CXL 共享内存方案展现了极强的聚合能力，总带宽突破 120 GB/s，IOPS 突破 2 亿。最关键的是，性能随节点增加几乎呈线性增长，证明了 CXL Switch 在处理多主机并发访问时具有极高的效率和极低的竞争损耗。
• 异构平台的兼容性验证： 测试涵盖了 Intel 第五代至强 (EMR) 和下一代至强 (GNR) 处理器，并配置了不同的 DDR5 内存组合（如 32GBx2 对比 64GBx1）。数据证明，尽管硬件规格略有差异，但 CXL 内存池均能稳定提供 25GB/s~32GB/s 的单机带宽，体现了良好的平台兼容性。
• 高并发随机访问能力： 210M 的随机读取 IOPS 是一个非常惊人的数据，这表明基于 CXL 的解耦内存池在延迟和吞吐上已经远超传统的 NVMe 存储集群，能够真正满足内存级计算（In-Memory Computing）对超高性能的需求。

图片重点展示了在单一 CXL 根端口（Root Port）连接下的性能极限以及长达 9 天的稳定性压力测试结果

• 极高的单端口带宽利用率： 在 PCIe 5.0 x16 的物理链路下（理论带宽约为 63GB/s），该方案在 1:1 读写混合模式下跑出了 62.1 GiB/s 的成绩，几乎榨干了物理链路的理论极限。这证明了 H3 的 CXL 控制器和交换架构在协议开销控制上做得非常出色。
• 工业级的稳定性验证： 图片强调了“连续 9 天 (9 days)”的压力测试，且吞吐量曲线近乎直线。这对于企业级存储和内存技术至关重要，证明了 CXL 内存池在高负载、多核心竞争的环境下，不会因为过热或信号完整性问题导致降速或失效。
• 多核并发访问的粒度管理： 测试配置中提到的“每核心分配 2GB 内存”以及 128 核的高并发环境，模拟了真实数据中心中高密虚拟化或容器化应用的场景。这表明该 CXL 方案能够很好地支持大规模并行计算任务，并提供稳定的内存带宽保障。

表格详细列举了在构建 CXL 基础架构时，技术团队在不同层级必须面对的具体挑战

• 处理器寻址逻辑的非标准化： Intel 和 AMD 在物理内存映射（System Physical Address, SPA）上的实现细节完全不同。对于 CXL 内存池化设备商而言，这意味着必须针对不同的 CPU 平台编写差异化的初始化和映射逻辑，无法做到完全的硬件透明化。
• 物理链路调试的专业性： 引入 Retimer 带来的 SRIS 时钟配置挑战，反映了 CXL 在物理解耦（Disaggregation）过程中的物理层难度。这种硬件层面的微调是确保大规模内存池在高带宽下保持稳定性的关键。
• 固件与系统的深度协同： CXL 的落地不仅是插入一张扩展卡，它需要从 BIOS 设置到操作系统内核驱动的全栈同步升级。任何一环（如 BIOS 映射错误或内核版本过低）都会导致 CXL 内存无法被正确池化或利用。

• 软件栈成熟度是落地的先决条件： CXL 硬件的领先性需要匹配足够先进的 Linux 内核。对于企业级应用，这意味着必须使用较新的发行版（如基于 Kernel 6.3+ 的系统），才能充分发挥 CXL 在内存池化和动态分配上的优势。
• 解耦架构下的可靠性挑战： 在传统服务器中，内存错误由本地 CPU 处理。而在 CXL 池化环境下，错误可能发生在 CXL 交换机或远端内存机箱中。这要求 CXL 交换机和控制器必须具备极其严密的错误隔离与处理机制，以防止单点故障导致整个计算集群的崩溃。
• 标准化与厂商实现的协同： 图片的描述暗示了不同厂商的 CXL 交换机和控制器在错误处理行为上可能存在差异，这增加了异构计算环境下的运维难度。统一的 RAS 规范和健壮的硬件控制器能力是实现“内存级可靠性”的关键。

图片总结了 CXL 技术落地的“行动呼吁 (Call to Actions)”，涵盖了应用场景、生态协作和合作伙伴三个关键维度。

• 锁定高价值垂直应用： CXL 的首要目标是解决那些被“内存瓶颈”限制的尖端应用。通过将 AI 和大数据处理作为切入点，利用 CXL 的池化能力来降低这些昂贵应用场景的 TCO（总拥有成本）。
• 全栈式技术协同的必要性： CXL 的落地不仅仅是硬件买卖，它是一个极其复杂的生态工程。从底层的 CPU 指令集、中间的 BIOS 寻址，到上层的操作系统内核和驱动，任何一环的缺失都会导致方案无法商用。这呼吁行业内硬件与系统软件厂商必须进行深度的联合调优。
• 从“能连通”转向“可管理”： 图片特别强调了软件合作伙伴在管理、编排和故障排查方面的作用。这标志着 CXL 技术正在从“实验室原型”阶段向“企业级运维”阶段过渡。如果没有成熟的监控和分析工具，企业将难以在复杂的生产环境中大规模部署解耦后的内存资源池。

延伸思考

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

1. 当内存成为独立池化资源后，数据中心的网络架构设计需要做出哪些根本性调整？ 传统网络拓扑能否满足CXL内存池对延迟和带宽的严苛要求？
2. 随着CXL从实验室原型走向企业级部署，软件生态的成熟度是否已成为制约技术落地的关键因素？ 从BIOS到内核驱动的全栈协同难题，应如何破解？
3. 在CXL内存池化架构下，单点故障域从单台服务器转移到CXL交换机或内存机箱，这种风险转移对数据中心可靠性设计意味着什么？ 企业应如何权衡池化带来的效率提升与潜在的故障放大风险？

原文标题：Composable Infrastructure Leverages CXL for Memory Sharing and Benchmark Results

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

#FMS25 #CXL内存扩展

---【本文完】---

丰子恺-护生画集-关关雎鸠，男女有别