构建一个完全本地的 LLM 语音助手来控制我的智能家居

原文 ↗ Hacker News 讨论 ↗

一个关于构建完全本地、带有 GLaDOS 风格的 Home Assistant 语音助手的详尽家庭项目，引发了人们对隐私保护、无需云端的智能家居的更广泛兴趣。评论者将 Mixtral、Mistral 和 TinyLlama 等本地模型与 GPT‑4 进行比较，在硬件需求、延迟、量化和 GPU 选择方面权衡其与云 API 的便利性。讨论大量聚焦于如何安全地让 LLM 控制真实设备——使用受约束语法、类似函数调用的接口以及严格的访问控制——同时 Home Assistant 的路线图也暗示了未来对本地 LLM 自动化和标准化 API 的内置支持。

项目反响与类似实现

  • 许多评论者也在构建类似的本地语音助手，常常以 Home Assistant 作为中枢。
  • 有些人只使用本地模型；另一些人先用 OpenAI/Mistral API 做原型，然后再转向本地方案。
  • 还有几个人分享了小型封装或库，用于简化函数调用以及与 Python 或 Home Assistant 的集成。

硬件、性能与量化

  • 大家非常强调使用 GPU：主要瓶颈是首 token 延迟，尤其是在提示词里包含完整家庭状态等大提示时。
  • 中端 GPU（例如 16 GB 消费级显卡）被认为是显存价格比和功耗表现都不错的选择，相比二手数据中心卡功耗更低，也不会过度压迫电源和 UPS。
  • 4-bit 量化（GPTQ、AWQ）很常见；有人报告在 Mixtral 类模型上大约 17 tok/s，算是“能用但不够灵敏”。
  • 也有人在 8–12 GB GPU 上运行 7B–20B 模型，甚至只用 CPU 做实验。

模型行为、语法约束与结构化输出

  • 多条评论建议使用语法约束（llama.cpp 中的 GBNF/BNF）或能将输出限制为有效 JSON 的库，而不是只依赖提示词格式。
  • 讨论还涉及：Mixtral 没有 system prompt 是否更容易受到 prompt injection；有人建议使用微调版本或其他对“system”支持更好的模型。
  • 关于约 7B 模型能力的争论：有人认为它们在狭窄任务上接近 GPT‑4；也有人认为它们在复杂、结构化自动化任务中不够可靠。

Home Assistant 集成与未来方向

  • Home Assistant 项目计划提供基于 LLM 的功能，但希望具备：
    • 更丰富、标准化的本地 LLM API（不只是“照搬 OpenAI”）。
    • 稳健的函数调用或受约束语法，使 JSON 动作总能安全地直接执行。
  • 一些想法包括：用自然语言写家庭行为规则书、根据历史记录由 AI 建议自动化，以及通过插件在本地模型之间一键切换。
  • 有人担心硬件要求；也有人指出 HA 本身是模块化的，LLM/STT/TTS 可以运行在单独、更强大的机器上。

安全、安保与网络

  • 一些评论者担心 LLM 控制实体设备（烤箱、门锁、门等）。建议的缓解措施包括：
    • 对输出进行硬编码安全检查。
    • 限制 LLM 可调用的服务/实体。
    • 类似 ACL/RBAC 的控制，有时通过未公开的 HA API 实现。
  • 有人担心恶意或“潜伏”模型；也有人认为真正的风险是普遍的 IoT 暴露，而不是 LLM 本身。
  • 将 Home Assistant 直接暴露到互联网这一做法颇具争议；少数人会在 WAF/VLAN 后这样做，但大多数人更偏好 VPN/WireGuard。

语音管线与用户体验

  • 延迟是一个反复出现的担忧：从说话到收到第一个回复如果超过 8 秒，普遍被认为只能算勉强可接受。
  • 建议包括：
    • 面向简单命令的前端语法/意图规则。
    • 缓存常用语句，甚至缓存 TTS 音频。
    • 先发出“请稍等”之类的早期响应，并将回复流式发送给 TTS。
  • 唤醒词和麦克风质量仍是实际痛点；带唤醒词模型和 I2S 麦克风的 ESP32-S3 设备是很受欢迎的实验方向。