AI回答开始得慢，和回答中途停顿是一回事吗：首个输出、生成间隔与总时长怎么量

同一个AI工具可能有三种“慢”。提交后很久才出现第一个字，是开始等待；第一个字很快出现但文字一停一走，是持续阶段不均；正文已经完整却迟迟不结束，则可能是尾部事件或连接状态。把三种现象都记成一次总时长，会丢掉定位所需的边界。

测量时先放弃“感觉变慢”的单一描述，改记五个时刻：请求送出、首个数据事件、每批文字增加、末次可见文字、连接结束。若平台还提供首个词元、输入词元、输出词元和缓存词元，就与浏览器时间放在同一行，而不是把不同层的数字混成一个。

首个输出之前发生了什么

AWS把模型运行分为预填充与解码。预填充读取完整输入并形成首个输出词元；解码再逐个产生后续词元。长对话、系统指令、工具说明和本次问题都会增加输入，最先影响的通常是开始前的工作量。

首个词元时间仍不是用户看到首字的时刻。模型产生数据后，还要经过服务网关、网络、浏览器读取与页面绘制。浏览器的首事件比服务端首词元晚，并不自动说明网络故障；中间任何一段都可能增加差值。

排队也可能发生在模型计算之前。服务端若只公开总调用时间，没有明确是否包含排队，就不能自行把全部首段等待归到预填充。记录指标名称与官方边界，比用相近名称互相替代更重要。

总时长不能代替持续吞吐

AWS指出，调用总时长上升有两个基本方向：模型生成词元的速度变慢，或一次请求产生了更多输出词元。第二种情况下，回答完成得更晚，却不表示单位时间吞吐下降。

它用OTPS表示每秒输出词元，并把总时长拆成首个词元时间，加上输出词元数除以OTPS。假设首词元为两秒，四百个输出以每秒四十个词元生成，解码约十秒；输出增至八百而速度不变，总时长就会多十秒。

因此总时长上升而OTPS稳定，更支持输入或输出变长；输出长度相近而OTPS下降，才更支持持续吞吐变化。这里的“支持”不是唯一证明，因为服务负载、采样方式和指标窗口仍可能造成差异。

如果平台不提供OTPS，可以用首事件到末次文字之间的可见字符增长作近似观察，但不能把字符数直接等同词元数。中文、英文、标点和编码的词元切分不同，近似值只适合同一输入条件下的相对比较。

回答结束也有两个时刻

用户读到完整句号时，连接不一定立即关闭。服务端可能随后发送使用量、引用、工具结果或结束标志。若只记录连接关闭，会把尾部元数据时间算入正文生成；若只记录最后文字，又看不到连接是否异常悬挂。

所以末次可见文字和最终事件要分开。两者差距稳定，可能只是协议流程；差距偶尔很大，才值得查看尾部事件、重试或客户端状态。不要因为连接多开一秒就判断模型还在生成。

前缀缓存改变的是输入阶段

Cloudflare把提示缓存描述为前缀缓存：复用预填充阶段已计算的输入张量。共享的系统指令、工具定义或长对话放在输入开头，后续请求若具有相同词元前缀，可能减少重复输入处理。

匹配的是精确前缀，不是“意思差不多”。在开头插入当前时间、随机编号或用户问题，会让后续内容无法沿用相同前缀。首个请求通常是冷请求，相同会话也要路由到持有缓存的实例才更可能命中。

缓存主要影响首段，并不保证回答更短，也不承诺后续每个词元更快。冷请求和热请求若混在平均值中，首个输出的波动会被误写成线路不稳定。比较时应单独标记缓存命中与可复用词元数。

可以做一组控制：固定系统指令与历史，只改变最后一个问题；再做一组让开头也变化。若前一组首事件更稳定，且平台显示缓存词元，证据更接近输入复用。没有缓存指标时，最多写“与前缀复用一致”，不能声称已经证明命中。

流式事件为何可能成批显示

WHATWG的EventSource规范规定，text/event-stream以UTF-8逐行解析，遇到空行才分派一个完整事件。字节已经进入浏览器但事件尚未闭合时，页面不会收到新的message事件，因此模型持续产生内容和页面连续显示并非同一个动作。

规范还描述连接关闭后的重连，并提醒不了解事件时序的中间层分块可能降低事件流可靠性。中途长空窗、随后一批文字到达，可能位于服务分帧、传输或重连过程，不能只凭屏幕表现判定模型停算。

EventSource只是一个接口。许多AI网页使用fetch可读流、WebSocket或自定义协议，分帧与重试规则不同。EventSource规范不能证明所有AI流式接口都采用相同传输，前缀缓存也不保证每次命中或固定加速。

若能打开客户端日志，分别记录网络数据事件和DOM文字变化。事件本身成批到达，证据更靠近服务端分块或传输；事件均匀到达但页面成批更新，证据更靠近脚本处理、主线程占用或绘制。

一次受控比较怎样做

固定模型版本、完整输入、系统指令、历史消息、输出上限、采样参数和会话条件。固定模型、输入、输出上限和会话条件，记录请求、首事件、每批文字、末次文字和结束事件，同时保存输入输出词元与缓存命中。

第一组只改变输入长度，保持回答范围接近，观察请求到首事件的变化。第二组保持输入一致，只调整输出上限，观察首事件后的持续时长。第三组保持前缀一致，对比冷请求与后续请求，并标注是否有缓存词元。

每组至少重复数次，报告中位数与较慢样本，不挑最快一次。高峰负载、实例路由和连接波动都会造成离散；单次快慢只能描述那一次，不能代表长期性能。

还要固定客户端。不同浏览器、扩展、后台标签页和省电模式会影响定时器与绘制。若服务事件时间稳定而可见文字时间变化，先检查客户端环境，再讨论模型。

从现象回到证据层

很久才出现首字：核对输入长度、冷请求、缓存词元、服务排队和首词元到首事件的差值。开始很快但持续变慢：核对输出数量、OTPS与事件间隔。文字成批出现：比较网络事件和页面变更。正文完成但连接不结束：检查尾部元数据与结束标志。

结论只写到证据覆盖的层。总时长变长不一定是模型变慢，首个输出慢不一定是网络问题；一次中途停顿也不足以证明服务端缓冲。分段时间线不会自动修复问题，却能让两次比较真正回答同一个问题。

用数字把两种慢分开

假设第一轮请求在两秒收到首事件，之后十秒完成四百个输出词元；第二轮仍在两秒收到首事件，却花二十秒生成同样数量。输入边界相近时，这组差异更接近持续吞吐变化。若第二轮生成了八百个词元，则完成时间翻倍可以由工作量解释。

再看另一组：两轮都生成四百个词元，首事件分别出现在两秒和八秒，开始后持续时间相近。差异更集中在首段，需要核对输入词元、冷请求、缓存与排队，而不是先把责任交给逐词元解码。

数字示例只说明拆分方法。服务端首词元和浏览器首事件不是同一个时钟点，输出词元也不能从可见汉字精确推回。报告中应写清采用平台指标还是客户端近似值。

事件间隔怎样记录

每次数据到达时写下相对请求时间和新增文字长度，不必录下敏感正文。若间隔大致稳定但每批长度不同，可能是服务端分块策略；若网络事件稳定而页面变化集中，优先查看客户端合并更新。

后台标签页可能降低绘制频率，屏幕休眠和省电模式也会改变定时器。测量时保持标签页前台，并记录浏览器版本、扩展和网络类型。客户端条件不同，就不把两组屏幕时间作精确性能对比。

连接重建时保存请求编号、事件编号和重试时刻。一次空窗后若出现新连接，更接近传输重连；没有网络层记录时，只能描述“页面在某段时间没有新增文字”，不能声称模型停止生成。

建立一行可复测记录

一行记录可包含：模型标识、输入词元、输出词元、缓存词元、请求时刻、服务首词元、浏览器首事件、末次文字、结束事件和错误码。未知字段留空，不以零代替；零表示明确测得为零，空白才表示没有观测。

同一组实验保存原始时间戳，再由脚本计算首段、持续段和尾段。这样以后改变计算边界时可以重新分析，不必依赖已经四舍五入的截图。若平台升级模型或指标定义，另开新组，不把升级前后强行接成连续趋势。

最终只报告能够复现的差异：首段中位数增加多少、持续段在相近输出量下怎样变化、页面事件是否晚于网络事件。没有足够样本时标记为个案，不用一次卡顿代表服务长期状态。

资料来源

• Amazon Web Services：《Diagnose InvocationLatency increases using output tokens per second (OTPS)》，发布或更新于 2026-07-28
• Cloudflare：《Prompt caching》，发布或更新于 2026-04-21
• WHATWG：《HTML Standard: Server-sent events》，发布或更新于 2026-07-20