大模型在线推理的预填充和解码阶段具有不同计算与资源特征，分离式架构尝试让这些阶段独立调度与扩展。NVIDIA Dynamo 因此值得基础设施团队关注，但“分离”并不自动带来更好效率。阶段之间需要传递状态，请求需要路由，资源池要维持版本一致，任何网络或调度问题都会进入用户延迟。评估重点应是自身请求分布和运维能力，而不是只看架构名称。
阶段拆分先回答负载是否真的不同
输入长度、输出长度、并发和到达模式决定预填充与解码占比。若请求短且负载稳定，拆分带来的额外调度和传输可能得不偿失；若长短差异大或两阶段资源需求明显不同，独立池才可能提供调度空间。应从生产匿名统计构造负载桶，在单体与分离架构上使用相同请求比较，不能用不同参数制造结论。
状态传递让网络进入关键路径
阶段间需要传递与请求相关的状态，数据量、位置和时效都会影响首 Token 与后续输出。网络容量不能只按平均 Token 吞吐估算，还要考虑突发、重试和多租户。跨节点、跨机柜或跨故障域的路径差异应单独测试。任何数据压缩、缓存或传输优化都要验证正确性和失败恢复。
独立扩展需要统一调度目标
两个资源池分别追求最高利用率，可能造成中间队列堆积。调度器要同时观察请求类型、阶段容量、缓存状态和服务等级，并对突发设置回压。预填充池扩得很快而解码池不足，只会更快制造等待。容量控制应以端到端首 Token、逐 Token 和尾延迟为目标，不能让单阶段指标主导全部决策。
故障恢复比单体服务更复杂
某个阶段实例失败时，请求状态能否重建、是否需要从头执行、客户端是否收到重复输出，都要明确。路由器和状态服务也可能成为共享故障点。应注入进程、节点和网络故障，观察请求级结果，而不是只看服务最终恢复。版本发布期间，新旧阶段是否允许交叉组合，需要由兼容矩阵控制。
平台治理要覆盖更多制品
模型、运行时、阶段服务、路由与调度配置可能分别发布。企业应生成一个端到端发布清单，锁定所有镜像、模型和配置摘要。日志与追踪需要跨阶段关联同一请求，同时遵守数据最小化。若可观测平台无法还原一次请求经过哪些实例，生产问题会比单体架构更难定位。
成本评估也应采用完整系统口径，统计等待、缓存、冗余与网络资源，而不是只比较单个 GPU 池的利用率。分离后某一池看似更满，若另一池长期预留或状态传输占用更多资源，整体效率未必改善。
值得执行的评估
- 用真实长度和到达分布比较单体与分离架构的资源、吞吐和高分位延迟。
- 测量阶段状态传递的字节、时间、网络路径和突发峰值。
- 逐级改变两个资源池容量，验证调度和回压不会把瓶颈隐藏在中间队列。
- 注入实例、节点和网络故障，检查请求重试、重复输出与恢复时间。
- 演练混合版本发布和完整回退，确认所有阶段实际组合可追溯。
Dynamo 的组件、概念与当前使用方式应以 NVIDIA Dynamo 官方文档为准。开源项目与文档会持续演进，本文只说明企业评估维度，不声称特定架构一定提高吞吐、降低成本或适用于所有模型。
WeChat
Profile