企业官网建设流程全解析

去年年底我给自己列了个“本地跑大模型”的计划，选来选去最后还是落到了 Ollama 上。试过之后发现，与其在 Ubuntu 系统里直接裸装，不如用 Docker 来部署 Ollama，整个流程干净、可控、换机器也方便。这篇博文我就从 Ubuntu 环境准备讲起，到 Docker 镜像加速、Ollama 容器启动、轻量模型拉取与 API 调用，最后把我在实际部署中踩过的坑一并列出来。全程拿我自己跑过的命令和参数说话，照着操作基本一次就能跑通。

1. 为什么建议在 Ubuntu 上用 Docker 部署 Ollama

1.1 Ollama 到底解决了什么问题

Ollama 是一个本地大模型运行框架，把模型的下载、加载、推理 API 这几件事封装得非常简单。你不需要懂 TensorFlow、PyTorch 或者 CUDA 的细节，也不需要手动去 Hugging Face 上下载权重文件再写推理脚本，只要一条ollama run qwen2.5:0.5b就能把模型跑起来。

它的优势在于抽象层做得非常薄。底层虽然也是调用 llama.cpp 或类似引擎，但对外暴露的是一个极简 REST API，默认监听11434端口。这个设计思路和 Redis、MySQL 这类服务类似，做成“常驻服务”之后，任何语言都能通过 HTTP 调用模型，后续对接前端、接 Python 后端、甚至做企业内部知识库都非常顺手。

有人可能会问，既然 Ollama 本身安装就不难，为什么还要用 Docker？因为我实际部署过两三台机器之后发现，Ollama 对运行环境是有要求的，比如 glibc 版本、CUDA 驱动、Python 依赖等等。一旦脱离官方推荐环境，安装失败的概率会明显上升。而 Docker 镜像里把运行时全部打好了，拉下来就是一个隔离好的“盒子”，对宿主机环境几乎零入侵。

1.2 Docker 部署相比裸装的三个优势

第一个优势是隔离性。Ollama 会写日志、下载几个 GB 甚至几十 GB 的模型文件、占用大量内存，如果用裸装方式，一旦出了问题，系统里会残留一堆服务和依赖。Docker 部署则把这些问题都关在容器里，清掉容器就等于完全卸载。

第二个优势是迁移方便。我原来在一台 Ubuntu 服务器里配好了这么多模型，后来要换到另一台机器，直接做个ollama_data数据卷迁移，把模型目录打包拷贝过去就完事了，不需要重新下一遍模型。如果你用裸装方式，得重新开环境、配依赖、重新 pull 模型，费时费力。

第三个优势是版本管理。Ollama 官方更新很勤，使用 Docker 镜像可以精确控制版本，比如固定到ollama/ollama:0.5.7这种具体 tag。升级时只要重新拉标签、按容器就行，出问题还能马上回滚。裸装升级一旦覆盖了旧版本，出现兼容问题就很难恢复。

2. 部署前的环境准备

2.1 Ubuntu 系统基础要求

我用的系统是 Ubuntu 22.04 LTS，这套方案对 Ubuntu 20.04 和 24.04 同样适用。内核要求不算苛刻，5.4 以上即可，因为 Docker 本身依赖内核特性，比较大的版本差异主要体现在存储驱动上，overlay2 是默认推荐配置，Ubuntu 20.04 以上基本不需要额外配置就能满足。

硬件上要注意两点。一个是 CPU 架构，x86_64 和 ARM64 都可以跑，但如果你用的是 CPU 推理，小模型 x86_64 会更友好一些。另一个是内存，只是跑 0.5B、1.5B 级别的小模型，8GB 内存就够了；但如果你准备之后尝试 7B 甚至 13B 模型，最好上 32GB 内存，或者至少有一块 8GB 显存的 NVIDIA 显卡。

在动手前先把系统更新到最新，避免依赖冲突：

sudo apt update && sudo apt upgrade -y sudo apt install -y curl git nano

这里顺手安装 curl 和 git，后面下载和编辑配置都会用到。如果你的系统之前装过旧版 Docker，建议先把旧版本卸载干净，然后再装新的。

2.2 安装 Docker 的正确姿势

安装 Docker 有两个主流路径：官方一键脚本和 apt 源安装。

官方脚本最简单，但前提是你的网络能顺畅访问 Docker 官方域名：

curl -fsSL https://get.docker.com | bash -s docker

如果网络条件不太稳定，更推荐用 apt 仓库方式安装。先添加 Docker 官方 GPG key 和 apt 源，然后正常安装：

sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

装完之后，记得把当前用户加进 docker 组，否则每次执行 docker 命令都要加 sudo：

sudo usermod -aG docker $USER newgrp docker

然后验证一下 Docker 服务状态：

sudo systemctl enable --now docker docker version

这里有一个容易踩的坑：如果提示连接 Docker socket 权限不足，多半是用户组没有刷新。重新登录一次，或者直接执行newgrp docker让当前会话生效就行。

2.3 给 Docker 配一份镜像加速

拉取 Docker 官方镜像在国内网络环境里经常很慢，这个和服务器带宽、地理位置都有关系。解决办法是配置镜像加速器，这些加速器本身是合法的公共镜像缓存服务。

我通常配置两个加速器，比如阿里云容器镜像服务的加速地址和道客云的公共加速地址。先创建或修改/etc/docker/daemon.json：

sudo mkdir -p /etc/docker sudo nano /etc/docker/daemon.json

写入以下内容：

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

这里只写了一个地址，是因为阿里云加速地址需要用户登录后获取专属域名。道家云的这个公共地址我自己用了很久，速度一直很稳定。改完配置后重启 Docker：

sudo systemctl daemon-reload sudo systemctl restart docker

然后用docker info查看 Registry Mirrors 是否生效。以后拉取镜像时，Docker 会优先走加速地址，速度往往能快不少。

3. 用 Docker 跑起 Ollama 服务

3.1 拉取官方镜像前先了解目录结构

Ollama 官方镜像名是ollama/ollama，我建议拉取的时候指定具体版本，不要直接用默认的 latest。因为 Ollama 跨版本升级偶尔会有模型兼容性变化，钉版本可以让你在重新部署时保持行为一致。

先拉镜像：

docker pull ollama/ollama:latest

拉取的同时，我们要搞清楚 Ollama 数据存储的位置。Ollama 把模型文件、日志和配置统一放在容器内的/root/.ollama目录，这条路径是整个部署方案里最重要的一条路径。如果你不把它挂载到宿主机，容器一旦被删除，所有已下载的模型都会丢失。

3.2 启动容器的关键命令

启动命令我会写成这样：

docker run -d \ --name ollama \ -v ollama:/root/.ollama \ -p 11434:11434 \ --restart=always \ ollama/ollama:latest

逐项解释一下参数含义：

• -d后台运行，日志交给 Docker 管理。
• --name ollama给容器起一个固定名字，后面执行 exec 命令时方便引用。
• -v ollama:/root/.ollama创建一个名为ollama的命名卷，并挂载到容器内的模型目录。这样即使容器删了，模型数据还在。
• -p 11434:11434把容器内的 11434 端口映射到宿主机，后续调用 API、对接 Web 界面都靠这个端口。
• --restart=always让容器在开机或崩溃后自动拉起，很适合作为服务运行。

这里我特意用命名卷而不是直接挂宿主机目录。命名卷由 Docker 管理，权限不会出现乱七八糟的问题，执行docker volume inspect ollama就能看到实际存储位置，备份时用tar打包目录也方便。

如果你的机器有 NVIDIA GPU，并且已经装好 nvidia-container-toolkit，可以在docker run里加上--gpus all参数来启用 GPU 加速，这个后面第 6.3 节会细说。

3.3 验证服务是否正常

启动之后，先确认容器状态：

docker ps | grep ollama

如果 STATUS 显示Up，再调一次 API 验证版本信息：

curl http://localhost:11434/api/version

看到类似{"version":"0.5.7"}的 JSON 返回，说明服务已经正常起来了。如果 curl 连接不上，第一件事不是查容器，而是看容器日志：

docker logs ollama --tail 50

Ollama 监听的是0.0.0.0:11434，所以宿主机上的 curl 一定能通。如果你在局域网的另一台电脑上访问不到，先去检查防火墙规则，Ubuntu 上通常需要放行 11434 端口：

sudo ufw allow 11434/tcp

4. 拉取并运行轻量模型

4.1 轻量模型怎么选

“轻量模型”不是一个严格的学术定义，我习惯把参数量在 0.5B 到 4B 之间、部署后内存占用可控、CPU 也能跑的模型都归到这个范围。下面这几款是我在 Ollama 模型库里实测下来表现不错的轻量模型：

如果是第一次部署，我非常推荐从qwen2.5:0.5b开始。体积最小、拉取最快，先把整条链路跑通，再根据需求切换到更大模型。0.5B 的模型虽然能力有限，但用来测试 API、试 web 界面、验证代码调用完全够用。

需要注意，模型体积不是固定不变的，Tensor 量化方式会影响实际文件大小。Ollama 默认拉取的标签通常会附上量化信息，比如qwen2.5:0.5b默认就是 Q4_K_M，如果想用更大精度的版本，可以显式指定qwen2.5:0.5b-q8_0，这样体积会更大，但精度也更高。

4.2 在容器内运行模型

拉取模型需要在容器内执行ollama命令：

docker exec -it ollama ollama run qwen2.5:0.5b

第一次执行时，Ollama 会先下载模型文件。由于模型文件体积有几百 MB 到几 GB，下载速度和你的网络条件强相关。如果下载过程卡住或太慢，可以参考第 6.2 节的解决办法。

下载完成后会进入交互式命令行界面，输入文字就会得到模型回复。输入/bye退出交互模式，模型会继续保留在容器里。

如果你不想进交互式界面，也可以直接用命令拉到模型库但不运行：

docker exec ollama ollama pull qwen2.5:0.5b

这样模型就保存在数据卷里了，后续要调用时随时可以加载。我比较推荐这种“先 pull 再 run”的方式，因为交互模式容易让人误以为模型没有持久化。

4.3 通过 REST API 调用模型

Ollama 最常用的接口有两个：/api/generate和/api/chat。

/api/generate适合“一次性文本补全”，直接把 prompt 丢进去拿结果：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:0.5b", "prompt": "用一句话解释什么是 Docker", "stream": false }'

返回 JSON 里的response字段就是模型生成的文本。stream: false表示等整段生成完再返回，调试时用这个参数最方便；生产环境里想实现“打字机流式输出”，可以把stream设为true，然后用curl -N或者 SSE 客户端来消费。

/api/chat适合多轮对话场景，需要带上历史消息：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2.5:0.5b", "messages": [ {"role": "user", "content": "1+1等于几？"} ], "stream": false }'

消息结构完全兼容 OpenAI Chat API 的格式，后面接 Python、JavaScript 都毫无障碍。我经常用 Python 里的requests直接调这个接口，几分钟就能写出一个本地聊天机器人。

5. 让 Ollama 容器更顺手：Compose 与界面化

5.1 用 docker-compose 管理容器

实际部署时，我从来不靠一条docker run打天下。因为要同时管理 Ollama 和 Web UI，用 Compose 编排更清晰，还能把端口、卷和重启策略都写在代码里，换机器部署时直接复制文件。

创建docker-compose.yml：

services: ollama: image: ollama/ollama:latest container_name: ollama restart: always ports: - "11434:11434" volumes: - ollama_data:/root/.ollama volumes: ollama_data:

然后启动：

docker compose up -d

之后查看状态就用docker compose ps，升级镜像时用docker compose pull && docker compose up -d，全省事了。如果后续要加第二个服务，改 YAML 文件就行，不需要再记住那一长串 docker run 参数。

5.2 可选：加一个 Open WebUI

纯命令行和 REST API 已经能干活，但如果想让家里其他人也能用，我强烈建议配一个 Open WebUI。它是一个开源对话前端，界面类似 ChatGPT，还能管理多用户和会话记录。

在docker-compose.yml里追加一个open-webui服务，并让它加入与 Ollama 同一个自定义网络：

services: ollama: image: ollama/ollama:latest container_name: ollama restart: always ports: - "11434:11434" volumes: - ollama_data:/root/.ollama open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: always depends_on: - ollama ports: - "3000:8080" environment: OLLAMA_BASE_URL: http://ollama:11434 volumes: - openwebui_data:/app/backend/data volumes: ollama_data: openwebui_data:

保存后重新docker compose up -d，等镜像拉取完成后，打开http://服务器IP:3000就能看到注册界面。首次注册的账号就是管理员账号。

这个方案最舒服的地方在于，Open WebUI 通过容器内部的ollama:11434访问 Ollama，不需要走公网端口，安全性和易用性都能兼顾。我在局域网里用手机浏览器连这个端口调用本地模型，速度非常理想。

6. 常见问题与排查实录

6.1 Docker 镜像拉取慢

这个问题的核心是 Docker Hub 在国内的访问不稳定。解决办法是配置镜像加速器。我在第 2.3 节已经写了 daemon.json 的写法，这里补充一个排查思路：配置加速后拉取镜像仍然慢，可以执行docker info看Registry Mirrors是否已列出你的加速地址；如果列表为空，说明 Docker 没有重新加载配置，重启一下服务。

还有个小技巧：不要在深夜高峰期执行大镜像拉取，很多公共加速服务在晚上 8 点到 11 点会有明显延迟。如果是企业环境，自己搭一套镜像仓库做内网缓存才是长久之计。

6.2 模型下载慢怎么处理

Ollama 的模型默认从registry.ollama.ai下载，模型文件动辄几百 MB 到几 GB，网络差的时候经常失败。处理方式不止一种，我这里说两种我亲测有效的方法。

第一种，在宿主机先把模型文件通过其他渠道下载好，再放进 Ollama 的模型目录。Ollama 模型本质上是 GGUF 文件，可以从 Hugging Face 等渠道找到同名格式，然后用 Modelfile 的方式导入。比如下载了qwen2.5-0.5b-instruct-q4_k_m.gguf，可以先准备一个 Modelfile：

FROM ./qwen2.5-0.5b-instruct-q4_k_m.gguf

然后执行：

ollama create qwen2.5-custom -f Modelfile

这样模型就会出现在本地模型列表里，API 调用时填qwen2.5-custom即可。这种“离线导入”方式很适合在公司内网、无外网环境下部署模型。

第二种，在容器外面先用临时容器预下载，再把数据卷挂载到正式容器。原理和第一种类似，核心还是把模型文件落进挂载目录。实际操作时我会先运行一个临时容器拉取模型，成功后删除临时容器，但保留数据卷，最后再启动正式容器。这个方案不需要改 Modelfile，适合网络波动不大、只是速度偏慢的场景。

6.3 GPU 加速用不上

如果在docker run里没加--gpus all，Ollama 会默认使用 CPU 推理。想启用 GPU，需要在宿主机安装 NVIDIA 驱动和 nvidia-container-toolkit：

sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

然后启动容器时加上--gpus all，并设置环境变量：

docker run -d \ --name ollama \ --gpus all \ -v ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama:latest

如果你用的是不带 GPU 的机器，也不要气馁。轻量模型本身用 CPU 跑也完全能接受，0.5B 模型在纯 CPU 环境下单次推理延迟也就一两秒，完全够用。

6.4 端口冲突与日志查看

11434 端口被占用时，容器会启动失败。用docker logs ollama --tail 50一般能看到bind: address already in use之类的提示。排查命令：

sudo lsof -i :11434

如果确实是其他进程占用了，要么停掉旧进程，要么改映射端口，比如把宿主机端口改成11435:11434。

平时排查问题我也建议先看日志，不要动不动就重启容器。Ollama 的日志里会详细记录模型加载过程、API 请求参数和错误堆栈，很多“莫名其妙”的问题一眼就能看出来，比如模型加载内存不足、请求路径写错等等。

6.5 容器权限与数据卷备份

命名卷的权限问题在 Ubuntu 上很少出现，但如果你手动挂载了一个宿主机目录，比如-v /home/ubuntu/ollama:/root/.ollama，有时会遇到容器内无法写入的情况。原因通常是目录属主不是 root，或者 SELinux 上下文不对。建议优先使用 Docker 命名卷，能避开大部分权限问题。

备份模型数据很简单，直接打包命名卷：

docker run --rm -v ollama:/root/.ollama -v /tmp/backup:/backup ubuntu tar czf /backup/ollama_backup.tar.gz /root/.ollama

恢复时把目录解压回对应位置即可。这个操作我在迁移服务器时用了好多次，非常可靠。

7. 实际使用中的几点体会

部署完成后，最直观的变化就是“本地有一个可以随时调用的推理 API”了。我平时写脚本需要批量改写文本、生成标签，或者做一些简单的意图识别，都是直接调http://localhost:11434/api/generate，既不需要外部服务，也不用担心数据隐私。

轻量模型的价值并不在于生成多惊艳的文章，而在于“低成本解决简单问题”。比如给工具函数写注释、从日志里提取关键字段、做简单的文本分类，这些场景用 0.5B 到 1.5B 的模型就足够了。非要拿 70B 模型跑这种任务，完全是资源浪费。

有一点要提前说清楚：轻量模型的幻觉问题依然存在，对它输出的数字和事实要人工校验。我一开始让它帮忙整理账单数据，结果它一本正经地算出了错误的总和，这个教训印象很深。

最后再分享一个小技巧。因为 Ollama 的模型是惰性加载，第一次调用某个模型时会有几秒的冷启动时间。如果你在做定时任务，想避免这个延迟，可以提前发一个空请求让模型预热：

curl http://localhost:11434/api/generate -d '{"model":"qwen2.5:0.5b","prompt":"ping","stream":false}'

第二次再调用同样的模型，延迟会明显下降。这个预热技巧在我对接定时任务时帮了大忙，省掉了每次任务启动时那几秒钟的空等。

我到现在已经在两台 Ubuntu 服务器上跑通这套 Docker + Ollama 部署，一次是纯 CPU 环境，另一次加了 NVIDIA GPU。整个链路下来，最深的体会是：先选一个小模型把流程跑通，再根据实际需求逐步换大模型，整个过程最稳妥，也最不容易中途放弃。