用大模型时最影响体验的往往除了答案质量，还有等多久：同一个模型，有时一秒出字，有时十秒没反应。这背后的指标叫推理延迟——从发出请求到收到回复的这段时间。把它拆成两段看，慢的原因立刻清楚：第一段是首字延迟，从发送到看到第一个字；第二段是生成速度，之后每秒出多少字。
一次请求进来后发生了什么
先看机制。你在输入框敲下一句话点发送之后，请求依次经过：网络传输到服务器、排队等待可用算力、模型读取你输入的全部内容（这一步叫预填充，决定首字延迟）、逐个字生成回复（这一步决定生成速度）、边生成边流式传回你的屏幕。
流式输出是个关键设计：模型并是边生成边发，第一个字先到每生成一部分就推送一次。所以你感知到的"快"，主要取决于首字延迟——第一个字出来得快，体感就是响应快；哪怕后面每秒只出几十个字，等待的焦虑感也远低于前几秒的空白。
五个变量决定快慢
变量一：模型大小。参数越多，算一步越慢，这解释了为什么同一产品里的轻量档响应更快。变量二：输出长度。让它写 2000 字，自然比回 100 字慢得多，这部分延迟是你自己的要求带来的。变量三：推理模式。开了深度思考的模型会先生成一段你看不见的内部推理再作答，首字延迟因此明显变长。变量四：服务端负载。高峰时段请求排队，延迟整体上抬，早晚差异可能比换一个模型还大。变量五：网络。传输时间占总延迟的一小块，但弱网环境下会被放大。
实测比看参数可靠
判断一个服务延迟高不高，用你自己的问题连测几次：记录从回车到出字的秒数，再感受整体完成时间。不同时段、不同负载下差别可能很大，上午测一次下午再测一次才有结论。测的时候注意控制变量——同样的提问长度、同样的输出要求，否则对比没有意义。
不同场景的容忍度
延迟并非越低越好，而是要匹配场景。实时对话对首字延迟敏感，超过两三秒的空白就会让人怀疑卡死了；批量处理长文档时，整体完成时间才重要，首字快慢无所谓。先把场景定清楚，再看要不要为速度付出成本。
| 场景 | 延迟敏感点 | 判断与做法 |
|---|---|---|
| 实时对话、客服 | 首字延迟 | 超两三秒出字体验就崩，选轻量档或换响应快的时段 |
| 写长文、生成报告 | 整体完成时间 | 首字慢无所谓，先干别的，回头收结果 |
| 深度思考类任务 | 内部推理时长 | 接受更长的等待换更稳的答案，赶时间就关掉 |
| 批量跑几十条任务 | 吞吐而非单次延迟 | 排队跑完即可，单条快慢不重要 |
推理延迟速查
- 延迟分两段：首字延迟、生成速度
- 体感快慢主要由首字延迟决定
- 五个变量：模型大小、输出长度、推理模式、负载、网络
- 高峰时段排队，早晚差别可能超过换模型
- 实测用自己的问题连测几次，控制变量
- 按场景定容忍度，不追求一味快
同样的模型，快慢为何不同
很多时候两家服务回答质量接近，体感却差一大截，差别在工程不在模型：排队策略、算力调度、缓存命中、生成端的优化，每一层都能省下或浪费几百毫秒。理解这一点，选服务时就不会只盯着模型版本——同一代模型，不同产品包装出来的响应速度可以完全不同。
降低延迟也有代价：更多算力、更激进的缓存、更小的模型，都意味着成本或质量的权衡。官方页面标注的速度指标会随版本和负载变化，具体以官方最新版本为准。
关于延迟的三个疑问
- 为什么问题越长，第一个字出来越慢？：模型要先把你输入的全部内容读一遍才能开始作答，贴几千字的文档时，这个预读时间会明显拉长首字延迟。长材料多等几秒属正常现象。
- 显示"正在思考"比直接出答案慢，值得等吗？：看任务。多步推理、数学、代码这类任务，内部推理通常换来更少的低级错误；寒暄、翻译、改写这类任务，关掉更快且质量没有差别。
- 同一句话早上快晚上慢，是我网卡了吗？：大概率是服务端负载波动导致的排队。换个时段再测同一句话验证，如果早晚差异稳定存在，就是负载问题而非本地网络。
延迟只是模型体验的一环，相关的基础概念可以顺着读：生成速度与每秒输出 token是延迟的第二段；模型参数量的差别解释了变量一的来龙去脉；模型量化怎么给模型瘦身是拿精度换速度的典型权衡；而免费版与付费版的额度与速度差异，正是变量四在产品层面的体现。
