关键要点
- 智能家居控制是一项狭窄的任务（解析指令→调用函数），小型模型能很好地胜任
- 小型模型（大约10亿-40亿参数）在配置一般的本地硬件上延迟更低——一颗给力的iGPU/NPU就够用
- 对于这项特定工作，函数调用的准确性比通识知识的广度更重要
- 更大的模型对开放式问题仍然有用——需要时系统可单独路由过去
- 具体的当前模型推荐请参见智能家居控制最佳本地LLM模型简明清单
为什么小模型在这里更胜一筹
延迟是语音控制的决定性因素——智能家居指令需要接近实时执行，而在本地硬件上，小型模型的响应速度比大型模型在相同硬件上的响应速度更快。
- 大型模型每生成一个token所需的计算量要大得多，这直接转化为在相同本地硬件上更慢的响应速度——表现为从说出指令到灯真正亮起之间可察觉的延迟。
- 智能家居指令通常简短且结构化（"关闭卧室的灯""把温控器设到20度"），并不需要大型模型所提供的更广泛的推理能力或知识库。
- 在本地运行小型模型也意味着更低的硬件要求——关于适合小型模型的设备与更大模型所需设备的区别，请参见本地智能家居最佳硬件指南。
函数调用是关键能力
对智能家居控制真正重要的能力是可靠的函数调用——把自然语言转化为对特定Home Assistant服务的、结构正确的调用，而不是通用的对话能力。
- 一个经过微调或本身就擅长函数调用的模型，能够可靠地将"让客厅暖和一点"映射到正确的气候控制服务调用，这是一项比开放式聊天质量更狭窄、也更可衡量的技能。
- 这也正是智能家居特有的幻觉风险显现的地方——关于如何将模型约束到实际可用的实体，请参见减少家庭自动化中LLM幻觉的指南。
- 在小型模型之间做选择时，应根据候选模型在你具体实体列表上的函数调用准确性来评估，而不是依据通用的基准分数。
小型模型的不足之处
小型模型是结构化指令解析的正确选择，但不适合开放式问题、复杂的多步推理，或需要广泛世界知识的任务。
- 如果你希望智能家居助手也能很好地回答一般性问题，一种常见模式是采用混合架构：将命令式输入路由给小型模型，把开放式问题路由给更大的模型（本地或其他方式）。
- 相比大型模型，小型模型更容易误解含糊不清的措辞——清晰一致的指令措辞和范围明确的实体名称，比单纯升级模型规模更能降低这一风险。
- 对于超出简单指令解析范围的自动化——跨多个传感器进行推理、判断某种异常模式是否值得发出通知——更大的模型可能确实值得付出额外的延迟，这取决于该自动化对时间的敏感程度。
这与模型推荐指南有何不同
本文解释了为什么小型模型是智能家居控制的正确架构选择；模型推荐简明清单则推荐了当前应实际使用的具体模型。
- 如果你想了解小型模型推荐背后的推理逻辑，请先阅读本文。
- 有关当前推荐的具体模型及其硬件要求，请参见智能家居控制最佳本地LLM模型指南。
- 有关移动设备专用的小型语言模型选项（一种不同的硬件场景），请参见跨系列的移动LLM模型指南。
常见问题
在智能家居控制方面，小型语言模型是否比大型模型准确性更低？
对这项特定任务而言未必如此——结构化指令的函数调用准确性，更多取决于模型对这项狭窄任务的适配程度，而非整体参数量。一个大型通用模型在解析"关灯"时，并不会自动比一个为此调优的小型模型更强。
本文所说的"小型"语言模型指多大的规模？
本文讨论的实用范围大约是10亿到40亿参数——足够小，能在迷你主机的集成显卡或NPU上响应灵敏地运行，无需独立显卡。
我可以在树莓派上运行小型模型吗？
非常小的模型可以在树莓派上运行，但速度较慢——关于树莓派与迷你主机在这项工作负载上的权衡，请参见本地智能家居最佳硬件指南。
开放式问题和指令是否需要不同的模型？
许多系统会分别路由这两类请求——小型模型快速处理指令解析，而如果你想要更广泛的对话能力，开放式问题可以路由给更大的本地或云端模型。这是一种架构选择，而非硬性要求。
这与减少家庭自动化中的幻觉有什么关系？
一个更小、范围明确的模型，只需要将指令映射到已知的实体列表，相比被要求进行更广泛推理的通用模型，本质上更不容易凭空捏造设备或误读状态——具体技巧请参见幻觉减少指南。
我应该使用哪些具体的小型模型？
具体的当前推荐请参见智能家居控制最佳本地LLM模型指南——本文讲的是规模选择背后的推理逻辑，而不是模型清单。
小型模型需要的内存更少吗？
是的——较少的参数量直接转化为更低的内存要求，这也是小型模型能在迷你主机的集成硬件上良好运行、而无需独立显卡的部分原因。