做语音输入产品时最难排查的一类问题不是“彻底坏掉”而是同一套模型有时几秒返回有时突然要等二十多秒。这周 InkTyper 就遇到了这个问题。最初我的直觉是模型变慢了是不是 SenseVoice 推理波动、GPU 被其他任务占用或者长音频拖慢了计算但把整条链路拆开计时后结果完全不同。真正需要治理的不是模型而是网络传输。一、先看异常数据切换统一算力网关前请求的上游延迟是• P501.93 秒• P956.36 秒切换后变成• P505.82 秒• P9524.75 秒• 超过 5 秒的请求占比从 7.1% 上升到 60%如果只看用户体感很容易得出“模型忽快忽慢”的结论。但模型侧的计时并不支持这个判断。在一段 37—73 秒的录音中• GPU 推理耗时约 0.44—0.58 秒• 网关内部处理约 0.8—1.2 秒• 额外多出的 14—28 秒发生在 Worker 到推理网关之间的网络传输也就是说端到端等待二十多秒时GPU 仍然只工作了不到一秒。二、为什么一开始会误判模型当日志里只有一个 total_ms上传、队列、网关、网络传输和模型推理全部混在一起。用户看到的是总等待时间工程师第一眼看到的也只是一个大数字。这时模型通常最先被怀疑因为它是链路里最显眼、也最容易被归因的部分。但如果没有分段计时所谓“模型性能下降”往往只是猜测。这次回看部署变化后我们定位到一个关键差异接入统一算力网关的同时启用了 QUIC Tunnel。它在当前网络环境和音频上传场景下产生了明显长尾导致 Worker 到推理网关之间的传输时间被拉长。三、我们做了哪些调整第一Tunnel 从 QUIC 回退到 HTTP/2但保留统一算力网关。第二在日志中增加 gateway_ms 和 transport_ms把网关、网络传输和模型耗时彻底拆开。以后再遇到长尾可以先判断究竟该优化模型还是该治理网络。第三客户端改用低码率 Opus。按当前音频特征估算上传体积可以缩小约 5—8 倍从源头降低网络波动对等待时间的放大。第四后续每次至少观察 30 条真实请求同时看 P50、P95 和超过阈值的请求占比而不是只凭一次“感觉变快”判断修复效果。四、这次排障最重要的结论端到端时间不等于模型推理时间。一个语音 AI 产品的实际等待时间至少包含录音处理、上传、网络传输、网关、排队、模型推理和结果回传。任何一段都可能制造长尾。如果日志只有一个总耗时问题出现后只能靠猜。把链路逐段计时才能知道应该优化模型、压缩音频、调整网关还是更换传输路径。如果你也在排查语音识别或其他在线推理服务可以先按下面的顺序检查1. 同时记录客户端总耗时与服务端总耗时先判断问题发生在客户端、服务端还是两者之间。2. 把上传、网关、排队、推理和回传分别计时不要让一个 total_ms 承担所有诊断工作。3. 除了平均值至少观察 P50、P95 和超时请求占比。平均值很容易掩盖少量但严重影响体验的长尾。4. 对照最近的部署变化尤其检查隧道协议、网关、跨区域路由和音频编码方式。5. 修复后用一批真实请求复测不用单次成功代替稳定性结论。这个顺序的价值在于先划分故障域再进入具体组件。否则团队很容易在 GPU、模型参数或并发配置上反复调试却没有触碰真正的瓶颈。InkTyper 还在持续打磨。相比只展示一次漂亮的 Demo我更愿意把真实的部署问题、误判过程和性能复盘记录下来AI 产品真正难的往往是让它在不同设备和网络环境下长期稳定地工作。