把DeepSeek跑进绿联NAS这件事我折腾了大概一个周末才完整跑通。起因很简单手上的云端API调用额度越用越心虚数据也总在别人服务器上转一圈我就想试试本地部署一条线。结果发现绿联NAS的用户群里官方镜像和接口都现成Ollama拉起DeepSeek模型并不难真正费工夫的是后面接n8n工作流的那些细节——端口、环境变量、容器网络、超时设置任何一个不对都能让你白忙半天。这篇就是把整个链路从头到尾的实操过程、选型逻辑和踩过的坑都写下来适合手里有绿联NAS、想跑私有化AI模型顺便接个工作流自动化的朋友参考。1. 为什么把DeepSeek跑在绿联NAS上而不是用云端API1.1 本地私有化部署的四个实际好处常见的选择其实有三种直接调云端API、在云服务器部署、在本地NAS部署。我最后选了NAS核心原因只有四个。第一是数据不出门。家庭或者团队内部的一些文档、日记、表格喂给云端模型总让人心里不踏实。本地跑模型请求和应答全程在自己机器上断电断网都不影响隐私边界清晰得多。第二是长期成本可预期。云端按token计费用得越多账越难看。NAS是一次性硬件投入加电费模型免费拉取适合高频次、小批量的调用场景。我每天要跑几十次文本归类用本地模型一个月下来电费基本可以忽略。第三是延迟稳定。云端API受网络波动影响高峰期偶尔要排队。本地模型哪怕速度不算快但响应时间是稳定的不会突然踢出超时错误。第四是方便和n8n这类自动化工具深度绑定。n8n跑在NAS上Ollama也跑在NAS上走内网访问不占用外网带宽工作流里调用模型和调用普通函数一样顺畅。1.2 绿联NAS做这件事够不够格绿联NAS用的是UGOS Pro系统底层是Linux支持Docker容器。这个点非常关键Ollama官方提供Linux镜像n8n也一样所以整个AI链路不需要依赖绿联是否内置了AI功能只要系统能跑Docker就能装。我手上的绿联是DXP系列配备Intel处理器。这类NAS平时当存储用可能觉得性能过剩但跑大模型推理刚刚合适——有足够的CPU算力内存可以扩展到比较大的容量硬盘读写速度也跟得上模型文件加载。n8n本身是Node.js应用内存占用不高Ollama则是吃内存大户模型文件动不动几个GB。所以选型时第一个要看的不是NAS的处理器而是内存上限。从我的实际体验看绿联NAS跑1.5B和7B的DeepSeek蒸馏版完全没问题14B的模型勉勉强强能用再往上就属于“能加载但速度太慢实用性下降”的范围。这个结论后面会详细说。2. 落地前的硬件选型与模型匹配2.1 先算清楚内存账再选模型很多人拿到NAS第一件事就在系统里搜“Ollama”或者“DeepSeek”装完开始拉模型才发现内存不够。这里一定要先搞明白一个对应关系模型参数量直接决定推理时占用的内存。Ollama在拉取模型时通常使用4-bit量化版本也就是说每个参数大约占0.5到0.7字节。一个7B参数的模型文件名后缀是7b实际加载后占用的内存大约是4到5GB。再加上系统本身、Docker守护进程、n8n服务、容器开销建议总内存至少是模型大小的两倍才能运行得比较从容。我把常见选项整理成了一个对照表方便你对着自己的NAS配置选模型参数量加载后约占用推荐最低内存使用体感deepseek-r1:1.5b1.5B约1.1GB4GB流畅适合测试链路deepseek-r1:7b7B约4.7GB8GB起步16GB舒适速度可接受日常工作够用主力选择deepseek-r1:14b14B约9GB16GB起步32GB舒适能跑但出字偏慢适合不赶时间的场景deepseek-r1:32b32B约19GB32GB起步需要高端NAS家用不太建议表格里没有列R1之外的更新版本因为Ollama官方仓库里DeepSeek家族最常见的还是R1系列蒸馏版。如果你看到其他版本的DeepSeek也在库里用同样的方式看待即可。2.2 DXP系列哪几个配置能玩绿联DXP系列从入门到高配都有玩AI的话我建议直接按内存筛。DXP2800这种入门型号原配内存通常较小虽然能加装但也有限适合跑1.5B模型做功能验证。DXP4800是我的主力机型原配8GB内存我加了一条后到16GB跑7B模型正合适。如果你的预算是DXP6800或者更高原配16GB甚至32GB那14B模型也能稳定跑做自动化工作流的“大脑”完全够格。处理器方面绿联这几款用的都是Intel处理器比如N100或者更高档位的型号。CPU推理和显卡推理不一样N100这种低功耗U在跑7B模型的时候速度大约在每秒4到8个token之间什么概念呢一段500字的回复大概需要一两分钟。这个速度不适合实时聊天但很适合后台任务处理比如摘要生成、内容分类、报表整理这类场景对响应时间并不敏感。如果你追求更好效果建议关闭OLlama默认可能加载到GPU显存的设置因为Intel核显在Ollama里的加速效果并不稳定强制用核显反而可能降低速度。与其依赖显卡不如把内存加到上限让CPU专心算。3. 在UGOS Pro里部署Ollama和DeepSeek3.1 准备镜像和容器运行环境UGOS Pro的文件管理界面里有“容器”应用入口它本质上是Docker的可视化管理工具。你在DockerHub拉镜像有两种方式一是在容器应用界面直接搜索镜像名拉取二是用SSH连进NAS在终端里执行命令。我习惯用SSH方式因为后面要用到一些参数终端操作更方便。第一步确保你的绿联NAS打开了SSH功能然后用终端连上去验证一下设备状态ssh 你的NAS用户名你的NAS内网IP uname -a确认能进终端后先建一个数据目录用来存放Ollama的模型文件和数据。这个地方容易被忽略如果直接让容器把模型写在默认路径系统和存储盘空间告急时会非常被动。mkdir -p /volume1/docker/ollama接着拉取Ollama官方镜像。镜像本身不大几百MB级别拉取时间取决于网络状况。docker pull ollama/ollama:latest3.2 启动Ollama容器时最容易埋坑的一个参数镜像拉下来之后启动命令本身很简单很多人在这里遇到问题。我先给出正确写法docker run -d \ --name ollama \ --restartalways \ -p 11434:11434 \ -v /volume1/docker/ollama:/root/.ollama \ -e OLLAMA_HOST0.0.0.0 \ ollama/ollama:latest-v是数据卷挂载把容器里的模型目录映射到刚才建的文件夹。-p是把Ollama的默认端口11434暴露给局域网。最关键的是-e OLLAMA_HOST0.0.0.0这个环境变量它告诉Ollama不要只监听容器内部的回环地址而是监听所有网卡这样n8n容器或者局域网里的其他机器才能连上它。我最初部署时没加这个变量结果容器正常启动、日志也正常但是在另一个容器里通过NAS的IP地址访问11434端口就是不通报connection refused。排查了半天翻文档才发现容器模式下Ollama默认只绑定127.0.0.1。这是新手最容易踩的一刀。3.3 拉取DeepSeek模型并测试容器跑起来之后验证一下服务是否正常docker exec -it ollama ollama list这条命令会列出当前已下载的模型。空列表是正常的接下来拉取模型。我建议先用最小的1.5B版本通一遍链路确认没问题再换7B因为7B模型有几个GB下载一次要等一段时间如果链路有问题拉完才发现就浪费时间了。docker exec -it ollama ollama pull deepseek-r1:1.5b这条命令会从Ollama官方模型仓库拉取模型文件。看到进度条走完再列表确认docker exec -it ollama ollama list接着直接做一次推理测试docker exec -it ollama ollama run deepseek-r1:1.5b 用一句话解释什么是NAS能正常输出答案就说明推理链路已经通了。这时再确认一个关键点实际上通过局域网IP能不能访问Ollama。在另一台电脑上执行curl http://你的NAS内网IP:11434/api/tags如果返回一串包含deepseek-r1:1.5b的JSON信息说明外部访问已经通了。这一步确认后再接n8n的时候心里就有底了。4. 把n8n接到Ollama上搭出第一个AI工作流4.1 部署n8n实例n8n是一个可视化的工作流自动化工具可以理解成“可以自定义逻辑的带界面的自动化机器人”。它在UGOS Pro上同样走Docker部署。我用的启动命令docker run -d \ --name n8n \ --restartalways \ -p 5678:5678 \ -v /volume1/docker/n8n:/home/node/.n8n \ -e GENERIC_TIMEZONEAsia/Shanghai \ -e TZAsia/Shanghai \ n8nio/n8n:latest端口5678是n8n的默认Web界面端口。数据卷挂载出来很关键否则容器重建后所有工作流都会丢失。GENERIC_TIMEZONE设置时区影响定时任务的触发时间。启动完成后浏览器访问http://你的NAS内网IP:5678会看到初始化界面按提示创建管理员账号。到这里如果只想跑一个转换流程n8n也可以不用直接写脚本发HTTP请求就行。但n8n能让你用鼠标把“接收问题、调用模型、返回结果、写文件、发通知”这些动作串起来维护成本低很多。4.2 n8n Ollama节点的配置逻辑n8n较新版本自带Ollama节点不需要装额外插件。你需要先创建一个工作流然后在节点面板搜索“Ollama”并拖进画布。我推荐使用“Ollama Chat Model”节点因为R1系列模型本质上是对话模型Chat Model节点提供的参数更合适。配置时有三个地方要注意第一是Base URL。填http://你的NAS内网IP:11434注意结尾不要加斜杠也不要写localhost。如果n8n也是容器localhost指向的是n8n容器自己不是NAS宿主机。第二是模型名称。填实际的模型名比如deepseek-r1:7b。不要填“deepseek”这个泛指的名字Ollama要求精确匹配仓库里已有的模型标识。第三是Temperature参数。这个参数控制生成随机性。做分类、提取这类任务建议设为0到0.3结果更稳定做头脑风暴、文案改写可以调到0.7左右。我默认是0.7几天用下来发现某些分类任务偶尔会给出不太稳定的格式调低之后就正多了。4.3 一个完整的“提问-回答”Webhook工作流配置好节点后我来搭一个最简单也最实用的工作流外部请求发来一个问题工作流调用DeepSeek给出答案再把答案返回给请求方。这个流程可以做API接口、做客服机器人后端、做自动摘要服务都是一样的套路。拖入节点顺序如下Webhook节点作为入口接收HTTP请求。Ollama Chat Model节点把Webhook传来的“问题”字段作为Prompt发给模型。Respond to Webhook节点把模型输出作为响应返回。Webhook节点需要设置一个路径比如chat。它会在界面里生成一个测试URL。Ollama Chat Model节点的Prompt设置在这个字段里引用上一个节点的数据括号写法是{{ $json.body.question }}。意思是从传入的JSON请求体里取question字段作为输入。配置完成后把Webhook节点状态切到Active然后在命令行或者任何HTTP客户端里测试curl -X POST \ http://你的NAS内网IP:5678/webhook/chat \ -H Content-Type: application/json \ -d {question:写一段新品发布的宣传语}正常返回一段由DeepSeek生成的宣传语文本工作流就完整跑通了。这个流程看起来简单但已经是n8nOllamaDeepSeek三者协同的基础骨架。你可以在这个基础上加条件分支、加数据存储、加通知节点比如判断问题里包含“报表”就去读某个文件再塞给模型。5. 实际跑起来之后性能、并发和调优方向5.1 我这边不同参数量模型的速度体感在绿联NAS上模型推理走的是CPU所以速度取决于处理器单核性能和内存带宽。我把1.5B和7B都实际用了几天体感如下1.5B模型几乎可以做到“打字机式输出”大概每秒10到20个token短问答毫无压力。7B模型速度明显下降我实测在N100处理器上大约每秒4到8个token。这个速度做实时聊天体验一般但做后台任务很合适。14B模型每秒只能出2到3个token一段稍长的回复可能要等几分钟适合不急于出结果的批处理场景。如果你的NAS处理器比N100规格高时间指标会好一些但结论不会改变7B是绿联NAS上最平衡的选择兼顾了模型能力和响应速度。5.2 并发请求和内存压力处理Ollama默认情况下同时只能处理一个请求。如果n8n里有多个工作流同时触发模型调用后到的请求会在Ollama队列里等待。如果你的场景经常需要并发可以在启动Ollama时加上环境变量-e OLLAMA_NUM_PARALLEL2这个值不建议设太大。每个并发请求都会叠加大量的内存占用两个7B并发大约需要额外再加4到5GB内存。内存不够时系统会开始使用交换空间速度会急剧下降甚至Ollama进程直接被系统杀掉。我的建议只有16GB内存的话把并发设为1用队列就够。5.3 普通配置下怎么提升出字速度几个实际能提速的手段优先使用量化版本模型。Ollama默认拉取的模型已经是4-bit量化版不要手动去找fp16版本那种虽然精度更高但内存占用翻倍出字速度明显下降对日常自动化任务收益不大。尽量让模型待命。频繁的模型加载和卸载会浪费额外时间。Ollama会保留最近加载的模型只要你不手动kill进程模型会一直在内存里待命后续请求响应速度会更快。减少代理链路上的额外开销。如果n8n和Ollama都在同一台NAS上直接走NAS内网IP的局域网地址最稳定不用经过路由器转发。以上优化的核心思路只有一个让Ollama在内存充足、网络路径最短的条件下跑。6. 踩坑记录从连不上到乱回复的过程6.1 Ollama明明运行却连不上的根因这是本文第一个重点坑我在前面已经提到了根因OLLAMA_HOST没设置成0.0.0.0。很多教程只让你在容器里映射端口却没说Ollama默认只听本地回环地址。所以容器内自己测试时一切正常换宿主机外部访问就黑屏。解决办法就是启动时加上那个环境变量。已经启动的容器可以先删掉再用新参数重新创建数据卷挂载了模型文件就不会丢。6.2 n8n节点报错“connection refused”第二个坑是n8n填Base URL时写了https://localhost:11434。localhost在n8n容器里指向的是n8n自己这条连接当然没人接。改成NAS的内网IP后问题就消失了。这里要注意如果你的路由器分配IP是动态的建议在路由器后台给NAS绑定固定IP否则哪天IP变了工作流就全断了。6.3 模型答复质量差问题不在模型而在上下文在我把5个知识文档直接塞进Prompt让DeepSeek一次性回答十几个问题后输出质量明显下降开始出现自相矛盾的表述。排查后发现不是模型问题而是上下文太长。R1系列的上下文窗口虽然可以设得很长但超过一定长度后中间部分的信息会被“忘掉”这对现状是普遍规律不是这个模型独有的缺陷。解决方法就是拆任务一个工作流只负责处理一段不超过几百字的输入多个问题就拆成多条请求必要时把长文档做分段索引而不是一次性全部塞给模型。这个做法对NAS上的小模型尤其重要因为本地算力本来就有限。6.4 并发请求把NAS拖到失联有一天我同时跑了三个工作流每个都指向7B模型结果NAS的Web管理界面直接打不开SSH也卡顿。登录系统看日志才发现内存耗尽触发OOM系统把所有容器都杀了一遍。教训就是前面说的不要盲目调高OLLAMA_NUM_PARALLEL。如果你的NAS内存不到16GB并发值保持默认的1更稳妥。内存空闲时模型推理本来就够慢并发上去只会更慢还不如让请求排队挨个处理。最后再说两点我的个人体会整套链路跑通之后我的感觉是本地AI自动化这件事的门槛已经比大多数人想象的低了。绿联NAS提供了存储和稳定的运行环境Ollama把模型部署简化成了几条命令n8n把工作流带到了可视化的画布上三者搭在一起以后很多以前需要写脚本定时执行的琐事现在拖拖节点就能完成。一个小建议如果你也想照这个思路搭建初期先用1.5B模型把整个链路跑通包括Webhook、节点关联、数据传递等一切稳定了再换7B模型。这样能避免在模型文件下载和内存压力问题上消耗太多时间。模型本身可以随时切换工作流不用改动这个迭代路径最顺。我自己当时的顺序是反过来的结果调试半天等工作流通了才想起来模型不太合适又回头重跑了一遍下载纯属浪费。另外一个很多人问过我的问题这套东西值不值得一直开机跑。我的答案是按需使用就值。NAS本身就是7x24小时运行的设备多加一个Ollama容器并不明显增加功耗但随时有AI能力可用、随时可以往n8n工作流里加一个“让DeepSeek做点什么”的节点这种灵活性确实让我日常处理文本的效率高了一截。你的NAS如果正好配置够用这套组合值得一试。
