简介：本文围绕大模型推理服务在跨机房场景下的部署优化展开，重点介绍PD分离架构的部署逻辑、KVCache传输瓶颈、Prefill-as-a-Service部署形态的架构变化，以及从资源规划、环境准备、上线验证到运维优化的完整部署思路。适合负责大规模模型推理上线的架构师、运维工程师及技术决策者阅读。
在深度学习推理服务走向大规模生产环境的过程中，一个非常现实的部署问题是：当单个机房的计算资源、网络拓扑或硬件选型无法同时满足计算密集型与访存密集型两类负载时，应当如何重新规划推理链路的部署形态。
本文讨论的部署对象是大语言模型推理服务中的 Prefill 与 Decode 两个阶段。部署目标是将这两个阶段从传统的同机房、同集群绑定形态，演进为可按硬件特性、网络条件、成本结构进行拆分部署的架构。具体来说，就是探讨一种将 Prefill 阶段作为独立计算服务部署在高算力资源池、并通过一定网络链路传递中间状态给 Decode 阶段的方案。
该部署任务适合以下读者：
阅读本文前，建议先理解大模型推理的两个基础阶段：Prefill 负责对输入序列进行并行计算，属于典型计算密集型负载；Decode 负责逐 token 生成输出，受限于显存带宽，属于访存密集型负载。两者在硬件需求上存在明显差异，这构成了拆分部署的基本动机。
PD 分离部署并不是新概念。在单集群内部，把 Prefill 与 Decode 部署到不同硬件节点上，已经成为大规模推理平台常见的做法。原因很直接：Prefill 对算力敏感，Decode 对显存带宽敏感，如果强行用同一种硬件同时承载两种负载，会造成资源利用率和吞吐能力的下降。
部署场景可以归纳为以下几类：
同机房同构集群场景：所有节点硬件类型一致，Prefill 与 Decode 逻辑上分离，但物理上仍部署在同一集群内。这是最基础的 PD 分离部署形态，部署难度较低。
同机房异构集群场景：在同一个机房内引入不同型号的计算硬件，一部分节点用于 Prefill，另一部分用于 Decode。这类部署需要解决异构硬件的任务调度、资源管理与网络互联问题。
跨机房 PD 分离场景：将 Prefill 部署在计算资源更充沛的机房或资源池，将 Decode 部署在更靠近用户或更注重带宽成本的机房。这是本文重点讨论的部署形态。
Prefill 云化服务场景：将 Prefill 完全抽象为一种计算服务，由独立资源池承载，多个 Decode 集群可以通过一定网络链路按需调用。该形态在理论上允许 Prefill 资源池独立扩展、独立计费、独立调度。
从部署实践来看，前两种场景已经有较为成熟的落地经验。后两种场景长期受限于一个核心问题：KVCache 的传输体积过大。
理解这类部署任务，需要先明确链路中的关键组件。一个典型的 PD 分离推理服务部署架构包含以下模块：
在启动跨机房 PD 分离部署之前，需要完成以下准备工作。
首先需要评估单请求的 KVCache 体积。该数值与模型层数、注意力头数、头维度、序列长度、缓存精度密切相关。一个关键判断是：当前目标模型在最长输入序列下，单请求 KVCache 的峰值体积是否处于跨机房网络可承载范围内。
准备清单建议包含：
跨机房部署需要明确以下网络策略：
即使是拆分部署，Prefill 与 Decode 两侧的模型版本、分词器版本、缓存精度配置也必须严格一致，否则会产生缓存格式不匹配的问题。建议在部署前建立版本校验清单，将模型权重版本、分词器版本、缓存精度、序列长度上限等关键配置纳入校验流程。
下面以“将 Prefill 作为独立服务部署在高算力资源池，Decode 部署在主服务集群，两者通过缓存传输通道衔接”为例，描述部署流程。
在部署前，先确认目标模型是否具备缓存压缩能力。混合注意力类模型由于在注意力计算中引入了稀疏或压缩机制，单请求 KVCache 体积相比传统 Dense Attention 模型可下降一个数量级或更多。缓存体积下降是跨机房传输可行性的核心前提。
部署时，应在 Prefill 侧与 Decode 侧使用相同的缓存压缩配置，并在两侧缓存元数据中统一记录缓存形状、精度与版本标识。
在高算力资源池中，按以下步骤搭建 Prefill 服务：
Prefill 服务池的设计要点是：它不直接面向最终用户，而是作为一个内部计算服务存在。请求进入后，只完成输入序列的编码与 KVCache 生成，不执行逐步解码。
缓存传输中间层承担两个职责：一是接收 Prefill 节点产生的 KVCache 写入；二是向 Decode 节点提供缓存拉取能力。部署时可以选择两种模式：
在跨机房场景中，中转模式更有利于解耦 Prefill 与 Decode 的部署位置，但会增加一次存储写入开销。具体选型需结合实际链路带宽与缓存体积权衡。
Decode 服务部署在主业务集群中，其配置要点包括：
请求调度路由需要实现以下流程：
先以少量内部测试请求验证完整链路：
确认联通后，再逐步放量。
部署过程中需要重点关注以下配置项。
缓存精度直接影响传输体积和生成质量。如果采用缓存压缩或量化，需要确保 Prefill 写入侧和 Decode 读取侧使用相同的压缩算法和精度配置。精度不一致是导致 Decode 生成质量下降或直接报错的常见原因。
最大序列长度需要在 Prefill 侧与 Decode 侧统一配置。如果 Decode 侧配置的最大序列长度小于请求实际长度，会导致缓存截断；如果 Prefill 侧配置过小，则无法完整编码长输入。建议两侧从同一配置中心读取该参数。
跨机房传输链路的时延通常高于同机房内部网络，因此传输超时阈值需要重新评估。超时配置过短会导致缓存传输失败被频繁重试；超时配置过长则可能掩盖真实网络故障。
建议对缓存传输失败设置有限次数重试，并设置退避时间。重试次数耗尽后，应将请求标记为失败并返回明确错误码，同时将异常事件写入监控系统。
当跨机房 Prefill 不可用时，是否可以自动回退至本地 Prefill 节点，需要预先配置。回退开关可以保底维持服务可用性，但会牺牲部分吞吐能力或成本效率，应根据业务优先级设定。
下面用一段通用流程示意，描述跨机房 Prefill 调用与缓存传输的部署逻辑。
请求进入主入口|v路由模块判断是否需要外部 Prefill|+-- 是 --+| v| 将输入序列发送至 Prefill 服务池| || v| Prefill 节点完成编码，生成 KVCache| || v| KVCache 写入缓存传输中间层| || v| 缓存元数据返回路由模块| || v| Decode 节点从中间层拉取 KVCache| || v+--> Decode 开始逐步生成输出|v输出返回用户
在实际部署中，缓存写入与 Decode 拉取可以是异步衔接的。Prefill 完成后并不要求 Decode 立刻启动，允许存在短暂排队窗口，这有助于在峰值流量下平滑调度两侧资源。
完成部署后，需要从以下几个层面验证服务是否达到上线标准。
可能原因包括：链路带宽不足、缓存体积超出预期、传输中间层写入效率低。排查思路是分段测量：先测量 Prefill 到缓存层的写入耗时，再测量缓存层到 Decode 的拉取耗时，同时对比理论带宽与实际传输速率。
如果跨机房部署后输出质量明显下降，优先排查缓存精度和压缩配置是否在两侧一致，其次排查 Decode 读取缓存时是否发生部分丢失或截断。
可通过设置合理的重试机制和超时窗口缓解。对于链路长期不稳定的情况，建议评估本地回退开关的开启策略，避免服务可用性受外部链路影响。
如果出现 Prefill 资源池空闲而 Decode 队列积压，需要检查请求路由策略是否合理，是否存在缓存传输入口带宽成为瓶颈。相反，如果 Decode 节点空闲而 Prefill 排队，则需要扩展 Prefill 节点数量或调整缓存传输策略。
跨机房拆分后，Prefill 与 Decode 的资源容量可以独立规划。建议以输入序列长度分布和并发请求峰值作为核心输入，分别计算两侧所需的算力与带宽容量，避免沿用同构同机房时期的固定比例。
跨机房部署引入了额外的缓存传输链路，可能产生传输成本。建议定期统计缓存传输总量，评估是否可以通过调整缓存压缩层级、预取策略或批处理策略降低传输开销。同时，Prefill 服务池可以按需扩容缩容，避免长期空闲。
应针对跨机房链路建立专门监控视图，包括传输成功率、传输时延分位数、网关流量、重试次数等指标。一旦指标恶化，应能触发告警并联动回退策略。
跨机房传输的缓存数据可能包含用户输入内容，应结合数据安全要求进行加密与访问控制。同时建议对缓存传输链路建立独立审计日志，记录传输发起方、接收方、数据体积与时间戳，便于事后追溯。
由于 Prefill 与 Decode 分离部署，版本升级必须考虑兼容性。建议升级时采用“先验证缓存格式兼容性，再滚动升级一侧组件”的原则，避免两侧版本不一致导致缓存无法读取。
大规模推理服务的 PD 分离部署已经从同机房架构演进到跨机房、跨资源池的部署形态。推动这一变化的关键因素，是缓存体积的显著下降使跨机房传输在带宽和成本上变得可行。
部署这类架构时，核心工作并不只是拆开两个推理阶段，而是要系统性地解决缓存传输、调度路由、环境一致性、安全防护、容量规划与运维监控等一系列工程问题。本文从部署目标、场景分析、架构拆解、前置准备、部署流程、配置说明、上线验证、问题排查到运维优化，逐步梳理了跨机房拆分部署的完整思路。
对于团队而言，在落地类似方案前，建议先对模型缓存体积、网络链路能力和业务时延容忍度做充分评估，再决定是否采用跨机房 Prefill 部署。无论是否引入云化 Prefill 资源池，部署后的验证与监控体系都是保证服务长期稳定运行的必要条件。