投机式 LLM 生成是一种技术：语音 Agent 在用户还在说完句子的过程中就开始准备回复，将回复隐藏起来，只有当用户最后说的话与回复所依据的内容一致时才播放出来。

在这篇博客中，我们将学习投机式 LLM 生成如何在用户还没说完话之前就开始回复。我们还将了解在普通语音 Agent 中等待时间都花在了哪里，Agent 如何根据目前已听到的词语做出早期猜测，当猜测正确或错误时会发生什么，它如何提前准备语音，它的成本是什么，以及何时使用它。

我们将涵盖以下内容：

  • 语音 Agent 回复的普通方式
  • 等待时间都花在了哪里
  • 什么是投机式 LLM 生成？
  • 投机式 LLM 生成如何一步步工作
  • 当猜测正确时会发生什么
  • 当猜测错误时会发生什么
  • Agent 如何知道词语发生了变化？
  • 提前准备语音
  • 投机式 LLM 生成的成本
  • 何时使用以及何时不使用

我是 Amit Shekhar，Outcome School 的创始人，我曾教导和指导过许多开发者，他们的努力让他们获得了高薪的技术工作，帮助许多科技公司解决了他们的独特问题，并创建了许多被顶级公司使用的开源库。我热衷于通过开源、博客和视频分享知识。

我在 Outcome School 教授 AI 和机器学习。

让我们开始吧。

语音 Agent 回复的普通方式

在深入探讨投机式 LLM 生成之前，我们必须了解普通语音 Agent 是如何回复的。

语音 Agent 是一个我们可以用语音与之交谈、它也用语音回应的系统。许多语音 Agent 以三个部分组成的链方式工作：

  • 语音转文本（STT）： 它聆听用户的语音并将其转换为文本。
  • LLM（大语言模型）： 它读取该文本并撰写回复。
  • 文本转语音（TTS）： 它将回复文本转换回语音。

还有一个部分与 STT 并行工作。它判断用户是否已经说完。我们称之为轮次结束检测。它会观察静音以及目前已说出的词语等因素，然后判断：“好的，用户说完了。现在轮到我们了。”

因此，普通的流程如下所示：

User speaks
     ↓
STT turns voice into text
     ↓
End-of-turn detection waits and says "user is done"
     ↓
LLM starts writing the reply
     ↓
TTS turns the reply into voice
     ↓
User hears the reply

在这里，我们可以注意到，LLM 在轮次结束检测判定“用户已说完”之前不会开始。所有环节都在排队等待。

等待时间都花在了哪里

假设用户说：“今天德里的天气怎么样？”

现在，Agent 无法在用户一停下来就立刻回复。它必须首先确认用户真的说完了。有可能用户只是换口气，接下来还会说“……那明天呢？”。因此，轮次结束检测会先等待一小段静默时间，然后才判定“用户说完了”。

之后，LLM 需要一些时间来生成回复的前几个 token。token 是一小段文本，比如一个词或词的一部分。然后，TTS 也需要一些时间来生成第一段音频。

所以，用户要依次等待以下所有环节：

  • 轮次结束检测的静默等待
  • LLM 生成前几个 token 所需的时间
  • TTS 生成第一段音频所需的时间

在两个人之间的真实对话中，从一个人停下到另一个人开口的间隔通常远小于一秒。而语音 Agent 把这些等待时间加起来后，间隔就变长了，对话会显得迟缓、机械。我们有一篇详细介绍如何为语音 AI Agent 构建延迟预算的博客，解释了这些等待时间是如何累加的。

静默等待和 LLM 时间是先后发生的。那么问题来了：能不能让它们同时进行？

答案是可以的。这就轮到投机式 LLM 生成登场了。

什么是投机式 LLM 生成？

投机式 LLM 生成是指 Agent 在尚未确认用户说完之前，就先把用户的话发送给 LLM，并准备好回复但不播放。

投机一词的意思是“基于猜测”。Agent 猜测当前拿到的词就是用户的最终话语，并基于这个猜测开始工作。之后，当轮次结束检测确认轮次已结束时，Agent 会检查自己的猜测是否正确。

  • 如果猜测正确，回复已经准备好了，Agent 立即播放。
  • 如果猜测错误，Agent 就丢弃提前生成的回复，用正确的词重新开始。

假设我们每天都会去一家茶店。我们一进门说“来一杯……”，店主就已经开始煮茶了，因为这是我们最常点的东西。如果我们最后说的是“……茶”，茶就会很快端上来。如果我们最后说的是“……咖啡”，他就把那杯茶放到一边，开始煮咖啡。他浪费了一杯茶，但大多数时候，我们能更快喝到茶。

这正是投机式 LLM 生成对回复所做的事情。其中一部分工作会被丢弃，但大多数时候，用户能更快得到回复。

注意：“投机解码”是另一个概念。投机解码是让一个更小、更快的模型提前猜测几个 token，从而使 LLM 本身更快地生成 token。而这里我们讨论的是在语音 Agent 中，在用户的回合尚未确认之前就提前启动 LLM。一些语音 Agent 框架将这种做法称为抢占式生成。

计划转型进入 AI 领域？

无论你今天在哪个技术领域工作，只要付出努力，你都可以转型到以下这些角色：

  • AI 工程师
  • 前沿部署工程师
  • AI Agent 工程师
  • Harness 工程师
  • 语音 AI 工程师
  • AI 架构师
  • LLM 工程师
  • LLM 推理工程师
  • 生成式 AI 工程师
  • MLOps 工程师
  • 机器学习工程师
  • 深度学习工程师

Outcome School 的 AI 与机器学习课程将带你实现这一目标。

投机式 LLM 生成如何一步步工作

学习这一点的最好方法是通过一个例子。

假设用户说：“晚上 8 点订一张两人桌。”

STT 不会等待整句话说完。在用户还在说话时，它就持续发送文本。我们把这些早期的文本片段称为临时转录（或部分转录）。当 STT 对某段语音有足够把握时，它会为该段语音发送一份最终转录。

第 1 步：用户正在说话。STT 陆续发送临时文本，比如“订一”，然后是“订一张”，再然后是“订一张两人桌”。

第 2 步：用户说“……晚上 8 点”然后停下。STT 发送最终转录“晚上 8 点订一张两人桌。”

第 3 步：Agent 不等待回合结束检测，而是立即将“晚上 8 点订一张两人桌。”发送给 LLM。这就是投机请求。

第 4 步：LLM 开始撰写回复：“好的，让我查一下晚上 8 点的两人桌是否空闲。”Agent 将这个回复存放在一个暂存区。我们把这个暂存区称为缓冲区。此时还没有向用户播放任何内容。

第 5 步：与此同时，回合结束检测仍在等待静默期结束。

第 6 步：静默等待结束，回合结束检测判定“用户已说完”。此时，回复的第一部分已经进入缓冲区。

第 7 步：Agent 将投机请求所用的词语与该回合的最终词语进行比较。两者一致，因此 Agent 立即播放缓冲区中的回复。

我们可以按先后顺序看到这两条时间线，如下所示：

Normal agent:

User stops
     ↓
Silence wait
     ↓
End of turn confirmed
     ↓
LLM starts
     ↓
First LLM tokens ready
     ↓
TTS makes the first audio
     ↓
Reply starts playing


Speculative agent:

User stops
     ↓
LLM work and silence wait run at the same time
     ↓
End of turn confirmed, first LLM tokens already in the buffer
     ↓
TTS makes the first audio
     ↓
Reply starts playing

在这里我们可以看到，在投机式 Agent 中，LLM 的工作与静默等待是重叠的。LLM 所需的时间被隐藏在 Agent 本来就要等待的时间里。

这就是投机式 LLM 生成在用户说完之前就开始回复的方式。

当猜测正确时会发生什么

当猜测正确时，最终的话语与发送给 LLM 的话语一致，因此缓冲区中的回复正是 Agent 本来也会产生的回复。

也就是说，用户得到的是相同的答案，只是更快了。

节省的时间最多可达 LLM 生成首批 token 所需的时间，因为这部分工作现在在静默等待期间运行。在许多语音 Agent 中，这是整个链路中最长的等待之一。所以，把它隐藏起来会让 Agent 感觉自然得多。

为了便于理解，我们来举一些数字。假设静默等待为 500 毫秒，LLM 需要 400 毫秒来生成首批 token。

  • 普通 Agent： TTS 至少要等 500 + 400 = 900 毫秒才能开始。
  • 推测式 Agent： 400 毫秒的 LLM 工作在 500 毫秒的静默等待内运行。因此，TTS 可以在 500 毫秒后开始。

由此可见，在猜测正确的每一轮中，Agent 都能节省 400 毫秒。如果 LLM 需要的时间超过静默等待，节省的时间就等于静默等待的时长，因为只有这部分可以重叠。

给你的一个快速提示

无论你在哪个技术领域工作，都要熟悉这些主题：

  • LLM
  • RAG
  • MCP
  • Agent
  • 微调
  • 量化

我们把它们全部整合在一个视频中：

AI 工程详解：LLM、RAG、MCP、Agent、微调与量化

不必中断阅读——先收藏起来，等有空的时候再看。未来的你会感谢现在的你。

现在，让我们回到主题。

当猜测错误时会发生什么

现在，让我们看看另一种情况。

假设用户说：“帮我订一张两人桌……”然后停下来思考。STT 为这些话语发送了最终转录，Agent 将这个停顿视为可能的话轮结束。它将“帮我订一张两人桌”发送给 LLM。LLM 开始生成：“好的，请问几点？”

但用户继续说道：“……晚上 8 点，靠窗的位置。”

现在，话语发生了变化。对于新的话语来说，早期回复“好的，请问几点？”是错误的。如果 Agent 播放它，用户会感到困惑，因为他们已经说了时间。

所以，一旦 STT 发来新的话语，Agent 会执行以下操作：

  • 取消正在运行的 LLM 请求，使其停止生成更多 token。
  • 丢弃缓冲区中的所有内容。
  • 当 STT 为完整话语“帮我订一张两人桌，晚上 8 点，靠窗的位置。”发送最终转录时，Agent 会将其作为新的推测式请求发送给 LLM。

用户永远不会听到错误的回复。 早期回复只存在于缓冲区中，从未被播放。

在这种情况下，第一个请求被浪费了，但新的请求仍然在话轮结束被确认之前就启动了。因此，Agent 在正确性上没有任何损失。唯一的损失是第一个请求浪费的 LLM 工作。

Agent 如何知道词语发生了变化？

AI Agent 会保留一份随推测请求发送的确切词语的副本。当轮次结束检测判定“用户已说完”时，AI Agent 会将该副本与该轮次的最终词语进行比较。

  • 如果两者相同，AI Agent 就使用缓冲的回复。
  • 如果两者不同，AI Agent 会丢弃缓冲的回复，并发出新的请求。

有些 AI Agent 还会检查随请求一起发送的其他内容，而不仅仅是词语。例如，对话历史以及 LLM 可以推荐的工具 列表。工具是我们的 AI Agent 代码可以运行的函数，比如查询预订系统。如果其中任何一项在期间发生了变化，早期回复就不再有效，也必须被丢弃。

注意： 在轮次结束得到确认之前，AI Agent 绝不能播放推测回复。整个方案之所以安全，正是因为早期回复在检查通过之前一直保持隐藏。

我们有一套关于 AI Agent 中的工具使用、Agent 架构以及如何设计实时语音 AI Agent 的完整课程——欢迎查看 Outcome School 的 AI 与机器学习课程。

提前准备语音

现在，是时候了解如何提前启动语音了。

我们可以将同样的思路应用到 TTS。一旦 LLM 生成了推测回复的第一句话，AI Agent 就可以将这句话发送给 TTS，并将生成的音频也保存在缓冲区中。

然后，当轮次结束得到确认且词语匹配时，AI Agent 甚至无需等待 TTS。第一段音频 已经准备就绪，可以立即开始播放。

如果词语不匹配，AI Agent 会同时丢弃缓冲的文本和缓冲的音频。

优点： 回复几乎可以在轮次确认的那一刻开始播放。

缺点： 如果猜测错误，AI Agent 会同时浪费 LLM 和 TTS 的工作。

这就是为什么许多系统默认只提前运行 LLM，只有当额外的速度值得额外的浪费时，才提前运行 TTS。

保持更新： 订阅我们的 newsletter，第一时间将我们最新的 AI 与机器学习博客送达您的邮箱。

投机式 LLM 生成的成本

推测性 LLM 生成是有成本的。每一次错误的猜测都是一个我们付费却从未使用的请求。

假设用户在一个长句子中间停顿了三次。AI Agent 可能会为单个轮次发送四个推测请求——每个停顿一个，真正的结束一个——而只有最后一个被使用。如果我们的 LLM 提供商按 token 计费，那些被丢弃的 token 仍然要花钱。TTS 也是如此。

另一个成本是负载。更多的请求意味着 LLM 服务器要做更多的工作。如果许多用户同时交谈，这些额外的负载可能会拖慢所有人的回复速度。

因此，AI Agent 必须在两件事之间取得平衡：

  • 尽早启动，以便回复更快。
  • 不要启动得太频繁，以保持浪费较低。

保持低浪费的一个常见做法是，只在 STT 的最终转录结果上启动推测性请求，而不是在每次中间转录时都启动。用户说话时，中间转录会频繁变化，如果每次都启动，会造成大量被丢弃的工作。

何时使用以及何时不使用

推测性 LLM 生成在以下情况下效果良好：

  • 用户说话是简短清晰的句子，例如预订、下单和简单提问。
  • 快速回复非常重要，例如在客户支持电话中。
  • 少量浪费请求带来的额外成本是可以接受的。

在以下情况下效果较差：

  • 用户说话是带有许多停顿的长句，例如讲故事或口述消息，因为猜测会不断出错，大部分工作都会被丢弃。
  • LLM 请求非常昂贵，每次浪费的请求都会损害预算。

还有一点需要注意。推测性请求只能用于准备回复，绝不能在现实世界中执行任何操作，因为猜测仍可能是错的。

假设推测性回复包含一个下单的工具调用。LLM 只推荐该工具调用，而由我们的 Agent 代码来执行它。因此，Agent 必须持有该工具调用，并且只在回合确认后才执行，绝不能在推测阶段执行。

我们有一篇详细的博客，介绍语音 Agent 如何隐藏慢速工具调用的延迟，其中解释了哪些工具可以安全地提前启动。

现在，我们应该已经理解了推测性 LLM 生成如何在用户说完之前就开始回复、如何将 LLM 时间隐藏在静默等待中、猜测对错时会发生什么，以及何时使用它。

常见问题

推测性 LLM 生成与推测性解码有什么区别？

它们解决的是不同的问题。推测性解码通过让一个更小、更快的模型提前猜测若干 token，使 LLM 本身更快地生成 token。推测性 LLM 生成则是在语音 Agent 中，在用户回合结束尚未确认之前就提前启动 LLM，使 LLM 时间与静默等待重叠。

推测性 LLM 生成能节省多少时间？

它最多可以节省 LLM 生成首批 token 所需的时间，因为这部分工作是在静默等待期间运行的。如果 LLM 所需的时间超过静默等待，那么节省的时间就等于静默等待的时长，因为只有这部分可以重叠。例如，静默等待为 500 毫秒，LLM 工作为 400 毫秒，那么 Agent 可以节省 400 毫秒。

Agent 是否应该在每次中间转录时都启动推测性请求？

不能。降低浪费的常见做法是，仅在 STT 输出最终转录结果时才启动投机请求。用户说话期间，中间转录结果变化非常频繁，如果每次都启动，会造成大量被丢弃的工作和额外成本。

投机请求可以运行工具调用吗？

不能。投机请求只能准备回复，因为猜测仍可能是错的。LLM 只是推荐一个工具调用，比如下单，而实际执行是由我们的 agent 代码完成的。因此，agent 会保留该工具调用，只有在确认本轮对话结束后才执行它。

什么是语音 agent 中的抢占式生成？

抢占式生成是一些语音 agent 框架对投机式 LLM 生成这一相同概念的叫法。agent 在还不确定用户是否说完时，就把用户的话发送给 LLM，将回复保存在缓冲区中，只有当最终话语匹配时才播放。

今天就到这里。

谢谢

Amit Shekhar Outcome School 创始人

你可以通过以下方式与我联系：

关注 Outcome School：