大模型跨数据中心PD分离部署实操教程

一、这篇教程解决什么问题

本教程面向开发者、运维工程师和技术负责人，解决一个具体工程问题：如何把大模型推理中的 Prefill 与 Decode 拆分到不同集群运行，并基于压缩后的 KVCache 完成跨数据中心传输。

在单机房部署中，Prefill 与 Decode 通常绑定在同一组高带宽 RDMA 网络中。原因是传统 Dense Attention 模型产生的 KVCache 体积较大，跨机房传输成本高、时延不稳定。但随着混合注意力、线性注意力、稀疏注意力或状态压缩机制的使用，部分模型的 KVCache 可以被显著压缩，于是出现了一种新架构：Prefill 放在高算力集群，Decode 放在高带宽或近用户集群，两者之间通过普通以太网传输 KVCache。

这种架构的价值在于：

• 不同阶段可以使用不同硬件，避免单机房同构资源浪费；
• Prefill 与 Decode 可以分别扩缩容；
• 可降低对专用 RDMA 网络的依赖；
• 可支持多机房、多地域和边缘部署。

但需要注意：普通以太网并不是默认可用的。必须先测量 KVCache 吞吐，再评估跨机房链路的带宽、时延、丢包、抖动和重试能力，才能判断方案是否成立。

二、先判断适用场景与不适用边界

适合尝试的场景

1. 异构芯片推理：Prefill 使用高算力芯片，Decode 使用高内存带宽芯片。
2. 弹性伸缩：两个阶段负载特征不同，希望独立扩缩容。
3. 多机房部署：将算力密集的 Prefill 集中到特定机房，将 Decode 部署到更靠近用户的机房。
4. 成本优化：希望减少昂贵 RDMA 网络依赖，使用成本更低的通用以太网。

不建议直接采用的场景

1. 强实时在线服务：对首 Token 时延极其敏感，无法承受跨机房传输抖动。
2. 跨地域高延迟链路：RTT 较高且丢包明显，容易拖垮整体时延。
3. 未实测压缩率的模型：如果 KVCache 压缩效果未知，不能贸然拆出 Prefill。
4. 缺乏网络监控能力的团队：无法观察丢包、抖动、重试和降级情况时，不建议上线。

三、开始前检查清单

在动手部署前，建议逐项确认以下条件：

检查项	是否必须	说明
明确模型注意力类型	必须	区分 Dense Attention 与混合注意力模型
可测量 KVCache 吞吐	必须	需获得字节/秒或 Gbps 口径
有目标 QPS 与 SLA	必须	用于计算带宽和时延预算
有跨机房网络监控	必须	包括带宽、RTT、丢包、抖动
有容器或服务编排能力	必须	用于拆分 Prefill 与 Decode
有降级方案	必须	网络异常时可回退或限流
有 KVCache 生命周期管理	必须	避免缓存堆积和内存溢出
有数据合规与删除机制	必须	涉及用户输入信息，需安全处理

四、第一步：先测量 KVCache，不要先定网络

跨机房 PD 分离的第一步不是采购网络，也不是写调度器，而是测量模型在实际输入长度下的 KVCache 吞吐。

4.1 必须采集的测量项

测量项	单位	作用
模型层结构	层 / 层类型	判断哪些层产生 KVCache
隐藏维度	d_model	计算单层 KV 大小
注意力头数	heads	计算键值对维度
KV 头数	kv_heads	影响压缩效果
精度	FP16 / BF16 / FP8	决定每元素字节数
输入长度	tokens	决定单次 KVCache 总量
batch size	条	影响并发吞吐
压缩率	%	决定压缩后体积
目标 QPS	req/s	决定稳态带宽需求
输出长度	tokens	影响 Decode 阶段驻留时间

4.2 推荐计算方式

可以使用如下思路估算原始 KVCache 字节数：

每层每 token 原始 KV 字节 = 2 × kv_heads × head_dim × bytes_per_element
总原始 KV 字节 = 层数 × 每层每 token 原始 KV 字节 × 输入长度
压缩后 KV 字节 = 总原始 KV 字节 × 压缩率

其中，2 表示 K 和 V 两部分。bytes_per_element 在 FP16 下通常为 2 字节，在 BF16 下也为 2 字节，在 FP8 下通常为 1 字节。

传输带宽估算可以写成：

KV 吞吐 = 压缩后 KV 字节 × QPS
带宽 Gbps = KV 吞吐 × 8 / 1,000,000,000

4.3 可接受阈值建议

不要直接套用“60 Gbps”这类经验值，必须以实测为准。建议采用以下判断口径：

1. 峰值 KV 吞吐不能超过链路可用带宽的 70%。
2. 传输时延增量不能破坏首 Token 时延 SLA。
3. P99 传输耗时必须低于端到端预算的 10% 到 20%。
4. 如果压缩后仍接近链路上限，应优先选择专用网络或继续压缩 KVCache。

五、第二步：把 Prefill 与 Decode 拆成两个服务

完成测量后，需要将单体推理服务拆成两个独立服务：

• Prefill 服务：部署在高算力集群，负责处理完整 prompt，并生成 KVCache。
• Decode 服务：部署在高带宽或近用户集群，负责接收 KVCache，并逐 token 生成结果。

拆分的关键是接口解耦。两个服务不能依赖共享进程内存，而要通过明确的 KVCache 传输协议通信。

5.1 必须定义的服务契约

契约项	示例	说明
KVCache 标识	kv_id	全局唯一，可包含模型版本和生成时间
序列化格式	Protobuf / MessagePack	需固定字段与版本
生命周期	60 秒到 300 秒	从生成开始计时，过期即删除
所有权	Prefill 创建，调度器暂存，Decode 消费后释放	避免无主缓存堆积
校验方式	CRC32 / xxHash64	防止传输损坏
错误码	KV_NOT_FOUND / KV_TIMEOUT / KV_CORRUPT / KV_EXPIRED	便于排障和重试
幂等重试	相同 kv_id 可重复读取	避免重复生成
释放流程	Decode 完成后发送确认	由存储或调度器删除

5.2 服务边界

Prefill 服务只负责生成 KVCache，不承担长周期解码任务。Decode 服务只负责消费 KVCache，不重新计算完整 prompt。

这种拆分有两个好处：

1. 两个阶段可以根据负载特征独立扩容；
2. 硬件选型可以更灵活，例如 Prefill 用高算力，Decode 用高内存带宽。

六、第三步：判断普通以太网能不能用于跨机房传输

这是整个方案中最容易犯错的环节。不能默认跨机房链路就是普通以太网可用。必须先确认边界。

6.1 需要测量的链路指标

指标	建议单位	关注点
可用带宽	Gbps	不是标称带宽，而是压测后的可用带宽
RTT	ms	影响首 Token 时延和传输时延
丢包率	%	丢包会显著放大重试成本
抖动	ms	影响 P99 时延
MTU	bytes	影响分块效率和丢包风险
分块大小	KB / MB	建议 1 MB 到 8 MB，需实测
压缩比	%	压缩后的 KVCache 体积
重试预算	次	建议 1 到 2 次，避免重试风暴
降级触发条件	P99 / 成功率	超过阈值即降级

6.2 普通以太网适用条件

满足以下条件时，才可以考虑使用普通以太网：

1. 压缩后的 KVCache 吞吐低于链路可用带宽的 70%；
2. RTT 和抖动不会导致首 Token 时延明显恶化；
3. 丢包率足够低，或可以通过快速重传控制影响；
4. MTU 与分块大小匹配，避免分片过多；
5. 有明确的重试、超时和降级机制；
6. 有持续监控，可以观察 P50、P99、成功率与重试率。

6.3 不适合普通以太网的信号

如果出现以下情况，应谨慎使用普通以太网：

• 压缩后仍接近链路带宽上限；
• 跨机房 RTT 超过首 Token 时延预算的 20%；
• 丢包率长期高于 0.1% 且无明显改善；
• P99 传输耗时波动很大；
• 无法区分是网络问题、压缩问题还是模型问题。

七、第四步：调度层如何把 KVCache 交给 Decode

在 Prefill 与 Decode 之间需要调度层。调度层负责选择 Decode 实例、路由 KVCache、处理超时和失败。

7.1 调度器需要参考的字段

kv_id
model_version
kv_size_bytes
created_at
ttl_seconds
prefill_instance
target_decode_instance
health_status
remaining_memory
queue_depth
retry_budget
current_retry_count

7.2 调度逻辑示例

function schedule(kv_id):
    kv = storage.get_meta(kv_id)
    if kv.expired:
        return release(kv_id)
    candidates = decode_pool.list(
        healthy = true,
        remaining_memory >= kv.kv_size_bytes,
        queue_depth < threshold
    )
    if candidates is empty:
        return degrade_or_queue(kv_id)
    target = select_best(candidates)
    target.assign(kv_id, ttl = kv.ttl_seconds)
    return target

调度策略应按阶段负载分别设置，而不是使用一刀切策略。Prefill 更关注算力和排队时间，Decode 更关注内存、带宽和 KVCache 驻留时间。

八、关键配置示例

以下参数为示例，必须结合实际压测调整。

参数	示例值	说明
kv_transfer_timeout_ms	300	单次 KVCache 传输超时
kv_retry_budget	2	最大重试次数
max_inflight_kv	32	最大在途 KVCache 数
chunk_size_kb	1024	单个分块大小
serialization	Protobuf	序列化格式
checksum	xxHash64	传输完整性校验
encryption	TLS 1.3	跨机房加密传输
kv_ttl_seconds	120	KVCache 保留期限
eviction_policy	TTL + LRU	淘汰策略
rate_limit_qps	1000	单集群限流阈值
degrade_p99_ms	50	超过该值触发降级
success_rate_threshold	99.9%	低于该值触发告警

如果实际链路 RTT 较高，应适当放宽超时，但同时要增加快速失败机制，避免请求堆积。

九、上线前怎么验收

跨机房 PD 分离不能只看“能否跑通”，必须通过压测验收。

9.1 建议压测口径

负载项	示例值
输入长度	1K / 8K / 32K tokens
输出长度	64 / 256 / 512 tokens
并发	1 / 8 / 32 / 64
持续时间	10 分钟到 60 分钟
网络条件	正常 / 延迟注入 / 丢包注入 / 断链恢复

9.2 验收指标

指标	建议口径
首 Token 时延	P50、P99 需低于 SLA
每 token 时延	观察 Decode 阶段稳定性
传输耗时	P50、P99 分别统计
传输成功率	建议不低于 99.9%
重试率	建议低于 1%
降级次数	建议低于总请求的 1%
资源利用率	CPU、GPU、内存、带宽均需观察
缓存淘汰率	避免过高，否则说明 TTL 或内存不足

9.3 压测步骤

1. 先用低并发验证链路正确性；
2. 逐步提升并发，观察带宽和时延变化；
3. 注入延迟或丢包，验证重试和降级；
4. 观察 Prefill 与 Decode 的队列深度；
5. 检查 KVCache 是否及时释放；
6. 记录失败原因，确认是否集中在网络、压缩或缓存生命周期。

十、常见错误与排查方向

错误一：没有实测 KVCache 就直接拆分

表现：Prefill 已生成 KVCache，但 Decode 长时间收不到。

排查：重新测量 KVCache 大小、压缩率、QPS 和带宽需求。

错误二：把标称带宽当成可用带宽

表现：压测时带宽打满，但线上仍然超时。

排查：使用真实压测工具测量可用带宽，并预留 30% 以上裕量。

错误三：没有设置 KVCache TTL

表现：Decode 集群内存持续增长，最终 OOM。

排查：增加 TTL、LRU 淘汰和释放确认机制。

错误四：重试没有预算

表现：一次网络抖动引发大量重试，导致雪崩。

排查：设置最大重试次数、退避策略和熔断条件。

错误五：固定 Prefill 与 Decode 配比

表现：一个阶段排队，另一个阶段空闲。

排查：根据队列深度、显存、内存和 QPS 动态调整实例数量。

十一、安全与合规要求

KVCache 中可能包含用户输入信息，因此跨机房传输必须考虑安全与合规。

1. 最小化采集：只传输完成推理所必需的 KVCache，不保留无关数据。
2. 脱敏处理：对敏感字段进行脱敏或替换。
3. 加密传输：跨机房链路应启用 TLS 或其他加密方式。
4. 访问审计：记录谁访问了 KVCache、访问时间和用途。
5. 保留期限：明确 KVCache 的 TTL，到期后自动删除。
6. 删除证明：保留删除记录，便于合规检查。
7. 地域合规：如果涉及跨地域用户数据，需要确认当地法规要求。

十二、总结

大模型跨数据中心 PD 分离部署的核心不是“简单拆服务”，而是建立一套可测量、可验证、可降级的工程链路。关键结论如下：

1. 先测量 KVCache，再决定是否跨机房传输；
2. 普通以太网不是默认选项，必须通过带宽、RTT、丢包、抖动和重试预算验证；
3. Prefill 与 Decode 必须有清晰的服务契约和 KVCache 生命周期；
4. 调度层要能感知实例健康度、内存、队列深度和重试预算；
5. 上线前必须做压测、故障注入和验收指标统计；
6. 安全与合规要和架构一起设计，而不是事后补救。

当混合注意力模型对 KVCache 的压缩足够充分，并且跨机房链路指标满足要求时，跨数据中心 PD 分离可以成为一种有效的异构推理部署方式。