在虚拟语音智能体中兼顾超低延迟和云经济性

Devin Reimer

欢迎学习“在虚拟语音智能体中平衡超低延迟和云经济性”课程。

大家好，我是 Devin Reimer。

我是 AstroBeam 的创始人兼首席执行官。

之前，我是 Owlchemy Labs 的首席执行官兼联合创始人，该工作室最知名的作品可能是《Job Simulator》。

因此，在 AstroBeam，我们专注于在游戏中构建实时 AI。

具体来说，我们非常关注语音输入。

目前我们已经发布了两款游戏，其中《Stellar Cafe》支持 VR 和 PC。

在这款游戏中，您将在空间站咖啡馆与机器人对话，并帮助它们解决问题。

完全由语音驱动。

您只需使用语音即可玩整个游戏，包括菜单和导航。

我们今天刚刚宣布的下一款游戏《Robo Detective》是专为 Android XR 打造的，特别是 XREAL 的 Project Aura。

在这款游戏中，你将扮演一名侦探，与机器人搭档一起审讯机器人，侦破机器人犯罪案件。同样，这款游戏也是 100% 语音驱动。

因此，语音代理非常难，而在游戏中，它们实际上更难。

原因在于，游戏的成本非常低，而语音智能体现在是该流程中新增的一项成本。

此外，我们不是在与其他语音智能体竞争，而是在与所有游戏的质量竞争，对吧？

因此，我们必须提供非常优质的内容。

这并不是说，在特定的语音智能体应用场景中，不存在独特的挑战或更高的风险，但游戏在这一领域的技术挑战绝对非常大。

不过，正因为它们是游戏，所以有很大的空间可以尝试如何解决这些难题。

因此，我相信，如果语音智能体能在游戏中发挥作用，那么它们几乎可以在任何地方发挥作用。

因此，我在此次演讲中讨论的内容不仅适用于游戏，还适用于您想要构建的任何语音优先应用。

因此，在考虑语音智能体时，我认为存在三大核心挑战。

因此，我们有延迟时间、智能和成本。

不过，我想明确一点，我所说的语音智能体是指对话式语音智能体，而不是提示式语音智能体。

我说的不是那种只是把语音输入发送给 LLM 然后等待回复的麦克风包装器。

我指的是现实世界中实时的来回对话，而这实际上非常难以构建。

我们先从延迟时间开始。

需要多快？

事实证明，它需要很快，非常快，但根据您所读的内容，它可能没有您想象的那么快，也可能比您想象的要快得多。

接下来，我们来谈谈在大量测试中发现的一些数据。

因此，我所说的端到端延迟时间是指从用户最后一次说话（用户发出的最后一个声音）到他们听到音频返回的时间。

我们在测试中发现，当启动时间达到 1.5 秒左右时，用户在提供游戏测试反馈时，就不会再提及速度快慢或类似问题。

在这个阶段，人们开始真正适应并感到舒适。

一旦我们的速度比这慢得多，人们就会经常提起：“这很好，但是…”，所以这似乎是一个最佳平衡点。

然后，随着速度进一步提升，我们发现，在大约 1.2 秒时，会出现一些更自然的互动，比如来回对话。

比如，我说一句话，机器人会很快回应，然后你来我往，就像聊天一样。

这似乎是一个尚未开发的最佳切入点。

不过，在堆栈中实际实现 1.2 秒的延迟相当困难。

另一个有趣的发现是，我们进行了大量测试，最终在某些场景下实现了不到 1 秒的延迟。

您可能会想：“哇，那太棒了！”

有时确实如此，但有时感觉很糟糕，非常诡异。

因此，您可能会听到有人说 800 毫秒的响应时间是正确的，或者 500 毫秒。

我甚至读过很多关于 300 的文章，因为这正是人类感知能力的极限。

事实上，这在很大程度上取决于具体情况。

举例来说，如果我问你叫什么名字，我会预期你会在多长时间内回答。

如果我问你生命的意义是什么，我希望你能在很短的时间内给出答案。

当我们实际进行测试并让用户对这种响应速度进行评分时，结果却大相径庭。

人们认为耗时较长的回答很快，反之亦然，因为这完全取决于上下文。

以及他们当时在对话中的位置。

通常，人们会期望第一个回答比后续回答更快，因为后续回答需要思考时间。

但有时，你可能会得到非常简短的来回对话，这会提高你的期望。

所以，这不是一门完美的科学，没有一个完美的数字，但我们发现，如果您的比例在 1.5 左右，那么您的表现就相当不错了。

因此，一旦您最终达到 1.5 秒，您就会开始真正关注一致性，对吧？

因为如果 90% 的情况下都是这样，但有 10% 的情况下需要 3 秒，那么您的体验就会感觉不连贯，不是不好，而是不连贯。

因此，当速度足够快时，您就会开始关注一致性，即始终保持高速，而不是大多数时候保持高速。

Devin Reimer

下面是一个标准的语音流水线架构。

因此，我们会将语音转文字的结果发送给 LLM，然后将 LLM 的结果发送回文字转语音。

我的意思是，在语音转文字过程中，我们会将音频发送到服务器，然后将其转换为文字。

在 LLM 方面，我们会获取该文本（即对话回复），或将其转换为对话回复，然后确定该角色将采取哪些行动。

我们将这些紧密结合在一起，因为我们认为这非常重要。

然后，在 Text-to-Speech 方面，我们获取该文本，将其发送到 Text-to-Speech，并将其流式传输给用户，同时与智能体想要执行的操作保持同步。

这样做的一个问题是，按顺序运行可能会非常慢，因为您最终必须逐个执行这些操作。

因此，我经常被问到的一个问题是：既然这种方法速度慢，而且需要三个步骤，为什么不直接使用语音到语音模型呢？

因为这样会更快，对吧？

是的，大多数情况下，这样做会更快，因为您只运行一个任务。

但它也存在一些重大弊端。

因此，虽然它速度很快，但对我们来说有一些重大缺陷，其中最大的缺陷就是成本。

因此，我们通常发现，运行语音到语音模型的成本大约是这种并行化方法的 3 到 5 倍。

因此，对我们来说，这种模式在经济上根本行不通。

在安全方面，情况实际上要棘手得多，因为在智能体说出回答之前，很难验证其回答是否安全。

但与此同时，如果您采用流水线方法，就可以在 LLM 生成回答后，在回答即将发送给用户之前，立即进行验证和安全检查。

在语音风格方面，您只能使用该语音到语音模型中的预设。

你不能说：“哦，你知道吗？

对于这种情况，我真的很想使用这种声音。”

您只能使用该特定版本。

在流水线方法中，您可以说：“哦，我要改变一下。

我将选择这个模型，因为这个模型非常适合这个特定用例。”

智能也是如此，对吧？

如果你有一个非常出色的语音到语音模型，能生成优质语音，但智能程度不尽如人意，你无法直接替换掉它，对吧？

您基本上被锁定了。

在流水线方法中，您会想：“对于这个应用场景，我想使用一个特定的模型。”

语音到语音模式绝对胜出的一个方面是理解用户语气。

比如讽刺等。

目前，语音转文字转写内容通常不包含太多此类信息，但我认为这种情况会随着时间的推移而改变。

这绝对是 Speech-to-Speech 的一大优势。

因此，Speech-to-Speech 在速度方面确实具有优势，但在可配置性方面确实存在一些挑战，而且高昂的成本对我们来说尤其是一个决定性因素。

那么，还有其他方法吗？

是。

我们应该做的是尽最大努力并行化流水线。

因此，我们采取了一些措施，例如在语音转文字功能尚未完全确定时，就运行 LLM。

我所说的置信度，是指对转写内容中生成的字词的置信度，以及对轮次结束的置信度。

因此，只要我们认为用户可能已经停止说话，并且这就是他们所说的话，我们就会提前运行。

因此，最坏的情况就是我们错了，对吧？

用户继续说话。

但即使在这种情况下，我们也只是取消 LLM，然后重新运行。

由于上下文可能会被缓存，而且我们没有生成那么多词元，因此这样做实际上不会产生很大的成本，而这样做的好处是，用户最终听到内容的速度会比您等待完全确信时更快。

我们也不会等到 LLM 生成完整回答后才开始将其发送到 Text-to-Speech。

我们等待的是第一个可说出的片段。

在大多数情况下，它是一个句子。

有时也可能是其他配置，但只要我们有了第一个句子块，就会将其发送到 Text-to-Speech。

然后，如果我们有良好的文字转语音功能，可以进行流式传输，那么一旦准备好进行流式传输，就可以将其传输给用户。

我们还非常谨慎地控制需要生成的 token 数量。

因此，我们不使用 JSON 封装容器等可能会增加额外 token 的内容。

我们尝试找出最简化的结构，以尽可能快地获得响应。

如果我们提前知道智能体最终会输出的第一批词元是什么，还会使用辅助预填充等功能。

对于文字转语音，最终会生成这两个分块，对吧？

因此，第一个可朗读的内容块会先传入，然后我们再运行其他所有内容。

但由于音频播放所需的时间比生成时间长，因此在第二块生成完成时，第一块几乎肯定已经播放完毕。

因此，用户实际上看不到该过程。

它会以最快的速度到达。

因此，在考虑选择不同的服务时，可以参考以下经验法则。

在选择合适的音频和智能体框架时，您最关心的是输入和输出的延迟时间是否最低。

那么，我上传和下载内容的速度有多快？

在语音转文字方面，我们关注的是达到置信度所需的时间。

因此，这是对转写结果和轮次结束的置信度。

它们是配对的，对吧？

如果你无法快速对其中一个建立信心，那么整个过程就会变得很慢，对吧？

因此，其速度取决于其中最慢的一个。

在 LLM 方面，我们关注的是生成第一个句子（即第一个可读出的文本块）所需的时间。

所以，这分为两个部分，对吧？

它是首 token 延迟和每秒 token 数的组合。

因此，如果您突然发现一个非常好的模型，其首 token 延迟非常短，但每秒 token 数很慢，那么它可能比替代方案更糟糕。

因此，请找出适合该目标的组合。

在文字转语音方面，您需要关注的是“首个音频生成时间”。

因此，测量这个时间非常重要，因为有时音频可能在开头有一段静音，用户听不到任何声音。

因此，您实际上必须衡量用户听到声音的时间点。

正如我之前提到的，最重要的是，您关心的是稳定性，而不是峰值速度，也不是最佳情况。

整个堆栈的延迟时间是否稳定？

Devin Reimer

因此，目前对于我们的音频智能体框架，我们使用的是 LiveKit。

对于语音转文字，我们使用的是 Deepgram。

对于 LLM，我们使用的是 Gemma 4 31B，并将其托管在 LiveKit 上。

在文字转语音方面，我们使用的是 Inworld AI 文字转语音 2。

在此基础上，我们构建了整个 AstroBeam AI 智能体 Harness，它不仅将所有这些元素整合在一起，还添加了打造出色语音智能体所需的所有组件，尤其是像我们这样专为游戏设计的高度互动型智能体。

我还没提到安全模型，

传统上，安全模型是 LLM 传递的一部分，但这会增加延迟时间，并增加一个额外的步骤。

那么，如果您自己运行，会怎么样？

所以，这才是我们的堆栈的实际情况。

因此，我们在这里所做的是，当我们收到第一段文本（即要发送给文字转语音 的第一段可朗读文本）时，我们会同时将其发送给安全模型。

由于安全模型较小，运行速度比语音转文字部分更快，因此几乎总是提前完成。

因此，最终的结果是，添加安全模型不会给我们的堆栈增加任何延迟，更棒的是，这个块足够大，我们实际上可以运行一个比大多数人想象的要大得多的安全模型。

这对我们来说非常重要，尤其是因为我们正在开发游戏。

那个世界有太多非常重要的背景信息。

举例来说，假设您正在开发一款中世纪游戏，其中有一个 NPC 会大喊“冲啊！”

砍掉他们的头！”，对吧？

传统的安全模型可能会说：“哇，这可不好。

你不应该这么说。”

但在这款游戏中，这完全合乎逻辑。

为此，我们采用了一个更强大的安全模型，该模型融入了更多关于全球动态的背景信息，从而能够实现这一目标。

您可能会注意到，我们实际上运行了两次安全模型，因此我们最终会在第一个分块上运行它，然后在我们获得最终分块后再次在整个内容上运行它。

同样，我们必须运行两次，但不会给堆栈增加任何延迟。

现在，我们的速度足够快了，但遗憾的是，如果我们不够聪明，速度快也没用。

Devin Reimer

那么，它需要有多智能？

它不仅需要足够智能，能为用户提供便利，更重要的是，它还要足够智能，能让您轻松进行开发。

人们在选择所需的情报时，往往不会考虑这一点。

我们开发语音智能体已经大约三年了。例如，在早期，我们使用了一些早期的 LLaMA 模型，虽然我们能够让它们为用户提供服务，但开发成本非常高，因为一切都非常脆弱。

模型很容易就会生成不理想或不合逻辑的回答，因此我们投入了大量工程努力来解决这个问题。

因此，这是我们优先考虑的事项，因为如果我们无法快速构建这些内容，就无法向用户提供这些内容。

因此，请务必同时考虑这两点。

因此，人们在思考智能时，通常会想到 LLM，对吧？

但这只是其中一个方面。

在智能方面，我们必须考虑每一个环节。

下面我们来谈谈语音转文字智能。

因此，我们在这里关注的是低字词错误率。

此外，不仅错误率低，而且即使发生错误，我们生成的内容也与实际内容非常接近。因为如果非常接近，LLM 通常可以结合上下文很好地理解其含义。

如果错误率较低，但失误率很高，LLM 在尝试弄清楚实际意图时会遇到更多困难。

另一个需要考虑的问题是目标平台。

举例来说，如果我正在构建 XR 应用，并且麦克风距离用户的嘴非常近，那么我将获得非常优质的高质量麦克风音频数据，这可能非常适合某些模型。

但如果我突然要为手机开发一款应用，而用户会在喧闹的街道上使用这款应用，那么情况就会大不相同，不同的模型会有不同的表现，并且能够以不同的方式智能地识别所说的内容。

因此，您必须考虑这一点，确保选择的目标平台与您要构建的目标平台一致。

接下来，我们来看看智能等式中的文字转语音部分。

听起来很自然，对吧？

我们的目标是向用户传达信息，用户能理解吗？

但这只是其中一部分，对吧？

智能体的表达能力也极其重要，因为表达本身就包含信息。此外，在游戏测试中，我们发现智能体的表达能力越强，用户就越觉得它们聪明，这非常合理。

然后，速度是否足够快？

我知道在上一部分中，我谈到了延迟时间，但实际上，延迟时间对感知智能也很重要。

用户会认为，响应速度与智能程度直接相关。

如果我能快速回应，听起来可能更聪明。

因此，这些因素对于用户对体验的感知以及他们能否沉浸在体验中至关重要。

接下来，我们来看看 LLM 方面的智能。

到目前为止，这是最难平衡的，因为这里有太多不同的要求，对吧？

因此，我们具备语音理解、上下文和接地能力。

在游戏中，这非常棘手，因为你必须立足于整个世界和宇宙，对吧？

这不是一个可以编造正在发生的事情的文本框。

如果游戏中的智能体说“桌子上有一个苹果”，但桌子上并没有苹果，就会破坏用户体验。

我们还需要模型能够严格遵守规则。

游戏非常注重规则。

LLM 能处理这种情况吗？

能否降低幻觉率？

当您反复与同一个智能体互动时，我们能否让其保持一致的性格？

感觉像同一个代理吗？

还有一个问题可能会让您感到棘手，因为它在开发初期并不是问题，那就是：您的模型能否处理不断增加的提示大小？

因为随着您不断开发，您不可避免地会在提示中添加更多内容。

但随着用户继续玩游戏，提示中会包含更多对话记录。

那么，该提示能否处理这种增长？

因为有时对于某些模型，随着提示长度的增加，回答质量会下降，因此您必须弄清楚每次输入提示时，实际需要输入多少内容。

但这只是冰山一角，具体情况还取决于您要构建的内容。

因此，您必须认真思考您正在构建的内容以及您想要实现的目标。

现在，我们的速度足够快，也足够智能，但如果成本太高，这些优势就毫无意义。

Devin Reimer

那么，这个价格需要多低呢？

遗憾的是，实际情况要比这复杂一些。

因此，我们必须考虑正在构建的应用或游戏的经济效益，对吧？

因此，您需要问自己几个问题。

用户与您的语音代理互动的时间有多长？

您从每位用户身上赚取了多少收入？

该语音堆栈每小时的运行费用是多少？

我们把它们放在一起，试图弄清楚，看看这些事情是否合理。

下面是我们的第一款游戏《星际咖啡馆》的经济模型。

因此，在 Stellar Cafe 的游玩时间大约在 1.5 到 3.5 小时之间，平均下来大约是 2 小时。

我们运行语音智能体的成本约为每位用户每小时 1.20 美元，而用户与智能体的互动时间占比为 100%。

这是一款完全由语音驱动的游戏。

我们对游戏收取 10 美元的固定费用，这是一种传统模式。

我们不采用订阅模式，因为这种模式在游戏中很难行得通。我坚信，我们必须以固定成本来运营，否则就无法持续，也无法扩大规模。

之前，我们的收费是 15 美元，但我们一直在努力降低这些服务器成本，所以现在我们实际上已经将其降到了 10 美元。

这个 1.20 美元就是我们目前所处的位置。

这不是一个通用的价格。

我见过这些东西的价格差异很大，有时甚至贵得多。

因此，您还必须弄清楚自己在成本方面处于什么位置。

我们可以降低价格，但我们正在努力尽可能提高质量标准。

因此，综合考虑这些因素，这意味着在 2 小时的游戏时间内，每位用户的语音堆栈费用约为 2.40 美元。

因此，由于我们收取 10 美元，而商店会收取费用，这意味着我们从每位用户身上赚取大约 4.59 美元，对吧？

因此，这种模式在经济上是可行的，对吧？

声音是我们的卖点，也是我们想要投入资金的地方，这很有效。

所以，这是一款非常小的游戏。

我们来聊聊更宏大的话题。

我们来假设一款游戏，一款叙事游戏，时长大约在 5 到 9 小时之间，平均时长为 7 小时。

实际上，大多数人（很多人）都不会玩完游戏，他们只是玩一小部分，然后就放弃了，但我想选择一个稍微高一点的数字，以确保经济模型仍然有效。

因此，我们仍按每小时 1.20 美元计算，但要做的改变是，语音组件的使用时间将占 60%，因为大型游戏除了语音之外，还会有更多机制。

因此，这仍然是一款非常依赖语音的游戏，但其中也会有其他类型的功能。

因此，如果我们收取 20 美元，再次进行计算，我们的成本大约是每位用户 5 美元，这意味着最终我们每位用户大约赚取 9 美元。

因此，通过这种方式，经济效益得以实现。

这并不意味着经济效益适用于所有情况。

举例来说，如果您想“打造一款免费开玩游戏，玩家的游戏时长可能在 1 小时到 100 小时以上”，那么您不应该这样做。

因此，我们取平均值 10 小时。

这款游戏完全由语音驱动，但假设我们有一款热门游戏，每位用户能带来大约 3 美元的收入，对于一款免费开玩游戏来说，这已经相当不错了。

您将为每位用户损失 10 美元。

因此，它还无法完成所有这些工作，您必须考虑当前正在构建的内容，以及它是否有意义。

不要等到最后才去弄清楚经济效益。

Devin Reimer

那么，接下来要问的问题是，本地模型怎么样？

因为如果您面临成本这一巨大挑战，本地模型不就能解决这个问题吗？

是的，确实如此。

但这里有一些权衡，我们必须考虑。

因此，从成本方面来看，是的，我们会消除服务器账单，这将是一个巨大的好处，会带来更多机会。

但现在，云端可以解决本地难以应对的许多问题。

例如，计算。

人们经常会说：“看，我找到了一个非常好的语音转文字模型，它可以在这个设备上本地运行，对吧？”

太棒了，但我们要考虑的是，它运行的不是一个模型，而是多个模型，对吧？

在我们的例子中，有四个，可能同时运行，因此，仅仅运行一次是不够的，它必须同时运行多次。

如果这些都做到了，那您的游戏或应用还有运行空间吗？

如果 GPU 性能已达到极限，您将无法真正渲染出电子游戏。

假设您已经克服了这些挑战。

那么，下一个是速度，对吧？

通常，您可以让它们运行，但它们会非常慢，感觉更像是提示，而不是实际的实时对话。

因此，从理论上讲，在本地获取数据确实有未来的优势，因为您不必从互联网进行往返。

目前，让模型以合适的速度运行以实现这一目标是一项挑战。

接下来，假设您已经解决了计算和速度问题，现在我们必须考虑质量，对吧？

因此，通常情况下，由于您是在本地设备上运行，使用的是较小的 LLM，例如更原始的文字转语音，这实际上可能会在您构建内容时带来一些挑战。

正如我之前提到的，在考虑 LLM 时，不仅要考虑它是否足够好，能满足用户的需求，还要考虑它是否足够好，能满足您的开发需求。

因此，如果该模型变得很难用来构建内容，那么这绝对是需要考虑的问题。

假设您已经解决了计算、速度和质量问题，接下来就是可移植性。

如果你赢了，并完成了整个过程，让这个东西在 RTX 5070 上运行，那可能就是它唯一能运行的地方。

因此，如果出现将其引入新平台的机会，您可能会遇到困难。

在云端，您只需要连接到互联网。

因此，这算是一个重大突破。

允许在多个平台上直播。

接下来，我们来谈谈混合方法，好吗？

因此，我们可以在云端运行一些内容，在本地运行一些内容。

有点像，这样可以吗？

好吧，这并不像你想象的那么大。

因此，如果您最终获得了一个足够小、可以在大多数本地平台上运行的模型，那么如果您在云端运行该模型，可能只需花费几分钱。

因此，通常只有在解决整个堆栈的问题后，才能取得最大的成效。

接下来，有人可能会问，如果可以的话，在本地运行会怎么样？

他们有合适的硬件，如果您没有，也可以在云端使用，对吧？

您可以在云端运行更强大的功能。

这带来了新的挑战，对吧？

如果您最终运行的是其他模型，这可能会对开发产生很大影响。

最终，您还是不得不花大量时间来处理最低规格。

而且模型的行为可能大不相同。

因此，除非您使用的是完全相同的模型，否则最终可能会增加大量的开发时间和成本。

因此，您需要考虑自己想要实现的目标，因为假设您确实弄清楚了这一点，并找到了一个好的本地模型（如果需要）或云模型（如果不需要），那么云模型的经济效益仍然必须可行。

因为如果突然之间，所有用户都转向云端，而您没有从经济角度考虑过这一点，那么您就会遭受损失。

因此，就本地模型而言，这绝对是一个巨大的经济优势，但目前仍处于早期阶段。

对于游戏等对价格敏感的应用，我认为它最终可能会胜出。

目前，除了更具体的用例（尤其是基于命令的内容）之外，其他用例都有些棘手。

因此，我们现在希望尽可能提供最佳体验。

这就是我们使用云端的原因。

但这是一个发展非常迅速的领域，情况变化很快。

接下来，我们来思考一下要使用的模型，对吧？

那么，下一个问题是开放权重与封闭权重。

我们在这里应该做什么？

在讨论这个问题时，我想重点关注大语言模型，因为我们发现，这是受开源与闭源问题影响最大的领域。

因此，这种方法有利有弊。

所以，说到闭源权重模型，这些通常是前沿智能模型，对吧？

因此，如果您需要最智能的体验，通常需要选择此模型。

与此同时，在开源方面，它们往往落后一代。

因此，这可能需要进行权衡。

在速度方面，我提到过，我非常关注首句生成时间。

我们发现，在闭源模型的生命周期内，其速度往往会下降。

造成这种情况的原因有很多。

可能是使用该模型的人数增加了，也可能是硬件已升级到更新的型号。

但这是我们注意到的一个问题。

因此，您必须小心，因为这可能会导致一个问题：如果您发布了某个产品，并且该产品很棒，但随着时间的推移，它可能会变得无法使用。

接下来是尖峰。

您非常看重这种一致性，因此，封闭模型通常围绕异步任务中的批处理构建，而不是 P99 延迟。而在开放模型方面，您可以选择一个关注您所关注的特定事项的提供商，从而获得您最终需要的信心、速度和延迟。

接下来是模型本身的生命周期。

因此，封闭式模型通常会在大约一年后停用。

这意味着，如果您最终开发了某个应用，开发周期为 1 年，并预计该应用将在生产环境中运行 3 年，那么您可能会经历 3 次以上的模型变更。

而且，模型更好并不意味着它对您更有效。

过去 3 年里，我们经历了许多模型变更，通常需要数周甚至数月的时间来重新调整所有内容。在开源方面，只要有人愿意托管该模型，或者您愿意自己托管，您就可以继续运行该模型。

最后是成本。

通常，随着时间的推移，这些封闭模型在发布新版本时，价格会比上一个版本更高。

因此，在经济效益方面，还有一点需要注意：您的经济效益可能在发布时可行，但在您最终迁移模型时却不可行。

在开源方面，您可以灵活地移动模型，而且由于是完全相同的模型，成本不太可能大幅增加。

因此，我们使用了 Gemma 4 31B，这对我们来说是一个巨大的突破，因为对我们而言，这是速度、智能和成本的最佳组合。

它还让我们能够快速行动。

与我们之前使用过的一些工具相比，它更易于开发。

这并不意味着我们只使用这一种方法。

我们使用了多种不同的开放和封闭模型组合。

例如，记忆生成、安全性和自定义等。

重要的是，要根据具体任务需求选择最合适的模型。

不过，Gemma 4 31B 才是语音智能体的主力。

因此，就两者之间的这种差异而言，开放模型绝对能让您拥有更大的控制权，并让您能够以更可预测的成本托管模型，从而长期保留模型。

而且，模型停用不会影响您的时间安排。

Devin Reimer

总结一下，关键在于平衡这三个方面，对吧？

延迟时间方面，我们正在努力平衡流式传输、并行处理、速度和一致性。

在智能方面，它足够智能，既能满足用户的需求，又能满足开发者的需求。

在成本方面，我们需要知道每位用户的成本是多少，以及每位用户能带来多少收入，这样才能确保经济效益。

不要先构建，然后再考虑经济效益。

从一开始就要考虑这一点。

虽然现在还处于非常早期的阶段，但这种模式已经开始产生经济效益。

因此，更便宜的模型肯定会更好，更智能的模型也肯定会更好。

但现在，今天，我们就可以开始着手解决那些真正棘手的挑战，让语音智能体无处不在。

因此，我非常高兴能将这些语音智能体的强大功能带给每个人。

谢谢。