AI 应用响应慢分层排查方法核心思路遵循「由外到内、自上而下、分层解耦、先易后难」的排查原则基于全链路 Span 埋点Langfuse精准拆解各环节耗时占比先排除外围共性问题再定位 AI 特有瓶颈避免一上来就优化大模型结果问题出在网络、数据库等外围环节。核心前提严格按照之前的规范做全节点 Span 埋点每个环节独立记录耗时是快速定位的基础。Langfuse 可直接输出各环节耗时占比无需盲目排查。一、全链路六层拆解与排查方法按请求流转顺序从用户端到模型算力共分为 6 层每层对应独立的瓶颈点、关键指标、验证方法。第一层端侧与网络接入层常见瓶颈用户本地网络差、跨运营商/跨地域延迟CDN 回源慢、静态资源阻塞端侧流式解析、渲染卡顿关键指标DNS 解析时间、TCP 连接时间、SSL 握手时间首包时间TTFB、端侧总耗时排查方法浏览器 F12 → Network 面板查看请求 Timing 拆分对比不同地域、不同网络环境的延迟差异同机房内直连后端接口做基准对比典型特征不同用户延迟差异极大同机房内调用延迟恢复正常所有接口非仅 AI 接口都存在延迟偏高第二层网关与接入层常见瓶颈网关转发性能差、协议转换开销大鉴权/验签逻辑复杂、远程调用鉴权服务限流排队、请求积压同步日志打印、全链路埋点阻塞关键指标网关处理耗时、鉴权耗时、排队时长网关错误率、限流触发次数排查方法网关监控看板查看各阶段耗时占比跳过网关内网直连后端服务接口对比延迟检查限流队列长度、并发连接数典型特征所有经过网关的接口都慢直连服务恢复正常高峰时段延迟明显飙升低峰时段恢复正常第三层业务应用服务层常见瓶颈业务逻辑复杂、串行循环处理关系型数据库慢查询、无索引、关联查询多缓存失效、缓存击穿多个外部依赖串行调用返回数据组装、格式转换耗时关键指标业务逻辑耗时、数据库查询耗时、外部依赖耗时接口 P50/P90/P99 延迟排查方法APM 工具SkyWalking、Pinpoint 等拆解方法级耗时数据库慢查询日志定位慢 SQLMock 掉外部依赖与数据库测试纯业务框架耗时典型特征非 AI 业务逻辑耗时占全链路 50% 以上普通业务接口也慢不只是 AI 接口第四层AI 编排层RAG/Agent 核心链路【AI 应用特有重点层】这是 AI 应用最容易出现瓶颈的层级也是最容易被误判为「模型慢」的层级。必须拆分子环节逐个定位Langfuse 全节点 Span 埋点可直接输出各环节耗时占比。标准子环节拆解与之前的埋点规范完全对应基础 RAG 链路查询改写 → 混合检索 → 重排序 → 上下文拼装 → LLM 生成 → 结果后处理Agent 场景额外增加任务规划 → 工具调用 → 结果解析 → 反思迭代各子环节常见瓶颈与验证子环节常见瓶颈点正常耗时占比验证方法查询改写/意图识别串行调用 LLM 改写、多轮意图推理通常 10%超过则异常跳过改写直接用原始查询检索对比耗时变化混合检索向量库查询慢、多路检索串行、关键词检索慢、过滤条件复杂15%~30%超过 35% 为检索瓶颈固定返回模拟上下文跳过检索看总耗时下降幅度重排序Reranker候选集过大Top50、Reranker 模型推理慢、串行重排10%~20%超过 25% 为重排瓶颈关闭 Reranker直接用粗召回结果生成对比耗时与效果上下文拼装长上下文截断处理、模板渲染、片段排序去重通常 5%固定拼装好的 Prompt 直接调用模型对比耗时工具调用Agent多工具串行调用、单个工具响应慢、重试等待工具越多耗时越高串行线性增长改为并行调用、Mock 工具返回对比耗时反思迭代循环多轮自我修正、多次调用 LLM、循环无收敛循环次数越多越慢关闭反思直接输出结果对比耗时排查核心方法直接查看Langfuse Trace 各 Span 的 duration 占比哪个环节占比最高优先排查哪个。典型误区80% 的「响应慢」问题都出在这一层的检索、重排、工具串行而非大模型本身。第五层模型推理层LLM / Embedding / Reranker三类模型的瓶颈点模型类型常见瓶颈关键指标Embedding 模型并发高排队、批量处理未开启、向量生成慢单条向量生成耗时、排队时长Reranker 模型跨编码器推理本身慢、候选集过大、并发不足单句对推理耗时、吞吐量生成大模型首 Token 延迟TTFT高、Token 生成速度TPS低、并发排队、长上下文推理慢TTFT、TPS、排队时长、推理耗时生成模型两大延迟类型区分首 Token 慢TTFT 高常见原因请求排队、上下文预处理慢、模型推理启动慢、路由转发慢现象流式输出半天不出第一个字出来之后速度正常生成速度慢TPS 低常见原因算力不足、输出 Token 太长、长上下文衰减、采样参数复杂现象第一个字出来很快但逐字输出速度很慢排查方法模型服务监控看板查看排队长度、GPU 利用率、TPS、TTFT直接调用模型原生接口跳过所有业务逻辑测试裸模型基准速度用极短 Prompt 短输出测试对比长上下文、长输出的延迟典型特征简单短请求也慢 → 大概率是排队、算力、路由问题短请求快、长请求慢 → 上下文长度、输出长度瓶颈高峰慢、低峰快 → 并发不足、排队瓶颈第六层基础设施与依赖层常见瓶颈向量库索引过大、未优化、内存不足、查询 IO 高数据库连接池满、锁等待、磁盘 IO 慢服务器CPU/内存跑满、带宽不足、磁盘 IO 瓶颈中间件消息队列积压、缓存命中率低关键指标CPU/内存/GPU 利用率、磁盘 IO、网络带宽向量库查询 P99 延迟、数据库慢查询占比排查方法基础设施监控看板查看资源水位扩容资源后对比延迟变化单独压测依赖组件向量库、数据库的基准性能二、标准排查流程从快到慢效率最高第一步看全链路耗时分布1 分钟定位打开 Langfuse → 找到慢请求 Trace → 查看各 Span 耗时占比 → 直接定位占比最高的层级这是最高效的方法前提是按规范做了全节点 Span 埋点无需任何额外排查。第二步排除外围共性问题先测内网直连服务接口排除网络、网关问题查看普通业务接口是否也慢排除业务层共性问题第三步拆分 AI 编排层查看检索、重排、生成各占多少比例逐个 Mock 验证跳过检索、跳过重排、跳过工具调用定位具体环节第四步定位模型层问题区分是首 Token 慢还是生成速度慢测试裸模型基准速度排除上层业务开销检查是否有排队、算力不足第五步检查基础设施检查资源利用率、依赖组件性能确认是否硬件、中间件瓶颈三、常见瓶颈典型画像与快速判断现象大概率瓶颈层优先排查点不同用户延迟差异极大同机房正常端侧/网络层用户网络、跨地域所有接口都慢直连服务正常网关层鉴权、限流、转发性能普通接口也慢数据库耗时高业务应用层慢 SQL、业务逻辑半天不出第一个字出来后速度正常检索/重排/首Token检索耗时、重排耗时、模型排队第一个字很快输出很慢生成模型层TPS、算力、输出长度工具越多越慢线性增长Agent 编排层工具串行调用高峰延迟飙升低峰正常并发/算力层限流、排队、算力不足知识库越大越慢检索层向量库索引、检索性能四、核心避坑❌ 一慢就怪大模型80% 的场景问题出在检索、重排、业务逻辑、网络而非模型本身❌ 不埋点瞎排查没有全节点 Span 埋点只能靠猜效率极低❌ 只看总耗时不拆分不区分首 Token 和生成速度定位不到根因❌ 只测单并发不测压测很多瓶颈只在高并发下出现单并发无法复现