有段时间没折腾本地大模型了直到有人把一块绿联NAS的配置单甩给我问能不能在上面跑DeepSeek。说实话这种把AI塞进小盒子的玩法听起来有点折腾但实际一旦跑通体验是真的不错。这次我就在绿联NASUGOS Pro系统上把DeepSeek通过Ollama部署起来再接进n8n工作流整个过程梳理一下给想在NAS上搞私有化大模型的朋友做个参考。这套方案的核心价值在于数据完全留在自己的设备里不依赖任何外部平台接口同时通过n8n把“本地大模型”变成工作流里的一个可调用环节。你可以让它每天自动整理文件摘要、当一个能接住群里消息的机器人、甚至做定时任务的内容改写。对注重隐私、又有自动化需求的人来说这基本上是最省心的一条自建路径。适合的读者有两类一类是手里正好有绿联NAS、想跑大模型又不知道从何下手的玩家另一类是已经在用n8n做自动化想把本地DeepSeek接进去、替代云端API的人。两种需求我这次都会讲到而且会尽量把踩过的坑都标出来。1. 方案整体思路NAS上跑大模型到底图什么1.1 为什么不在云端调用非要放本地很多人第一步会问DeepSeek官方API不是挺便宜的吗为什么非要在NAS上自己折腾一套这就得说清楚“本地部署”和“云端调用”的差别了。云端API胜在方便、模型大、响应快但数据往外送这件事对个人来说可能无所谓如果涉及公司内部资料、个人笔记、客户信息很多人是不愿意走外部接口的。本地部署就没有这个心理负担模型跑在自家内网请求不出门哪怕断网都能用——这是它最不可替代的优势。另外还有一个很实际的原因虽然DeepSeek的API很便宜但它是按token计费的高频调用比如每小时跑一次批量总结、每天处理大量文本累积起来也是一笔费用。本地部署之后电费几乎可以忽略等于把“按次付费”变成了“一次性买断”。所以结论很明确这笔折腾是划算的。尤其是你本来就有NAS24小时开机资源闲着也是闲着把大模型跑在上面相当于白捡一个本地AI服务。1.2 方案全景Ollama、DeepSeek、n8n分别管哪一段三个核心组件分工非常清晰Ollama负责模型管理。它是一个极简的LLM运行工具拉模型、启动推理、暴露HTTP接口都是它的活。没有它你要手动下载模型权重、处理依赖、写推理代码那才是真的劝退。DeepSeek这里指的是deepseek-r1系列开源模型。在本地方案里它不是“App”而是被Ollama拉取并运行的一个本地模型文件。n8n工作流编排平台。它本身没有AI能力但可以发起HTTP调用把Ollama作为后端服务来使用。通过n8n画节点你可以搭出“收到消息→让DeepSeek处理→把结果发回”的自动化链条。这三个组件之间是解耦的Ollama只负责模型n8n只负责流程中间通过HTTP API通信。这样的好处是以后你想换模型比如从deepseek换成qwen、llamaOllama侧换一个名字就行n8n那边几乎不用改。1.3 为什么选绿联NAS当作部署基座绿联NAS的UGOS Pro系统内置了Docker Manager这对我这种“不想在NAS上装黑群晖、也不想写一堆Linux命令”的人来说非常友好。它能在图形界面里完成镜像拉取、容器创建、端口映射、存储挂载这些操作基础部署甚至不需要SSH。也就是说哪怕你没怎么用过Linux只要会跟着界面点也能把Ollama和n8n跑起来。硬件层面绿联NAS配置普遍能到8GB乃至16GB内存这正好卡在7B/14B级别模型的可运行范围。论盘位、散热这些常规NAS指标咱就不展开了单看“能装Docker 内存有升级空间”这两点它就足够胜任本地大模型的载体。2. 选型与硬件评估跑得动才是硬道理2.1 部署前先盘一盘NAS的家底动手之前最重要的一步不是看教程而是先看自己NAS的硬件配置。在UGOS Pro的“系统信息”里能直接看到CPU型号、内存和存储剩余空间先把这三个数据记下来。模型推理最吃的是内存。模型在推理时除了要把权重加载到内存里还要给上下文KV Cache和计算缓冲留出空间。经验公式大概是这样运行模型占用的内存 ≈ 模型文件大小 × 1.2 ~ 1.3。举个例子deepseek-r1:7b 这个模型的4-bit量化版文件大小约4.7GB那运行它至少需要5.5GB到6GB可用内存。如果NAS还跑着其他Docker容器内存占用就更紧。CPU影响的是生成速度。我用过的NAS设备里Intel N100、N5095这类新一点的处理器体验尚可7B模型大概每秒能生成几个token如果是J4125这种老处理器速度会明显慢不少但也不是不能用只是等待时间会长一些。生成速度这块后面再细说。建议如果你手里设备内存低于8GB优先跑1.5B或者3B级别的小模型别硬上7B不然系统容易卡到没法用。2.2 DeepSeek模型池怎么捞从1.5B到32B的取舍Ollama仓库里的deepseek-r1有多个尺寸常见的包括1.5b、7b、8b、14b、32b、70b。对NAS来说基本只有前三个是切实可行的。先给一个体感参考表基于常见NAS硬件配置的经验数据模型规格量化后体积约建议最低内存适用情况deepseek-r1:1.5b1.1GB4GB文本分类、简单问答、路由判断deepseek-r1:7b4.7GB8GB摘要、改写、情感分析、常规问答deepseek-r1:8b5.2GB8GB~12GB相比7B稍强差距不大deepseek-r1:14b9GB16GB长文本生成、逻辑推理速度变慢deepseek-r1:32b20GB32GB旗舰NAS可跑速度感人我的推荐是起步先跑7B。它是效果和资源消耗最平衡的档位日常的总结、翻译、问答都够用了。如果你试完之后觉得生成质量不够再升级14B也不迟。2.3 存储位置与磁盘要留多大模型文件要落在硬盘上这点也要提前规划。我把Ollama的数据目录单独挂载到 /volume1/docker/ollama 下面这样模型、容器配置、日志都在一个地方后续备份也方便。存储空间方面只跑一个7B模型其实只需要5GB左右但建议预留20GB以上因为你很可能跑着跑着就想拉个14B甚至其他模型试试。顺便提醒一句Ollama拉模型的时候是边下载边解包临时空间占用会短暂超过最终体积磁盘剩余空间低于10GB时最好别硬拉。3. 部署Ollama并拉取DeepSeek模型3.1 在UGOS Pro里创建Ollama容器绿联NAS部署Docker容器不用SSH在UGOS Pro的Docker管理界面就能完成。第一步在“镜像”页面搜索 ollama/ollama选择 latest 标签点击下载。UGOS的Docker Manager是支持镜像仓库搜索的我等一下就好。第二步下载完成后点击“创建容器”关键配置如下容器名称可以叫 ollama方便后面识别端口映射宿主机 11434 → 容器 11434这里左栏是宿主机端口右栏是容器端口保持一致就行存储映射新建一个 docker/ollama 目录映射到容器内的 /root/.ollama这是Ollama保存模型的位置环境变量我额外加了一个 OLLAMA_KEEP_ALIVE5m意思是模型在空闲5分钟后才从内存释放避免每次请求都重新加载模型响应会快很多提示Ollama默认把端口监听在0.0.0.0上这意味着同一局域网内的设备都能访问11434端口。这是有意的——因为后面n8n可能跑在另一个容器里它需要通过局域网IP访问Ollama。但如果你觉得不放心后面可以通过防火墙限制来源IP。3.2 拉取deepseek-r1模型容器跑起来之后可以直接在UGOS Docker界面选中 ollama 容器点击“终端”按钮进入Shell。这会打开容器内部的一个命令行然后执行ollama pull deepseek-r1:7b这里解释一下ollama pull 命令就是去模型仓库下载指定的模型。deepseek-r1:7b 中的 :7b 是标签表示7B版本不带标签默认拉latest通常是7B或最大版本不同模型策略不一样建议还是显式写标签。下载过程会分块进行屏幕上能看到多个进度条。如果中途断了不用慌重复执行同一条命令会从断点续传不会从头开始。这是我实际用下来Ollama做得比较稳的地方。等进度条全部走完可以在容器终端里直接跑一句验证ollama run deepseek-r1:7b进入交互式对话界面后输入“你好”看模型能不能正常回话。能回话说明本体没问题按CtrlD退出即可。这一步一定要做它把“模型能不能跑”和“API能不能用”两个问题先区分开后面排查时思路就清晰了。3.3 用curl验证本地推理服务模型能本地跑还不够我们要确认API接口对外可调用。在局域网里的任意一台电脑上打开终端执行curl http://你的NAS局域网IP:11434/api/generate \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, prompt: 用10个字介绍你自己, stream: false }如果返回的JSON里带有一段文本response字段说明API正常。如果提示拒绝连接优先检查容器是否还在运行、端口映射是否正确而不是先去折腾代码。这一步完成之后Ollama这块就彻底通了。接下来才是重头戏——部署n8n然后把两者接上。4. 部署n8n工作流平台4.1 n8n容器部署与数据持久化n8n的官方镜像叫 n8nio/n8n部署方法和Ollama几乎一样在UGOS的Docker界面里搜索拉取、创建容器即可。 配置要点端口映射宿主机 5678 → 容器 5678存储映射将 docker/n8n 目录映射到容器内的 /home/node/.n8n这是n8n保存工作流、凭证和设置的地方环境变量我设置了 GENERIC_TIMEZONEAsia/Shanghai 和 TZAsia/Shanghai确保定时触发器按北京时间跑启动容器后浏览器访问 http://你的NAS局域网IP:5678 首次打开会要求注册管理员账号填一个邮箱密码就行这个邮箱只是本地账号不会被发送到任何地方。4.2 n8n里最基础的两个准备进入n8n主界面后有两个设置我建议顺手做掉。第一个是“Settings → Workflow”把Timezone确认成Asia/Shanghai。这个如果不改后面配定时任务时会出现“每天上午9点”实际却按UTC凌晨触发的问题很容易被绕晕。第二个是给自己的需求想好触发方式。n8n支持很多触发器我这次实战会用到Webhook收到外界HTTP请求后触发这是接入群聊机器人、其他系统通知最直接的方式。如果你只是打算定时跑任务就用Schedule Trigger操作更简单。5. 把DeepSeek接进n8n两种接入方式详解5.1 方式一HTTP Request节点通用调用法n8n里最通用的做法就是用一个HTTP Request节点直接请求Ollama的API。流程先添加一个Webhook触发器再添加HTTP Request节点最后用Respond to Webhook节点把结果返回给调用方。HTTP Request节点的具体配置MethodPOSTURL填 http://你的NAS局域网IP:11434/api/generate注意这里填的是宿主机IP不是localhost。因为n8n跑在独立的容器里容器内的localhost指向它自己HeaderContent-Type 设为 application/jsonBody使用JSON原始格式粘贴如下内容{ model: deepseek-r1:7b, prompt: 请用中文把下面内容总结成100字以内{{ $json.body.text }}, stream: false, options: { temperature: 0.7 } }这里用到了n8n的表达式语法 {{ $json.body.text }}它会把Webhook请求体中text字段的值动态取出来塞进prompt里。这就是n8n“编排”的精髓——不同节点产出的数据可以被后面任意节点使用。返回的JSON里完整回答在 response 字段。所以加一个“Respond to Webhook”节点把Response Body设置成{ result: {{ $json.response }} }保存并部署这个工作流然后用curl测试curl -X POST http://你的NAS局域网IP:5678/webhook/你的路径 \ -H Content-Type: application/json \ -d {text: 绿联NAS上的DeepSeek部署完成测试一下摘要能力。}如果一切正常你会看到响应里的result字段包含一段总结文字。这时候外部系统比如脚本、机器人、甚至手动请求就都能通过这个Webhook获得本地DeepSeek的AI能力了。5.2 方式二n8n自带的Ollama节点更适合Agent流程如果你不满足于简单的一问一答想在n8n里搭带记忆的Agent对话流程方式二更合适。n8n在AI相关的节点分类里提供了 Ollama Chat Model 这类模型接入节点可以直接在AI Agent和Basic LLM Chain流程中使用。配置很简单把节点类型选为Ollama Chat Model填入两个值Base URLhttp://你的NAS局域网IP:11434Modeldeepseek-r1:7b比起手写HTTP请求这种节点的优势是n8n已经帮你处理好了消息格式转换、流式响应、历史记录拼接等细节。缺点是灵活性略低如果你要做非常定制化的请求体还是HTTP Request更自由。我的习惯是简单任务摘要、改写、翻译用HTTP Request复杂Agent场景多轮对话、带工具调用用Ollama节点。两条路都通了以后基本能覆盖所有需求。5.3 实战工作流做一个文件摘要助手这里我分享一个完整可落地的场景监控某个NAS共享文件夹新上传的文档自动调用DeepSeek生成摘要。先解释一下思路UGOS Pro支持在容器里挂载NAS文件夹我们先给n8n容器手动挂载一个只读的目录比如 /volume1/documents 映射到容器 /data。然后n8n里用“Read/Write Files from Disk”节点读取 /data 下新出现的文本文件把文件内容交给HTTP Request节点调用DeepSeek最后用“Send Email”节点把摘要发出去。工作流节点顺序大概是Schedule Trigger比如每小时触发一次Read File节点读取 /data 下最新文件HTTP Request节点调用DeepSeek生成摘要Send Email节点发送摘要结果这个流程的关键点是挂载目录。UGOS的Docker容器默认只访问容器内目录必须手动把NAS共享文件夹映射进去容器才能看到外部文件。很多人载在这里不是n8n配置有问题而是文件根本没被挂进去。如果你没有发邮件需求可以把最后的Send Email换成“Write to File”节点把摘要写回 /data/summary.txt也是全自动的。6. 实操中踩过的坑与排查速查6.1 容器间网络不通最常见的一堵墙我第一次接n8n和Ollama时尴尬了半小时。n8n的HTTP请求一直报 ECONNREFUSED原因就是我在URL里写了 localhost:11434。对n8n容器来说localhost是它自己的独立网络空间那里并没有Ollama。解决方式有几种最推荐URL里使用NAS宿主机的局域网IP比如 http://192.168.1.100:11434如果不确定IP可以在NAS的终端里执行 ip addr 查一下如果两台容器在同一个自定义Docker网络里也可以用容器名互相访问比如 http://ollama:11434但UGOS默认桥接网络不支持这样写排查思路先别改n8n先在宿主机上curl一下Ollama端口确定通了再去容器里curl一下Ollama端口看是网络层问题还是端口层问题。6.2 推理速度慢、内存不足、被系统杀掉这是NAS跑大模型最现实的问题。7B模型在N100这类处理器上生成速度大致在5~8 token/s也就是每秒吐几个字。遇到长文总结等待时间可能以分钟计。如果你的内存紧张推理过程中NAS其他服务会明显变卡甚至容器直接消失。排查方法很直接在UGOS的“资源监控”里看内存曲线。如果某次推理时内存接近100%那不是模型问题是资源不够。解决办法按优先级排先把内存升级到16GB这是最有效的在Ollama调用时把 options.num_ctx 从默认4096降到2048能显著减少内存占用减少同时运行的其他Docker容器只保留一个正在使用的模型不要同时驻留多个模型6.3 中文回答不理想问题的根源在提示词DeepSeek-R1本身对中文支持不差但本地部署后有时会输出混着英文、甚至完全英文的内容这其实不是模型坏了而是提示词里没有明确要求语言。我自己常用的system prompt模板是你是一个严谨的中文助手。无论用户用什么语言提问请始终使用简体中文回答输出内容要条理清晰。如果你用HTTP Request方式可以在请求体里加一个system字段配合prompt一起发送Ollama的 /api/generate 接口支持 system 参数直接传即可。这一步对最终体验的影响比选哪个参数还大。6.4 端口暴露与访问安全Ollama和n8n默认都监听在0.0.0.0局域网内任何设备都能访问。如果你只在家庭内网使用问题不大如果你希望限制访问可以在UGOS的防火墙上只放行特定来源IP。对n8n再额外提一句n8n有完整的用户体系和登录认证默认情况下未登录用户无法访问工作流管理界面这层保护要开着千万别为了让某些请求“更容易进来”而关闭认证。Webhook触发器可以无登录访问但只暴露这一条通道管理界面仍受保护。6.5 Ollama拉取模型时的网络问题拉模型中途失败时不时会遇到。多数原因是镜像下载超时或磁盘空间不足。处理办法先检查磁盘剩余空间重新执行 ollama pull它支持断点续传如果多次在同一个进度卡住可以手动下载GGUF格式文件然后通过 ollama create 命令本地导入。这个办法稍繁琐但绕开网络问题很有效拉取模型这个过程有耐心就行模型文件本身没毛病多数时候只是网络丢包。7. 经验总结与后续扩展方向整套方案跑通之后我最大的感受是本地大模型和n8n的组合真正的上限不在于模型跑多快而在于你想出多少场景。目前我留给自己的几个扩展想法供参考接一接入群机器人把Webhook地址挂到群机器人上群里发消息自动获得本地AI回复不依赖任何外部智能服务做一个定时日报每天早晨让DeepSeek把昨天的笔记、RSS摘要汇总成一份简短的“晨报”发到邮箱把本地知识库文件定期切片用Ollama做Embedding再用n8n接一个检索问答接口这就是一个小型私有知识库问答系统这套方案的组件之间是松耦合的Ollama可以换成其他推理引擎DeepSeek可以换成其他模型n8n也可以换成其他自动化平台。但你一旦真正理解了“模型作为服务、流程作为粘合剂”这种架构随便怎么换都能快速搭出新的应用来。我个人在实际操作中的体会是在NAS上跑DeepSeek确实不是为了追求性能而是追求“可控”和“私有”。按今天的硬件水平7B级别的模型已经能承担很多实际任务14B在高端NAS上也不是完全不能跑。先随便挑一个模型跑通全流程再根据真实响应速度决定要不要升级更大的模型这个顺序最不容易让人半途而废。