0
0

MemCache、MemFabric 与 Mooncake：KV 池化、逐层传输和 PD 排障

2026-10-17
推理系统与部署

整理于 2026-09-18，回顾北京时间 9 月 17 日的提问。依据可见摘录及当日重新查证的官方资料；没有登录服务器或复测补丁。

问题起点

你从 Mooncake、MemCache、YuanRong 的差别，追问 use_layerwise、PD 共置，再根据他人使用 MMC 的线索，考虑存储中转能否绕过当前 P→D 直传故障。这个推理方向值得验证，但配置标签不能代替实际调用链证据。

先区分对象管理与数据移动

Ascend MemCache 是面向 AI 推理的分布式 KVCache 存储引擎，不是传统 Web 缓存 Memcached。官方仓库提供 put/get/exist/remove 等对象接口，MetaService 管理池资源及成员，LocalService 提供客户端接口与内存资源；MemFabric 是它的异构内存传输底座。官方仓库

Mooncake 也有 Transfer Engine 与 Store 两类能力。比较时要对齐“存储管理”和“传输”层次，不能把一个 Store 与另一个网络协议直接当作替代品。YuanRong 相关后端在本次没有完成对应版本的源码核查，暂不推断其全部能力或与 MemCache 的性能高低。

MMC 到底指什么

官方仓库和部署文档确实使用 mmc-local.conf、mmc-meta.conf 及 MMC_LOCAL_CONFIG_PATH 等命名。当前排障语境的 MMC 指向这一 MemCache 配置体系；不据此编造缩写全称，也不泛化到其他同名项目。

Layerwise 的意义和条件

逐层处理允许一部分层的 KV I/O 与其他层计算形成流水。它改变的是提交时序、等待粒度和缓冲生命周期，不是自动减少所有 KV 字节数。只有计算与搬运能够重叠、且缓冲及时释放，才可能降低暴露的等待或临时内存压力。

官方 KV Pool 文档给出 backend=memcache 与 use_layerwise 的组合示例；不同角色和路径有不同使用条件。必须固定文档版本、connector 与模型状态布局，不能将任一示例参数搬到所有混合注意力模型。KV Pool 指南

“走 MemCache”不等于“已绕过 Mooncake”

应画出实际两条路径：

  • 直接交接：P 产生状态 → 传输 connector → D 接收。
  • 存储中转：P 写对象 → 存储确认可读 → D 查询与读取 → 恢复执行。

一个服务可以同时配置缓存池与 P/D connector，缓存未命中时还可能转向另一条路径。你提到 store_only 模式以及现有 Mooncake master，是当前实验方案线索；未取得代码差异、完整运行日志和输出对照，本篇不将其登记为已修复。

最小验证清单

  1. 固定 P/D 的模型、镜像、connector 配置和源代码版本，分别列出实际加载的包与配置文件。
  2. 给一条请求贯穿记录：缓存 key/块映射、写入、可读确认、读取、首 token、释放。
  3. 先短输入冷缓存，再同前缀热缓存，核对命中日志、传输字节和输出正确性。
  4. 检查取消、写入失败、读取失败与块复用，防止“拿到了对象”却恢复了错误状态。
  5. 比较端到端 TTFT/TPOT 和内存占用，不只看一次 GET/PUT 带宽。

以上是建议实验，不是本次执行结果。关联：PD 分离、DCP 与 KV Pool：计算分工、缓存分片和跨节点复用。