企业官网建设流程全解析

前阵子帮同事在实验室的Ubuntu服务器上搭了一套内网可用的本地大模型服务，用的就是Ollama加OpenWebUI这套组合。折腾了几天，踩了不少坑，也把一些关键细节摸清楚了。正好最近不少朋友在问“怎么在Ubuntu上自己部署一套大模型”这件事，索性把整个流程和一些经验整理出来——包括为什么选这套方案、每一步的完整操作、以及我实际遇到的几个让人头大的问题。

这篇文章适合谁？如果你有一台Ubuntu机器（物理机、虚拟机、云服务器都行），手头有块N卡或者哪怕只有CPU，想跑起来一个类ChatGPT的网页端大模型服务，又不想把数据交给第三方，那这篇教程能帮你少走很多弯路。核心内容就是：Ubuntu上装Ollama、用Docker跑OpenWebUI、把两者对接起来，最终得到一个浏览器里就能聊天的本地大模型平台。

1. 整体方案设计与选型思路

1.1 为什么是Ollama + OpenWebUI，而不是其他组合

先说结论：这俩是目前个人自部署大模型服务里“最快跑通”的组合，没有之一。

我在选型的时候认真对比过几个方案，各有各的适用场景：

Ollama的角色相当于“本地模型运行时”，负责把大模型文件跑起来，对外暴露一个HTTP API。OpenWebUI则是一个完全开源的网页聊天界面，长得跟ChatGPT几乎一模一样，支持多用户注册、会话管理、模型切换、参数调整，还支持联网搜索和知识库。两个东西一结合，就是一个低配版的“私有ChatGPT”。

为什么不用llama.cpp直接跑？因为纯命令行界面没人受得了，你总不能让团队里所有人都去敲命令。为什么不用vLLM？因为这个项目第一诉求是“快速可用”，不是“高并发”，vLLM配置和调优的成本对于个人用户来说实在太重了。

1.2 硬件门槛与性能预期

关于硬件，直接给一份我实测过的参考表：

这里有个重要的点：Token对中文的切割和人眼阅读速度的关系。人眼阅读速度大概每秒5-8个字，一个汉字大致等于1-2个token。所以10 token/s以上就已经能顺顺当当地读了，低于这个数就会觉得“卡卡的”。

如果只有CPU没有GPU，也不是不能玩。Ollama会默认用AVX/AVX2指令集做CPU推理，装好了直接用就行。只是别选太大的模型，7B或8B的量化版（Q4）在16GB内存的机器上跑起来是没问题的。我第一次部署是在一台只有CPU的4核小主机上跑的，速度惨不忍睹但流程跑通了；后来换了带显卡的机器，体验直接起飞。

1.3 系统版本与分区建议

Ubuntu版本建议直接用22.04 LTS或24.04 LTS，不要用那些非LTS版本。原因很简单：LTS版本维护时间长、第三方软件兼容性好、内核稳定，Docker和NVIDIA驱动在LTS上几乎不会遇到编译问题。我自己用的是22.04 LTS，NVIDIA驱动5系、Docker 27、Ollama最新版都兼容良好。

分区方面，如果你的机器主要是用来跑模型的，建议给根目录或者挂载目录留出足够空间。一个7B量化模型大约4-5GB，32B量化模型大概20GB，如果以后还想多下载几个模型，100GB空间不算多。我的习惯是单独挂一块数据盘，把模型目录软链接到大容量分区上，这样即使系统盘重装，模型文件还能保留。

2. Ubuntu环境准备与前置工作

2.1 基础系统配置

拿到一台新的Ubuntu之后，第一件事是确认系统版本和架构：

lsb_release -a uname -m

正常输出x86_64架构就可以了。接着更新系统软件源，建议替换成国内可用的镜像源，速度会快很多。编辑/etc/apt/sources.list（22.04的源格式跟旧版不一样，需要注意），替换成对应版本的Ubuntu镜像源地址。我用的阿里云和清华的源都试过，很稳定：

# 备份原文件 sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # 用sed替换或直接编辑文件 sudo sed -i 's|http://archive.ubuntu.com/ubuntu|https://mirrors.aliyun.com/ubuntu|g' /etc/apt/sources.list sudo sed -i 's|http://security.ubuntu.com/ubuntu|https://mirrors.aliyun.com/ubuntu|g' /etc/apt/sources.list sudo apt update && sudo apt upgrade -y

24.04的系统用的是.sources格式，操作方式略有差异，本质还是一样的替换源。换完源后再装几个基础工具：

sudo apt install -y curl wget git vim net-tools

这里多说一句：net-tools里的ifconfig虽然有点过时，但在排查网络问题时真的很顺手。后面排查OpenWebUI连不上Ollama的时候，你会需要用它。

2.2 安装Docker与国内镜像源配置

OpenWebUI官方推荐的部署方式就是Docker，所以Docker是必装的。安装Docker用官方脚本或者apt安装都可以：

curl -fsSL https://get.docker.com | bash # 或者 sudo apt install -y docker.io

装完之后把当前用户加入docker组，避免每次都要sudo：

sudo usermod -aG docker $USER # 重新登录或执行 newgrp docker 生效

Docker装好之后必须配镜像加速，原因你懂的——有些镜像从官方仓库拉下来慢到怀疑人生。编辑/etc/docker/daemon.json：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.net" ] }

改完重启Docker：

sudo systemctl restart docker docker info | grep "Registry Mirrors" -A 3

能看到镜像源列表就说明配置成功了。我用的是DaoCloud的加速，稳定性和速度都还可以。注意镜像源地址可能会变，如果拉不动就换一个再重启。

2.3 NVIDIA驱动与GPU透传配置

如果你有N卡，这步是关键。先确认显卡型号：

lspci | grep -i nvidia

然后Ubuntu上装NVIDIA驱动最稳妥的方法是使用官方驱动的仓库。我推荐的顺序是：

# 安装前先禁用nouveau开源驱动（如果有） sudo bash -c "echo 'blacklist nouveau' >> /etc/modprobe.d/blacklist.conf" sudo bash -c "echo 'options nouveau modeset=0' >> /etc/modprobe.d/blacklist.conf" # 更新initramfs sudo update-initramfs -u # 重启 sudo reboot

重启后安装驱动。最简单的方式是通过ubuntu-drivers工具：

sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall

或者去NVIDIA官网下载对应的.run安装包手动装，但命令行自动安装足够满足99%的场景了。装完用nvidia-smi验证：

nvidia-smi

如果能看到一个类似表格的GPU信息界面，驱动就成功了。

接下来安装NVIDIA Container Toolkit，让你用Docker跑容器时能把GPU透传进去：

# 添加官方软件源 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit # 配置Docker使用NVIDIA runtime sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

验证方式：

docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi

如果容器里能看到GPU信息，说明透传成功了。这一步我当初卡了很久，结果发现是Docker版本太老不认--gpus参数，升级Docker之后就好用了。如果你用的Docker版本很低，建议先升级到新版。

3. Ollama部署与模型管理实操

3.1 安装Ollama的两种方式

Ollama的安装官方推荐一条命令：

curl -fsSL https://ollama.com/install.sh | sh

这个脚本会自动下载对应架构的安装包、创建systemd服务、设置开机自启。但很多人会在这一步卡住——脚本下载安装包的时候特别慢，甚至超时。我自己第一次装就等了十五分钟，一度以为死机了。

如果遇到下载慢的问题，有两种解决办法：

第一种，先用浏览器或者下载工具把安装包下载下来，再本地安装。访问Ollama的GitHub Releases页面找到对应的ollama-linux-amd64.tgz文件，下载好之后：

sudo tar -C /usr -xzf ollama-linux-amd64.tgz # 创建系统用户 sudo useradd -r -s /bin/false -m -d /usr/share/ollama ollama # 创建systemd服务 sudo tee /etc/systemd/system/ollama.service > /dev/null <<EOF [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [Install] WantedBy=default.target EOF sudo systemctl daemon-reload sudo systemctl enable --now ollama

第二种方式是在安装脚本里指定镜像地址。如果官方地址拖不动，可以通过环境变量让脚本走镜像：

curl -fsSL https://ollama.com/install.sh | OLLAMA_MIRROR=https://mirror.example.com sh

具体镜像地址以社区里实时可用的为准，配置之后下载速度会快很多。这两种方式都能解决问题，我用的是第一种，因为可以直观看到安装包到底下载到没有。

3.2 常用命令与模型选择

Ollama装好之后，先确认状态：

ollama --version systemctl status ollama

然后就可以拉模型了。先别急着下大模型，建议先拉一个几GB的小模型把流程跑通。我推荐顺序是这样：

# 看已有模型 ollama list # 拉取一个7B/8B的模型 ollama pull qwen2.5:7b # 运行模型，进入交互对话 ollama run qwen2.5:7b

模型选择是很多新手容易犯错的地方。直接说结论：

• 1.5B/3B：零基础测试用，速度飞快但智商下线，适合先跑通流程
• 7B/8B：入门黄金档，推荐qwen2.5:7b和llama3.1:8b，普通对话、写代码都还行
• 13B/14B：需要16GB以上显存，质量有明显提升
• 32B：需要24GB显存，或者CPU+大内存硬扛
• 70B以上：基本上属于服务器级别了，个人玩不推荐

量化概念需要理解一下。Ollama的模型标签里常见q4_0、q8_0、fp16这些后缀，表示权重量化精度。量化相当于把模型从“原始高清素材”压缩成“高质量压缩包”，占空间更小、运行更快，代价是答案质量略降。Q4量化的7B模型大约4GB，Q8大约8GB。我的建议是：显存够就选Q8，不够就选Q4，差距没有想象中那么大。

查看模型占用和运行状态：

# 查看当前运行的模型 ollama ps

Ollama默认会把模型放在/usr/share/ollama/.ollama/models目录（以deb包安装时）。如果你想换位置，设置环境变量OLLAMA_MODELS指向新目录就行：

# 修改service文件添加环境变量 sudo systemctl edit ollama.service # 在里面填入 [Service] Environment="OLLAMA_MODELS=/data/ollama/models"

改完重启服务即可。

3.3 监听配置与API测试

默认情况下Ollama只监听127.0.0.1:11434，也就是只有本机能访问。如果OpenWebUI是Docker容器跑的，它访问Ollama需要能通过网络连通，所以一般要把监听地址改成0.0.0.0：

sudo systemctl edit ollama.service [Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

重启并验证：

sudo systemctl restart ollama ss -tlnp | grep 11434

能看到0.0.0.0:11434就对了。

然后用curl测试一下API是否正常：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "你好，用一句话介绍你自己", "stream": false }'

如果返回一段JSON包含“response”字段，说明Ollama服务完全正常了。后面OpenWebUI连不上Ollama，大概率不是Ollama的问题，而是网络连通性或地址配置的问题。

4. OpenWebUI部署配置与完整联调

4.1 Docker部署OpenWebUI

Ollama就绪之后，轮到前端界面OpenWebUI。官方推荐最简启动命令是：

docker run -d \ -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main

这条命令的参数解释一下：

• -p 3000:8080：把容器的8080端口映射到宿主机的3000端口。你在浏览器访问宿主机的3000端口就能打开OpenWebUI了
• --add-host=host.docker.internal:host-gateway：让容器内部能通过host.docker.internal这个域名访问宿主机。这是Docker 20.10以上版本的标准做法，没有这个参数容器里访问宿主机IP会比较麻烦
• -v open-webui:/app/backend/data：把数据目录挂载出来，用户的账号、聊天记录、配置都存在这里，容器删了也不会丢
• --restart always：容器挂了自动重启

有一点需要说明：OpenWebUI镜像仓库在ghcr.io，国内拉取有时候慢或者直接超时。可以先去一些提供镜像加速的站点查一下有没有对应的镜像地址，或者直接下载官方离线包再导入镜像。我用的时候有一次拉取花了半小时，建议提前有心理准备。如果确实拉不下来，换一个时间多试几次，或者通过带有代理的Docker配置解决——这个属于网络环境差异，不展开讲了。

4.2 首次登录与Ollama对接

启动之后，浏览器访问http://你的服务器IP:3000。第一次打开会让你注册一个账号，这个账号自动成为管理员。OpenWebUI本身不限制用户数，注册了就能用，非常适合小团队内部部署。

登录进去之后，它默认会去找http://localhost:11434来连Ollama。如果你是用Docker方式跑的OpenWebUI，容器里的localhost和宿主机不是一个，所以需要手动配置连接地址。在管理员设置里找到“外部连接”或“Ollama API地址”，填上：

http://host.docker.internal:11434

如果没用--add-host参数，这里就要填宿主机的局域网IP，比如：

http://192.168.1.100:11434

填好之后，点一下连接测试或者直接刷新页面，如果能正常显示模型列表，就说明对接成功了。这个时候你应该能在OpenWebUI的页面里看到已经拉取的模型名字，点击模型，输入问题，就能开始聊天了。

联调过程中最常遇到的问题就是“无法连接到Ollama API”。遇到这个别急，排查思路放到第5章说。

4.3 Docker Compose方式部署

如果以后要经常维护这套环境，建议一开始就用Docker Compose来管理。新建一个docker-compose.yml：

version: '3.8' services: ollama: image: ollama/ollama:latest container_name: ollama ports: - "11434:11434" volumes: - ollama_data:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0:11434 restart: always deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui depends_on: - ollama ports: - "3000:8080" environment: - OLLAMA_BASE_URL=http://ollama:11434 volumes: - open-webui_data:/app/backend/data restart: always volumes: ollama_data: open-webui_data:

看到区别了吗？Compose方案里Ollama也容器化了，OpenWebUI直接用http://ollama:11434访问它，这是Docker容器间的内网通信，速度更快也少了很多网络配置。唯一需要注意的是，Ollama在容器里要跑GPU，需要在上层配置gpus: all参数。如果你没有GPU，把这段配置去掉就行。

启动：

docker compose up -d

查看日志：

docker compose logs -f open-webui

这套方案的好处是迁移方便，整个服务就是几个容器，换机器时直接导出配置重来一遍就行。

5. 常见问题与排查技巧实录

5.1 模型下载慢或一直失败

这是被问得最多的问题。Ollama默认从官方模型库拉文件，走了不同地区网络之后速度差异极大。我实测一个7B模型在部分网络环境可能要下半小时甚至更久，而且过程中断点断传还不一定做得好。

经验解法有几种：

• 设置OLLAMA_MODELS目录到磁盘空闲大的位置，防止默认位置空间不够
• 通过环境变量指定模型库镜像地址，国内有不少社区维护的Ollama模型镜像，能够大幅加快下载
• 直接手动下载GGUF文件后用ollama create导入模型，绕开官方拉取链路

第三种我详细说一下。比如你在HuggingFace或国内模型托管平台下载了qwen2.5-7b-instruct-q4_k_m.gguf，然后写一个Modelfile：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf TEMPLATE """{{ if .System }}<|start_header_id|>system<|end_header_id|> {{ .System }}<|eot_id|>{{ end }}<|start_header_id|>user<|end_header_id|> {{ .Prompt }}<|eot_id|><|start_header_id|>assistant<|end_header_id|> """ PARAMETER temperature 0.7 PARAMETER top_p 0.9

然后执行：

ollama create qwen2.5-local -f Modelfile

这样就把本地的GGUF文件注册成Ollama可用的模型了，完全绕开了下载流程。

5.2 显存不足或内存不足导致OOM

玩本地大模型的人都会遇到OOM（Out of Memory）。最经典的错误是“Error: failed to allocate memory”，出现这个通常是你的模型太大，显存或内存装不下。

三个解决办法按优先级排：

• 换成更小的模型或更低的量化版本，这是最有效的方式
• 关掉num_ctx的上下文窗口大小，OpenWebUI里可以配置每个模型的上下文长度，默认可能太大占内存
• 升级硬件，这是治本的办法

我看硬件情况的时候习惯用这几个命令：

# 实时查看显存使用 watch -n 1 nvidia-smi # 查看内存使用 free -h # 查看磁盘空间 df -h

先确认卡在哪一个维度，再对症下药。如果是我自己的16GB内存机器跑7B Q4量化，模型推理时内存大概吃7-9GB，剩余空间并不宽裕。多开浏览器标签页，再跑模型就容易把内存打满。这种情况可以在OpenWebUI里限制并发会话数量，别让多个人同时跑大招。

5.3 OpenWebUI连接Ollama失败

OpenWebUI页面里显示“Unable to connect to Ollama”或“Failed to fetch model list”，是最常遇到的问题。按这个顺序排查：

第一步，确认Ollama服务本身活着：

systemctl status ollama curl http://localhost:11434/api/tags

如果curl返回了JSON格式的模型列表，说明Ollama没问题。

第二步，确认OpenWebUI容器能访问到宿主机：

docker exec open-webui curl http://host.docker.internal:11434/api/tags

如果容器里curl不通，问题大概率出在--add-host参数上，或者你用了Docker Compose但没有配置对应域名。

第三步，确认防火墙：

# Ubuntu自带的ufw如果开启了，要放行11434和3000端口 sudo ufw status sudo ufw allow 11434/tcp sudo ufw allow 3000/tcp

我遇到过最诡异的一个问题是：服务器上同时跑了多个Python服务，导致11434端口被某个进程旁路占用。排查的时候用ss -tlnp | grep 11434看一眼对端地址就一目了然了。

5.4 常见问题速查表

6. 进阶玩法与日常使用建议

6.1 多用户管理与权限配置

OpenWebUI自带用户管理，管理员登录后台可以禁用注册功能，改成手动开通账号。这样适合团队内部用，避免外部闲杂人等都来注册。在管理员设置里还有“模型收藏”“分组管理”等功能，可以对不同用户组限制可用的模型，比如普通员工只能用小模型，高级用户才能用32B的大模型。

我自己实际使用的感受是：OpenWebUI的多用户做得比预想中好很多，账号系统、会话隔离、分享功能都有。甚至每个用户还可以自定义自己的模型参数字段，对懂行的用户来说自由度很高。

6.2 联网搜索接入

OpenWebUI支持接入各种搜索API，比如SearXNG、Tavily等。配置好之后，模型回答问题时会先搜索相关内容再给出回答，避免“闭门造车”。这里有一个关键参数需要注意：如果搜索服务是自建的，同样要注意容器网络连通性，用host.docker.internal来访问宿主机上的SearXNG端口。

6.3 与桌面工具联动

OpenWebUI只是一个网页端，但它的后端API是标准的OpenAI兼容接口。这意味着你可以把ChatBox、Cherry Studio这类桌面客户端也接进来，配置时把API地址指向http://你的服务器:3000/api，密钥填OpenWebUI的API Key就能用。我试过在局域网内用手机上的ChatBox连接服务器上的OpenWebUI，体验跟在网页端聊没什么差别，但界面更加本地化，适合日常重度使用。

6.4 维护与升级建议

几个维护小技巧：

• 定期备份OpenWebUI的/app/backend/data目录，里面存了所有账号和聊天记录，迁移时拷走就行
• Ollama升级前先ollama list确认模型列表，升级不会清掉模型，但保险起见还是看一眼
• Docker镜像升级前先docker compose pull，然后docker compose up -d，注意先看GitHub Release有没有重大变更
• 如果长时间不用，ollama stop可以停止所有加载的模型释放显存

我在实际运维这套系统时一个比较深的体会是：本地大模型部署其实不是“装好就行”，而是“持续迭代模型”的过程。今天用7B的模型可能觉得不错，但过两天出了新的微调版本，拉下来一试，效果又好了不少。所以建议你把Ollama的模型目录当成一个“模型仓库”来管理，定期清理不常用的，保留最新的，这样磁盘和显存都能利用得更高效。

这套系统我已经跑了大半年，中间重装过系统、换过机器、接过多个前端界面，每次迁移数据都很顺利。现在团队里几个人都在用，有写代码问问题的，有做文档摘要的，还有用来润色文本的，基本替代了对外部服务的依赖。回头想想，当初选Ollama + OpenWebUI这套方案，最看重的一点就是“不折腾”——从零装到用上，核心流程半小时内搞定，剩下的时间都可以花在优化模型和玩法上。希望这份教程也能帮你少踩几个坑。