大模型PD分离推理跨数据中心部署指南

一、部署概述

PD分离（Prefill-Decode Disaggregation）已经是大规模大模型推理的主流部署范式。其原理并不复杂：Prefill阶段一次性处理全部输入上下文，属于计算密集型任务；Decode阶段逐token自回归生成，属于显存带宽密集型任务。两者对硬件需求截然不同，理想做法是“算力强的集群跑Prefill、显存带宽强的集群跑Decode”，也就是异构推理。

但传统方案有一个硬约束：两阶段之间必须搬运KVCache。在传统稠密注意力模型上，一个32K token的请求，KVCache传输速率需求可高达约60 Gbps，普通跨机房以太网根本扛不住。因此Prefill与Decode必须共享同一张高带宽RDMA网络，被“绑死”在同一个机房。后果是：想做异构推理，就得把不同类型的芯片塞进同一个集群，硬件配比无法灵活调整，运维极其僵化。

新一代混合注意力模型改变了游戏规则。这类模型通过线性注意力、滑动窗口等设计，使KVCache体积相比稠密注意力模型缩小了十几倍到几十倍。近期某大模型团队与高校的联合研究提出：可以把Prefill拆出去、部署到另一个机房的高算力集群上，然后用普通以太网把KVCache传回来做Decode，即“Prefill即服务（Prefill-as-a-Service）”的跨数据中心架构。公开实测数据显示，其吞吐量比同构PD部署高约54%，比朴素异构方案高约32%。

本文要帮助读者完成的就是这套架构的落地部署。部署完成后的预期效果是：本地集群专注Decode、贴近用户保障时延；远端高算力集群承载Prefill、按需扩缩容；跨中心链路只承载压缩后的KVCache流量；整体吞吐显著提升，且具备本地回退能力，任何一环故障不会导致服务整体不可用。

适合读者：推理服务负责人、GPU集群运维工程师、平台架构师、企业大模型基础设施团队。阅读前建议先理解以下背景：所用模型为混合注意力架构；推理服务以API形式对外提供；两个数据中心之间网络可达且带宽可预估。

二、部署场景

在动手之前，先确认你的业务是否属于以下场景之一：

1. 跨地域异构算力协同：多个数据中心存在不同代际、不同类型的加速卡，传统同构集群无法混部利用，通过跨中心PD分离可以让“算力型芯片”与“带宽型芯片”各司其职。
2. 算力潮汐调度：远端机房算力在夜间空闲、成本更低，可将Prefill任务外溢到远端错峰执行，白天再撤回本地。
3. 本地容量瓶颈：Decode贴近用户保障体验，Prefill外置扩吞吐，本地不必为长上下文场景大量堆算力。
4. 渐进式算力整合：新采购的高算力集群与存量的高带宽集群分居两地，通过该架构滚动整合，避免一次性迁移。

反向判断：如果你的模型仍是稠密注意力架构，或者两个机房之间可用带宽很低，跨中心传输KVCache的收益会很有限，此时应优先考虑同机房PD分离方案。

三、架构与组件

部署前先拆解组件。整体数据流为：请求 → 路由层 → 远端Prefill集群 → KVCache传输链路 → 本地Decode集群 → 响应返回。

组件	部署位置	核心职责	关键要求
网关/路由层	本地数据中心	判断请求是否外溢Prefill、选择远端站点	低时延、高可用、支持灰度与熔断
Prefill服务集群	远端高算力机房	计算并导出KVCache	高算力实例、开启分块预填充
KVCache传输服务	两端	分块、压缩、流式传输、校验、重试	带宽匹配、失败可回退
Decode服务集群	本地/近用户	导入KVCache并完成生成	高显存带宽、保留本地Prefill兜底能力
调度与元数据服务	本地	维护请求与KVCache块位置的映射	强一致性、低时延
监控与日志	全局	跨中心指标采集、日志汇聚、链路追踪	统一时钟源、统一看板

几点补充说明：

• 路由层是控制面，承担所有流量决策，必须多实例部署，避免单点。
• Prefill服务无业务状态，天然适合多站点水平扩展，站点间互为备份。
• KVCache传输链路是整个架构的枢纽，它决定跨中心方案成立与否，后文的带宽测算、分块配置都围绕它展开。
• Decode服务有会话状态（上下文缓存），需要配置缓存池与回收策略，防止显存碎片长期累积。

四、前置准备

1. 模型与软件依赖

• 混合注意力架构的模型权重，及其配套的推理配置文件；
• 支持PD分离及KVCache导出/导入能力的推理引擎（主流开源推理框架普遍已具备该能力，选型时重点验证这一项）；
• 容器运行时、镜像仓库、服务编排与配置管理组件。

2. 硬件资源规划

• Prefill集群：高算力GPU实例，建议部署在算力强、电价与成本更优的机房；
• Decode集群：大显存、高显存带宽实例，部署在靠近最终用户的位置；
• 两地实例数量按“Prefill算力总量 ÷ 单实例吞吐”与“Decode带宽总量 ÷ 单实例吞吐”分别测算，允许比例随业务动态调整——这正是该架构相对同构部署的核心灵活性。

3. 网络规划与带宽测算（重点）

稠密注意力模型的KVCache体积可按通用公式估算：

KVCache体积 ≈ 2 × 层数 × KV头数 × 头维度 × 精度字节数 × token数

混合注意力模型需按其注意力层实际配置折算，通常为稠密基线的十分之一到几十分之一。带宽需求则按：

需求速率 ≈ 单请求KVCache体积 × 并发数 ÷ 可容忍传输窗口

其中“可容忍传输窗口”是指你允许KVCache在跨中心链路上花费的时间，它直接计入首token延迟（TTFT）预算。建议跨中心链路日常利用率控制在70%以下，为突发流量和重传预留余量。

4. 云资源准备（可选）

上述组件既可以在自建机房完成，也可以使用通用云产品类目承载：例如通过百度智能云的GPU云服务器分别创建Prefill与Decode集群，用负载均衡分发请求，用云监控、日志服务构建可观测性，用对象存储统一保管模型权重；也可按同样规划逻辑在其他自有环境中实施。

5. 账号权限与安全

• 两地集群的访问凭据与跨中心通信的双向认证；
• 传输链路的加密证书、密钥托管与定期轮换策略；
• 最小化开放端口，仅放行KVCache传输服务端口与运维通道，配置白名单。

6. 数据准备

• 模型权重分发到两地并校验一致性（哈希对齐）；
• 准备多档长度的压测流量样本与输出评估集，用于上线前后逐token对拍。

部署清单：☐ 混合注意力模型权重 ☐ 两地GPU实例规格与数量 ☐ 跨中心带宽与路由策略 ☐ 证书、密钥与白名单 ☐ 监控日志接入 ☐ 回退方案与演练计划。

五、部署流程

按“规划→网络→两端服务→传输链路→路由→联调→灰度→全量”的顺序推进，每一步都有明确的验收点。

第1步：固化容量规划基线。 将准备阶段测算的带宽、实例数、传输窗口写入配置基线，作为后续所有调优的参照物。

第2步：跨中心网络打通。 建立两地通信通道（专线或加密隧道），配置路由与防火墙；随后做带宽与延迟基线压测，记录大文件传输速率和往返时延。这一步为什么重要：后续排查TTFT劣化时，必须能区分“链路本身变了”还是“服务配置变了”。

第3步：部署远端Prefill集群。 初始化运行环境、分发权重，以无状态服务形式拉起实例，开启分块预填充，配置健康检查端点并接入监控。验收点：健康检查通过、单实例压测吞吐达标。

第4步：部署本地Decode集群。 拉起Decode实例，配置KVCache接收端口与导入逻辑。注意：本地Prefill能力不要关闭，它既是联调对照组，也是生产回退路径。

第5步：配置KVCache传输链路。 统一分块大小、序列化格式与压缩选项，开启校验和与失败重试。验收点：用测试数据块做回环传输，校验通过、速率符合测算。

第6步：部署路由层。 配置触发规则（输入长度阈值、当前负载条件）、远端站点选择策略与熔断条件。

第7步：端到端联调。 构造从短到长的测试请求，验证KVCache正确导入，并将远端Prefill+本地Decode的输出与本地直跑结果逐token对拍。此步不可省略：传输错误可能表现为“语法正常但内容错乱”，抽样肉眼检查极易漏判，必须程序化对拍。

第8步：灰度切流与全量。 按1%→10%→50%→100%的比例逐步放开远端Prefill，每个档位观察TTFT、请求成功率与带宽水位，达标后再推进。全程保留一键切回本地全流程的开关。

六、关键配置说明

配置项	作用	风险点与建议
远端Prefill触发阈值	输入超过N个token才外溢	阈值过低，短请求白白承担传输时延；过高，远端算力闲置。按TTFT分界点实测确定
分块预填充大小	平衡算力利用率与首块产出速度	过大则首块就绪变慢，直接推迟传输开始时间
KVCache传输分块大小	决定流水线并行度	过大增加首块传输延迟；过小放大协议开销
压缩开关	节省跨中心带宽	压缩消耗CPU，需在带宽成本与算力开销间权衡
传输超时与重试次数	控制故障时的时延上限	超时过长拖垮TTFT，过短则链路抖动被放大为失败
回退开关	传输失败时本地重做Prefill	牺牲时延保成功率，生产环境建议默认开启
熔断阈值	远端错误率或延迟越限时全量走本地	防止远端故障传导为整体不可用

七、部署示例（通用示意）

路由决策伪代码：

function route(request):
    if request.input_tokens >= REMOTE_THRESHOLD and remote_pool.healthy():
        site = choose_site(remote_sites, by=load_and_bandwidth)
        kv_blocks = site.run_prefill(request)          # 远端计算
        ok = transfer(kv_blocks, to=decode_cluster)    # 跨中心传输
        if not ok:
            kv_blocks = decode_cluster.local_prefill(request)  # 回退兜底
        return decode_cluster.decode(request, kv_blocks)
    else:
        return decode_cluster.local_prefill_and_decode(request)

通用配置片段（字段为示意，命名以实际推理框架为准）：

routing:
  remote_prefill_threshold_tokens: 4096
  fallback_to_local_prefill: true
  circuit_breaker:
    error_rate_limit: 0.05
    latency_p99_limit_ms: 2500
kv_transfer:
  chunk_size_mb: 32
  compression: generic_stream_codec
  checksum: true
  retry: 3
  timeout_ms: 4000
prefill:
  chunked_prefill_tokens: 2048

八、上线验证

1. 功能验证：多档长度请求（如4K/16K/32K token级别）与本地直跑逐token对拍完全一致；人为中断传输链路，确认回退路径自动生效且输出仍正确。
2. 性能验证：采集TTFT的P50/P99、每token生成延迟（TPOT）、单实例吞吐与整体吞吐，并与同构部署基线对比；同时观察跨中心链路利用率是否落在设计区间。
3. 稳定性验证：执行数小时长稳压测，观察显存与句柄是否泄漏；演练远端集群重启、跨中心断链两类故障。
4. 可观测性验证：确认核心指标看板齐备、告警通知链路畅通、两地日志时间戳可对齐。

九、常见问题与排查

现象	可能原因	处理思路
TTFT整体升高	带宽不足或分块过大	提升链路带宽、调小传输分块、开启压缩
TTFT出现P99尖刺	跨中心链路抖动	缩短超时、增加一次快速重试、提前触发熔断
输出内容异常、逻辑错乱	KVCache传输损坏或导入错位	检查校验和配置、分块对齐与导入顺序，回归对拍流程
Decode实例空转等待	Prefill完成通知或元数据丢失	检查元数据服务与消息通路，为等待设置上限超时
远端算力利用率偏低	触发阈值过高或流量不足	下调阈值或收缩远端规模，重新对齐容量
显存碎片持续增长	缓存池回收策略缺失	配置缓存池整理，或周期性滚动重建实例

十一、运维与优化

• 监控告警分层分级：资源层（GPU利用率、显存、带宽）、链路层（传输速率、重传率、RTT）、服务层（TTFT、成功率、队列长度）、业务层（QPS、吞吐），按“提示—警告—严重”三级设定通知策略。
• 弹性调度：按时段与实时负载动态调整远端Prefill比例，结合两地成本错峰调度，是控制单位token成本的主要手段。
• 容灾设计：本地同构PD路径常备兜底，远端可部署多个Prefill站点互为备份；定期做断链演练，防止“回退能力”在长期不用后悄悄失效。
• 成本治理：持续评估传输压缩收益、回收闲置远端实例、对模型权重与日志设置生命周期策略。
• 安全运维：密钥定期轮换、白名单变更审计、传输加密状态巡检。
• 版本与回滚：每次升级保留上一版本镜像与配置快照；出现异常时优先通过路由切换整体回滚，而不是在流量在线时原地修复。

十二、总结

回顾整个部署：部署对象是跨数据中心的PD分离推理架构；成立前提是混合注意力模型把KVCache体积压缩了十几倍到几十倍，使普通以太网足以承载跨机房传输；成败关键是KVCache传输链路的带宽测算、分块与容错配置；上线依赖“逐token对拍+灰度切流”两道安全阀；长期稳定则依靠本地回退、监控告警与弹性调度三件套。按本文的规划、部署、验证与运维路径执行，你就能把“把Prefill变成一种跨数据中心服务”的想法，变成一套可观测、可回退、可持续优化的生产级推理部署。