Prefill 与 Decode 分离可以让两类计算阶段使用不同批处理和 GPU 资源，但它把 KV Cache 的交接放进了用户请求关键路径。长上下文、并发请求和模型并行会让状态体积迅速增长；如果调度器只按空闲 GPU 分配而忽略接收节点距离与网络队列，计算利用率提高也可能换来更差的首 token 或每 token 时延。
架构评审要为一次请求画出入口、prefill 队列、KV 生成、传输、decode 接收和响应路径，并标明每一步的排队、复制与故障语义。网络容量应按高分位上下文长度和并发迁移计算，不能只依据平均请求。KV Cache 是否压缩、分片或复用也必须作为版本化假设。
先估算每个请求的状态体积
根据模型层数、KV 头、头维度、数据类型、token 数与并行切分计算传输量，并分别统计短、中、长上下文。实际实现可能采用分页、量化或选择性传输，必须用目标框架测量确认。容量报告应保留公式与模型版本，防止模型升级后继续沿用旧值。
调度器要感知数据移动成本
空闲 decode 实例如果位于远端机柜或拥塞路径，迁移时间可能超过等待本地资源。调度决策应综合队列长度、KV 大小、网络距离、节点健康与缓存命中，并设置最大迁移预算。请求重试时要避免重复大规模传输造成放大流量。
计算网与服务网边界要清晰
用户入口、模型服务控制、KV 数据面和 GPU 集合通信可能使用不同网络平面。若共用同一 Fabric，需要制定 QoS 与拥塞隔离，防止批量 KV 迁移压住健康检查或响应流量。分离网络则要计算额外端口、路由和运维成本。
故障恢复不能留下孤儿状态
prefill 完成后 decode 节点失败，系统要决定重新 prefill、从副本恢复还是返回错误。KV Cache 通常包含请求上下文，安全策略还要覆盖内存、传输和日志中的数据边界。演练应验证超时、取消和回收，避免失效状态长期占用显存。
端到端指标压过局部 GPU 利用率
验收同时观察 TTFT、TPOT、请求完成率、KV 传输 P95/P99、网络队列、GPU 利用率和排队长度。使用真实上下文分布与并发波形运行长稳测试，并与不分离架构做对照。只有用户时延与资源效率共同改善，拆分才有工程价值。
可执行的验证动作
- 按模型、精度、上下文和并行方式计算 KV 状态体积。
- 让调度策略同时考虑队列、数据大小、网络距离和健康。
- 划清入口、控制、KV 数据与集合通信网络边界。
- 演练 decode 故障、请求取消、重试和状态回收。
- 以 TTFT、TPOT、完成率和 KV 传输尾延迟联合验收。
官方能力与项目结论的边界
NVIDIA AI Enterprise 文档为企业 AI 软件、部署与支持生命周期提供官方入口。
推理组件、模型和数据传输能力需要按所用软件版本与部署架构确认。
具体功能、版本、兼容与部署条件请以NVIDIA AI Enterprise 文档的当前页面为准。官方系列信息用于建立候选范围，不能替代完整料号、目标平台支持清单和现场验证。
项目协同与能力边界
中科新远是 NVIDIA Networking Elite 合作伙伴。中科新远可结合 Spectrum-X、SuperNIC 和 GPU 集群现状，协助测算 KV 数据路径、端口容量、隔离策略和长稳验收用例。具体合作范围和项目交付内容以当前有效资质、官方目录及书面确认结果为准。
Prefill 与 Decode 分离后，只要 GPU 利用率提高就值得上线吗？
不能只看 GPU 利用率。KV Cache 传输与排队进入关键路径，必须同时改善用户端 TTFT/TPOT、完成率和资源效率，并验证故障恢复。
WeChat
Profile