让语音助手边听边调用工具：推测执行如何缩短响应等待

导语

语音助手的迟缓，往往不只来自语音识别或大语言模型本身。对于天气、日程、搜索等需要外部工具的请求，传统级联流程通常是：先完成语音识别，再由模型判断意图并生成工具调用，工具返回结果后，模型才开始组织回答。只要这些环节依次等待，工具执行时间就会被完整叠加到用户说完话之后。

论文《Hiding Tool Latency in On-Device Cascaded Voice Agent through Speculative Execution》提出了一个直接的改进方向：在用户还没有说完时，就根据流式 ASR 的部分结果预测可能需要的工具，并提前启动执行。

核心方法

• 从部分识别结果预测工具请求：系统新增 Predictor 模块，持续观察语音识别过程中不断变化的中间文本，推测用户是否正在提出需要工具协助的请求。
• 提前执行并缓存结果：一旦预测出候选工具调用，系统便在后台执行，并把结果暂存。用户说完后，缓存内容可以直接注入发送给大语言模型的提示词，减少模型等待工具返回的时间。
• 处理自我修正：语音交互中，用户可能在一句话中改变地点、时间或其他参数。过早执行的请求因此可能失效。研究采用规则式验证机制，只将被判定为仍然有效的缓存结果交给模型。
• 保留串行流程作为兜底：如果提前预测失败、结果无效或根本没有可用缓存，大语言模型仍可像基线系统一样直接发起工具调用。因此，推测执行并不会强制系统使用错误的提前结果，其最坏情况下的延迟上界仍接近原有串行流程。

实测结果与意义

研究者在一套完整实现的 Android 语音助手上进行了实时测量。加入推测执行后，首次音频输出的中位时间从 5.79 秒降至 4.60 秒；标准差则从 3.49 秒降至 2.81 秒。换言之，收益不仅体现在典型响应更快，也体现在等待时间更加稳定、可预测。

这项工作的关键并非单纯压缩某个模型的推理时间，而是重新安排系统中可以重叠的工作。语音识别尚未结束时，工具请求预测和网络或本地工具执行已经开始，原本串行的等待被部分隐藏起来。对于端侧助手而言，这种思路尤其具有工程价值：它不依赖把所有模块替换成全双工模型，而是可以嵌入现有的 ASR、LLM 和工具编排架构。

当然，推测执行也带来预测错误、无效调用以及额外资源消耗等系统设计问题。规则验证和模型兜底降低了错误风险，但能否在更多工具、更复杂修正和不同设备条件下保持收益，还需要更广泛的评测。总体来看，这项研究说明，语音助手的低延迟不仅取决于模型有多快，也取决于系统是否能尽早开始那些确定性足够高的工作。

来源：Hugging Face Daily Papers