感谢你们打造了如此出色的产品！我怀疑克隆OpenAI的API是出于兼容性的原因。大多数基于AI的软件已经支持GPT-4 API，而OpenAI的官方客户端非常容易地允许你覆盖基础URL。一个本地的LLM API不太可能如此流行，这会大大限制这种设置的使用场景。一个很好的例子就是我所做的，如果没有能够运行OpenAI API的副本，这会困难得多。我必须承认，我对LLM的内部机制了解不多（更不用说理解变压器背后的数学了），所以对于你的第二个观点，我可能说不出太多。我真的希望HomeAssistant可以将响应流式传输到Piper，而不是必须一次性准备好整个响应。我认为这会让LLM的集成更加高效，尤其是在像我这样的消费级硬件上。现在，当我与Whisper对话结束后，要大约8秒钟才能开始听到GlaDOS的声音，而大部分时间都花在等待语言模型响应上。…
源讨论构建一个完全本地的LLM语音助手来控制我的智能家居原帖 186 条评论 · 导入时统计Home Assistant的创始人在这里。写得真好！ 在Home Assistant中，我们计划在今年内直接集成类似的功能。OP提到了一些我们也有过类似问题的好观点，我希望能有本地LLM社区来解决这些问题： * 我希望看到一个标准化的本地LLM API，而不仅仅只是复制ChatGPT的API。例如，当Home Assistant与一个随机模型通信时，我们应该能够查询该模型以了解它具备哪些功能。 * 我希望看到本地LLM支持类似或等效于OpenAI函数的功能。我们无法在提示中包含所有可能的信息，我们需要让LLM能够执行操作以变得有用。受限语法看起来像是一个可能的替代方案。创建一个生成JSON的提示是可能的，但需要相当复杂的提示，而且即使如此，LLM仍可能出错。我们希望确保所有…
完整原文把你的经验，加入这段讨论。
流式响应 definitely 是我们应该研究的东西。挑战在于我们不能只是流式传输单个单词，而是需要找到一种方法来学习如何切分句子。可能从段落开始是一个好的第一步。
完整原文这8秒中有多少是花在LLM上还是Piper上的呢？ 一些示例响应对于典型的家庭自动化用例来说太长了，这会加剧这个问题。GladOS有很多空间可以调皮，但8秒太慢了，无法使用。 另一种方法可能是让LLM预先生成一组类似GladOS的响应，然后从中选择，而不是总是让LLM生成新的响应。此外，添加一个缓存，将Piper首次合成的.wav文件存储起来。缓存是Mycroft AI的做法。不确定在你的设置中添加这个会有多容易。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。