LLM 与语音模型推理服务：先把延迟拆成可观测链路

Posted on Edited on

推理服务的问题经常被简化成“换更快的框架”。vLLM、SGLang、Triton 都很重要，但如果系统不能解释一次请求的延迟来自排队、预填充、解码、音频前端、网络还是后处理，换框架只是碰运气。

语音和 LLM 结合后，延迟问题更复杂：音频切片、流式 partial、模型队列、token 生成和系统超时会叠在一起。

要解决的问题

线上推理关注的不是平均速度，而是尾延迟和稳定性。一个服务平均很快，但 p99 经常超时，用户体验仍然不可接受。

语音模型还多了几个阶段：音频读取、重采样、特征提取、chunk 组织、ASR 或 speech encoder 推理、LLM 解码、流式输出。任何一层都可能放大延迟。

主线判断

推理服务选型之前，必须先把延迟拆成可观测链路。

vLLM、SGLang、Triton 只能优化它们覆盖的那一段。若 p99 来自排队、预处理、音频编码、tokenizer、后处理或下游消费，替换解码框架并不会解决问题。先定位瓶颈，再谈框架。

最小抽象

可以把请求生命周期拆成：

1
2
3
4
5
6
7
ingress
  -> queue
  -> preprocess
  -> prefill / encode
  -> decode / stream
  -> postprocess
  -> response

vLLM 和 SGLang 主要优化 LLM serving 的调度、KV cache、batch 和解码吞吐；Triton 更适合做模型服务编排和算子级部署。它们解决的是不同层次的问题，不能用单一 benchmark 直接替代系统观测。

工程闭环

服务必须记录分阶段指标：

  • queue wait；
  • preprocess time；
  • prefill 或 encoder time；
  • first token / first partial latency；
  • tokens per second；
  • p50 / p95 / p99；
  • timeout reason；
  • batch size、dtype、KV cache 命中情况。

对流式语音系统，还要单独看 partial 的稳定性：早出结果是否经常回滚，回滚是否影响下游，semantic end 或 turn-taking 判断是否被延迟拖垮。

没有这些指标，优化就会变成只看 GPU 利用率。GPU 忙不代表服务健康，GPU 不忙也可能是队列、网络或调度策略出了问题。

反直觉点

GPU 利用率高不一定代表服务健康。它可能说明 batch 足够大，也可能说明请求在队列里等太久。GPU 利用率低也不一定代表模型快，可能是 CPU 前处理、线程锁、网络或调度策略把请求挡在模型外。

吞吐优化和交互优化经常冲突。离线批处理希望合更大的 batch，实时语音更关心 first partial、first token 和取消响应速度。把两类请求放进同一套队列策略，很容易让吞吐变好、体验变差。

全局 timeout 也不够。一个请求超时，必须知道它死在 queue、preprocess、encode、prefill、decode 还是 postprocess。否则告警只能说“慢了”，不能指导修复。

可观测闭环

每个 request id 都要贯穿 ingress、queue、preprocess、encode、first partial、first token、decode、postprocess 和 response。日志至少保留输入长度、音频时长、batch size、输出 token 数、取消原因和 timeout reason。

面板先做三张就够。第一张是端到端延迟分解；第二张按音频时长、文本长度、batch 和输出 token 分桶看 p95/p99；第三张按失败原因分桶。三张面板能回答大部分早期问题：请求太长、队列太深、编码慢、解码慢、后处理慢，还是预算配置不合理。

排障路径

若 queue wait 高，先查并发、限流和调度策略。若 first token 慢但后续 token 快，查 prefill、编码和输入长度。若 first token 快但总耗时长，查 decode 吞吐和下游消费。若只有 p99 变差，查长输入、异常重试、锁竞争和资源抖动。

只有这些归因跑通以后，vLLM、SGLang、Triton 的比较才有意义。否则框架选择会变成单次 demo 的主观印象。

小样本推演

假设线上 p99 突然变差，但平均延迟几乎不变。若没有链路分解，最容易误判成模型变慢。真正的原因可能是长音频比例上升、某个 CPU 后处理线程阻塞、队列合批策略等待过久，或者下游消费速度下降。

request id 贯穿全链路后，排查会变成一个很具体的问题：慢请求是否集中在长输入，是否 queue wait 高，是否 first token 高，是否 decode tokens per second 下降，是否 postprocess 异常重试。只有能回答这些问题，框架替换才是有依据的优化，而不是重新抽签。

直接结论

推理框架选型前，先把延迟链路拆开并落日志。vLLM、SGLang、Triton 都可以进入候选，但判断依据应该是分阶段延迟、吞吐、p99、资源利用和失败原因，而不是单次 demo 的响应速度。

下一步阅读：音频模型 Batch 一致性排查：从有效输入区间到逐层 diff