别看token/秒：AI延迟真正该测的五个指标

模型在 notebook 里跑 40 token/秒。部署完成后，用户一次点击到答案展示花了 11 秒。

第一个数字没错——它测的只是链路上的一个环节，而且往往是最快的那个环节。下面是你应该去测的五个数字，以及判断的阈值。

Token/秒测的是链路中的某一个环节

原文作者描述了一个 AI 功能的完整调用链：browser → edge → 认证层 → 你的 API → 队列 → server → model provider → 持久层 → 返回。原文观点是："A token-per-second number measures exactly one link in that chain, and it is usually the fastest one. The rest of the chain is where latency, cost, and failure actually live."

这就是为什么 40 token/秒和 11 秒之间的差距不是模型的 bug。这是测错了地方的结果——测错地方，优化也就优化错地方。

部署之前需要掌握的五个数字

文章里的测试脚本测了五个指标，用 httpx 异步方式运行：

Cold start——空闲后第一次调用的耗时长，单独测量。

Warm p50——连续 20 次调用的中位数。

Warm p95——同样 20 次调用的 p95 尾延迟。

Concurrent p95——10 个请求通过 asyncio.gather 并发运行的 p95。

Error rate——status ≥ 400 或彻底请求失败的比例，两组调用合并计算。

关键在于脚本不输出一个单独的分数。它是和代码里预先声明的 budget 做对比：p95_seconds: 3.0 和 error_rate: 0.01。过没过，没有模糊地带。

如果想先快速感受一下再写脚本，一条带 -w "%{time_total}s" 的 curl 命令打到 chat 端点，就足以测出 cold start。

跑三次，每次回答不同的问题

作者建议在三个环境上跑同一套测试：本地模型、一个免费 server、以及一个正在收费的线上端点。读法是：第一次几乎没信息量，第二次才是真实用户的感受，第三次才是你真正在付钱买的东西。

如果最差的环境依然能达到 budget，就不需要加钱上更高 tier。如果达不到，文章指出只有两个选择：买更多 compute 来掩盖问题，或者修复整条链路。

问题通常不出在模型

作者的经验直说：故障几乎从来不在模型上。它藏在你为了避免 timeout 而加的那个队列里，藏在你把整个 response 全部缓存完才发送第一个字节的 streaming wrapper 里。这两个对 token/秒的 benchmark 完全不可见，但都是用户直接感受到的东西。

关于来源

原文有 disclosure 说明它是在某个 vendor 的产品推广框架内写的，所以请取其测量方法，忽略工具推荐部分。

本周可执行的任务

选一个正在生产环境运行的 AI 功能，为它声明 p95 budget 和 error rate，然后实测。如果你还没有那个功能的 p95 数字，你就不知道它是快是慢——你只知道模型快。