企业官网建设流程全解析

如何搭建高吞吐PD分离（Prefill/Decode Disaggregation）：UCM异构资源管理完全指南

【免费下载链接】unified-cache-managementUnified Cache Manager（推理记忆数据管理器），是一款以KV Cache为中心的推理加速套件，其融合了多类型缓存加速算法工具，分级管理并持久化推理过程中产生的KV Cache记忆数据，扩大推理上下文窗口，以实现高吞吐、低时延的推理体验，降低每Token推理成本。项目地址: https://gitcode.com/ModelEngine/unified-cache-management

🚀Unified Cache Manager（UCM，统一缓存管理器）是一款以 KV Cache 为中心的开源推理加速套件，它对大模型推理过程中产生的 KV Cache 记忆数据进行分级管理与持久化，帮助你在 Prefill/Decode 分离（PD Disaggregation）架构下实现高吞吐、低时延、低成本的推理服务，尤其适合 GPU/NPU 混合的异构集群场景。

对于新手而言，PD 分离听起来很复杂，但其实核心逻辑可以一句话概括：Prefill 节点负责"读入"，Decode 节点负责"输出"，KV Cache 通过共享存储传递，两者彻底解耦。本文将带你从原理到实操，一步步搭建起自己的 PD 分离集群。

一、为什么需要 PD 分离？

大模型推理分两个阶段：

• Prefill（预填充）：一次性处理整段输入，计算密集型，吃 GPU 算力；
• Decode（解码）：逐 token 生成输出，访存密集型，吃显存带宽。

两个阶段的资源特性截然不同。混在同一个实例里，长请求的 Prefill 会阻塞短请求的 Decode，互相拖累。把两者拆分到不同节点独立部署（即Prefill/Decode Disaggregation），可以各自按最优策略调参，显著提升吞吐并降低 TTFT（首 Token 时延）。

UCM 的 PD 分离设计围绕三大核心组件展开：独立的 Prefill/Decode 部署策略、KV Cache 存储与传输策略、调度策略。

二、三种 KV Cache 传输模式，UCM 选择了哪种？

Prefill 与 Decode 节点之间传递 KV Cache，业界大致有三种模式：

UCM 选择了第三种模式——让统一存储池（基于 Prefix Cache 逻辑）成为 KV Cache 传输的中继。这带来四大实际收益：

1. 彻底解耦：Prefill 与 Decode 互不依赖，调度逻辑和异常处理大幅简化；
2. 零额外开发：完整复用 Prefix Cache 代码路径，无需为 PD 分离单独编写逻辑；
3. 实例无状态化：统一存储充当推理实例状态，单个实例故障可无缝迁移，系统鲁棒性显著增强；
4. 异构推理近乎零成本：P 节点和 D 节点可以使用不同 GPU/NPU 型号、不同精度、不同启动方式，KV 与计算分离后，异构环境天然支持——这正是"异构资源管理"的关键价值所在。

三、UCM 整体架构速览

UCM 采用分层设计，自顶向下依次是：Proxy（PD 混合/分离调度器）、Integration（对接 vLLM、SGLang、MindIE 等推理引擎的插件层）、Prefill/Decode 加速库、Sandbox（研发中的实验性技术）、Store（存储适配层）与 Centralized Storage（集中式存储）。

其中 Store 层是 PD 分离的数据底座，PipelineStore 将Cache Store（设备↔主机内存）与Posix Store（主机↔本地盘/SSD/NFS 持久存储）串成数据管道，KV Cache 即可在任意节点之间高效流转。

四、动手实践：1P1D 集中式 PD 分离最快上手 🏁

下面以单节点、1 个 Prefill 实例 + 1 个 Decode 实例（1P1D）为例，展示 UCM 集中式 PD 分离的最小完整流程。

第 1 步：准备 UCM 配置文件

创建一个 UCM 配置文件（可参考仓库示例 examples/ucm_config_example.yaml），核心内容：

ucm_connectors: - ucm_connector_name: "UcmPipelineStore" ucm_connector_config: store_pipeline: "Cache|Posix" storage_backends: "/mnt/test1" # 所有节点可访问的共享存储目录 cache_buffer_capacity_gb: 32 enable_event_sync: true use_layerwise: false

⚠️要点：当 Prefill 与 Decode 部署在不同节点时，所有节点必须挂载同一个共享文件系统（如 NFS），storage_backends指向该共享路径。

第 2 步：分别启动 Prefill 与 Decode 服务

两端启动命令几乎一致，关键差异在端口与可见设备（Ascend 平台用ASCEND_RT_VISIBLE_DEVICES代替CUDA_VISIBLE_DEVICES）：

vllm serve /home/models/Qwen2.5-7B-Instruct \ --max-model-len 20000 --tensor-parallel-size 1 \ --gpu_memory_utilization 0.87 --block-size 128 --port 7800 \ --kv-transfer-config '{ "kv_connector": "UCMConnector", "kv_role": "kv_both", "kv_connector_module_path": "ucm.integration.vllm.ucm_connector", "kv_connector_extra_config": {"UCM_CONFIG_FILE": "/path/to/ucm_config_example.yaml"} }'

UCM 与 vLLM 的对接实现在 ucm/integration/vllm/ucm_connector.py，它通过 vLLM 标准的 KV Connector 接口注入，无需修改推理引擎。

第 3 步：启动代理服务器做请求分发

UCM 自带一个轻量代理服务器 ucm/pd/toy_proxy_server.py，负责把请求按轮询策略分发给 Prefill 和 Decode 实例：

python3 toy_proxy_server.py --pd-disaggregation --host localhost --port 7802 \ --prefiller-host <prefill-node-ip> --prefiller-port 7800 \ --decoder-host <decode-node-ip> --decoder-port 7801

第 4 步：验证与压测

一条curl即可完成基本测试；压测可直接使用 vLLM 自带 benchmark 工具：

vllm bench serve --dataset-name random --random-input-len 4096 \ --random-output-len 100 --num-prompts 10 --host localhost \ --port 7802 --endpoint /v1/completions

XpYd 扩展：多 Prefill + 多 Decode 实例时，只需为每个实例分配不同端口，代理服务器通过--prefiller-hosts/--decoder-hosts传入完整地址列表即可，完整步骤见 docs/source/user-guide/pd-disaggregation/centralized_pd.md。

五、异构资源管理：Ascend 做 Prefill、CUDA 做 Decode 🎯

这是 UCM PD 分离最亮眼的场景——P 节点与 D 节点使用不同硬件平台。例如 Prefill 使用 Ascend NPU（计算性价比高），Decode 使用 CUDA GPU（生态成熟），前提只有两条：

• 所有 vLLM 实例必须使用相同的 dtype（如统一bfloat16）；
• 共享存储对所有节点可见。

启动时 Prefill 端使用export ASCEND_RT_VISIBLE_DEVICES=0，Decode 端使用export CUDA_VISIBLE_DEVICES=0，其余参数（含 UCM 连接器配置）完全一致。KV Cache 在统一存储池中完成跨平台搬运，异构差异被存储层完全吸收，无需任何跨平台传输代码。

这种"新旧 GPU 混布、异构算力混用"的集群形态正在成为主流，因为直连传输模式在异构环境下越来越复杂，而 UCM 的解耦架构天然适配。

六、大规模分布式 PD 分离：P2P 传输 + 大规模专家并行 🏗️

当集群扩展到 MoE 大模型（如 Qwen3-235B、GLM-5.1）时，推荐分布式 PD 分离架构：UCM 在 Prefill 节点实现 Prefix Cache 复用，Mooncake负责 Prefill 到 Decode 的 P2P KV Cache 高速传输，两者通过 vLLM 的 MultiConnector 双通道协作。

以 8 节点（192.168.10.1~8）部署 GLM-5.1 为例：

• Prefill 实例：4 节点，DP4TP8 并行策略，启用专家并行（Expert Parallelism）；
• Decode 实例：4 节点，DP8TP4 并行策略；
• 传输通道：P 节点配置MultiConnector（Mooncake 做 producer + UCMConnector 做前缀缓存），D 节点配置MooncakeConnectorV1做 consumer；
• 负载均衡：由独立代理服务将请求分发到各 DP 实例。

Prefill 节点的 KV 传输配置示意（Decode 端只需把角色换成kv_consumer）：

{ "kv_connector": "MultiConnector", "kv_role": "kv_producer", "kv_connector_extra_config": { "connectors": [ { "kv_connector": "MooncakeConnectorV1", "kv_role": "kv_producer", "kv_connector_extra_config": { "prefill": {"dp_size": 4, "tp_size": 8}, "decode": {"dp_size": 8, "tp_size": 4} } }, { "kv_connector": "UCMConnector", "kv_role": "kv_both", "kv_connector_module_path": "ucm.integration.vllm.ucm_connector", "kv_connector_extra_config": {"UCM_CONFIG_FILE": "/path/to/ucm_config_example.yaml"} } ] } }

注意decode段的并行参数必须写成Decode 端的 dp/tp（DP8TP4），这是 P/D 并行策略不一致时最易踩的坑。完整部署脚本见 docs/source/user-guide/pd-disaggregation/large_scale_ep.md 与 docs/source/user-guide/pd-disaggregation/distributed_pd.md。

七、性能实测：UCM 前缀缓存带来多少加速？📊

在 8 节点 A3 集群（128 并发、32K 输入 + 1K 输出、KV Cache 预热命中率 0.8）下，三种场景的对比数据：

128K 长上下文下 TTFT 下降约61%。这里有个关键细节：数据并行下，测试请求未必被路由回预热时的 DP 进程，HBM 前缀缓存的实际命中率远低于预期的 0.8；而 UCM 把所有 KV Cache 存入共享外部存储，任何 DP 进程处理请求都能命中缓存，保证真实命中率 = 预热比例。

另一组 GLM-5.1 4 节点 A3 集群（2 Prefill + 2 Decode）实测中，64K 上下文 + 30 并发场景下，启用 UCM 前缀缓存后TTFT 降低 82.1%、吞吐提升 141%，详见 docs/source/user-guide/best-practices/GLM-5.1-A3_4Node_PD_Disaggregation.md。

八、PD 分离带来的调度灵活性

解耦之后，调度器获得了前所未有的优化空间：

• 榨干算力：利用 Chunked Prefill 占用 Decode 实例的剩余算力；P/D 角色可自动互换；任务可中途迁移，避免异常导致重算；
• 改善体验：防止长请求拖慢短请求，显著降低平均 TTFT 与 TPOT；同一用户的请求经简单哈希映射到同一实例，提高本地缓存命中率；
• 强化容错：内置重试与检查点恢复机制，调度器自身弱状态、多实例冗余，消除单点故障。

九、新手避坑清单 📝

1. 共享存储必须全员可见：跨节点部署时，所有节点挂载同一 NFS 路径，且storage_backends指向它；
2. dtype 必须全局一致：异构平台上尤其注意，P/D 实例的--dtype要相同；
3. Ascend 平台用对设备变量：是ASCEND_RT_VISIBLE_DEVICES，不是CUDA_VISIBLE_DEVICES；
4. 并行参数写对端：分布式模式下，Prefill 节点配置里decode段的 dp/tp 要填Decode 端的并行策略；
5. 长上下文控制并发：Decode 实例 HBM 的 KV Cache 容量决定了并发上限，超出会触发抢占重算，反而拖慢吞吐。

十、延伸学习路径

一句话总结：UCM 用"统一存储池中继 KV Cache"这一极简设计，把 PD 分离中最复杂的跨节点、跨硬件传输问题转化为一次普通的缓存读写——逻辑简单、彻底解耦、天然支持异构，让新手也能快速搭建起生产级的大规模推理集群。

【免费下载链接】unified-cache-managementUnified Cache Manager（推理记忆数据管理器），是一款以KV Cache为中心的推理加速套件，其融合了多类型缓存加速算法工具，分级管理并持久化推理过程中产生的KV Cache记忆数据，扩大推理上下文窗口，以实现高吞吐、低时延的推理体验，降低每Token推理成本。项目地址: https://gitcode.com/ModelEngine/unified-cache-management