海光 DCU 性能测试实录冷启动如何把 0.325% 伪装成接近三倍在一组海光 DCU gfx936 推理 A/B 中第一次看到结果时几乎没有理由不兴奋。我们只替换了一条 BF16 MLP gate/up GEMM 的 vendor solution。四次新服务按照 B-A-B-A 顺序运行结果是baseline1: 4.183840 tok/s candidate1: 15.041781 tok/s baseline2: 5.503544 tok/s candidate2: 15.138390 tok/s两个 baseline 都慢两个 candidate 都快。这不是一次偶然尖峰而且所有运行都生成了 1809 个 token10/10 文本完全一致。如果只看常见的 A/B 原则这组结果似乎已经很有说服力baseline 重复了candidate 重复了顺序交错输出一致failed 为 0。但它仍然是错的。一个明显不符合物理预算的结果这条改动只影响 Prefill 中一个固定大 GEMM shape。它不会让 Decode TPOT 大幅下降也不可能把完整服务从 4-5 tok/s 直接推到 15 tok/s。当局部改动与端点收益相差几十倍时第一反应不应该是“中了大奖”而应该是测量窗口里混进了什么于是我们不再只看整组吞吐而是拆开每个请求的时间线。问题很快出现每个 baseline 服务都在同一个靠后请求上进入了数分钟级冷路径candidate 也有冷路径但持续时间短得多。这个异常足以主导整组墙钟时间。为什么 B-A-B-A 没能消除污染B-A-B-A 能降低随机波动但它有一个隐含前提每次 B 和 A 的系统状态分布相同这次并不满足。四次运行都使用“新启动的服务”而冷路径是进程级状态。每个 baseline 都重新经历了相似的首次路径因此污染不是随机噪声而是和配置、服务生命周期或缓存状态相关的系统性偏差。交错顺序只能处理时间趋势处理不了“每个新进程第一次执行某个 shape 时都会发生什么”。换句话说B-A-B-A 重复了污染而不是消除了污染。先看单请求真实信号其实很小排除那个数分钟异常请求后对其他请求做归因baseline 的 TTFT 只比 candidate 慢约38 ms/request换算成整组 output throughput物理上大约对应 0.29%而不是接近三倍。这个数字和改动范围更匹配只改 Prefill GEMMTPOT 不应显著变化每个请求只获得几十毫秒 TTFT 改善完整请求持续时间远大于这几十毫秒。于是实验需要重做。新协议每个进程先完整跑一遍修正后的流程不是增加几个短 warmup而是每个新服务 - 完整运行固定 10 请求一次 - 丢弃第一次完整结果 - 再运行相同 10 请求 - 只记录第二次顺序仍然保持baseline1 - candidate1 - baseline2 - candidate2这样做的目的是让每个进程都经历同样的 shape、编译和缓存建立过程再进入测量窗口。稳态结果终于回到物理范围第二轮测量结果如下运行output tok/stokensmean TTFTp99 TPOTfailedbaseline116.41743918093150.450 ms43.792 ms0candidate116.47869718093107.261 ms43.715 ms0baseline216.41302718093148.763 ms43.745 ms0candidate216.45845218093106.818 ms43.826 ms0四种交叉比较的吞吐变化为candidate1 vs baseline1: 0.3731% candidate1 vs baseline2: 0.4001% candidate2 vs baseline1: 0.2498% candidate2 vs baseline2: 0.2768%均值结果candidate mean vs baseline mean 0.3250%两个 baseline 之间只差 0.027%说明修正后的参考已经稳定。所有测量仍然保持1809 个输出 token10/10 文本一致failed0TPOT 基本不变。这和“只优化 Prefill GEMM”的预期完全一致。最危险的不是冷启动而是合理的假证据链如果第一次结果只有一组 4.18 对 15.04很容易被识别为异常。真正危险的是它看起来拥有完整证据B1 慢 A1 快 B2 慢 A2 快 文本一致 无失败这套证据会让人放松警惕。但只要四个进程都没有经过同样的完整 warmupB-A-B-A 仍然可能比较的是四种不同的进程状态。如何识别类似问题1. 先做物理预算如果改动只省几十毫秒 TTFT却观察到几倍吞吐优先怀疑测量。2. 拆每个请求整组吞吐会隐藏单个数分钟异常。逐请求 TTFT、TPOT 和持续时间更容易定位污染源。3. Warmup 必须覆盖真实 shape一个短 prompt 或一个小 shape 的 warmup不能保证后面的长 shape 已完成编译和缓存建立。4. 新进程和同进程要分开理解进程间 A/B 测的是“启动后完整生命周期”进程内第二轮更接近稳态 kernel 效果。两种口径都可以有价值但不能混在一起。5. 输出一致只能证明语义没有证明计时正确1809 token 和 10/10 文本一致排除了生成漂移却无法排除 I/O、编译、缓存和 runtime 冷路径。这为什么是海光 DCU 论坛值得讨论的问题海光 DCU 大模型服务通常同时包含 DTK kernel、Triton/Inductor 编译、CUDAGraph、模型加载和多种 shape cache。本文没有把那次冷路径唯一归因于其中某一项但它证明了进程状态足以压过真实 kernel 收益。因此论坛中的 DCU benchmark 最好同时公开是否为新进程warmup 是否覆盖完整真实请求计时是否包含首次编译和图捕获是否按请求记录 TTFT/TPOTbaseline 与优化版本是否经历相同生命周期。这些信息能让不同海光 DCU 结果真正可比较而不只是各自给出一个最快数字。结语同一条改动第一次看起来把吞吐从 4-5 tok/s 提升到 15 tok/s修正进程内 warmup 后真实稳态收益是 0.3250%。两组数字都来自真实运行但回答的是不同问题第一组主要测到了冷路径差异第二组才接近目标 GEMM 的稳态服务收益。这次实验留下的最重要结论不是“0.325% 太小”而是A/B 的价值不在字母顺序而在 A 和 B 是否处于相同系统状态。在 DCU 大模型推理中编译、图捕获、权重加载和 shape cache 都可能成为隐形变量。没有完整、对称的 warmup再漂亮的 B-A-B-A 也可能只是把同一个误差重复了四次。