四个补全样本里有三个变快能不能宣布优化成功如果剩下一个变慢很多平均延迟和尾部体验仍可能变差。只报“胜率 75%”会把最难受的那一条藏起来。性能工程需要让每份输入在两个方案中都出现再比较同一输入的差值。10 月 16 日 vLLM 的优化说明强调覆盖支持的配置并验证正确性这比挑一项最好结果更接近可维护的工程流程。官方文章配对先从请求身份开始输入文本一样还不够。分词器、模板、采样、最大输出、停止条件和缓存状态也会改变工作量。代码补全尤其要固定光标位置、可见上下文和判分方式不能一个方案生成两行另一个方案生成整个函数。from statistics import mean, median baseline {a:10, b:20, c:30, d:100} candidate {a:9, b:19, c:29, d:130} if set(baseline) ! set(candidate): raise ValueError(unpaired requests) if any(v 0 for v in list(baseline.values()) list(candidate.values())): raise ValueError(invalid latency) ids sorted(baseline) delta [candidate[k]-baseline[k] for k in ids] assert delta [-1, -1, -1, 30] assert median(delta) -1 and mean(delta) 6.75 print({faster_pairs:sum(d 0 for d in delta), pairs:len(ids), median_delta:median(delta), mean_delta:mean(delta)})这些是人为构造的耗时样本没有单位也不来自真实 IDE。它们说明中位差值为 −1、平均差值却为 6.75。两个数字都没错只是描述分布的不同部分。更大的测试需要展示原始样本、重复运行、方差和失败请求而不是用四条记录推断总体置信区间。先确认生成内容可接受端到端比较不能只留下耗时。若优化导致语法错误、工具调用格式变了或输出在中途停止应先判为正确性失败再单独统计延迟。采样模式下也不能要求单次文本逐字相同来证明分布等价需要与所声称的正确性目标匹配。维度最小记录正确性输出、停止原因、判分与失败类型时延TTFT、输出间隔、完成时间工作量输入/输出Token、缓存热度环境模型修订、引擎提交、硬件与并发测试顺序也会影响结果。始终先跑基线、再跑候选可能把后者的热缓存与设备状态优势算成补丁收益。可以交错或随机化顺序但要保留可重现的种子与运行编号。离线代码只验证配对和统计真实代码模型、IDE、GPU和业务质量未测试。最终结论应明确哪些任务更快、哪些变慢、代价是什么“多数样本获胜”只是其中一条证据。