夜雨聆风大家好，我是 AI 人的一天。
不知道大家有没有遇到过这种情况。
同一个大模型。
在官方聊天页面里，回复很快。
接到自己的产品里，却总感觉慢半拍。
有时半天不出字，有时刚开始很快，写着写着又越来越慢。
很多人的第一反应是：
模型不行。
服务器不行。
网络不行。
但真正进入生产环境以后，你会发现，“AI 快不快”并不是一个简单指标。
首字延迟、生成速度、总耗时、排队时间、P95 延迟……
每一个数字，都可能影响用户体验。
今天，我们就来聊聊：
到底是谁拖慢了你的 AI？
一、首字延迟（TTFT）
TTFT，全称 Time To First Token。
它表示：
从用户发送请求，到模型返回第一个 Token，需要多长时间。
说得更直白一点，就是：
用户要等多久，才能看到 AI 开始说话。
假设用户点击发送以后，等了 8 秒，页面上才出现第一个字。
即使后面的内容生成得很快，用户仍然会觉得这个系统很慢。
因为在那 8 秒里，页面没有任何反馈。
首字延迟通常会受到这些因素影响：
提示词和上下文有多长
模型本身有多大
请求是否正在排队
服务节点是否拥堵
模型是否需要进行较长时间的推理
是否调用了搜索、数据库或其他外部工具
所以，首字慢不一定是模型生成慢。
它也可能还在读取上下文、等待计算资源，或者执行前置任务。
对于聊天机器人、智能客服、语音助手来说，TTFT 尤其重要。
因为用户最在意的，往往不是答案什么时候全部写完，而是：
它到底有没有开始处理我的问题？
二、输出速度（TPS）
TPS 在大模型场景中，通常指 Tokens Per Second。
也就是：
模型每秒能够生成多少个 Token。
如果首字延迟决定“多久开始说”，那么 TPS 决定的就是：
开始以后，说得有多快。
例如，同样生成一段 1000 Token 的内容。
一个模型每秒生成 20 Token，大约需要 50 秒。
另一个模型每秒生成 100 Token，大约只需要 10 秒。
差别非常明显。
TPS 对长内容生成影响尤其大，例如：
生成长篇报告
编写大量代码
输出数据分析结果
生成会议纪要
进行长篇内容创作
短回答只差几秒，用户可能感觉不明显。
但输出越长，生成速度的差距就会被不断放大。
不过，TPS 也不是越高越好。
有些模型为了完成更复杂的推理，会在回答前或回答过程中消耗更多计算时间。
它可能写得慢一点，但答案更加可靠。
所以选择模型时，不能只比较“谁打字更快”，还要看：
速度、质量和成本之间的平衡。
三、总延迟（End-to-End Latency）
总延迟表示：
从用户发出请求，到完整结果全部返回，一共花了多长时间。
它通常包括：
请求传输时间
排队时间
上下文处理时间
模型推理时间
内容生成时间
工具调用时间
结果整理和返回时间
所以，一个 AI 应用的总耗时，并不完全由模型决定。
举个例子。
用户问：
“请分析这家公司最近一年的经营情况。”
系统可能需要先搜索资料，再读取财报，接着调用模型分析，最后整理格式。
模型本身可能只用了 10 秒。
但搜索用了 8 秒，文件解析用了 12 秒，排队又用了 5 秒。
用户最终等待的，就是 35 秒。
在 Agent、RAG、联网搜索和自动化工作流里，这种情况非常常见。
调用步骤越多，总延迟越容易被拉长。
四、排队时间（Queue Time）
很多 AI 应用在测试时很快，上线以后却突然变慢。
原因往往不是模型发生了变化，而是：
请求开始排队了。
当同一时间进入系统的请求超过可用处理能力时，后来的请求只能等待。
就像一家餐厅只有几个厨师。
平时来了两桌客人，出餐很快。
高峰期突然来了几十桌，即使每道菜的制作速度没有变化，顾客等待的时间也会明显增加。
AI 服务也是一样。
排队时间通常和这些因素有关：
并发量是否突然升高
账号或服务实例是否达到限制
GPU 资源是否充足
是否有少数超长请求占用了大量资源
系统有没有设置合理的优先级
是否进行了限流和负载均衡
这也是为什么压测不能只看单次请求有多快。
真正上线时，更应该关注：
多人同时使用时，系统还能不能保持稳定？
五、P50、P95 和 P99 延迟
看延迟时，很多人只看平均值。
但平均值有时会骗人。
假设 100 次请求中，95 次只需要 2 秒，另外 5 次却需要 30 秒。
平均下来，数字可能还算能看。
但那 5 个等待半分钟的用户，体验已经非常糟糕。
所以，生产环境通常还会关注：
P50：一半请求能在这个时间内完成
P95：95% 的请求能在这个时间内完成
P99：99% 的请求能在这个时间内完成
例如：
P50 是 2 秒
P95 是 8 秒
P99 是 25 秒
这说明大部分请求确实很快，但少量请求存在明显的长尾问题。
对用户量较大的产品来说，“少量”也可能意味着很多人。
如果每天有 100 万次请求，哪怕只有 1% 的请求特别慢，也会影响 1 万次使用体验。
所以：
平均延迟告诉你系统通常有多快。
P95 和 P99 告诉你，系统最差的时候到底有多慢。
六、流式输出为什么很重要？
很多聊天产品都会采用流式输出。
也就是模型生成一个 Token，前端就显示一个 Token。
这样做并不会减少完整回答所需的计算量，却能明显改善用户的等待感受。
例如，一段回答完整生成需要 20 秒。
非流式输出：
用户面对空白页面，等满 20 秒以后，才能看到完整结果。
流式输出：
用户可能 1 秒后就能看到第一个字，随后持续看到内容出现。
两种方式的总耗时可能完全相同，但体验差别很大。
这也是 AI 产品和传统接口不同的地方。
优化 AI 体验，不只是缩短真实耗时，还要减少用户感知到的等待。
七、模型越快，产品就一定越好吗？
不一定。
有些系统为了追求速度，会缩短上下文、减少检索结果、跳过必要的工具调用，或者选择能力更弱的模型。
结果虽然出来得更快，但答案质量下降了。
反过来，如果每个简单问题都调用最强模型、读取大量资料、执行复杂工作流，质量可能很高，成本和延迟却难以接受。
真正合理的做法，是根据任务分层。
简单任务
使用更快、更便宜的模型。
复杂分析
允许更长的推理时间。
长文档任务
提前拆分和索引内容。
多工具任务
尽量并行执行，减少无意义的串行等待。
耗时任务
展示明确的处理状态，必要时改为异步执行，完成后再通知用户。
所以，速度并不只是一个模型参数。
它还是一套产品设计和系统工程问题。
八、这几个指标到底怎么看？
其实也不用死记。
记住下面几句话就够了。
用户迟迟看不到第一个字，重点看 TTFT。
开始回复以后写得很慢，重点看 TPS。
完整任务等待时间太长，重点看总延迟和工具调用耗时。
测试很快、上线变慢，重点看并发和排队时间。
大部分请求正常、偶尔特别慢，重点看 P95 和 P99。
最后
所以，以后再有人说：
“这个 AI 怎么这么慢？”
不要只盯着模型。
真正拖慢它的，可能是上下文、排队、工具、网络，也可能是整个工作流。
最后记住一句话：
模型决定它能跑多快。
系统设计决定用户最终要等多久。
往期精彩：
429 Too Many Requests：到底是谁限制了你的 AI？
