LLM 响应慢先查哪里从检索到流式输出的延迟排障用户点击发送十一秒后才看见答案。监控上只有一条request_duration它说明体验慢却没有告诉我们应该换模型、增加副本、减少检索片段还是检查代理缓冲。LLM 应用的延迟要沿请求路径拆开看。本文把原文的排障思路整理成测量口径、链路字段和实验步骤。所有示例数字都用于说明方法不是生产基准。1. 一次回答经过多个系统典型 RAG 请求会经过鉴权、查询向量化、检索、重排、提示词组装、模型服务、流式转发和前端渲染。用户体验到的是一个操作后端执行的却是一串工作。排障时先找到慢在哪个区间再决定检查哪个组件。数据库整体延迟正常不代表该请求使用的检索路径正常模型调用变慢也不能直接推断 GPU 算力不足。2. 先定义“首内容延迟”可以记录以下时间点应用收到请求t0检索开始与完成t1/t2发送模型请求t3收到第一个有效内容片段t4向客户端转发该片段t5转发结束t6。指标计算方式能回答什么应用首内容延迟t5 - t0后端多久开始向客户端提供答案模型调用首内容延迟t4 - t3模型请求多久返回首段内容检索耗时t2 - t1检索区间耗时转发等待t5 - t4后端收到内容后是否及时发出网络上的一个内容片段不一定等于一个模型 Token。若没有 Token 级数据应避免把流式分片间隔叫作逐 Token 延迟。前端若能埋点还可以测量用户提交到首次渲染的整体时间。不要直接相减不同机器未经校准的时间戳。单个进程内使用单调时钟测量持续时间跨服务关系交给分布式追踪表达。3. 把等待与执行分开模型调用的首段等待可能包含网络传输、请求准入、资源排队、提示词处理和初始输出。只有自己运营推理服务并且暴露了相关指标才有条件继续拆分。托管 API 若没有返回内部排队数据正确描述应是“模型调用首内容延迟增加内部排队和执行耗时未知”。不能只根据总等待就断言 Prefill 变慢。反过来如果后端很早收到内容浏览器却迟迟不显示应该继续检查 SSE 转发、代理缓冲、压缩和前端渲染而不是立刻更换模型。4. 用 Trace 连接一次请求建议从下面的 Span 结构起步POST /answer authenticate embed_query retrieve_documents rerank_documents construct_prompt generate_answer wait_for_first_content consume_response_stream上下文传播把服务之间的调用连接起来日志中的 Trace ID 和 Span ID 则帮助回到同一条执行路径。OpenTelemetry 上下文传播文档记录应用版本、模型标识、提示词版本、索引版本、输入输出长度和选入文档数。请求 ID 适合放在 Trace 或日志中不适合作为高基数监控指标的标签。原文中的属性名是建议字段不应误当成所有 SDK 都已实现的标准字段。团队应统一命名、单位及采集边界。5. 一个检索配置变更的排障例子观测项变更前变更后检索耗时180 ms190 ms选中文档518输入 Token240010800模型首内容等待650 ms2300 ms这些是原文的虚构示例。它们支持“上下文变大可能影响首内容等待”这一假设但还不能证明因果关系并发、缓存命中和请求类型也可能变化。下一步应固定问题集、模型、输出上限与负载条件对比旧检索策略和新策略同时记录答案质量。只把上下文缩短到很快却删掉回答需要的证据不算有效优化。6. 用假设表推动调查假设已有证据下一步验证上下文增大影响模型等待输入长度上升匹配负载比较新旧策略并发排队增加高并发时延迟更高查看服务侧准入与排队指标下游缓冲后端收得早客户端显示晚分段比较后端、代理和客户端时间调查中把观察、假设、缺失证据和验证动作分别记录。即便使用 LLM 辅助总结也要求它引用具体 Trace 和配置变更避免把相关性写成已经确认的根因。最后按模型、输入长度区间、输出长度区间、版本与区域比较 P50/P95 等分位数。总平均值混合了不同工作负载可能把流量结构变化误报为版本退化。 LLM 响应慢，先查哪里？从检索到流式输出的延迟排障
LLM 响应慢先查哪里从检索到流式输出的延迟排障用户点击发送十一秒后才看见答案。监控上只有一条request_duration它说明体验慢却没有告诉我们应该换模型、增加副本、减少检索片段还是检查代理缓冲。LLM 应用的延迟要沿请求路径拆开看。本文把原文的排障思路整理成测量口径、链路字段和实验步骤。所有示例数字都用于说明方法不是生产基准。1. 一次回答经过多个系统典型 RAG 请求会经过鉴权、查询向量化、检索、重排、提示词组装、模型服务、流式转发和前端渲染。用户体验到的是一个操作后端执行的却是一串工作。排障时先找到慢在哪个区间再决定检查哪个组件。数据库整体延迟正常不代表该请求使用的检索路径正常模型调用变慢也不能直接推断 GPU 算力不足。2. 先定义“首内容延迟”可以记录以下时间点应用收到请求t0检索开始与完成t1/t2发送模型请求t3收到第一个有效内容片段t4向客户端转发该片段t5转发结束t6。指标计算方式能回答什么应用首内容延迟t5 - t0后端多久开始向客户端提供答案模型调用首内容延迟t4 - t3模型请求多久返回首段内容检索耗时t2 - t1检索区间耗时转发等待t5 - t4后端收到内容后是否及时发出网络上的一个内容片段不一定等于一个模型 Token。若没有 Token 级数据应避免把流式分片间隔叫作逐 Token 延迟。前端若能埋点还可以测量用户提交到首次渲染的整体时间。不要直接相减不同机器未经校准的时间戳。单个进程内使用单调时钟测量持续时间跨服务关系交给分布式追踪表达。3. 把等待与执行分开模型调用的首段等待可能包含网络传输、请求准入、资源排队、提示词处理和初始输出。只有自己运营推理服务并且暴露了相关指标才有条件继续拆分。托管 API 若没有返回内部排队数据正确描述应是“模型调用首内容延迟增加内部排队和执行耗时未知”。不能只根据总等待就断言 Prefill 变慢。反过来如果后端很早收到内容浏览器却迟迟不显示应该继续检查 SSE 转发、代理缓冲、压缩和前端渲染而不是立刻更换模型。4. 用 Trace 连接一次请求建议从下面的 Span 结构起步POST /answer authenticate embed_query retrieve_documents rerank_documents construct_prompt generate_answer wait_for_first_content consume_response_stream上下文传播把服务之间的调用连接起来日志中的 Trace ID 和 Span ID 则帮助回到同一条执行路径。OpenTelemetry 上下文传播文档记录应用版本、模型标识、提示词版本、索引版本、输入输出长度和选入文档数。请求 ID 适合放在 Trace 或日志中不适合作为高基数监控指标的标签。原文中的属性名是建议字段不应误当成所有 SDK 都已实现的标准字段。团队应统一命名、单位及采集边界。5. 一个检索配置变更的排障例子观测项变更前变更后检索耗时180 ms190 ms选中文档518输入 Token240010800模型首内容等待650 ms2300 ms这些是原文的虚构示例。它们支持“上下文变大可能影响首内容等待”这一假设但还不能证明因果关系并发、缓存命中和请求类型也可能变化。下一步应固定问题集、模型、输出上限与负载条件对比旧检索策略和新策略同时记录答案质量。只把上下文缩短到很快却删掉回答需要的证据不算有效优化。6. 用假设表推动调查假设已有证据下一步验证上下文增大影响模型等待输入长度上升匹配负载比较新旧策略并发排队增加高并发时延迟更高查看服务侧准入与排队指标下游缓冲后端收得早客户端显示晚分段比较后端、代理和客户端时间调查中把观察、假设、缺失证据和验证动作分别记录。即便使用 LLM 辅助总结也要求它引用具体 Trace 和配置变更避免把相关性写成已经确认的根因。最后按模型、输入长度区间、输出长度区间、版本与区域比较 P50/P95 等分位数。总平均值混合了不同工作负载可能把流量结构变化误报为版本退化。