一、项目背景

我们部署的客服大模型，平时响应挺稳，偶尔会抽风式变慢，前端转圈转到用户骂街。出问题那几次，我们从网关、路由、检索到推理挨个问，谁都说自己没问题。最后只能靠猜，猜完改完也不确定是不是真因，因为没人能说清一条慢请求到底卡在哪一段。这种"慢得不明不白"的状态持续了小一个月，直到一次大促超时把投诉量顶上去，我们才下定决心把链路透明化。

这类问题的本质是大模型应用链路长，一个请求要过网关鉴权、路由决策、向量检索、提示词拼装、模型推理、后处理好几段，任何一段抖动都会被放大成用户感知的慢。没有端到端的可观测，定位全靠经验和个人英雄主义。

二、落地场景

我们在整条链路统一埋了 trace。每个请求进来分配一个 trace_id，网关、路由、检索、推理各段在入口出口打点，记录分段耗时。慢请求（超过动态阈值的）被自动采样，把这一次请求的完整分段计时聚合成一张火焰图，哪一段占的高一眼看出来。

定位到瓶颈后，运维可以回放这条 trace，看是检索段某次向量库查询慢，还是推理段排队等待长。火焰图按服务维度聚合，能看出是偶发单点还是某类请求普遍慢。告警按分段 P99 配置，哪段超了推到对应负责人，而不是笼统的"服务慢了"。

三、关键技术挑战与解决思路

跨进程 trace 串联是第一道关。我们的网关、路由、推理是独立服务，trace 上下文靠请求头透传，早期漏传了检索段，导致火焰图里检索永远是零耗时，反而显得推理段特别慢，误导了我们整整两周。补齐透传后才看到真相。

分段计时精度也有讲究。推理段内部有排队、预填充、解码多个子阶段，只记首尾会掩盖内部排队。我们把推理段再拆细，才定位到慢请求主要是排队等 GPU 而非解码慢。

慢请求采样不能全采，成本扛不住，也不能只采报错，因为很多慢请求没报错只是慢。我们按耗时分位数动态采样，只对超过 P95 的请求抓完整火焰图，量可控又能覆盖问题。

告警设计也花了心思。我们不是对整体延迟告警，而是按分段设独立阈值，检索段超了推给检索负责人，推理段超了推给推理团队，谁家孩子谁抱走，避免一群人围着一条笼统的慢了告警互相看。回放能力也得跟上，定位到瓶颈后能拉出那条 trace 逐步看，而不是只相信聚合数字。我们复盘了几次误判，都是因为只看聚合没回放，被平均掩盖了长尾，后来强制要求长尾类问题必须回放确认。

定位能力之外，我们还沉淀了一份常见瓶颈手册，把火焰图里高频出现的形态分类，比如长尾集中在检索段多半是分片不均，集中在推理排队多半是并发打满。新人排障照手册对，不用每次从头分析。这东西看着朴素，却把平均排障时间又压了一截，也比依赖个别老手靠谱。

可视化的另一面是把火焰图做成可分享。定位出瓶颈后，运维一键把这条 trace 的火焰图发给对应负责人，对方不用登我们的平台就能看，沟通成本降了一截。我们之前靠截图加口述，对方还得问上下文，现在图一发，谁卡了谁认领。这种把诊断结果变成可流转资产的做法，比堆监控面板实用，排障协作顺多了。

长期看，我们把火焰图数据也喂回了容量规划。哪段长期偏高，就针对性扩那段的资源，而不是整体堆机器。这比凭经验加卡精准，几轮下来推理集群整体成本反而降了，因为钱花在了真正瓶颈的地方。

案例片段（已脱敏）： 一次 P99 从 1.2 秒涨到 4.8 秒的告警。火焰图显示推理段仅占 0.9 秒，检索段高达 3.1 秒。下钻检索段 trace，发现某次批量向量查询因索引热点分片未均衡，单分片耗时 2.7 秒。修复分片均衡配置后，检索段回落至 0.4 秒，整体 P99 恢复 1.3 秒。全程定位耗时从原来平均约 3 小时降至约 12 分钟。

四、效果数据

慢请求定位时效从原来平均约 3 小时（靠人肉挨个问）降到约 15 分钟。整体 P99 延迟在透明化后通过几轮针对性优化下降约 35%。归因准确率（定位出的瓶颈段与实际根因一致的比例）我们内部抽检验证约 92%，误判率明显下降。

最值钱的是排障从救火变常态。现在每周看火焰图聚合，能提前发现某段在缓慢劣化，而不是等用户投诉。

五、可复用经验总结

大模型应用慢，千万别靠猜，链路不透明时所有人都在甩锅。端到端 trace 加上慢请求火焰图，是这类排障的标配，但埋点必须覆盖全段，我们漏了检索段，硬是把模型背了两周黑锅，其实根因在向量库。分段要拆细到能定位子阶段，只记首尾会漏掉内部排队。采样策略也要想清楚，全采烧钱、只采报错漏问题，按分位数动态采最划算。可观测不是上线后补的装饰，是架构一开始就该留的命门。