为什么必须固定基准
升级镜像、驱动、推理框架或换量化版本之后变慢，是排障里最常见也最容易吵起来的问题。可靠做法是先有一套固定负载基准：同一份数据、同一并发、同一输入输出长度，只改一个变量后重跑，并把首 token 延迟与逐 token 延迟分开看。两者退化的方向指向完全不同的根因，混在一起看就只能靠猜。
基本信息
| 适用平台 | 自托管推理服务，各引擎通用 |
|---|---|
| 基准要素 | 数据集、并发、输入长度、输出长度四项固定 |
| 观察指标 | 首 token 延迟、逐 token 延迟、总吞吐、显存与缓存水位 |
| 记录要求 | 镜像版本、驱动版本、权重版本一并写进报告 |
| 权限要求 | 能读引擎指标与显卡状态的普通账号即可 |
典型使用场景
- 版本升级后验证：新版本在目标并发下是否退化
- 驱动与固件变更：区分是软件变化还是底层变化带来的影响
- 参数调优对照：改一个参数就跑一遍同一份基准
- 容量评估：给出可承诺的并发档位与对应延迟
- 故障复盘：把退化点与变更时间线对齐，找到引入版本
- 跨硬件对照：换卡或换机型用同一基准比较，避免只按纸面参数下结论
固定基准（示意）
固定基准（示意）
<基准脚本> --input-len 1024 --output-len 256 --concurrency 16 # 固定形状与并发
# 记录首 token 延迟与逐 token 延迟的分位数，以及显存与缓存水位
# 每次只换一个变量，其余保持不变；数据与并发都不换
git -C /opt/llm rev-parse HEAD > /tmp/ver.txt # 记录代码版本退化方向对照
| 现象 | 优先怀疑 | 核对方法 |
|---|---|---|
| 首 token 延迟变差 | 预填充计算、编译与图捕获 | 用长输入短输出的档位单独测 |
| 逐 token 延迟变差 | 解码路径、量化内核、通信 | 用短输入长输出的档位单独测 |
| 整体吞吐下降 | 调度策略、批处理配置、降频 | 对照显存水位与降频记录 |
| 波动变大 | 同卡邻居、磁盘 IO、网络 | 查同机其他任务与整机负载 |
一次只改一个变量：镜像、驱动、参数、权重分开对比，混合变更得到的结论不可信。
把基准脚本与数据集纳入版本管理：否则过几个月没人能复现当初的结论，也没法和新结果对齐。