详细内容或原文请订阅后点击阅览
分解是一个千 GPU 问题
在将预填充与解码分开之前必须满足的三个条件得到了回报，以及为什么分块预填充是低于该阈值的正确默认值。分解是一个千 GPU 问题首先出现在走向数据科学上。
来源:走向数据科学今年每个主要推理框架都推出了预填充解码分解。 NVIDIA 将其内置到 Dynamo 中。 SGLang 使其成为大规模部署的默认设置。 vLLM 添加了 KV 连接器 API 来原生支持它。共识正在快速形成：将预填充和解码拆分到单独的 GPU 池上，从而提高吞吐量。
对于大多数团队来说，这种共识是错误的。
Doubleword 的分析表明，平衡的分解部署与并置吞吐量相匹配，但在 GPU 数量较少时，舍入损失占主导地位：您无法分配部分 GPU，因此专业化收益会被不完整的工作线程利用率所吞噬。这种规模的实际好处是独立的 SLO 调整，而不是吞吐量。
2025 年 6 月的一项研究评估了数十万个设计点，发现分解对于预填充密集型流量模式和大型模型最为有效。对于大多数团队实际运行的混合流量工作负载，排队和节点间 KV 缓存传输主导着端到端延迟。分解的团队移动了瓶颈。他们没有删除它。
我在服务于中型分类模型的推理工作负载上遇到了这个问题。 TPOT 在突发流量下激增，第一反应是将预填充与解码分开。相反，我在同一个 GPU 池上启用了分块预填充。 TPOT 稳定。问题在于调度干扰，分块预填充可以在不添加网络跃点的情况下解决该问题。
分解解决了什么：干扰问题
预填充和解码具有相反的硬件配置文件。预填充受计算限制：整个输入序列上的并行矩阵乘法，GPU 计算利用率为 80% 到 95%。解码受内存带宽限制：顺序 KV 缓存读取一次生成一个令牌，H100 上的计算利用率低于 5%。
当两者共享 GPU 时，它们会争夺相同的资源。在突发工作负载下，在解码过程中到达的单个大型预填充请求会使每个输出令牌的时间增加 2 到 30 倍。当预填充使计算单元饱和时，解码批处理会停止。
DistServe 证明了该修复方法可以大规模发挥作用：将预填充和解码分离到专用池上，在相同的延迟限制下，服务的请求数量增加了 7.4 倍。在 DistServe 基准规模上，分解无疑是正确的选择。
下图显示了每种方法的瓶颈所在：共置、分解和分块预填充
但是有一个更简单的修复方法可以在不改变架构的情况下处理大部分干扰。
分块预填充：大多数团队实际需要的修复
分块预填充将长预填充请求分解为较小的块，并将它们与同一 GPU 上的解码批次交错。没有单独的节点池。没有通过网络传输 KV 缓存。无需调整 P:D 比率。
TNG Technology Consulting 使用启用分块预填充的标准 vLLM 测量到总令牌吞吐量增加了 50%。解码批次仍在同一硬件上的预填充块之间运行，但调度干扰已降至大多数生产工作负载可以容忍的水平。
将其想象为高速公路上的收费站：分块预填充不是为一辆超大卡车关闭所有车道，而是让卡车一次通过一条车道，而正常交通则继续通过其他车道。
分块预填充并不能完全消除干扰。它限制了它。每个预填充块在有限的时间内占用计算单元，然后进行解码。对于每秒大约 50 个请求以下且提示长度适中的工作负载，该界限足够严格。
维度
分类
分解的三种成本：解释者跳过的内容
解释文章介绍了分解的好处。他们跳过了它的成本。
KV 传输税。每个完成预填充的请求都必须通过网络将其 KV 缓存发送到解码节点。对于 70B 参数模型，每个请求大约为 2.6 GB。
当预填充和解码共享一个节点时，KV 缓存保留在 GPU 内存中。一旦跨节点分解，该传输就会到达网络互连，并且可用带宽会根据您的拓扑下降几个数量级。
这就像将工厂装配线分成两座建筑物：每座建筑物的专业化程度有所提高，但现在您在它们之间运输半成品零件。如果同一机架中没有 InfiniBand 或 NVLink，运输成本将占据主导地位。您无法通过分解方式摆脱缓慢的网络。
操作界面。分解使您的基础设施管理加倍。您现在运行单独的预填充和解码节点池，每个节点池都有自己的扩展策略。 P:D 比率取决于您的工作负载组合：LMSYS 独立评估了 DeepSeek-R1 的 4 个预填充节点和 9 个解码节点，并且这些数字会在提示与输出长度比率发生变化时发生变化。
没有优雅的后备。如果预填充节点出现故障，解码节点将无法填充。角色在启动时分配。
无声的失败悬崖。在低并发情况下，分类服务工作得很好。在生产并发中，它会以不产生错误的方式进行中断。SGLang 问题#9266 记录了 64 个或更多并发请求时系统性的 KV 缓存传输失败，向客户端返回 HTTP 400。
Issue #30233 描述了一个更严重的故障：当输入超过最大请求长度时，预填充端会中止，但仍会传输单令牌 KV 缓存。解码端从未初始化的内存生成。调用者不会看到任何错误。
决策数学：必须满足的三个条件
Modular 的推理手册报告称，小型或未调整工作负载的分解导致性能下降 20% 到 30%。开销是真实且预先加载的：无论吞吐量增益是否实现，您都需要为每个请求支付 KV 传输成本。
仅当三个条件同时满足时，分解才能收回成本：
足够的 GPU 进行干净分配。DeepSeek 需要数千个 GPU，然后 P:D 比率才能生成与其流量组合相匹配的整数节点数。对于 8 到 16 个 GPU，您的比率选项为 1:7 或 2:6，这两种情况都不适合您的工作负载。
维持 KV 生产率的网络带宽。如果您的预填充池生成 KV 缓存的速度比互连传送它们的速度快，则解码空闲等待数据的节点。瓶颈从计算干扰转移到网络传输。
用于改变流量混合的动态自动缩放。聊天工作负载（短提示、长解码）需要与 RAG 管道（长提示、短解码）不同的 P:D 比率。如果您的流量组合在白天发生变化，而您的节点池是静态的，那么您的一侧会过度配置，而另一侧则会匮乏。
如果这些条件中的任何一个不成立，则分块预填充是更好的默认值。下面的决策流程图将这三个条件映射到具体的路由选择。
分块预填充
吞吐量增益
+50%（TNG、vLLM）
规模增加 7.4 倍 (DistServe)
网络要求
无（相同 GPU）
InfiniBand 或 NVLink
运营开销
vLLM 标志
单独的池、P:D 调整、KV 路由器
故障模式
任何
有限干扰
无声的 KV 损坏、并发悬崖
比例阈值
~1,000+ GPU
多回合惩罚
无
KV状态滞留在解码节点
分块预填充与分解服务：吞吐量、运营成本和故障特征。
在做出决定之前要衡量什么
不要根据架构图拆分您的基础架构。先测量一下。
TPOT 位于 p95，而不是 p50。中值隐藏了分解目标的干扰尖峰。如果您的 p95 每个输出令牌时间在分块预填充的 SLO 范围内，则不会遇到分解所解决的问题。
预填充 TTFT 的一小部分。配置文件您的实际请求。如果预填充执行只占第一个令牌时间的一小部分，则瓶颈在其他地方：队列、调度或网络。分解并不能解决这些问题。
并发时 KV 传输的可靠性。在大规模分解之前，请在生产并发级别运行它，而不仅仅是在低 QPS 下运行。在超过并发阈值之前，SGLang 问题跟踪器中记录的故障模式不会出现。
结论：从分块预填充开始
默认为分块预填充。它解决了大多数团队实际存在的调度干扰问题，网络开销为零，且无需扩展操作面。对您的 p95 TPOT 进行基准测试。如果成立，就到此为止。
分解是大约一千个 GPU 之上的正确架构，具有快速互连，并具有管理 P:D 比率调整和 KV 传输可靠性的工程能力。这些条件描述了超大规模提供商和大型推理提供商。他们没有描述大多数在 2026 年交付 LLM 功能的制作团队。
进一步阅读
何时分解（Doubleword 对分解所需条件的分析）
超越喧嚣：推理分解的务实态度（2025 年 6 月，对数十万个设计点的分解进行系统评估）
H100 上的分块预填充（TNG 的 +50% 吞吐量测量）
Modular LLM 推理手册（Modular 的 20-30% 下降警告和决策标准）
推理分解（Wing VC 对计算/带宽划分的分析）
···
感谢您的阅读。我是 Mostafa Ibrahim，Codecontent 的创始人，Codecontent 是一家以开发人员为先的技术内容机构。我撰写有关代理系统、RAG 和生产人工智能的文章。如果您想保持联系或讨论本文中的想法，可以在 LinkedIn 上找到我。