11. 语音与多模态推理
本篇导读
前面一直是打字提问。现在小林对麦克风说“年假怎么申请？”，希望听到回答。本篇先沿着这段声音走一遍，再判断哪些环节能借用 LLM 引擎，哪些需要专门的语音运行时。读完应能分清首字、首 token 和首个可播放音频。
同一个问题，多了哪些接力
小林的声音先变成文字，资料助手生成回复，再把回复变成声音。可以把它想成“听写员 → 资料答疑员 → 播音员”的接力：中间的人写得再快，也不能消除听写员判断是否说完、播音员准备开口的等待。实际系统可让几段工作重叠，图中还画出了用户打断时的控制路径。
语音推理适用缓存、批处理、量化和调度这些思想，但不一定能直接用 vLLM 或 SGLang 执行整条链路。 要先看模型怎样计算，再看引擎是否实现了它的输入、状态、输出与流式协议。“能输入音频”“能流式转写”“能实时生成音频”是三种不同能力。
进一步区分：不同 ASR / TTS 架构能迁移哪些优化？
| 语音路线 | 核心计算 | 可迁移的优化 | 需要专门处理的部分 |
|---|---|---|---|
| CTC ASR | 声学编码器输出帧级分布，再折叠或搜索 | 算子、量化、声学 batch、长度分桶 | 特征帧、流式状态、CTC 解码与热词 |
| Transducer ASR | encoder、prediction network、joint 协作 | 编码器优化、搜索批处理、状态池 | blank、对齐、beam、跨块状态 |
| Encoder-decoder ASR | 音频编码，再自回归生成文本 | decoder KV、批处理、attention 优化 | encoder 状态、cross-attention、长音频分段 |
| LLM 型 ASR | 音频编码与投影，语言模型生成文本 | 受支持路径上的 KV、连续 batch、量化 | 音频编码、模态位置、输入处理与端点 |
| 时长/声学模型加声码器 TTS | 文本到声学特征，再转波形 | batch、编译、算子与精度优化 | 时长、音素、声学帧、声码器分块 |
| 自回归音频 token TTS | 逐步生成语义或 codec token | 可能使用 KV、调度、推测 | 多码本、采样、codec 解码与音频拼接 |
| 扩散 / flow TTS | 多步去噪或积分生成声学表示 | 编译、融合、batch、减少求解步骤 | 质量与步数关系、条件编码和声码器 |
| 端到端语音模型 | 音频输入输出，可能交错文本与音频 | 引擎已适配部分的调度与缓存 | 全双工、音频时钟、打断、回声和多流状态 |
Whisper 类架构含自回归 decoder，但不等于普通纯文本 decoder-only 模型。Flow 或扩散模型的“步数”，也不是 LLM 的输出 token 数。每个路线都应使用与自身结构匹配的优化和质量指标。
语音为什么还有等待
一段离线音频可以一次送入模型；实时麦克风只能不断收到未来的声音。系统可能要攒够一个声学块，保留右侧上下文，等待 VAD 判断结束，再修正和提交文本。
对话里“用户已经说完”与“系统确认说完”存在时间差。把断句等待从 500 ms 降到 200 ms，可能比语言模型快几个 token 更影响体验；但过短会在自然停顿处截断句子，损害识别与交互。
ASR 主体通常可以在用户说话时运行；用户停止后，关键路径更接近“端点等待 + ASR 收尾 + 首段回复文本 + TTS 首块 + 播放开销”，而不是把整段 ASR 运行时间再加一遍。
首音频时延预算从用户实际停止说话起算
断句等待
300 ms
累计排队
50 ms
ASR 收尾
150 ms
首段可合成文本
250 ms
TTS 首个可播放块
180 ms
首个可播放音频约 930 ms
串行关键路径估算，未计网络、播放缓冲、回声消除与设备开销；ASR 主体假设已在说话时运行，只计收尾。分块模式仍须攒够可合成文本，后续音频也须及时续上。这里不估计整段对话完成时间。
先降低 LLM 时间，再降低断句等待，观察总预算的变化。切换到等待完整文本和音频，会把两段额外等待带回首音频路径。真实系统可能重叠更多阶段，也可能因网络、语音质量或播放缓冲增加成本，因此要用 trace 校准每项。
文本流式不等于音频流式
ASR 可以逐步返回临时文本，但最终结果可能修订；协议需要区分 partial 与 final。TTS 接口即使通过流传输，也可能先算完全部音频再切块返回；这种传输流式并不意味着模型首音频计算已经缩短。
真正的增量 TTS 还要考虑输入文本块是否足以确定发音和韵律。文本太短可能造成停顿、重音或语调不自然；等待整句又增加首音频。LLM 的 token 边界也不一定是适合合成的词句边界。
首块很快只是开始。后续块若不能赶上播放时钟，就会断音。需要同时观察音频 chunk 的到达间隔、可播放时长和缓冲水位。
语音的性能指标
| 指标 | 解释 | 需要防止的误读 |
|---|---|---|
| RTF | 处理墙钟时间 / 音频时长 | 30 秒音频耗时 3 秒，RTF=0.1；不代表实时对话只有 0.1 秒等待 |
| 首字/首个 partial | 从约定起点到首次文本 | 起点是音频首帧、用户停说还是请求发出，结论不同 |
| Final 时延 | 用户实际结束到稳定最终结果 | 含端点与收尾，不能只测模型 forward |
| 首音频时延 | 到首个可播放音频 | HTTP 首字节可能是头信息或不足以播放的数据 |
| 音频续流 | 块间隔、缓冲和欠载 | 平均生成速度快仍可能偶发长停顿 |
| 质量 | WER/CER、说话人、音质、自然度等 | 不同任务需要不同评估，不能只测吞吐 |
例如 10 路音频的批量离线 RTF 很低，可能来自充分聚批。在线只有一小块音频到达时，等待凑 batch 会损伤延迟；要把 batch 大小和最大等待时间一起调。
取消、打断和会话状态
用户说“停一下”时，需要终止或失效化旧 LLM 请求、TTS 合成、待播放音频，并清理会话引用。已经发出的音频不能靠取消 GPU 任务撤回，播放器也要有清空队列的协议。
底层原生推理未必能立即中断，超时后仍可能继续使用缓冲。应用应区分“用户不再等待”与“底层资源已释放”，避免重复提交同一任务或过早复用内存。具体实践见推理输入合同与资源生命周期。
什么时候选择哪条部署路线
如果模型是引擎明确适配的音频输入或输出生成模型，可以评估 vLLM、SGLang 及其相关多模态扩展，但要单测流式、采样、codec 和并发状态。仅支持文本部分，不能推断整条语音链路都受加速。
传统 ASR/TTS 或端侧 SDK，通常应从模型官方运行时、ONNX Runtime、TensorRT、OpenVINO、Core ML、ExecuTorch 等匹配目标设备的路线评估。服务器上的声学模型可能与 LLM 引擎并列运行，通过业务层连接。
图像与视频同理：视觉 encoder、预处理、多模态 token 展开和解码各有成本。图像数量、分辨率、视频帧数和音频长度可能让“相同文本 token 数”的请求完全不是同一种负载。
判断练习：ASR 的 final 慢 800 ms，换 vLLM 能直接解决吗？
先拆出 VAD 端点等待、声学收尾、decoder、搜索和队列。如果 600 ms 来自确认用户说完，替换 decoder 引擎未必有效。如果模型受支持且 decoder 是主要瓶颈，才有明确的评估方向。还要保持识别质量和切句完整度。
本篇回顾
- 语音助手包含听、答、说、播放几段工作；加速语言模型只改变其中一段。
- 能否用 vLLM / SGLang，取决于具体模型与流式路径的适配；传统声学模型也有自己的优化路线。
- 实时体验同时取决于端点等待、首音频、续流和打断，不能只看 tokens/s 或离线 RTF。
任务、设备和模型已经明确，怎样缩小框架候选范围？ 下一篇做框架选型与版本对比。