讨论是否纳入下一阶段roadmap

/label add triaged

----提示----
0、自己提的issue，打如下标签：/label add triaged
1、v1.0.0的issue，打 high-priority
2、自己正在看的问题，打 triage-review 标签；
3、系统自动打的是 triaged 标签
4、测试自己提的，信息要非常明确，仓库要准确
5、开发提的一些建设性问题，打独立统计的标签：feature，rfc，performance
6、已定位待合入或者待测试的，打 ok-to-test 标签
7、问题方案不确定需要讨论的，打 help-wanted

Issue 标签使用规范

请根据以下规则为 Issue 打标签，保持分类准确：

⚠️ 测试or用户提 Issue 前请检查：问题描述是否清晰、仓库是否正确，避免信息不全影响处理效率。

1、MoonCakeStore的主从架构中，主节点（Master Service）与从节点（Store Service）之间的控制面通信采用自研的轻量级RPC协议，具体基于阿里自研的coro_rpc框架实现。该协议专为元数据管理设计，仅处理控制流（如位置查询、节点注册），不参与实际KVCache数据传输。
coro_rpc 原生支持RDMA通信，其底层传输协议可根据场景动态选择TCP或RDMA（InfiniBand/RoCE）。MoonCakeStore主从通信默认用TCP：因控制面流量小、强一致需求高，TCP的简单可靠更符合实际运维需求。
数据面与控制面严格分离：
控制面：主从间仅传输元数据指针，默认走TCP（可选RDMA）。
数据面：KVCache实际传输强制使用RDMA，完全绕过主节点。

2、NVIDIA Dynamo 的 KV Cache 内存池管理核心在于 KV Block Manager (KVBM)，其设计目标是打破 GPU 显存限制，通过分层存储和智能调度实现 KV Cache 的高效复用。该系统并非传统主从架构，而是采用分布式协同模式，各组件通过事件驱动与低延迟通信库（NIXL）实现去中心化协作
KVBM 明确采用分布式架构，而非主从模式，具体表现为：

1.无中心化控制节点
去中心化决策：每个 Worker 节点独立管理本地 KV Cache 状态，并通过事件广播全局共享元数据（如 KV Block 位置、热度），无需中央调度器强制分配资源。

2.元数据全局共享但无主节点
分布式键值存储：KV Cache 的元数据（如 Block ID、位置、热度）通过 etcd 或 NATS JetStream 构建最终一致性视图，所有节点平等读写，无单一权威节点。
本地缓存优化：节点会缓存高频访问的元数据，减少跨网络查询，但不依赖主节点同步。

3、LMCache有以下类型的跨实例 KV Cache 共享的示例：

1.通过集中式缓存服务器的 KV Cache 共享：centralized_sharing
LMCache 的集中式共享有两种部署模式，它们使用不同的协议栈：

模式一：v1 内嵌模式（RemoteBackend + 远程存储服务器）

所有 vLLM 实例连接到一个 中心化的远程存储服务器 ，通过 remote_url 配置指定。
支持内置实现(lm:// TCP Server)、 Redis、 InfiniStore、 Mooncake或 S3/FS/...等等。底层协议完全由 remote_url 的 scheme 决定——用 lm:// 就是 TCP，用 infinistore:// 就是 RDMA，用 redis:// 就是 Redis 协议。

模式二：MP 多进程模式（LMCache Server + ZMQ）

将 LMCache 运行为独立服务进程，多个 vLLM 实例通过 ZMQ 连接。

2.通过点对点缓存传输共享 KV 缓存: p2p_sharing
P2P（点对点）KV 缓存共享允许多个服务引擎实例之间直接传输缓存，而无需集中式缓存服务器。LMCache 支持通过基于控制器的架构进行 P2P 共享，使用 NIXL（NVIDIA 推理传输库(支持 RDMA/TCP) ）优化实例之间的数据传输。 NIXL 根据硬件环境自动选择 RDMA 或 TCP。在有 RDMA 网卡时，数据传输走 RDMA 零拷贝路径，控制面走 ZMQ TCP，实现了控制面和数据面的分离。