深潜｜异构PD分离原理与探索

大语言模型的在线服务要在有限时延内持续处理并发请求。随着输入长度、输出长度和并发量不断增加，推理系统会同时受到吞吐、交互时延和缓存命中等多方面挑战。

尽管算法也在持续演进，对Attention的KV Cache做了各种优化，如MLA 通过压缩降低KV Cache的存储压力；DSA通过稀疏选择减少长序列Attention的实际访问和计算量[5-6]。然而，在保证输出质量的前提下，长上下文状态管理和持续生成仍面临结构性约束。

模型持续迭代发展，对国产算力形成了严峻的考验。一个无法绕过的核心问题是：如何让国产算力充分发挥其优势，让具有不同特点的计算卡分别承担更合适的阶段，并在性能、状态一致性和系统成本之间取得平衡。PD分离的相关研究已经从阶段分离和KV Cache中心化等方向给出了初步答案[1-3]，但考虑到异构，仍有许多工程边界需要理清。

根据Roofline模型[4]，程序的性能主要受限于两个因素：

Prefill对输入prompt执行一次性前向计算，并建立后续生成所需的KV Cache。输入token可以组成较大的batch，需要计算完整batch的自注意力，再加上线性层可在batch内复用已加载的权重数据，因此计算单元更容易保持较高利用率。

Decode在Prefill完成后以自回归方式逐token生成输出。每一步只为每条活跃序列推进一个token，却要反复读取模型权重和历史KV；在Decode batch_size较小或序列较长时，单步计算量有限，显存带宽和KV容量往往先成为限制。因此，P和D使用同一模型，并不意味着它们适合相同的计算卡或相同的调度策略。

从调度层面分析，Prefill和Decode共享GPU，会不可避免地影响彼此。当一个新的Request 进入，推理系统只能：

不论是哪一种，都会影响到TPOT（Time Per Output Token）。

PD分离不会减少Decode本身的计算量和KV访问量，但可以避免长Prefill干扰逐token生成。我们一般将PD交接的时延计入TTFT（Time To First Token），P端交付KVCache和最后一个位置的输出分数，由D端生成首Token。

受限于工艺和设计，前期部分国产算力卡为HBM2/HBM2e工艺，HBM带宽低，对于Decode这种带宽敏感场景，难以达到业务SLA。而在Prefill场景，却可以最大限度发挥自身的算力优势。

因此，异构PD分离是综合了P和D的特点，结合了国产算力的现状，给出的一个合适的解决方案。

P交给D的不是抽象的“缓存”，而是一组具有明确模型语义的状态。它可能包括各层KV、MLA压缩状态、DSA检索所需的索引键、不同KV group的数据以及TP/PP分片。D开始 Decode 前，这些状态必须满足三个条件：覆盖的token 构成连续前缀，必要的层、group和并行分片全部齐备，数据格式能够被D正确解析。

P与D之间存在三类数据路径：

Mooncake是KV Cache管理的代表框架。控制面记录内容键、副本位置和完成状态，数据面通过远程直接内存访问（RDMA）等高带宽通道搬运KV，元数据服务不转发大块数据[3,7]。系统可以在 P 完成后再选择目标D，同一前缀也可以被多个兼容实例复用。

直连和共享Store经过的链路不同，需要分别计算网络时间。直连只有一个P到D的搬运阶段，共享Store至少包含“P 写入 Store”和“Store 读取到D”两个串行搬运阶段，若D读取的正是 P 本轮发布的全部状态，P 完成必要对象的写入并发布提交标记后，D 才开始读取，“KV_bytes_put” 和 “KV_bytes_get”两个字节数通常相同，Store 路径还要加入提交、查询和对象可见性时间；若 Store 已经持有历史块、P 只补写新增块，则 “KV_bytes_put”可以小于 “KV_bytes_get”。若系统支持block级提交，写入与读取可以在不同block之间形成流水线，此时应按流水线的关键路径计算，不能继续把两个阶段的总时间直接相加。

结合直连与共享，D可以先从Store路径异步获取已有块，等待P计算完成后，通过直连方式获取新增块，P也同步去做Store以便下一次命中。

两台不同服务器上的GPU，通过RDMA网络直接“对话”。GPU Direct RDMA 减少主机内存拷贝和CPU参与，直连路径通常是一跳P→D。为如今集群部署推理的庞大的数据交换铺就了一条畅通无阻的“高速公路”。

单次传输负载越高，越容易打满带宽上限，因此需要针对KV Cache实际大小，来决定传输策略，异步分块还是合并整体都有可能。

以某生产系统，服务1000用户，每个用户保留20个Sessions，每个Session的平均有效上下文长度为32K token估算，完整保留所有Sessions所需的存储为：

这个量级的KV Cache，不可能全部都存放在HBM中，因此我们需要多级存储，使用不同介质承担不同热度的数据。Mooncake的SSD Offload 设计和SGLang HiCache均提供了公开的分层缓存实践[7-9]。其中，HBM指设备侧高带宽内存，DRAM指容量更易扩展的动态随机存取内存：

KV Cache的冷热判断不能仅依赖最近访问时间。不同数据的复用规律各异，例如固定系统提示词、热门知识库前缀与一次性长文档；同时，对象大小也会影响单位容量的收益。因此，存储需分层定位：HBM优先保留活跃的Decode状态；DRAM保留可跨实例复用且重算代价高的前缀；SSD则存放更冷但仍有潜在价值的对象。此外，缓存的提升与淘汰需设置高低水位线、最短驻留时间及并发迁移上限，以防止同一批KV在DRAM与SSD之间反复抖动。

写入策略同样需要分层。首先，必须为“当前请求交接”所需的KV预留空间，确保在存储拥塞时也不会丢弃这些状态。其次，对于仅为“未来复用”而写入的KV，则可采取更灵活的策略，如立即写入、仅写入热点数据，或在淘汰时回写。通过为前台交接与机会性缓存设置不同的优先级，可避免缓存写入操作反向拖慢TTFT。

Prefix Cache 通常将token序列切分为多个block，并采用链式哈希进行计算。由于每个block的哈希值不仅取决于本块内容，还依赖前序block 的哈希值，因此系统要求前缀必须从开头连续命中。如果中间出现缺失，即使后续block存在于缓存中，也无法跳过缺口直接复用[10]。

在构建内容哈希键时，除了token本身，还必须包含租户、模型版本和缓存格式等上下文信息。相同的 token 序列并不代表不同模型、RoPE 配置或量化方式下生成的 KV Cache 可以互换。此外，系统需采用强摘要算法或引入二次校验机制来防范哈希碰撞，不能将“内容寻址”简单等同于“格式兼容”。

当不同KV group的物理block大小不一致时，调度器只能复用各group共同命中的连续前缀[11]。在一种实现方案中，系统利用最大公约数（GCD）确定哈希边界，利用最小公倍数（LCM）确定调度粒度。假设group A 的物理块包含16个token，group B 包含24个token，则GCD 为8，LCM 为48。

其中，GCD是统一的寻址粒度，用于解决不同物理块如何建立统一哈希边界的问题；LCM 则是所有group都能覆盖完整物理块时的最小共同复用粒度。例如，若查询得到72个候选token，调度器会先向下对齐到48，核对这48个token 在所有group中的哈希与完整性。全部通过后，这48个token才能复用，剩余24个需重算。最终的命中长度，是所有层、group和并行分片共同拥有的最长连续前缀，而非单一对象返回的最大值。

即使在单一group中，也存在块尾部的重算问题。当输入长度为N、块大小为B时，可复用的token 数为floor(N / B) * B，而尾部不足一个块的部分（N mod B）必须重算。

块大小的设置是一个需要权衡的参数：块越小，尾部重算和内部碎片越少，但会增加哈希计算、元数据存储和传输请求的开销；块越大，控制面负担越轻，但会增加尾部重算量和单次SSD读取量。因此，块大小不仅是检索参数，也是存储和传输参数，不能仅针对单一缓存层进行优化。

异构方案的经济性可以先用单机月收入做一阶估算，再与设备、网络、存储和运维成本比较。当前公式只用于说明 Prefix Cache 对P侧收入。

定义以下变量：

假设，TGS = 500，N = 8，H = 0.8，U = 0.5，设置一组假设计价口径（不代表公开市场价格），未命中Prefix Cache单价为￥8/Mtokens，命中Prefix Cache单价为￥2/Mtokens代入得：

由公式可以发现，不同方向的优化，均可以对收益产生影响：

做好模型极致性能优化和系统Cache管理，对于提升收益，均是必不可少的选项。

异构PD分离，是结合了大模型推理的特点，和部分国产算力现状，找到的一种可以兼顾服务性能和Token经济的解决方案。不过方案在部署上仍然存在诸多限制，这里主要讨论两种情况：

1、跨机房、跨数据中心部署： 在技术上可行，但实时的P到D交接应尽量限制在同一个低时延网络域内。广域网络更适合异步复制、冷KV灾备，以及能够容忍较高TTFT的会话迁移。若要形成跨域推理资源池，还必须具备带宽预留、流量治理、租约管理，以及故障场景下的一致性降级策略。

2、分布式KV存储也可以独立于智算集群建设，通过标准化接口服务多个P/D集群。要实现这种解耦，需要将KV存储建设为标准化数据服务，提供内容寻址、租户隔离、模型与缓存格式标识、提交、租约、淘汰、复制和故障恢复等能力。存储资源可以独立扩容和运维，但读取带宽、网络位置和服务质量仍需与计算集群协同规划。由此看，计算、网络和存储可以在资源管理上解耦，却不能在网络拓扑和SLO设计上彼此独立。

如果解决了上述问题，智算P集群、智算D集群和通算存储集群等，能做到彼此解耦，但可跨地域纳管，或许才是真正做到实现“算力一张网”。

数据说明：正文中的公式、计价参数和容量参数用于说明推理阶段、交接路径、收入估算和容量规划之间的理论关系，不代表任何芯片、网络、市场价格或生产系统的实测结果。

参考文献

[1] Zhong, Y. et al. *DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving*. OSDI 2024. https://arxiv.org/abs/2401.09670

[2] Patel, P. et al. *Splitwise: Efficient Generative LLM Inference Using Phase Splitting*. ISCA 2024. https://arxiv.org/abs/2311.18677

[3] Qin, R. et al. *Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving*. FAST 2025. https://arxiv.org/abs/2407.00079

[4] Williams, S. et al. *Roofline: An Insightful Visual Performance Model for Multicore Architectures*. Communications of the ACM, 2009. https://doi.org/10.1145/1498765.1498785

[5] DeepSeek-AI. *DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model*. 2024. https://arxiv.org/abs/2405.04434

[6] DeepSeek-AI et al. *DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models*. 2025. https://arxiv.org/abs/2512.02556

[7] Mooncake Project. *Mooncake Store Design*. https://github.com/kvcache-ai/Mooncake/blob/b4ccdc3082d2def865ecf1b5e68bc511025da40e/docs/source/design/mooncake-store.md

[8] Mooncake Project. *SSD Offload Design*. https://github.com/kvcache-ai/Mooncake/blob/b4ccdc3082d2def865ecf1b5e68bc511025da40e/docs/source/design/ssd-offload.md

[9] SGLang Project. *HiCache: Hierarchical KV Cache Management*. https://docs.sglang.ai/advanced_features/hicache.html

[10] vLLM Project. *Automatic Prefix Caching*. https://docs.vllm.ai/en/latest/design/prefix_caching/

[11] vLLM Project. *Hybrid KV Cache Manager*. https://docs.vllm.ai/en/latest/design/hybrid_kv_cache_manager/