基于大模型的语音助手控制智能家居
内容提要
本文介绍了作者如何创建一个本地运行的智能助手来控制家庭设备，具有幽默和讽刺的性格。作者详细介绍了硬件和软件架构，并解决了一些技术问题。最终成功创建了一个能够控制家庭设备并回答问题的智能助手。
延伸解读
本地推理的硬件取舍
作者使用4060Ti显卡运行Mixtral模型，因显存有限而选择量化版本。在GPTQ（10800令牌上下文）和AWQ（6000令牌上下文）之间，作者为传递完整智能家居状态而选择GPTQ，牺牲了部分质量。这体现了本地部署大模型时，硬件资源与功能需求之间的现实权衡。
提示词工程实现个性与功能
通过精心设计的Chat模板，作者将GlaDOS的讽刺性格与智能家居控制结合。模板要求回答简短、讽刺、逐步不耐烦，并禁止使用列表或Markdown，以适应语音播报。同时，通过条件判断和JSON输出，模型能区分问答与控制指令，实现自然交互。
vLLM作为推理引擎的优势
作者选择vLLM因其速度快且支持多客户端并发，并提供OpenAI兼容API，简化了集成。这使得本地助手能同时服务多个请求，提升了实用性。对于需要实时响应的智能家居控制，推理引擎的效率至关重要。
Q&A
为什么作者要自己做一个本地智能助手，而不用Siri或Google Assistant？
因为Siri和Google Assistant虽然能控制设备，但无法定制，且本质上依赖云服务。作者希望拥有一个完全在本地运行、可个性化定制、不依赖云的智能助手，同时也能学习新东西并拥有一个很酷的实用工具。
作者用了哪些硬件来搭建这个本地智能助手？
作者使用了Protectli Vault VP2420和TRENDnet TEG-3102WS等设备来搭建本地智能助手的硬件架构。
为什么选择vLLM作为推理引擎？
作者选择vLLM是因为它的速度非常快，而且是他发现的唯一一个可以同时为多个客户端提供服务的引擎。它还支持与OpenAI兼容的API服务器，这让集成变得更加容易。
作者为什么选择Mixtral模型的量化版本而不是完整版？
因为完整的fp32模型需要超过100GB的VRAM，作者的4060Ti无法运行。量化版本虽然会稍微降低质量（类似MP3压缩），但能大幅降低资源需求。作者在GPTQ（10800令牌上下文）和AWQ（6000令牌上下文）之间选择了GPTQ，因为需要将整个智能家居状态传递给模型，需要更大的上下文。
如何让智能助手具有GlaDOS式的幽默和讽刺性格？
作者通过修改Chat模板来实现。在系统提示中明确要求助手以GlaDOS的语气回应：冷漠、简洁、讽刺、逐渐不耐烦、暗示用户会痛苦地死去、避免列表和Markdown、适合文本转语音朗读等。同时添加JSON支持，使助手能根据用户意图输出控制智能家居的JSON指令。
这个智能助手能控制哪些类型的智能家居设备？
根据文章中的模板和示例，助手可以控制灯光（如客厅、卧室、办公室的灯）、咖啡机、洗衣机、烘干机等设备，还能查询温度、设备状态（如游戏PC是否开启、某人是否在家），并支持场景模式（如颜色循环、派对模式）的启用和禁用。
