AI 推理延迟怎么排查？从请求到屏幕拆分等待阶段

用户说“AI 回答慢”时，瓶颈可能在模型，也可能在客户端队列、连接建立、代理缓冲、工具调用或页面渲染。只看一条总耗时，无法判断是首个字迟迟不来、生成中的停顿、工具在等待，还是答案已经到达浏览器却没有显示。先追踪一条请求经过的阶段，再选择改动。

本文聚焦单次请求的延迟诊断：把一次等待拆成可观察的时间线，并区分直接证据与推测。它不估算本地服务能承载多少并发；要为到达率、突发和持续队列找容量边界，请用本地推理服务并发试验。要定位 Agent 运行中第一个流程偏差，则用Agent 运行轨迹复核。

先定义用户感知的“开始”和“完成”

同一次请求至少有三个不同结束点：服务端产生首个 Token、客户端收到首段内容、界面把文字绘制出来。流式响应中的首字节也可能只是 HTTP 标头或事件封装，不代表用户已经看到答案。总完成时间还受输出长度影响；响应更长但生成速度正常，不一定是推理变慢。

为每个阶段采用同一请求编号，记录一组带起止点的时间：

阶段	建议记录	可以回答的问题
客户端	本地队列、连接准备、实际发出、首字节、首段可见文字、末字节、渲染完成	请求何时发出，用户何时真正看到并读完结果？
网关与代理	收到请求、转发上游、首段回传、缓冲或重试	是否被限流、排队、重试或攒批后才转发？
模型服务	接收、调度、可用时的队列、首 Token、流式输出、完成	可见指标是否支持“服务内部在等待或生成慢”的判断？
外部工具	每次调用开始、结束、状态码、工具名与调用编号	等待是否花在搜索、数据库或其他下游？
结果处理	解析、校验、后处理、UI 渲染完成	模型结束后，应用还花了多久才显示结果？

用单调时钟测同一机器上的阶段时长，避免系统时间校准让耗时变成负数。跨机器拼接轨迹时保留每个时钟来源和时钟同步状态。父级总 span 已包含子 span 的时间，汇总总等待时不要把二者相加；并行分支也可能在时间上重叠。

把请求形状与重试记录下来

延迟对输入、输出与执行路径都很敏感。保存模型与版本、输入 Token 数、输出 Token 数、是否流式、上下文长度、工具调用数、是否命中缓存、冷启动状态、地区、HTTP 状态以及重试次数。不要只保存“Prompt 大约一千字”：实际 Token 数、附加上下文和图像等输入会改变工作量。敏感请求内容留在获准的观察系统中，用脱敏编号或受控证据位置关联。

客户端到首个可见 Token 的时间（TTFT）包含它之间经过的等待。若推理服务的指标显示自己的请求队列耗时，可以用它解释总等待的一部分；这段队列已经包含在客户端 TTFT 中，不能再加一遍。TTFT 很长并不能单独证明 Prefill 慢，网络、冷加载、限流或网关重试都可能造成类似现象。

自己管理的推理服务可能暴露队列、Prefill、Decode 和 Token 时间直方图；托管 API 未必开放内部跨度。看不到服务端指标时，把来源阶段记为“未观测”，不要通过客户端总耗时猜测供应商内部发生了什么。请求是否出现 429、是否在某一代理重试，以及服务端是否给了 request ID，往往比一个推测出来的原因有用。

按最早出现的异常来分流

先比较请求发出、服务收到、首字节、首 Token、界面显示和完成之间的时间，再看错误与请求形状。下面的模式给出下一步测量方向，而不是诊断结论：

观察到的模式	优先核对	仍需排除
用户点击到请求发出已很久	客户端任务队列、并发限制、上传准备	浏览器主线程阻塞、前端重试
请求已发出，但网关很晚才转发	网关排队、连接池、限流和重试记录	DNS、TLS 或跨区网络
服务收到后到首 Token 变长，随后输出节奏正常	已暴露的模型队列、冷启动、输入长度与 Prefill 指标	服务端排队是否已包含在所测 TTFT 中
首 Token 正常，输出中多次停顿	流事件时间戳、输出长度、服务调度与工具交接	代理是否只在特定分块后冲刷
模型端已发出内容，浏览器却很晚才呈现	代理缓冲、应用事件解析、主线程与渲染	记录的是首字节还是首个可见字符
模型响应及时，但任务完成很慢	工具调用、重试次数、顺序依赖和后处理	工具等待能否与模型时间重叠

先找时间线上最早违反目标的边界，再在这一层增加区分原因的测量。分布也应按模型版本、输入长度、流式开关、地区、工具路径和缓存情况切片；把完全不同的请求混成一个 P95，会掩盖长输入或某一个区域的问题。一次请求可以解释故障路径，但不能证明某配置的容量表现。

案例一：短问题等了很久，回答却很快

内部商品助手对一个短问题要了很长时间才开始显示，之后几秒便完成。轨迹显示客户端很快发出请求，模型服务隔了一段时间才开始处理；这一轮恰逢实例冷启动，服务端同时出现加载活动。复核者能直接确认的只有“接收至首 Token 延长且发生加载”，不能仅凭它声称所有慢请求都由冷启动造成。

下一步把同一脱敏输入分别在实例首次请求与预热后各运行数次，同时记录服务状态与相同的时间点。如果只有首次请求显著延长，就为冷启动单独设产品预期或调整预热；若两种情况都慢，再查看队列与输入长度。这个诊断不需要先增加 GPU，也不把试验结果外推成服务容量。

案例二：推理端持续输出，用户却只能看到整段文本

客服摘要服务在本地记录中有连续的流式事件，但浏览器的首个可见内容总在响应末尾才出现。客户端抓取表明事件已到达应用服务器，反向代理却把响应缓冲到连接结束才转发。此时模型生成速度不是用户等待的主要原因；修改 Prompt 或量化模型不会消除代理的缓冲策略。

团队针对测试端点调整流式转发，并检查首事件确实及时抵达浏览器、页面逐段绘制且取消操作有效。再用慢网络和长回答复测，以免只验证了本机环境。若没有服务器至代理、代理至浏览器的事件时间戳，应先补这条证据链，不能仅根据最终输出推定代理故障。

先选择能证伪猜测的测量

针对观察到的第一处延迟，设计一项小对照：同一请求在冷／热服务、短／长输入、带／不带工具、直连／经过代理时各表现如何？一次只改变一项条件，保留模型版本、内容长度和采样配置。流式与非流式请求应分别比较，因为两者的“开始响应”对用户意味着不同事件。

具体改动也要有回退与重测条件。增加预热会增加常驻资源；关闭代理缓冲可能改变连接占用；把长请求拆分可能损失跨段上下文。比较改动前后相同路径的端到端用户等待、错误和任务质量，不要只挑某一个内部计时器来宣布问题已解决。

常见问题

用户看见的首字延迟就是模型 TTFT 吗？

不是。模型服务 TTFT、客户端收到首字节、客户端收到首段文字和界面首次绘制是不同事件。先在各层记录时间戳，再注明产品采用的服务目标是哪一个。

只要首 Token 快，整体体验就好吗？

不一定。答案可能很长，流式途中可能停顿，工具可能拖慢任务，界面也可能晚渲染。把首段出现、流式间隔、端到端完成和业务验收分别监测。

不适用边界

部分托管模型服务不会公开内部队列或 Prefill／Decode 计时，因此只能判断哪些阶段尚未观测，不能把黑盒总时延归因给某个内部组件。单次轨迹用于定位下一次测量，不替代并发容量测试、尾延迟 SLO、长期趋势分析或安全审查；跨机器比较前还要核实计时口径与时钟关系。