拆分了我们的实时语音栈（STT -> LLM -> TTS），成本降低约14倍。代价是延迟增加，外加一个我未预料到的好处。

几个月来一直在生产环境中运行语音代理，终于做了大家告诫不要做的事。拆除了融合的实时模型，重建为三个独立阶段：语音转文本，然后LLM，然后文本转语音。原因纯粹是成本。融合的实时设置对我们来说成本约为每分钟0.18美元。将其拆分为现成的STT + LLM调用 + TTS提供商，成本降至约每分钟0.0125美元。大约14倍，对于任何实际通话量来说，这个差距是整个商业案例，而非四舍五入的误差。明显的代价是延迟。融合模型确实更快，因为它不是在三个服务之间跳跃，而语音对延迟非常敏感，你能感受到每一个额外的100毫秒。我们的目标是保持在约788毫秒的语音到语音延迟以下，有些日子我们确实输掉了这场战斗。如果你的产品是人们会互相打断的实时电话，融合可能仍然值得花钱。我没想到的部分是我不想回头的原因。一旦管道拆分，LLM输出在音频生成之前就是纯文本，所以每个护栏都在文本上运行。你可以在生成任何音频样本之前捕捉到错误答案或幻觉数字并将其杀死。对于融合模型，当你知道说了什么时，话语已经被说出了。这种可检查性最终对我比成本更重要。所以诚实的权衡：融合更快，拆分更便宜且更容易理解。如果你处于早期且对成本敏感，或者你只是想能控制这东西说什么，我会从拆分开始，只有在延迟真正成为问题时才融合。好奇在生产中使用拆分栈的人们达到的延迟是多少。788毫秒的语音到语音延迟是我似乎无法持续低于的墙。