近期使用第三方大模型API对接WorkBuddy时，频繁遇到模型下线、密钥无效、服务内部报错等问题，稳定性难以保障。对于持有群晖NAS的用户，完全可以在本地部署Ollama大模型服务，原生兼容OpenAI协议接口，直接作为自定义模型接入WorkBuddy。所有数据本地运行，无需依赖第三方平台，也没有额度、限速、模型下架的困扰。
本文基于群晖DS1019+（DSM 7.4、8GB内存、赛扬J3455）实测编写，兼顾性能与稳定性，包含完整部署步骤、WorkBuddy对接配置以及防止拖垮NAS的必做优化项。
一、硬件前提与模型选型建议
本地部署大模型，内存是第一约束，其次是CPU算力。以8GB内存的群晖DS1019+为例，系统核显会占用部分显存，实际可用内存约7.6GB；扣除DSM系统、常驻Docker服务（Immich、DTK、Vaultwarden等）的1.5~2GB占用，能稳定分配给大模型的内存约4.5~5GB。
推荐模型分级
| 模型名称 | 参数规格 | 运行内存占用 | 推荐度 | 适用场景 |
|---|---|---|---|---|
| qwen2.5:3b | 3B参数（int4量化） | 1.8~2.2 GB | ✅ 首选 | 日常对话、文案整理、信息摘要，响应流畅，不影响NAS其他服务 |
| deepseek-r1:3b | 3B参数（int4量化） | 2.0~2.4 GB | ✅ 备选 | 逻辑推理、数学计算能力略强，内存占用与3B通义千问相当 |
| qwen2.5:7b | 7B参数（int4量化） | 4.2~5.2 GB | ⚠️ 谨慎使用 | 接近内存红线，仅适合短对话，长时间使用易触发OOM导致NAS卡顿 |
结论：8GB内存机型优先选择3B参数模型，稳定流畅不折腾；如果追求更强能力，建议先升级内存到16GB，再上7B模型。
二、群晖Container Manager部署Ollama
采用项目（docker-compose）方式部署，与你现有Docker服务管理习惯一致，便于后续维护。
步骤1：创建数据目录
打开File Station，在你的Docker存储路径（本文以/volume2/docker为例）下新建文件夹：
- 上级目录：
/volume2/docker/ollama - 子目录：
/volume2/docker/ollama/data（用于持久化保存模型文件，避免容器重建后重复下载）
步骤2：新建项目并编写配置
- 打开「Container Manager」→「项目」→「新建」
- 项目名称：
ollama - 路径：选择刚才创建的
/volume2/docker/ollama - 来源：选择「创建docker-compose.yml」
粘贴以下配置（已包含内存限制优化）：
<code>services: services: ollama: image: ollama/ollama:latest container_name: ollama restart: always mem_limit: 2.8g ports: - "11434:11434" volumes: - ./data:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0 - OLLAMA_ORIGINS=* - OLLAMA_NUM_PARALLEL=1 - OLLAMA_MAX_LOADED_MODELS=1 - OLLAMA_THREADS=2 </code>
步骤3：启动服务
点击下一步完成项目创建，等待镜像拉取与容器自动启动。确认容器状态为「运行中」即可进入下一步。
三、拉取本地大模型
- 进入Container Manager → 容器 → 找到
ollama→ 操作 → 「打开终端」 - 根据选型执行对应的拉取命令：
首选（均衡推荐）：
ollama pull qwen2.5:3b备选（推理加强）：
ollama pull deepseek-r1:3b等待终端出现success提示，即代表模型下载完成并就绪。
四、WorkBuddy添加自定义模型接口
回到WorkBuddy的「添加模型」页面，供应商选择「自定义」，按以下参数逐项填写：
- 接口地址：
http://你的群晖内网IP:11434/v1
示例：http://192.168.xx.xx:11434/v1
注意：结尾只到/v1，不要追加/chat/completions，客户端会自动拼接路径。 - API Key：任意填写即可（例如填
ollama），本地服务不校验密钥。 - 模型名称：与你拉取的模型名完全一致，例如
qwen2.5:3b - 高级配置：取消「工具调用」勾选，图片输入、思考模式、自定义协议均不勾选。
- 输入、输出保持「使用提供商默认值」
填写完成后点击「测试连接」，提示成功后保存即可使用。
五、部署优化建议（必做，防止拖垮NAS）
群晖NAS的核心定位是存储与轻量服务，大模型属于高负载应用，必须做好限制，避免影响基础服务稳定性。
1. 强制内存上限（最关键）
上述compose配置中的mem_limit: 4.5g必须保留，严格限制Ollama最大内存占用。防止模型推理时内存持续上涨，触发系统OOM杀掉进程，甚至导致整个NAS假死、文件服务中断。
如果使用3B模型，可将上限放宽到3g，预留更多资源给其他服务。
2. 非必要时关闭大内存容器
如果临时测试7B模型，建议先暂停immich_machine_learning、dtk_worker等内存占用较高的非核心容器，腾出内存空间，用完再恢复。
3. 避免长时间高负载推理
赛扬J3455这类低功耗CPU，纯CPU跑大模型会持续满负载。不要用来处理长文本总结、批量代码生成等耗时任务，否则会导致NAS文件访问、相册备份等其他服务响应变慢。
4. 系统预留空间
必须给DSM系统、文件缓存、网络缓冲预留至少1~1.5GB内存，不要把内存占满。一旦开始使用硬盘交换分区，整体性能会断崖式下跌，同时损伤硬盘寿命。
5. 外网访问建议
如果需要在外网调用该接口，优先通过群晖自带反向代理+HTTPS访问，或者路由器端口映射；不建议直接将11434端口暴露在公网，避免未授权访问。
六、常见问题排查
- 测试连接失败：检查群晖防火墙是否开放11434端口，确认接口地址结尾是
/v1，模型名称与拉取的完全一致。 - 响应速度很慢：纯CPU推理3B模型属于正常现象；如果异常卡顿，查看内存占用是否触顶，触发了交换分区。
- 容器自动退出：大概率是内存超限被系统杀掉，调低
mem_limit数值，或者换用更小参数的模型。
七、WorkBuddy高级配置选项怎么勾选（对照表）
很多新手容易踩坑：以为勾选开关就能开启AI的识图、思考、工具能力。实际上这些选项只是 WorkBuddy 客户端侧的协议打包开关，勾选后会在请求报文里增加对应的特殊字段。只有 Ollama后端 + 当前加载的模型同时支持该特性时，勾选才有效；模型不支持就会直接超时、请求失败。
核心原则：一次尽量只开启一种高级能力，不要多个选项同时勾选，尤其对于DS1019+这类低CPU性能NAS，复杂请求极易超时。
| 使用模型 | 图片输入 | 工具调用 | 思考模式 | 自定义协议 | 说明 |
|---|---|---|---|---|---|
| qwen2.5:3b（当前推荐，纯文本） | ❌ 不勾选 | ❌ 不勾选 | ❌ 不勾选 | ❌ 不勾选 | 适合日常问答、文案撰写、摘要整理，负载最低、稳定性最好 |
| qwen2.5:3b-v / qwen2.5:7b-v（多模态识图版） | ✅ 勾选 | ❌ 不勾选 | ❌ 不勾选 | ❌ 不勾选 | 支持上传图片识别内容，内存占用相比普通文本模型更高 |
| deepseek-r1:3b / deepseek-r1:7b（推理思考模型） | ❌ 不勾选 | ❌ 不勾选 | ✅ 勾选 | ❌ 不勾选 | 模型会输出 <think> 标签包裹的思考过程，客户端分离展示思考内容与最终答案 |
| qwen2.5:3b-fc（Function Call工具调用版本） | ❌ 不勾选 | ✅ 勾选 | ❌ 不勾选 | ❌ 不勾选 | 支持函数、工具调用，适合需要外部能力联动的场景 |
| 所有标准Ollama /v1接口 | — | — | — | ❌ 永远不勾选 | 自定义协议用于非标改造API，原生Ollama不要开启 |
最简建议：如果你主要用来写文章、整理信息、日常对话，就使用 qwen2.5:3b，高级配置全部留空不勾选，是这套NAS硬件下最稳妥的方案。
八、DS1019+ 资源监控与负载控制实战提醒
从Dozzle监控面板可以直观看到：qwen2.5:3b运行时，Ollama容器常驻占用约2.7GB内存，推理阶段CPU占用飙升至80%以上。DS1019+搭载J3455处理器、8GB物理内存，同时运行Immich、DTK、PostgreSQL、Redis等多个容器，资源余量非常紧张。
- 建议增加
cpus:2.0限制CPU核心，OLLAMA_THREADS=2限制推理线程，避免Ollama独占全部CPU导致其他服务卡顿、接口超时； - 内存上限锁定2.8G，防止模型推理时内存持续上涨触发系统OOM，容器被强制杀死；
- 最优使用策略：按需启停Ollama容器，不用AI的时候直接停止ollama，释放2.7G内存给NAS核心存储、图片备份服务；
- Immich的机器学习容器（immich_machine_learning）同样是内存大户，不使用图片识别功能时建议暂停；
- 该硬件条件下，禁止常驻加载7B及更大参数模型，极易内存溢出、服务瘫痪。
补充说明：群晖DSM不支持compose里cpus CPU配额限制
DS1019+这类Braswell平台的DSM内核没有开启CFS CPU带宽调度，在compose中填写 cpus: x.x 会报错：NanoCPUs can not be set, as your kernel does not support CPU CFS。
- 内存限制 mem_limit 不受影响，可以正常使用；
- 必须删掉 compose 中的 cpus 配置项；
- 替代方案：依靠
OLLAMA_THREADS=2在模型推理层控制线程数，同时在Container Manager图形界面调低容器CPU调度优先级； - OLLAMA_THREADS 是 Ollama 自身的参数，不依赖系统cgroup，在群晖上可以正常生效，是J3455机型控制负载的核心手段。
总结
在群晖NAS上部署Ollama本地大模型，最核心的价值是数据安全、稳定可控、永久免费。对于日常轻量使用场景，3B参数模型完全够用，且不会对NAS造成过重负担。如果后续有更高需求，升级内存是性价比最高的优化方式。
部署完成后，WorkBuddy就可以完全离线调用本地大模型，不再受第三方平台的服务波动、模型下架、额度限制影响，打造完全属于自己的私有AI助手。
