跳到主要内容
新型互联与远程内存

第7章:主流系统对比与选型 —— 把前六章放在一张大表上

横向对比 RDMA / CXL 上的主流远程内存系统:DM 事务、KV-cache 池、训练 offload、CXL memory pool。给一个具体场景能 3 分钟选出该用哪个

System Comparison Decision Tree FORD Mooncake Pond ZeRO Selection

前六章拆完一个个系统,现在把它们放在同一张大表上对照——你会发现 FORD / Motor / Mooncake / Pond / ZeRO-Infinity 看似毫不相干,但都在同一组 trade-off 上选边。本章给一份决策树 + 对比矩阵,让你拿到一个新需求(比如”我要做一个低延迟的多租户向量数据库”,或”我要把训练 checkpoint 速度提 5ד)时,3 分钟选出该用哪类系统、避开什么坑。读完这章你也能批判性看任何新论文:它是真创新,还是把已有 trade-off 换了个套子。

📑 目录

1. 一张大表:把所有系统放在同一坐标

七轴坐标:{延迟级别, 容量级别, 一致性强度, 编程模型, 硬件依赖, 主要 workload, 是否成熟可生产}

系统延迟容量一致性编程模型硬件Workload生产成熟度
FaRM几 µs节点 RAM 总和序列化 OCCverbs(显式)RDMA 100GbEOLTP闭源研究
FORD几 µs同上序列化 OCCverbs(显式)RDMA 100GbE短 OLTP, TPC-C开源研究原型
Motor几 µs同上MVCC 快照verbs(显式)RDMA 100GbE混合 OLTP/OLAP开源研究原型
LOTUS几 µs同上(沿 Motor)verbs + reactiveRDMA 100GbE漂移负载 OLTP部分开源
AdaptX ⭐几 µs同上(沿 Motor)verbs + 控制面RDMA 100GbE极端 hotspot开源(CREST patch)
Mooncake几十 µs几十 TB最终一致(KV)RPC + transfer engineRDMA + GPUDirectLLM 推理Kimi 商用
DistServe几十 µs同上最终一致调度框架RDMA + GPULLM 推理学术原型
SplitWise几十 µs同上最终一致调度 + 异构硬件RDMA + 异构 GPULLM 推理Azure 内部
Pond100-300 ns几 TB(机柜内)硬件一致NUMA(透明)CXL 2.0 Type 3通用 VM 内存Azure 已部署
TPP100-300 ns同上硬件一致NUMA(透明)CXL Type 3Meta data centerMeta 已部署
ZeRO-Infinityµs ~ msNVMe TB 级强(同步)DeepSpeed APINVMe + CPU大模型训练工业广泛
HugeCTRµs(查询)TB 级强(参数)Merlin SOKGPU + DDR + PMEM推荐训练工业广泛
InfiniSwapµs ~ ms远端 RAM 池弱(swap 语义)透明(swap)RDMA通用 swap 替代学术 + 部分生产

对照组(非 disaggregation 方案):

系统类型与 disaggregation 关系
vLLM单机 PagedAttention同问题但不分离
Polar / Aurora共享存储数据库工业 disaggregation 的早期落地
NVMeoF远端块存储比 RDMA 更高层抽象,延迟差 1 个数量级

2. 决策树:从需求到系统

                              新需求
                                │
              ┌─────────────────┴─────────────────┐
              │                                   │
       事务一致性需求?                        无强一致需求
              │                                   │
       ┌──────┴──────┐                ┌───────────┴───────────┐
       Y             N                LLM 推理?               N
       │             │                    │                   │
   DM 事务系统        │                    Y                   │
       │             │                    │             ┌─────┴─────┐
   ┌───┴───┐         │              KV-cache pool?     训练?    通用扩内存?
   │       │         │                    │              │           │
  短 OLTP  混合       │              ┌─────┴─────┐        Y           │
   │       │         │              Y           N        │           │
  FORD   Motor       │         Mooncake    DistServe   ┌─┴─┐         │
                     │         (含 PD)     SplitWise   ZeRO  HugeCTR │
                     │         (含 KV池)               Inf   (推荐)  │
                     │                                                │
              ┌──────┴──────┐                                  ┌──────┴──────┐
              │             │                                  │             │
        漂移负载?        极端 hotspot?                     单机扩展?      多机 swap?
              │             │                                  │             │
              Y             Y                                  Y             Y
              │             │                                  │             │
            LOTUS        AdaptX                          CXL Type 3    InfiniSwap
                                                        (Pond / TPP)

几个高频实际问题的快速答案:

  • “我要做低延迟向量数据库” → KV-cache 池技术栈 + Mooncake 类的 transfer engine
  • “我要把训练 checkpoint 速度提 5×” → GPUDirect Storage + RDMA + sharded checkpoint
  • “我要让 8 台机器共享一个大 hash 表” → 短期:DM 事务系统(Motor),中期:CXL 3.0 sharing
  • “我要省钱训 70B 模型” → ZeRO-Infinity 或 FSDP + offload
  • “我要做云上多租户内存弹性” → CXL Type 3 + Pond-style placement(自研或买 Astera 方案)

3. 按需求维度的横向对比

3.1 延迟敏感度排序(从最严到最松)

层级延迟代表系统
Cache-coherent100-300 nsCXL Type 3(Pond, TPP)
单机网络1-3 µsRDMA(FaRM, FORD, Motor)
KV transfer几十 µs-msMooncake KV pool
Storage IO几十 µs-msNVMe(ZeRO-Infinity)
跨数据中心ms 级NVMeoF, 跨 DC RDMA

3.2 一致性需求排序

一致性强度代表备注
Hardware coherentCXL.mem最强,硬件保证
Strict serializable OCCFORD, FaRM软件 OCC,验证后 commit
Snapshot isolationMotorMVCC,放宽到 SI
Strong eventualMooncake KV”刷新会达到一致”
Weak / swap-likeInfiniSwap应用须自己处理过期

3.3 总持有成本排序(硬件 + 工程)

方案硬件成本工程成本备注
CXL Type 3中(扩展卡)低(NUMA-like)商用产品成熟
RDMA + 软件栈中(网卡 + 交换机)高(verbs 编程 + 调优)DM 系统主路线
GPUDirect + transfer engine高(NIC + GPU)高(同 RDMA)LLM 推理主路线
NVMe + DeepSpeed低(SSD)中(框架成熟)训练主路线
InfiniSwap-like中低(透明)学术为主

4. 容易混淆的”看起来像”系统辨析

”Mooncake 不是数据库”

Mooncake 看起来像分布式 KV store,但它对一致性的要求是松的——KV blocks 是不可变的(LLM 生成的 token KV-cache 不会被改),所以不需要事务/锁。如果你拿 Mooncake 去做”分布式键值数据库”会发现并发更新无法保证。

“CXL pool 不是 swap”

CXL pool 是硬件一致的(load/store 直接访问),swap 是软件透明 (page fault 触发 IO)。两者的语义、延迟、性能特征完全不同。把 CXL pool 当 swap 用会浪费它的硬件一致性,把 swap 当 CXL pool 用会被频繁 page fault 拖死。

“FORD 不是分布式数据库”

FORD 是单 region 内的 disaggregated 事务系统——所有 CN/MN 都在一个 RDMA 网络内,不考虑跨 region 复制 / 网络分区 / 时钟漂移。把它当 Spanner / Aurora 类全球数据库用会立刻翻车——它从未设计应对那些场景。

“ZeRO-Infinity offload 也是远程内存”

是的——ZeRO-Infinity 把 optimizer state 倒去 NVMe,本质就是用本地 NVMe 当”远端”。但它的延迟假设非常宽松(几十 µs-ms 都可接受),因为训练 batch 大,IO 可以 hide。别把这套思路套到推理 KV-cache 上,推理延迟预算严得多。

“InfiniSwap 不是 Mooncake”

两者都是”远端内存”,但 InfiniSwap 是通用 swap 替代(应用无感知,内存不够就换页),Mooncake 是应用级显式管理(KV blocks 是 first-class object)。InfiniSwap 通用但慢,Mooncake 专用但快——典型 generality vs performance 权衡。

5. 选型的三个隐藏成本

新人选型最容易忽视的三个隐藏成本:

5.1 运维成本

  • RDMA 调优:PFC/ECN/DCQCN 参数,任何一个配错性能腰斩。生产部署必须有专门的网络团队
  • CXL 固件升级:CXL 是新生态,固件 bug 不少,升级流程跟传统服务器不一样
  • GPUDirect 兼容:NIC 固件、GPU 驱动、kernel 版本三方匹配,一致性维护代价高

5.2 开发成本

  • 显式 vs 透明:RDMA verbs 是显式编程,要自己管 MR 注册、QP 创建、batch 攒。新人上手 3-6 个月
  • CXL NUMA-aware:虽然透明,但要发挥性能必须 numactl 或主动 page placement,否则跨 NUMA 访问反而慢
  • CXL.cache 的细节:Type 2 的 device/host bias 切换、cache 一致性失败模式,深度使用要懂硬件
  • 错误处理:RDMA 的错误代码 50+ 种,生产代码要全 cover,LOC 比想象的多

5.3 故障恢复成本

  • MN 节点 crash:DM 事务系统下 MN 数据如何恢复?Motor 用 MVCC 多副本,FORD 单版本恢复难度更大
  • KV pool 失效:Mooncake 的 KV blocks 被某节点 evict 了,正在生成的 request 怎么办?(典型答案:fallback 到 prefill 重算)
  • 跨故障域协调:PD 解耦后,prefill 节点和 decode 节点之间需要 lifecycle 协调,状态机比同机版复杂 5×

🌟 结论:选型时把硬件成本和工程成本都看上——RDMA 100GbE 网卡 ¥10K 一张看起来便宜,但配 RDMA 团队 + 维护代码 + 调优 + 故障演练,三年总持有成本比同等性能的 CXL Type 3 方案可能高 2-3×。

6. 系统组合:谁配谁

实际生产很少单用某一套——几个常见组合:

6.1 LOTUS + AdaptX(数据面 + 控制面)

LOTUS 解决”锁迁回 CN”,AdaptX 在它之上加多控制环路。这是数据面 + 控制面的经典组合,本系列的工作就在这条线上。

6.2 Mooncake + ZeRO-Infinity(推理 + 训练共集群)

大厂训推一体集群,RDMA fabric 共用:

  • 白天推理高峰:Mooncake KV pool 占主带宽
  • 夜间训练:ZeRO-Infinity offload 占主带宽
  • 共用 GPUDirect Storage 接 NVMe,fault tolerance 一套机制

6.3 CXL Type 3 + RDMA(同机柜近 + 跨机柜远)

  • 机柜内热数据:CXL Type 3 内存池 → 100ns 一致访问
  • 跨机柜冷数据:RDMA verbs → µs 级访问
  • 用一个统一的虚拟地址抽象,应用透明感知

⭐ frontier 方向:RDMA over CXL fabric——RDMA 协议 endpoint 实际上是 CXL pool 网关,跨机柜走 RDMA,机柜内透明转 CXL load/store。

6.4 Pond + TPP(同 CXL 平台两层优化)

  • Pond 解决”VM 调度时分配 CXL 内存比例”
  • TPP 解决”运行时 page placement 自动化”
  • 配合使用,VM 整体性能/成本曲线更优

🌟 结论:真正的生产系统都是”多个分离思想的组合”——很少有”纯一个方案”通吃。学完前六章后,看到一个新系统先问”它在大表的哪一格,组合了哪些已知思想”。

✅ 自我检验清单

  • 大表:能默写至少 8 个系统在主轴上的位置
  • 决策树:任意新需求能在 3 分钟内走完决策树
  • 三档延迟:能讲清”100 ns / µs / ms”三档延迟各自对应什么硬件路径
  • 容易混淆辨析:能解释为什么”Mooncake 不是数据库”
  • 隐藏成本:能讲清运维 / 开发 / 故障恢复三类隐藏成本各自的来源
  • 组合:能给出至少 2 个真实可行的系统组合方案
  • 批判性:看到一篇新论文,能在大表上指出它的位置 + 增量贡献

📚 参考资料

综述

  • A Survey on Memory Disaggregation: Trends and Future Directions(各类期刊和会议有多个综述,推荐 IEEE Computer / ACM SIGOPS Operating Systems Review 上的最新版)
  • Memory in the Age of AI Agents(2025):同期 AI memory 综述,可对照看

关键论文(已在前面章节展开)

  • 见第 4 章(DM 事务):FaRM / FORD / Motor / LOTUS / AdaptX
  • 见第 5 章(KV-cache):Mooncake / DistServe / SplitWise
  • 见第 6 章(训练):ZeRO-Infinity / DeepSpeed / Pollux / Bamboo
  • 见第 3 章(CXL):Pond / TPP

行业讨论

  • SemiAnalysis 的 disaggregation ecosystem 综述(系列博客)
  • The Next Platform 的 RDMA / CXL 系统横评
  • OCP(Open Compute Project) 的 memory disaggregation working group 报告

框架文档

  • 各系统的开源 repo / 官方文档已在对应章节列出

下一章下场实战 —— 在真实 RDMA 集群上跑通一套 disaggregated 系统。