1. 家庭智能新形态为什么是 HomeAgent 而不是又一个 App这两年智能家居赛道最大的尴尬是硬件堆料越来越猛但用户体验始终在原地打转。手机里装七八个 App每个 App 对应一个生态灯光一个、窗帘一个、安防一个语音助手各喊各的设备之间基本靠用户当人肉网关。我家里那套智能设备就是典型——买的时候每个单品都挺聪明连在一起就集体降智。所以当“后摩智能×绿联 HomeAgent”这个组合出现的时候我第一反应是终于有人开始从芯片和系统的角度而不是从单品 App 的角度来想家庭智能这件事了。HomeAgent 这个名字挺直白——家里的智能代理它要解决的痛点也很明确让一个家庭只用一个大脑而不是一堆各自为政的遥控器。后摩智能做的是 AI 芯片绿联做的是 NAS 和网络存储设备这两家凑到一起做 HomeAgent本质上是在干一件事——把大模型能力从云端搬到家里让智能家居系统拥有一个本地化的、私有的、真正理解你这个家的 AI 中枢。它不是往手机里再塞一个 App也不是往音箱里再堆一个语音助手而是让家庭里的数据、算力、模型和应用在一个私有环境里跑起来。这套思路的核心价值在于三个词本地化、私有化、场景化。本地化意味着响应速度不受云端的网络波动影响家里断网也能用私有化意味着家庭数据不出门摄像头画面、门锁记录、生活日志这些敏感信息不需要上传到别人的服务器场景化则是说它学的不是“通用世界知识”而是“我们家”的知识——比如你家孩子几点放学、客厅哪个角落光线最差、你的猫每天固定蹲在哪个位置。这篇文章我想从产品设计、技术实现、实际部署和问题排查几个层面把这套“家庭智能新形态”拆开聊一聊。对 NAS 玩家、智能家居爱好者或者想在自己家里跑本地大模型的朋友来说这套玩法应该能给你不少可落地的参考。2. 整体设计思路为什么需要“私有 AI 大脑”而不是云服务2.1 云智能的天花板网断了家就“傻”了先回顾一下现在绝大多数智能家居的运行逻辑。你对着音箱说“关灯”语音上传到云端云端识别语义下发指令灯灭。这一套流程平时看起来挺流畅但一旦宽带出问题、云服务商机房抖动、或者某个智能音箱品牌调整服务策略整个家立刻退化成手动模式。家里那个号称“智能”的中枢只是个遥控器。更麻烦的是数据隐私。家里装个摄像头、买个体重秤、用个智能门锁产生的数据统统先上云再说。你可能觉得无所谓但仔细想想——摄像头画面存在服务商手里睡眠数据、起居时间、出入记录都在别人数据库里躺着这本身就是个隐患。国内智能家居厂商这些年也在强调隐私但架构上天生的“云优先”决定了数据必须过一道手。后摩智能和绿联这次做的 HomeAgent选了一条相反的路线把 AI 能力放到家里让数据在本地闭环。设备产生的数据在本地的 NAS 里完成存储和处理大模型推理在本地芯片上完成只有在需要外部知识的时候才主动去碰云端。这一套下来核心场景完全自给自足断网反而成了最能体现价值的时候。2.2 后摩智能在里面的角色边缘算力的核心引擎后摩智能做的是 AI 芯片但它的定位和常规的 NPU 不太一样——主打量产落地的边缘端大模型推理。也就是说它不是那种几十上百瓦的云端训练卡而是功耗、价格、算力都卡在“适合放到家里”这个区间里的推理芯片。HomeAgent 这种产品形态对算力的要求其实很微妙。太弱的芯片跑不动大模型动辄几十瓦的显卡放在家庭环境又完全不现实毕竟不是每个家庭都有专门的设备间和足够的散热条件。后摩智能的芯片在这个维度上做了平衡——能跑百亿参数级别以下的模型功耗控制在消费级设备能接受的范围内同时支持常见的主流模型架构。这意味着你在家里跑一个 7B 或者 14B 的对话模型不需要一台插着 RTX 4090 的服务器一台体积正常的 NAS 或者边缘主机就能搞定。绿联在 HomeAgent 里的角色则是把这个芯片变成一套普通用户能用的产品。绿联这些年从硬盘盒做到 NAS最大的积累在于存储、网络、文件系统和消费级产品的整体设计能力。NAS 是天然的家庭数据中心机身里塞一块后摩智能的推理芯片再配套一套软件系统就能把一个“存文件”的设备升级成“能思考”的家庭大脑。2.3 绿联 NAS 的价值从“存数据的盒子”到“理解家庭的系统”如果你用过绿联的 NAS 产品应该知道它的界面做得比传统 NAS 友好不少普通用户不需要敲命令行也能完成基本配置。这种产品化能力在 HomeAgent 这个项目里比“性能参数”更重要——因为目标用户不只是折腾 NAS 的极客还有只想“让家更聪明”的普通家庭。我理解这套系统的设计意图是把 NAS 从“存储工具”变成“家庭服务底座”。存储、计算、模型推理、设备联动这些都变成 NAS 上的基础能力。用户的家庭相册、监控录像、设备日志、语音交互记录全部沉淀在本地模型基于这些数据提供个性化服务——比如问你“上周三晚上客厅有人吗”它能直接基于本地录像推理回答而不是给你甩一堆 App 里的时间轴。2.4 与传统智能家居的差异化系统联动 vs 单品控制传统智能家居是“单品控制”逻辑每个设备一个 App每个 App 一套云HomeAgent 是“系统联动”逻辑整个家庭是一套系统设备只是这套系统的传感器和执行器。打个比方传统智能家居像你雇了五六个各管一摊的保姆每个保姆只认自己的活儿互相之间不通气HomeAgent 更像是你家装了一个大管家这个管家认识你们家所有人知道每个房间的情况能自己拿主意——而且这个大管家住你家不用每天把家里情况打电话汇报给外面的公司。这种差异落到实际体验上特别明显。传统模式下你想实现“晚上回家开门后客厅灯亮、窗帘拉起、空调调到 26 度、音箱开始放轻音乐”得靠场景自动化规则一条条拼每个设备都要单独设置出错了还很难排查。HomeAgent 的方式则是让模型理解“主人回家了”这个意图自己去调用对应的设备接口适配当天的天气、时间、甚至你的心情——这是一种从“规则驱动”到“意图驱动”的转变。3. 核心细节解析HomeAgent 里的模型、私有数据和算力调度3.1 模型选型先弄清楚跑什么模型再谈智能水平HomeAgent 这套体系里模型是大脑的软件载体。目前这个项目透露出来的技术路线走的是“小模型专用化 大模型泛化”的组合方案。专用小模型负责家庭场景里高频、确定性强的任务比如语音唤醒、关键词识别、设备状态判断、人脸识别。这类任务用参数量很小的模型就能做得又快又准在边缘芯片上跑得非常流畅功耗也低适合常驻运行。泛化大模型负责真正需要“理解”的任务比如“帮我查一下上周厨房摄像头拍到过几次人走动”“根据最近的能耗情况帮我规划一下空调开关时间”——这种开放式、需要推理的任务靠小模型的规则匹配做不到需要大模型具备语言理解和多步推理能力。这类模型参数量大、计算量大不需要常驻运行但需要做到“随叫随到”。这套“双模型协同”的思路和一个通用大模型硬扛所有任务的方案相比优势在三点功耗低、响应快、容错高。常驻的小模型只需很小的算力大模型按需加载整体功耗能压到消费级设备能接受的范围内。而模型层做了模块化普通用户甚至可以根据自己家的设备情况选择不同版本的模型组合。3.2 私有知识库让模型认识你的家模型本身是“通用智能”但家庭场景需要的是“专属智能”。要让模型知道你的家是什么样的需要给模型提供家庭相关的上下文信息这就是私有知识库的用武之地。HomeAgent 里的私有知识库建设过程大致是这样的系统先把家里的设备拓扑、房间分布、人员信息、自动化规则、历史记录等数据规范化存入本地数据库当用户向模型提问或下指令时系统先从知识库里检索相关的上下文信息把这些信息连同用户的问题一起拼接成 Prompt再交给大模型做推理。这套流程在技术圈里叫RAG全称是 Retrieval-Augmented Generation检索增强生成。RAG 的好处是不用重新训练模型。大模型还是那个通用模型但每次回答问题时都能“临时翻查”你家的专属资料。比如模型本身不知道你家客厅朝南还是朝北但知识库里记录了这一条检索到之后模型就能基于这个信息给出更靠谱的开关窗帘建议。绿联 NAS 本身就擅长管理结构化数据和文件存储把私域知识库建在 NAS 上是顺理成章的。相册、语音记录、设备日志这些非结构化数据存放在 NAS 的存储池里向量化之后灌入向量数据库检索的时候按语义相似度召回。这块包含了不少工程细节后面我会写一篇专门的实操笔记展开讲。3.3 算力调度与功耗控制边缘推理不是把显卡塞进 NAS先说一个认知误区——很多人觉得“本地跑大模型”就是把一块大显卡塞进 NAS 机箱里这就想得太简单了。NAS 要常年 7×24 小时开机功耗和噪音是硬约束。你放一张 350W 的显卡在家里电费先不说那个风扇噪音你一个星期就受不了。HomeAgent 这类方案更现实的路径是对算力做分层调度。简单的推理任务用芯片上的低功耗核来跑复杂的任务才启动高性能核做加速计算任务结束后高性能核可以完全关断只保留低功耗常驻核。这种机制对软硬件协同设计的要求很高——芯片要支持动态电压频率调节系统软件要能在毫秒级别切换不同功耗档位。另外模型精度也有讲究。家用场景对绝对精度没有那么高的要求但非常在意延迟和功耗。用 INT8 甚至 INT4 量化后的模型体积能缩小到 FP16 模型的一半甚至四分之一推理速度更快功耗也更低。后摩智能这类主打端侧推理的芯片通常都对低精度计算做了专门优化实际跑起来比“通用芯片硬跑大模型”的体验要顺滑很多。3.4 家庭数据安全与隐私边界本地化带来的直接收益就是隐私保护。HomeAgent 的系统架构里用户的家庭数据默认留在本地模型推理也在本地完成云端只承担必要的外部服务调用——比如查天气、查菜谱这种本身就依赖外部数据的请求。但这不代表本地化之后就万事大吉。本地系统同样需要考虑访问控制、数据加密、攻击面管理的问题。NAS 设备本身暴露在家庭网络中如果网络里有其他不安全设备或者用户把 NAS 的管理端口暴露到了公网依然存在被入侵的风险。所以我一直建议所有本地 AI 系统都要默认假设网络环境不可信做好分区和权限隔离。后面我会专门列一个安全配置清单。4. 实操过程在绿联 NAS 上部署一个最小可用的本地 AI 服务4.1 准备工作硬件要求与系统环境要说清楚实际部署得先有一个能落地的平台。后摩智能和绿联的合作产品现在还在导入阶段但基于现有的绿联 NAS 设备我们完全可以抢先搭一套“HomeAgent 最小可用版”——本质上是把大模型跑在绿联 NAS 上私有知识库和模型调用都放在本地实现一个基础版的家庭智能问答与联动控制。硬件方面我建议准备一台至少 x86 架构、内存 16GB 以上的绿联 NAS。模型推理非常吃内存尤其是加载 7B 模型并执行推理时内存占用能到 68GB这还没算 NAS 本身的系统、存储服务和其他 App 的开销。如果你打算跑 14B 模型内存建议直接上到 32GB。软件层面绿联 NAS 的系统基于 Linux官方提供了 Docker 支持这是运行本地大模型服务最方便的路径。我用的是绿联私有云系统在应用中心里启用了 Docker然后在 Docker 里跑开源推理框架比如 Ollama 或者 LocalAI。这类框架对硬件的要求比较宽松能自动检测环境中的 GPU 或者 NPU 加速设备没有的话也可以用 CPU 硬扛只是速度和功耗要有所妥协。提示如果只是体验性质不必一上来就追求顶配。先跑一个 1.5B3B 的小模型把全链路摸通了再逐步换大模型。直接上大模型调试成本高容易劝退。4.2 部署流程从拉取镜像到跑通第一个对话第一步在绿联 NAS 的应用中心里启用 Docker。不同型号的绿联 NAS 入口位置略有区别但基本都在“应用中心”→“Docker”这个菜单下。启用之后点击“镜像”→“拉取镜像”搜索 ollama/ollama选择带版本号的官方镜像拉取。拉镜像这一步可能会踩坑——国内网络环境下Docker Hub 的访问速度不稳定大镜像Ollama 的镜像不算大几百 MB 左右容易超时。我当时的处理办法是在镜像加速器配置里填了几个可用的镜像源地址重新拉取之后速度就正常了。这个操作在 Docker 的设置界面里就能改不需要 SSH 进后台。镜像拉取完成后创建容器。关键配置如下端口映射宿主机的 11434 端口映射到容器的 11434 端口这是 Ollama 默认的 API 端口。目录挂载把 NAS 上某个存储空间挂载到容器内的 /root/.ollama这个目录用来存放模型文件。好处是 Docker 容器本身可以随时重建但模型文件不会丢。环境变量如果内存充裕可以设置 OLLAMA_KEEP_ALIVE 来控制模型在内存中保持加载的时间。默认情况下模型处理完一次请求后会在内存里停留几分钟避免频繁加载。容器启动成功后进入容器终端或者直接通过 SSH 操作宿主机执行ollama pull qwen2.5:3b。这里选通义千问的 3B 版本是因为它对中文支持好模型体积大约 2GB 左右家用 NAS 的 CPU 也能在几秒内完成一轮对话。拉取完成后执行ollama run qwen2.5:3b输入“你好”能正常回复就说明部署成功了。4.3 接入家庭知识库用向量检索让模型“认识”你的家模型能对话只是第一步要让它真正服务家庭还得给它喂“家庭知识”。这一步我用的是 RAG 方案。先跑一个向量数据库容器像 Qdrant 或者 Milvus Lite 都行资源占用都不大。然后写一段脚本把家庭的设备清单、房间结构、常用自动化规则等结构化信息以及家庭手册、设备说明书这类文档分割成 chunk用嵌入模型转成向量写入向量数据库。之后每次向大模型提问流程是这样的把用户的问题先做向量嵌入在向量数据库里做相似度检索取回最相关的家庭知识片段然后拼接 Prompt 发给大模型。大模型基于这些上下文信息才能给出贴合家庭实际情况的回答。这个流程跑通之后你就可以问“我家客厅的灯支持色温调节吗”系统会先检索知识库中有关“客厅”和“灯”的条目再带着这些上下文去询问大模型最后给出的答案就不再是“我无法回答”了。嵌入模型的选择上我用的 BGE 系列的中文嵌入模型它体积很小CPU 上就能跑检索效果在中文场景下属于第一梯队。嵌入模型常驻内存占用大约 300500MB对 NAS 来说压力不大。4.4 接入家庭设备联动把问答变成行动到了这一步系统已经能“回答问题”了但还谈不上“智能家庭”。更进一步的玩法是把大模型的输出对接上设备控制接口。绿联 NAS 的智能家居集成能力目前还在逐步完善但通用的路径是通过 MQTT 协议或 HTTP API 对接家里的智能设备网关比如 Home Assistant。思路是大模型理解用户意图后输出结构化的指令比如开灯、关空调、调亮度系统再把这个指令转换成对应平台的 API 调用。这一步的典型问题是“幻觉”。大模型可能编造一个不存在的设备名称或者理解错了设备状态。我的经验是在 Prompt 里明确给出可操作设备的完整清单和状态字段并约束模型只能从清单中选择设备不能自由发挥。同时在系统层面做一道校验如果模型输出的设备 ID 不在清单里直接拒绝执行并请用户重新描述。我搭的最小可用版最终做到了这样的体验对系统说“离家的时候记得关掉客厅的灯和空调”系统会先在设备清单里检索出“客厅主灯”“客厅空调”再生成执行序列然后调用 MQTT 接口下发指令。整个过程不经过任何云服务延迟在 2 秒以内。5. 常见问题与排查技巧本地 AI 部署最容易踩的五个坑5.1 容器日志看不到内容怎么排查Docker 容器启动了但 ollama 的日志里没有任何输出这种情况多半是容器内部服务没起来或者端口监听异常。先检查容器状态docker ps -a如果容器状态是 Exited用docker logs 容器名看退出原因常见的是目录挂载权限问题——宿主机的挂载目录没有给足读写权限容器内进程无法写入。另外有个容易忽略的点绿联 NAS 的 Docker 管理界面里创建容器时如果勾选了“与宿主机共享网络”这种网络模式端口映射就不生效了。这种情况下要用容器 IP 而不是 localhost 访问服务。排查时先确认网络模式再确认 API 端口能通curl http://localhost:11434/api/tags能返回 JSON 就说明服务正常。5.2 模型下载速度慢或者拉取失败ollama pull卡在下载阶段大部分原因还是网络问题。模型文件存放在境外对象存储上下载速度受网络环境影响很大。解决思路有三个配置镜像加速器Docker Hub 本身可以加速但 Ollama 的模型下载不走 Docker Hub而是走 registry.ollama.ai这个域名目前没有通行的加速方案。手动下载模型文件然后导入在另一台网络环境更好的机器上把模型文件下载好传到 NAS 上再用ollama create命令从本地文件导入模型。这个方法麻烦一点但最可靠。换用支持从 Hugging Face 下载模型的推理框架如 LocalAIHugging Face 在国内环境也有镜像站下载难度会低一些。5.3 推理速度慢CPU 跑模型如何优化家用 NAS 如果没有独立 GPU 或 NPU纯 CPU 推理的速度确实感人。3B 模型生成一段 100 字的回答可能需要 30 秒左右14B 模型会慢到难以忍受。优化手段有几条降低模型精度。用 q4 量化版本的模型文件推理速度能提升 12 倍显存占用下降一半。限制上下文长度。Ollama 默认的上下文长度是 2048如果不需要太长对话历史保持默认即可。上下文越长计算量越大。关闭其他高负载容器。NAS 上同时跑着下载任务、相册索引任务时CPU 资源被抢占推理速度会进一步恶化。优先保证推理容器的 CPU 配额。5.4 知识库检索不到相关内容RAG 系统里经常出现“感觉模型没看过知识库”的情况。排查顺序如下先检查向量数据库里有没有数据查一下 collection 的 count为 0 说明写入部分出了问题。检查嵌入模型是否正常工作。嵌入模型本身也是一个小模型如果嵌入模型服务没起来所有文档写入都会失败。检查 chunk 切分逻辑。如果一段文本太长比如把整本说明书当成一个 chunk嵌入后的向量检索命中率会很低。建议 chunk 长度控制在 300500 字之间覆盖相邻业务逻辑的内容放在同一个 chunk 里。5.5 设备联动指令不生效模型已经输出了“打开客厅灯”这样的指令但设备没反应。这种问题通常不在模型侧而在指令翻译层。先手动调用一下设备平台的 API确认接口本身可用再确认指令格式和平台要求的格式是否一致——有些平台用 JSON-RPC有些用 RESTful还有的要求先鉴权。另一个隐蔽的坑是权限问题NAS 上运行的容器如果需要调外部 API出网权限要放行。绿联 NAS 的 Docker 默认网络模式是桥接容器访问外部网络没问题但如果开了防火墙策略就要检查出站规则。6. 对整个行业的思考边缘 AI 会不会成为智能家居的标配我把这套 HomeAgent 的方案在本地完整跑了一遍之后最大的感受是智能家居行业折腾了这么多年一直缺的不是智能而是“隐私前提下的大模型能力”。前些年的智能音箱、智能中控屏本质上是把语音助手放到家里但数据和逻辑都在云端用户体验受制于网络和服务商策略。HomeAgent 的本地化路线等于把大模型这块最后短板也补上了。而且从成本结构上看边缘 AI 也在变得越来越可行。以前说“本地跑大模型”大家第一反应是买显卡、改机箱、搞水冷那是极客玩法。但随着后摩智能这类端侧推理芯片的量产以及 NAS 厂商把推理能力做成标准功能普通家庭用户很快也能享受到“买一台 NAS 就送 AI 大脑”的体验。这不需要用户懂技术厂商已经把复杂都封装在产品里了。当然这套方案的挑战也很明显——模型能力相比云端大模型还是有差距家庭场景复杂的多轮对话、多设备协同对模型泛化能力的要求很高本地算力决定了无法运行超大参数的模型这也是为什么 HomeAgent 这类系统需要持续在“小模型效果优化”上投入。但方向对了剩下的都是工程问题。从我自己的实际体验来说把大模型跑在自己家里的意义并不只是一个“能聊天的 NAS”而是重新拿回了对家庭数据的控制权。你不需要担心哪天某个云服务商调整政策导致设备失灵也不需要担心敏感数据被拿去训练别人的模型。这个价值越用得久越有体会。接下来我会继续在这个平台上尝试接入更多设备用真实场景检验这套方案的边界在哪里。 HomeAgent：NAS与边缘AI芯片驱动的私有化智能家居大脑
1. 家庭智能新形态为什么是 HomeAgent 而不是又一个 App这两年智能家居赛道最大的尴尬是硬件堆料越来越猛但用户体验始终在原地打转。手机里装七八个 App每个 App 对应一个生态灯光一个、窗帘一个、安防一个语音助手各喊各的设备之间基本靠用户当人肉网关。我家里那套智能设备就是典型——买的时候每个单品都挺聪明连在一起就集体降智。所以当“后摩智能×绿联 HomeAgent”这个组合出现的时候我第一反应是终于有人开始从芯片和系统的角度而不是从单品 App 的角度来想家庭智能这件事了。HomeAgent 这个名字挺直白——家里的智能代理它要解决的痛点也很明确让一个家庭只用一个大脑而不是一堆各自为政的遥控器。后摩智能做的是 AI 芯片绿联做的是 NAS 和网络存储设备这两家凑到一起做 HomeAgent本质上是在干一件事——把大模型能力从云端搬到家里让智能家居系统拥有一个本地化的、私有的、真正理解你这个家的 AI 中枢。它不是往手机里再塞一个 App也不是往音箱里再堆一个语音助手而是让家庭里的数据、算力、模型和应用在一个私有环境里跑起来。这套思路的核心价值在于三个词本地化、私有化、场景化。本地化意味着响应速度不受云端的网络波动影响家里断网也能用私有化意味着家庭数据不出门摄像头画面、门锁记录、生活日志这些敏感信息不需要上传到别人的服务器场景化则是说它学的不是“通用世界知识”而是“我们家”的知识——比如你家孩子几点放学、客厅哪个角落光线最差、你的猫每天固定蹲在哪个位置。这篇文章我想从产品设计、技术实现、实际部署和问题排查几个层面把这套“家庭智能新形态”拆开聊一聊。对 NAS 玩家、智能家居爱好者或者想在自己家里跑本地大模型的朋友来说这套玩法应该能给你不少可落地的参考。2. 整体设计思路为什么需要“私有 AI 大脑”而不是云服务2.1 云智能的天花板网断了家就“傻”了先回顾一下现在绝大多数智能家居的运行逻辑。你对着音箱说“关灯”语音上传到云端云端识别语义下发指令灯灭。这一套流程平时看起来挺流畅但一旦宽带出问题、云服务商机房抖动、或者某个智能音箱品牌调整服务策略整个家立刻退化成手动模式。家里那个号称“智能”的中枢只是个遥控器。更麻烦的是数据隐私。家里装个摄像头、买个体重秤、用个智能门锁产生的数据统统先上云再说。你可能觉得无所谓但仔细想想——摄像头画面存在服务商手里睡眠数据、起居时间、出入记录都在别人数据库里躺着这本身就是个隐患。国内智能家居厂商这些年也在强调隐私但架构上天生的“云优先”决定了数据必须过一道手。后摩智能和绿联这次做的 HomeAgent选了一条相反的路线把 AI 能力放到家里让数据在本地闭环。设备产生的数据在本地的 NAS 里完成存储和处理大模型推理在本地芯片上完成只有在需要外部知识的时候才主动去碰云端。这一套下来核心场景完全自给自足断网反而成了最能体现价值的时候。2.2 后摩智能在里面的角色边缘算力的核心引擎后摩智能做的是 AI 芯片但它的定位和常规的 NPU 不太一样——主打量产落地的边缘端大模型推理。也就是说它不是那种几十上百瓦的云端训练卡而是功耗、价格、算力都卡在“适合放到家里”这个区间里的推理芯片。HomeAgent 这种产品形态对算力的要求其实很微妙。太弱的芯片跑不动大模型动辄几十瓦的显卡放在家庭环境又完全不现实毕竟不是每个家庭都有专门的设备间和足够的散热条件。后摩智能的芯片在这个维度上做了平衡——能跑百亿参数级别以下的模型功耗控制在消费级设备能接受的范围内同时支持常见的主流模型架构。这意味着你在家里跑一个 7B 或者 14B 的对话模型不需要一台插着 RTX 4090 的服务器一台体积正常的 NAS 或者边缘主机就能搞定。绿联在 HomeAgent 里的角色则是把这个芯片变成一套普通用户能用的产品。绿联这些年从硬盘盒做到 NAS最大的积累在于存储、网络、文件系统和消费级产品的整体设计能力。NAS 是天然的家庭数据中心机身里塞一块后摩智能的推理芯片再配套一套软件系统就能把一个“存文件”的设备升级成“能思考”的家庭大脑。2.3 绿联 NAS 的价值从“存数据的盒子”到“理解家庭的系统”如果你用过绿联的 NAS 产品应该知道它的界面做得比传统 NAS 友好不少普通用户不需要敲命令行也能完成基本配置。这种产品化能力在 HomeAgent 这个项目里比“性能参数”更重要——因为目标用户不只是折腾 NAS 的极客还有只想“让家更聪明”的普通家庭。我理解这套系统的设计意图是把 NAS 从“存储工具”变成“家庭服务底座”。存储、计算、模型推理、设备联动这些都变成 NAS 上的基础能力。用户的家庭相册、监控录像、设备日志、语音交互记录全部沉淀在本地模型基于这些数据提供个性化服务——比如问你“上周三晚上客厅有人吗”它能直接基于本地录像推理回答而不是给你甩一堆 App 里的时间轴。2.4 与传统智能家居的差异化系统联动 vs 单品控制传统智能家居是“单品控制”逻辑每个设备一个 App每个 App 一套云HomeAgent 是“系统联动”逻辑整个家庭是一套系统设备只是这套系统的传感器和执行器。打个比方传统智能家居像你雇了五六个各管一摊的保姆每个保姆只认自己的活儿互相之间不通气HomeAgent 更像是你家装了一个大管家这个管家认识你们家所有人知道每个房间的情况能自己拿主意——而且这个大管家住你家不用每天把家里情况打电话汇报给外面的公司。这种差异落到实际体验上特别明显。传统模式下你想实现“晚上回家开门后客厅灯亮、窗帘拉起、空调调到 26 度、音箱开始放轻音乐”得靠场景自动化规则一条条拼每个设备都要单独设置出错了还很难排查。HomeAgent 的方式则是让模型理解“主人回家了”这个意图自己去调用对应的设备接口适配当天的天气、时间、甚至你的心情——这是一种从“规则驱动”到“意图驱动”的转变。3. 核心细节解析HomeAgent 里的模型、私有数据和算力调度3.1 模型选型先弄清楚跑什么模型再谈智能水平HomeAgent 这套体系里模型是大脑的软件载体。目前这个项目透露出来的技术路线走的是“小模型专用化 大模型泛化”的组合方案。专用小模型负责家庭场景里高频、确定性强的任务比如语音唤醒、关键词识别、设备状态判断、人脸识别。这类任务用参数量很小的模型就能做得又快又准在边缘芯片上跑得非常流畅功耗也低适合常驻运行。泛化大模型负责真正需要“理解”的任务比如“帮我查一下上周厨房摄像头拍到过几次人走动”“根据最近的能耗情况帮我规划一下空调开关时间”——这种开放式、需要推理的任务靠小模型的规则匹配做不到需要大模型具备语言理解和多步推理能力。这类模型参数量大、计算量大不需要常驻运行但需要做到“随叫随到”。这套“双模型协同”的思路和一个通用大模型硬扛所有任务的方案相比优势在三点功耗低、响应快、容错高。常驻的小模型只需很小的算力大模型按需加载整体功耗能压到消费级设备能接受的范围内。而模型层做了模块化普通用户甚至可以根据自己家的设备情况选择不同版本的模型组合。3.2 私有知识库让模型认识你的家模型本身是“通用智能”但家庭场景需要的是“专属智能”。要让模型知道你的家是什么样的需要给模型提供家庭相关的上下文信息这就是私有知识库的用武之地。HomeAgent 里的私有知识库建设过程大致是这样的系统先把家里的设备拓扑、房间分布、人员信息、自动化规则、历史记录等数据规范化存入本地数据库当用户向模型提问或下指令时系统先从知识库里检索相关的上下文信息把这些信息连同用户的问题一起拼接成 Prompt再交给大模型做推理。这套流程在技术圈里叫RAG全称是 Retrieval-Augmented Generation检索增强生成。RAG 的好处是不用重新训练模型。大模型还是那个通用模型但每次回答问题时都能“临时翻查”你家的专属资料。比如模型本身不知道你家客厅朝南还是朝北但知识库里记录了这一条检索到之后模型就能基于这个信息给出更靠谱的开关窗帘建议。绿联 NAS 本身就擅长管理结构化数据和文件存储把私域知识库建在 NAS 上是顺理成章的。相册、语音记录、设备日志这些非结构化数据存放在 NAS 的存储池里向量化之后灌入向量数据库检索的时候按语义相似度召回。这块包含了不少工程细节后面我会写一篇专门的实操笔记展开讲。3.3 算力调度与功耗控制边缘推理不是把显卡塞进 NAS先说一个认知误区——很多人觉得“本地跑大模型”就是把一块大显卡塞进 NAS 机箱里这就想得太简单了。NAS 要常年 7×24 小时开机功耗和噪音是硬约束。你放一张 350W 的显卡在家里电费先不说那个风扇噪音你一个星期就受不了。HomeAgent 这类方案更现实的路径是对算力做分层调度。简单的推理任务用芯片上的低功耗核来跑复杂的任务才启动高性能核做加速计算任务结束后高性能核可以完全关断只保留低功耗常驻核。这种机制对软硬件协同设计的要求很高——芯片要支持动态电压频率调节系统软件要能在毫秒级别切换不同功耗档位。另外模型精度也有讲究。家用场景对绝对精度没有那么高的要求但非常在意延迟和功耗。用 INT8 甚至 INT4 量化后的模型体积能缩小到 FP16 模型的一半甚至四分之一推理速度更快功耗也更低。后摩智能这类主打端侧推理的芯片通常都对低精度计算做了专门优化实际跑起来比“通用芯片硬跑大模型”的体验要顺滑很多。3.4 家庭数据安全与隐私边界本地化带来的直接收益就是隐私保护。HomeAgent 的系统架构里用户的家庭数据默认留在本地模型推理也在本地完成云端只承担必要的外部服务调用——比如查天气、查菜谱这种本身就依赖外部数据的请求。但这不代表本地化之后就万事大吉。本地系统同样需要考虑访问控制、数据加密、攻击面管理的问题。NAS 设备本身暴露在家庭网络中如果网络里有其他不安全设备或者用户把 NAS 的管理端口暴露到了公网依然存在被入侵的风险。所以我一直建议所有本地 AI 系统都要默认假设网络环境不可信做好分区和权限隔离。后面我会专门列一个安全配置清单。4. 实操过程在绿联 NAS 上部署一个最小可用的本地 AI 服务4.1 准备工作硬件要求与系统环境要说清楚实际部署得先有一个能落地的平台。后摩智能和绿联的合作产品现在还在导入阶段但基于现有的绿联 NAS 设备我们完全可以抢先搭一套“HomeAgent 最小可用版”——本质上是把大模型跑在绿联 NAS 上私有知识库和模型调用都放在本地实现一个基础版的家庭智能问答与联动控制。硬件方面我建议准备一台至少 x86 架构、内存 16GB 以上的绿联 NAS。模型推理非常吃内存尤其是加载 7B 模型并执行推理时内存占用能到 68GB这还没算 NAS 本身的系统、存储服务和其他 App 的开销。如果你打算跑 14B 模型内存建议直接上到 32GB。软件层面绿联 NAS 的系统基于 Linux官方提供了 Docker 支持这是运行本地大模型服务最方便的路径。我用的是绿联私有云系统在应用中心里启用了 Docker然后在 Docker 里跑开源推理框架比如 Ollama 或者 LocalAI。这类框架对硬件的要求比较宽松能自动检测环境中的 GPU 或者 NPU 加速设备没有的话也可以用 CPU 硬扛只是速度和功耗要有所妥协。提示如果只是体验性质不必一上来就追求顶配。先跑一个 1.5B3B 的小模型把全链路摸通了再逐步换大模型。直接上大模型调试成本高容易劝退。4.2 部署流程从拉取镜像到跑通第一个对话第一步在绿联 NAS 的应用中心里启用 Docker。不同型号的绿联 NAS 入口位置略有区别但基本都在“应用中心”→“Docker”这个菜单下。启用之后点击“镜像”→“拉取镜像”搜索 ollama/ollama选择带版本号的官方镜像拉取。拉镜像这一步可能会踩坑——国内网络环境下Docker Hub 的访问速度不稳定大镜像Ollama 的镜像不算大几百 MB 左右容易超时。我当时的处理办法是在镜像加速器配置里填了几个可用的镜像源地址重新拉取之后速度就正常了。这个操作在 Docker 的设置界面里就能改不需要 SSH 进后台。镜像拉取完成后创建容器。关键配置如下端口映射宿主机的 11434 端口映射到容器的 11434 端口这是 Ollama 默认的 API 端口。目录挂载把 NAS 上某个存储空间挂载到容器内的 /root/.ollama这个目录用来存放模型文件。好处是 Docker 容器本身可以随时重建但模型文件不会丢。环境变量如果内存充裕可以设置 OLLAMA_KEEP_ALIVE 来控制模型在内存中保持加载的时间。默认情况下模型处理完一次请求后会在内存里停留几分钟避免频繁加载。容器启动成功后进入容器终端或者直接通过 SSH 操作宿主机执行ollama pull qwen2.5:3b。这里选通义千问的 3B 版本是因为它对中文支持好模型体积大约 2GB 左右家用 NAS 的 CPU 也能在几秒内完成一轮对话。拉取完成后执行ollama run qwen2.5:3b输入“你好”能正常回复就说明部署成功了。4.3 接入家庭知识库用向量检索让模型“认识”你的家模型能对话只是第一步要让它真正服务家庭还得给它喂“家庭知识”。这一步我用的是 RAG 方案。先跑一个向量数据库容器像 Qdrant 或者 Milvus Lite 都行资源占用都不大。然后写一段脚本把家庭的设备清单、房间结构、常用自动化规则等结构化信息以及家庭手册、设备说明书这类文档分割成 chunk用嵌入模型转成向量写入向量数据库。之后每次向大模型提问流程是这样的把用户的问题先做向量嵌入在向量数据库里做相似度检索取回最相关的家庭知识片段然后拼接 Prompt 发给大模型。大模型基于这些上下文信息才能给出贴合家庭实际情况的回答。这个流程跑通之后你就可以问“我家客厅的灯支持色温调节吗”系统会先检索知识库中有关“客厅”和“灯”的条目再带着这些上下文去询问大模型最后给出的答案就不再是“我无法回答”了。嵌入模型的选择上我用的 BGE 系列的中文嵌入模型它体积很小CPU 上就能跑检索效果在中文场景下属于第一梯队。嵌入模型常驻内存占用大约 300500MB对 NAS 来说压力不大。4.4 接入家庭设备联动把问答变成行动到了这一步系统已经能“回答问题”了但还谈不上“智能家庭”。更进一步的玩法是把大模型的输出对接上设备控制接口。绿联 NAS 的智能家居集成能力目前还在逐步完善但通用的路径是通过 MQTT 协议或 HTTP API 对接家里的智能设备网关比如 Home Assistant。思路是大模型理解用户意图后输出结构化的指令比如开灯、关空调、调亮度系统再把这个指令转换成对应平台的 API 调用。这一步的典型问题是“幻觉”。大模型可能编造一个不存在的设备名称或者理解错了设备状态。我的经验是在 Prompt 里明确给出可操作设备的完整清单和状态字段并约束模型只能从清单中选择设备不能自由发挥。同时在系统层面做一道校验如果模型输出的设备 ID 不在清单里直接拒绝执行并请用户重新描述。我搭的最小可用版最终做到了这样的体验对系统说“离家的时候记得关掉客厅的灯和空调”系统会先在设备清单里检索出“客厅主灯”“客厅空调”再生成执行序列然后调用 MQTT 接口下发指令。整个过程不经过任何云服务延迟在 2 秒以内。5. 常见问题与排查技巧本地 AI 部署最容易踩的五个坑5.1 容器日志看不到内容怎么排查Docker 容器启动了但 ollama 的日志里没有任何输出这种情况多半是容器内部服务没起来或者端口监听异常。先检查容器状态docker ps -a如果容器状态是 Exited用docker logs 容器名看退出原因常见的是目录挂载权限问题——宿主机的挂载目录没有给足读写权限容器内进程无法写入。另外有个容易忽略的点绿联 NAS 的 Docker 管理界面里创建容器时如果勾选了“与宿主机共享网络”这种网络模式端口映射就不生效了。这种情况下要用容器 IP 而不是 localhost 访问服务。排查时先确认网络模式再确认 API 端口能通curl http://localhost:11434/api/tags能返回 JSON 就说明服务正常。5.2 模型下载速度慢或者拉取失败ollama pull卡在下载阶段大部分原因还是网络问题。模型文件存放在境外对象存储上下载速度受网络环境影响很大。解决思路有三个配置镜像加速器Docker Hub 本身可以加速但 Ollama 的模型下载不走 Docker Hub而是走 registry.ollama.ai这个域名目前没有通行的加速方案。手动下载模型文件然后导入在另一台网络环境更好的机器上把模型文件下载好传到 NAS 上再用ollama create命令从本地文件导入模型。这个方法麻烦一点但最可靠。换用支持从 Hugging Face 下载模型的推理框架如 LocalAIHugging Face 在国内环境也有镜像站下载难度会低一些。5.3 推理速度慢CPU 跑模型如何优化家用 NAS 如果没有独立 GPU 或 NPU纯 CPU 推理的速度确实感人。3B 模型生成一段 100 字的回答可能需要 30 秒左右14B 模型会慢到难以忍受。优化手段有几条降低模型精度。用 q4 量化版本的模型文件推理速度能提升 12 倍显存占用下降一半。限制上下文长度。Ollama 默认的上下文长度是 2048如果不需要太长对话历史保持默认即可。上下文越长计算量越大。关闭其他高负载容器。NAS 上同时跑着下载任务、相册索引任务时CPU 资源被抢占推理速度会进一步恶化。优先保证推理容器的 CPU 配额。5.4 知识库检索不到相关内容RAG 系统里经常出现“感觉模型没看过知识库”的情况。排查顺序如下先检查向量数据库里有没有数据查一下 collection 的 count为 0 说明写入部分出了问题。检查嵌入模型是否正常工作。嵌入模型本身也是一个小模型如果嵌入模型服务没起来所有文档写入都会失败。检查 chunk 切分逻辑。如果一段文本太长比如把整本说明书当成一个 chunk嵌入后的向量检索命中率会很低。建议 chunk 长度控制在 300500 字之间覆盖相邻业务逻辑的内容放在同一个 chunk 里。5.5 设备联动指令不生效模型已经输出了“打开客厅灯”这样的指令但设备没反应。这种问题通常不在模型侧而在指令翻译层。先手动调用一下设备平台的 API确认接口本身可用再确认指令格式和平台要求的格式是否一致——有些平台用 JSON-RPC有些用 RESTful还有的要求先鉴权。另一个隐蔽的坑是权限问题NAS 上运行的容器如果需要调外部 API出网权限要放行。绿联 NAS 的 Docker 默认网络模式是桥接容器访问外部网络没问题但如果开了防火墙策略就要检查出站规则。6. 对整个行业的思考边缘 AI 会不会成为智能家居的标配我把这套 HomeAgent 的方案在本地完整跑了一遍之后最大的感受是智能家居行业折腾了这么多年一直缺的不是智能而是“隐私前提下的大模型能力”。前些年的智能音箱、智能中控屏本质上是把语音助手放到家里但数据和逻辑都在云端用户体验受制于网络和服务商策略。HomeAgent 的本地化路线等于把大模型这块最后短板也补上了。而且从成本结构上看边缘 AI 也在变得越来越可行。以前说“本地跑大模型”大家第一反应是买显卡、改机箱、搞水冷那是极客玩法。但随着后摩智能这类端侧推理芯片的量产以及 NAS 厂商把推理能力做成标准功能普通家庭用户很快也能享受到“买一台 NAS 就送 AI 大脑”的体验。这不需要用户懂技术厂商已经把复杂都封装在产品里了。当然这套方案的挑战也很明显——模型能力相比云端大模型还是有差距家庭场景复杂的多轮对话、多设备协同对模型泛化能力的要求很高本地算力决定了无法运行超大参数的模型这也是为什么 HomeAgent 这类系统需要持续在“小模型效果优化”上投入。但方向对了剩下的都是工程问题。从我自己的实际体验来说把大模型跑在自己家里的意义并不只是一个“能聊天的 NAS”而是重新拿回了对家庭数据的控制权。你不需要担心哪天某个云服务商调整政策导致设备失灵也不需要担心敏感数据被拿去训练别人的模型。这个价值越用得久越有体会。接下来我会继续在这个平台上尝试接入更多设备用真实场景检验这套方案的边界在哪里。