概念插画，不代表实测性能数据。
服务器每秒吐出的 token 更多，聊天框却迟迟没有动静，这两件事可以同时发生。一次推理升级值不值得上，得先问清楚：我们想缩短用户哪一段等待？
一张成绩单里的两种“快”
10 月 6 日合并的 vLLM PR #60140，公布了 GLM-5.3 改用 FP8 KV cache 的一组结果。在 TP4、8,000 输入／1,000 输出 token、并发 1、4、16 的测试中，表中吞吐提升 2.3%—5.5%，但首 token 延迟（TTFT）p50 增加 6.9%—11.1%。同时，总延迟 p50 下降了 3.1%—6.3%。也就是说，开口晚了一点，整段回答却更早完成。来源：PR #60140
这组数字来自贡献者报告，本文没有复测；它也没有覆盖更长输入的扫描。后续补丁把该默认行为收窄到 NVIDIA SM100。把结果直接套到所有 GLM 部署，会越过证据边界。来源：PR #60281
把等待拆开，优化才有方向
用户先等第一段输出，再等待后续内容，最后拿到完整结果。服务器吞吐统计的是整体产出；TTFT 看启动等待；ITL 看相邻流式输出之间的间隔；完成时间看整个请求。vLLM 的服务端 TTFT 还包含输入处理等时间，不能当作纯 GPU 计算耗时。客户端的网络、网关和显示开销也应另外观察。来源：指标设计
调度本身就包含取舍。vLLM 的 chunked prefill 把长输入切块，与正在生成的请求一起调度。官方文档指出，较小的批次 token 预算通常有利于 ITL，较大的预算有利于 TTFT。这是理解指标分叉的一般机制；上述 PR 没有据此证明其首字回退的原因。来源：优化指南
缓存也要看省掉哪段工作。前缀缓存复用相同输入前缀的计算，帮助的是 prefill，不会直接缩短生成新 token 的 decode。重复读同一份长文档与不停生成长答案，收益自然可能不同。来源：前缀缓存及限制
升级前，先写下验收条件
下面是本文建议的测试方案，并非已经跑出的结果。
-
固定比较条件。记录 GPU、模型版本、推理框架提交、量化方式、并行策略、推测解码和采样参数。每次只改变待验收的项目，否则很难判断收益来自哪里。
-
建一个小矩阵。选三类真实任务：短对话、长文档短答、长输出；分别跑新前缀和可复用前缀，再覆盖低负载、日常负载、接近服务上限的负载，形成 18 个格子。输入长度须落在模型支持范围内，负载档位由自己的流量决定。
-
再加一次突发流量。记录实际到达率、实际并发、排队时间和失败请求。固定并发测到的是一种压力，真实用户突然涌入是另一种；限流器也可能把等待搬到客户端。vLLM 的压测工具将请求到达率与最大并发分开设置，并提供客户端排队指标。来源：压测参数
-
每格保留完整成绩。至少看 TTFT、ITL、总延迟的 p50／p95／p99，以及吞吐、缓存命中、抢占、超时与错误率。独立重复测试，写明预热方式和样本量；样本少时，尾部百分位尤其需要谨慎解释。量化升级还要另过任务质量关，不能用速度代替正确率。
-
先定门槛，再看收益。交互助手可以优先守住首字和流式停顿；离线批处理可以更看重完成量。具体门槛应来自产品需求。只统计同时满足延迟目标的成功请求，更接近可用产出；vLLM 也支持按 TTFT、每 token 输出耗时和总延迟设置 goodput 门槛。来源：goodput 参数
让升级结论落到用户身上
最后的验收报告，最好回答一句具体的话：“在我们的流量和质量要求下，每小时能多完成多少请求，最慢那批用户要等多久？”
吞吐增长值得高兴。把它与等待、质量和失败率放在一起，才知道这次升级究竟改善了什么。
资料核对截至 2026 年 10 月 19 日。本文依据公开贡献者测试和官方文档作工程分析，测试矩阵为作者建议；未进行独立性能或质量复测。文档的 latest 页面可能继续更新，请以实际部署版本为准。