企业官网建设流程全解析

把大模型跑在自己的绿联NAS上，这件事我从立项到跑通，前后折腾了一个周末。最开始只是图个新鲜，想在Docker里装一个Ollama，再配合Open WebUI，等于家里多了一台24小时在线的私有大模型服务。后来发现这东西的价值远不止“多个聊天机器人”——模型和数据全在自己硬盘上，不绑定任何外部服务，局域网内随叫随到，真正做到了免费、私密、可控。这篇教程就把我完整的搭建过程、踩过的坑、以及调优经验一次讲清楚，帮助同样手持绿联NAS的朋友少走弯路。

1. 方案选型：为什么是绿联NAS + Ollama + Open WebUI？

1.1 从“云端大模型”到“本地私有模型”的动机

先聊聊动机。这几年大模型产品非常多，各家跑分一个比一个高，对话体验也越来越好，但对于我这种对数据敏感、又想要长期可控服务的用户来说，云端服务始终有几个绕不开的问题：第一是数据隐私，聊天内容、上传的文档都会经过别人的服务器，不管协议怎么写，心理上总觉得不踏实；第二是额度与限制，很多平台有每日对话次数、上下文长度、多端登录的限制，用起来不够自由；第三是稳定性，一旦服务方调整策略或者网络出现波动，整套体验就断崖式下跌。

本地私有模型恰好能解决这三个问题。模型文件整体存放在自己的NAS硬盘中，所有推理计算都在本机CPU/GPU上完成，不产生任何外部请求。断网也能继续用，局域网里的家人、同事、朋友都可以访问，而且没有任何按量计费的概念。对于已经有一台绿联NAS的用户来说，这笔部署成本几乎为零——只需要跑两个Docker容器，剩下的事情就是选择模型和使用方式。

1.2 Ollama和Open WebUI各自扮演什么角色

很多人第一次听到Ollama和Open WebUI的时候容易犯迷糊，不知道这两个东西到底是什么关系。我用最朴素的方式解释：Ollama是“模型的发动机”，负责下载、加载、运行大模型，对外暴露一个API接口；Open WebUI是“驾驶舱”，负责把发动机的动力表现出来，让你能在浏览器里像ChatGPT一样对话、管理会话、上传文档。两者一个管后端、一个管前端，通过HTTP协议通信，分工非常清楚。

选Ollama而不是手动去跑Python推理脚本，主要原因是它把模型管理这件事简化到了极致。以前我们要跑一个开源大模型，需要下载权重、安装Transformers、配置推理框架、处理显存分配……现在一条ollama run qwen2.5:7b就搞定了。Ollama自动处理模型量化、上下文窗口、并发请求，而且对CPU环境做了不少优化，对NAS这种没有独立显卡的设备特别友好。

Open WebUI则是目前开源生态里完成度最高的AI对话界面。它支持多用户注册、会话管理、Markdown渲染、代码高亮、联网搜索、知识库检索（RAG）等能力，而且自带用户权限体系。你在一台NAS上部署好之后，家人、同事各自注册账号，相互隔离，互不干扰，体验无限接近商业产品。

1.3 绿联NAS的硬件适合跑到哪个量级

绿联NAS属于x86架构的私有云设备，近几年的DXP系列，比如DXP2800、DXP4800、DXP4800 Plus、DXP6800 Pro等，基本都采用了Intel N100/N305或者Core系列处理器，配合DDR4/DDR5内存。这类设备跑大模型完全可行，但大家要根据内存规模选合适的模型。

如果你手上的绿联NAS是DXP4800 Plus这种8GB起步的型号，建议先从3B模型玩起，确认整个流程跑通之后再根据内存余量升级模型。不要一上来就拉70B的大模型，那大概率会把NAS卡到连管理界面都打不开。内存不够的时候优先选量化版本，Ollama默认使用的就是Q4_K_M量化，在体积和效果之间取了一个还不错的平衡点。

2. 部署前的准备：目录、镜像、模型与端口规划

2.1 绿联NAS端的环境准备

在动手之前，先把绿联NAS的系统环境整理干净。我用的系统是UGOS Pro，新版本已经内置了Docker容器服务，不用额外安装。如果你是老用户，建议先把系统升级到最新版本，避免Docker管理界面出现一些奇奇怪怪的兼容问题。

接下来做三件事。第一，确认SSH已经开启，虽然用绿联的Docker界面也能完成部署，但SSH会更方便查看日志、执行ollama pull命令，强烈建议开启。开启路径是“控制面板→终端机→SSH”，勾选启用即可。第二，规划好存储目录。我习惯在/volume1/docker/下面按应用建子目录，这次用到了两个目录：

/volume1/docker/ollama /volume1/docker/open-webui

Ollama的模型文件默认比较大，一个7B模型就要占4到5GB，如果准备部署多个模型，建议先确认volume1卷的空间是否充足，可以趁现在把不用的下载文件清理一下。第三，固定NAS的内网IP。在路由器后台给NAS一个静态IP，或者在UGOS Pro的“网络设置”里配置固定地址，这样后面配置API调用、局域网访问时IP不会变来变去，省去很多麻烦。

2.2 镜像拉取与网络问题

本次使用的两个镜像分别是ollama/ollama和ghcr.io/open-webui/open-webui。前者来自Docker Hub，国内网络下拉取通常没有太大问题；后者来自GitHub的容器仓库，不同地区、不同运营商的情况下速度差异很大，有时候会卡在几百KB/s。

如果拉取镜像特别慢，我一般会用这几种方式兜底：一是多试几次，Docker在拉取镜像时支持断点续传，重新构项目时往往能续上；二是在绿联NAS的Docker设置中配置可用的镜像加速地址，加速地址尽量选择正规云厂商提供的公共加速服务，不要随便加来路不明的地址，有安全隐患；三是换一个时间段再试，晚上或者清晨通常比白天高峰要快很多。

这里多说一句：不要为了拉一个镜像就去搜索所谓的“加速脚本”，尤其是要求你用root权限执行的第三方脚本，风险非常高。镜像拉不下来顶多是慢，数据被脚本拿走就是大事故了。

2.3 模型选择与资源估算

模型选择是整个项目中最需要认真对待的一步。很多人一上来就追新，看到哪个模型跑分高就拉哪个，结果NAS内存被吃满，连Docker容器都被系统自动杀掉了。合理的方式是“按内存反推模型”，先看NAS的内存容量，再看日常并发需求，最后选模型。

我用的是DXP4800 Plus，内存16GB，日常主要跑qwen2.5:7b，偶尔切换到deepseek-r1:7b做推理题。两个模型轮流加载，16GB内存基本够用，但需要注意在加载新模型时旧模型会被换出，如果同时加载两个7B模型，内存就会比较紧张。这一点后面通过环境变量OLLAMA_MAX_LOADED_MODELS做了限制。

另外，绿联NAS的CPU基本都支持AVX2指令集，这是Ollama正常运行的硬性要求，近几年的产品都满足，老型号如果CPU不支持AVX2，建议不要浪费时间尝试。

3. 完整实操：从SSH到Compose，一次跑通

3.1 创建业务目录

整个部署流程我最推荐的是Docker Compose方式，因为绿联NAS的Docker管理界面本身就支持“项目”功能，可以直接粘贴Compose文件创建多容器应用。一个Compose文件同时拉起Ollama和Open WebUI，还能自动创建内部网络，让两个容器通过服务名互相访问，非常省心。

先用SSH登录NAS，执行下面的命令创建目录：

mkdir -p /volume1/docker/ollama mkdir -p /volume1/docker/open-webui cd /volume1/docker

如果你不喜欢用SSH，也可以在绿联NAS的文件管理器中手动创建这两个文件夹，效果一样。注意目录名不要带空格和特殊字符，容器挂载时对路径严格区分大小写，保持全小写最稳妥。

3.2 编写docker-compose.yml

接下来在/volume1/docker/下面创建docker-compose.yml文件。你可以直接用SSH的vi编辑器写，也可以在电脑上写好之后通过文件管理器上传。

services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - /volume1/docker/ollama:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0 - OLLAMA_KEEP_ALIVE=24h - OLLAMA_MAX_LOADED_MODELS=1 - OLLAMA_NUM_PARALLEL=1 networks: - ai-net open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped ports: - "3000:8080" volumes: - /volume1/docker/open-webui:/app/backend/data environment: - OLLAMA_BASE_URL=http://ollama:11434 depends_on: - ollama networks: - ai-net networks: ai-net: driver: bridge

这里对几个关键配置做一个说明。Ollama容器的OLLAMA_HOST=0.0.0.0是必须的，它让Ollama监听所有网络接口，否则只有容器内部能访问，Open WebUI通过ollama:11434这个内部地址倒是能通，但你想从局域网直接调API就不行了。OLLAMA_KEEP_ALIVE=24h让模型加载之后保持24小时不释放，避免每次对话都要重新加载模型，等待时间能从十几秒缩短到一两秒。OLLAMA_MAX_LOADED_MODELS=1限制同时最多加载一个模型，防止内存溢出。OLLAMA_NUM_PARALLEL=1让每个模型同时只处理一个请求，虽然牺牲了并发，但换来了稳定性。

Open WebUI的端口映射是3000:8080，原因是Open WebUI容器内部默认监听8080端口。如果你想把Web界面改成别的端口，只需要改左侧的3000，右侧的8080不要动。如果你不想让局域网用户直接看到管理界面，也可以只映射到127.0.0.1，但一般家庭内网问题不大。

3.3 启动服务并验证

在SSH中执行：

cd /volume1/docker docker compose up -d

第一次启动需要拉取两个镜像，ghcr.io的镜像如果卡住，可以按之前的思路换加速地址或者多试几次。启动之后用下面的命令查看状态：

docker compose ps docker logs -f ollama docker logs -f open-webui

正常情况下，Ollama的日志会显示类似“Listening on 0.0.0.0:11434”的提示，Open WebUI的日志会提示服务已启动。此时在浏览器输入http://NAS_IP:3000，就能看到Open WebUI的注册页面了。如果页面打不开，优先检查绿联NAS的防火墙是否放行了3000端口，有些系统默认会阻止未识别的端口访问。

3.4 拉取模型并切换

Ollama部署好之后，容器里是没有任何模型的，需要手动拉取。执行：

docker exec -it ollama ollama pull qwen2.5:7b

这就是前面说过的Ollama简化操作的最好体现，一条命令就把模型下载并解包好。下载速度取决于网络环境，一个4.7GB的模型，在正常网络下可能需要10到20分钟。下载完成之后可以用ollama list确认：

docker exec -it ollama ollama list

你会看到类似下面的输出：

NAME ID SIZE MODIFIED qwen2.5:7b 123abc... 4.7 GB 2 minutes ago

想切换到deepseek-r1时，只需要再执行一次ollama pull deepseek-r1:7b，两个模型会共存，在Open WebUI的下拉菜单里随时切换。但注意不要同时加载多个大模型，前面环境变量设为OLLAMA_MAX_LOADED_MODELS=1，新模型加载时旧模型会自动释放。

4. 界面配置与日常使用

4.1 初始化管理员并切换到中文

第一次打开Open WebUI时，第一个注册的账号会被自动设置为管理员。这一步很关键，管理员账号拥有管理用户、配置模型、修改系统设置的权限，建议用强密码，不要用常见的123456。

注册登录之后，默认界面是英文的，切换中文的方法是：点击右下角的头像图标，进入“Settings”→“General”→Language，选择“简体中文”，保存之后刷新页面即可。新版Open WebUI的语言支持已经很完善，中文界面的汉化率在90%以上，基本不影响使用。如果你下载的是较旧版本，可能没有中文选项，直接拉取main标签的最新版即可。

4.2 在Open WebUI中关联Ollama

正常情况下，Compose方式部署的两个容器在同一个Docker网络中，Open WebUI通过OLLAMA_BASE_URL=http://ollama:11434环境变量就能自动连接Ollama，不需要在页面上手动配置。

打开管理面板“管理员设置”→“连接”，在弹出的Ollama连接配置中确认地址是http://ollama:11434。如果你不是用Compose方式部署，而是分开创建的容器，这里的地址就要改写成宿主机内网IP，形如http://192.168.x.x:11434。

判断是否连通很简单，在Open WebUI的模型选择下拉框里，如果能列出刚才拉取的qwen2.5:7b，就代表连接成功。如果列表是空的，先回到SSH执行curl http://localhost:11434/api/tags测试Ollama接口是否正常，再检查两个容器是否在同一网络。

4.3 常用对话参数与本地知识库

在Open WebUI的模型设置里，我们可以调整温度、上下文长度、重复惩罚等参数。我用qwen2.5:7b时的习惯设置是：

上下文长度尤其要注意。Open WebUI支持拖一个PDF或者TXT文件到聊天窗口里做知识库问答，也就是RAG检索增强生成。如果你传了一个很长的文档，系统需要把文档切块、向量化、再检索相关片段，上下文窗口太小的话效果会打折扣，但调得太大又占内存。我的经验是7B模型用4096是一个比较舒服的平衡点，既不影响长文档问答，也不会让NAS内存告急。

4.4 通过OpenAI兼容接口提供API给其他应用

Ollama除了给Open WebUI提供服务，还暴露了一个与OpenAI兼容的API接口，这意味着你可以把NAS变成一个“私有API服务”，供内网里其他应用使用。接口地址是：

http://NAS_IP:11434/v1

比如你用curl直接测试：

curl http://192.168.1.100:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好，请介绍一下自己"}] }'

这样的API接口还能被很多客户端直接使用。比如Cherry Studio、ChatBox这类桌面应用，都支持配置自定义API地址，你把地址填成http://192.168.1.100:11434/v1，模型名填qwen2.5:7b，就能在电脑上获得一个完全私有的ChatGPT式客户端。如果你用VS Code里的编程助手插件，同样可以指向这个地址，让内网模型帮你写代码，代码不会出网。这个“一次部署，多方调用”的特性，是我认为本地私有模型最大的价值之一。

5. 常见问题与排查技巧

5.1 模型下载太慢或失败

模型下载慢是遇到最多的问题，尤其是在国内网络环境下，从Ollama的官方镜像源拉取几个GB的模型确实可能让人崩溃。我的处理优先级是这样的：先选择较小的模型试水，比如qwen2.5:3b只有大约2GB，下载压力小得多；其次避开网络高峰时段，深夜实测速度通常最好；如果公司或小区宽带有可用的镜像加速，可以在Ollama的environment里设置OLLAMA_REGISTRY_MIRROR，指向合法的镜像源地址。

还有一个比较稳妥的离线方案：在一台网络环境较好的电脑上装好Ollama，先用ollama pull把模型拉下来，然后把本机的~/.ollama目录整体拷贝到NAS的/volume1/docker/ollama目录下。因为Ollama的模型目录结构是完全兼容的，拷贝完成之后重新启动容器，模型直接就能识别，全程不走NAS的下载通道。这个办法在模型文件特别大的时候反而最省心。

5.2 内存不足、卡顿甚至OOM

16GB内存跑7B模型，表面看是够的，但NAS上往往还运行着文件服务、相册智能识别、虚拟机和各种容器，真正留给Ollama的可用内存打个七折八折很正常。如果你在日志里看到Out of memory，或者Open WebUI的响应时间突然变得极慢，优先级最高的操作是限制Ollama的资源占用。

先确认OLLAMA_MAX_LOADED_MODELS=1已经设置，再检查OLLAMA_NUM_PARALLEL是不是被调大了，这两个环境变量分别控制“加载几个模型”和“同时处理几个请求”。如果问题仍然存在，就把NAS上的虚拟机、其他重型容器先停掉，然后观察一段时间。最后一步才是换小模型，比如从7B降到3B。毕竟在NAS上追求极致大模型本身就是伪需求，稳定可用才是核心。

5.3 局域网其他设备打不开Open WebUI

在浏览器访问http://NAS_IP:3000打不开，原因通常是三个方向。第一是NAS系统防火墙拦截了端口，到UGOS Pro的安全设置里把3000端口放行，或者临时关掉防火墙做对照测试；第二是路由器的AP隔离功能，有些路由器默认开启“访客网络隔离”，会阻止设备之间的互访；第三是Compose中端口映射没有生效，用docker compose ps确认端口有没有被占用。如果需要同时通过HTTPS访问，可以在绿联的“反向代理”或“应用门户”里配置域名转发，把3000端口映射到已备案的域名上。

5.4 Open WebUI与Ollama的连接不稳定

Open WebUI经常提示“无法连接到Ollama”，但ollama容器本身是正常的。最常见的原因是没有用服务名连接，而是写成了localhost。在Compose网络中，localhost指向容器自己，而不是宿主机，正确地址是http://ollama:11434。如果你非要写成宿主机IP，确保NAS的防火墙放行了11434端口。

另一个容易忽略的问题是Open WebUI容器启动时Ollama可能还没就绪，虽然Compose配置了depends_on，但它只控制启动顺序，不控制“等待就绪”。如果日志里一直报连接拒绝，重启一次Open WebUI容器通常就能解决：

docker restart open-webui

5.5 模型文件占用空间过大，如何迁移目录

玩到后面模型越来越多，/volume1/docker/ollama目录可能会膨胀到几十GB。如果发现卷空间不够，需要把整个Ollama目录平移到更大的卷上。做法并不复杂：先把Ollama容器停掉，用mv命令把目录移到目标卷，然后修改Compose文件中的/volume1/docker/ollama映射路径，再执行docker compose up -d重新创建容器即可。个人建议不要把模型目录和系统目录混在一起，单独划分一块空间，后续管理起来清晰很多。

到了这一步，整套绿联NAS上的私有大模型服务已经基本构建完整了。如果你也是第一次接触这套方案，我建议从qwen2.5:3b开始把链路跑通，再逐步升级模型，因为部署成功的成就感会直接决定你是否愿意继续研究下去。而一旦你确认了“原来本地模型真的能做到这个程度”，后面无论是给家人分配账号、还是把接口接入到更多应用，都会有更清晰的思路。最后分享一个我自己的习惯：模型的版本偶尔会更新，每隔一段时间记得到Ollama官方看一下新版本tag，ollama pull一条命令就能原地升级，比从零部署要轻松太多了。