LLM 与语音模型推理服务：队列、流式与可观测性

Posted on

推理服务的性能问题，很多时候不在单次 GPU forward，而在排队、预处理、batch 调度、流式输出、取消机制和可观测性之间。模型越大，单次推理越重要；系统越复杂，队列和状态越容易成为真正瓶颈。

vLLM、SGLang、Triton Inference Server、TensorRT-LLM 等开源生态，提供的是不同层级的解法。选型前要先拆清楚瓶颈在哪里。

不要只看端到端耗时

端到端耗时是结果，不是诊断。一个请求慢，可能慢在：

  • 等待队列；
  • tokenizer 或 audio frontend；
  • prefill；
  • decode；
  • 网络传输；
  • 后处理；
  • 流式 flush；
  • 取消请求没有及时生效。

如果日志只记录总耗时，系统调优会很盲。至少要把 request queue time、prefill time、decode time、first token latency、p95/p99 latency 和 GPU utilization 分开。

vLLM 适合什么

vLLM 的重点是高吞吐 LLM serving，PagedAttention 和 continuous batching 是它的核心优势。它适合请求量较高、输入输出长度差异明显、需要动态 batch 的场景。

但 vLLM 不是所有问题的答案。若瓶颈在音频预处理、外部工具调用、复杂后处理或流式状态管理，仅替换引擎未必能带来明显收益。

SGLang 的位置

SGLang 更强调结构化生成和运行时控制。它适合把 prompt、约束解码、工具调用、并行分支和缓存复用组织成更可控的程序。

如果系统需要复杂推理流程，SGLang 这类运行时可以减少手写 glue code。但它也要求把生成过程抽象得更清晰，否则只是把复杂度换了位置。

Triton 与底层引擎

Triton 更像通用推理编排层，适合把预处理、模型、后处理拆成可观测组件。TensorRT-LLM 更偏底层引擎优化，依赖硬件、版本和模型结构匹配。

它们更适合明确瓶颈已经在底层执行路径的场景。如果请求排队、数据转换和状态管理没有先量化，过早下沉到引擎优化很容易浪费时间。

语音模型的额外变量

语音模型比纯文本 LLM 多几类状态：

  • 音频 chunk 边界；
  • 重叠窗口；
  • frontend 缓存；
  • partial hypothesis；
  • 长音频切分；
  • 实时输入的取消和刷新。

这些状态如果没有清晰生命周期，会造成内存泄漏、延迟抖动或输出污染。流式服务不是把接口改成 SSE 就结束了，核心是状态如何创建、复用、取消和回收。

基准测试怎么做

建议至少准备三组基准：

  1. 单请求基准：观察模型和预处理的最低延迟；
  2. 并发基准：观察队列、batch 和 p99；
  3. 长运行基准：观察内存、句柄、缓存和错误恢复。

语音任务还要加入短音频、长音频、静音、噪声和连续 chunk。只测理想样本会低估线上复杂度。

小结

推理服务的关键不是“哪个框架最快”，而是哪一层正在限制系统。先把队列、预处理、prefill、decode、流式输出和取消行为拆开观测，再决定是换 serving runtime、加调度层，还是优化数据路径。

Request trace schema

Serving logs should carry a trace id across client, gateway, frontend, model runtime, and streaming output. A minimal trace separates client send time, server receive time, queue time, preprocessing, prefill, decode, postprocessing, first-token latency, final-token latency, and client receive time.

For speech and multimodal workloads, the trace also needs feature length, chunk count, cache reuse, cancellation state, and output flush timing. Otherwise p99 latency is visible, but not explainable.