从Docker到DeepSeek-R1：Ubuntu本地部署AI助手一站式指南

如果你手上有一台Ubuntu机器，不管它是闲置的旧笔记本、一台攒了好几年的台式机，还是云上租来的服务器，都可以把它变成一个 7×24 小时在线的本地 AI 助手。标题里提到的“从 Docker 到 DeepSeek-R1 一站式”，说白了就是一条非常成熟的路子：用 Docker 把模型运行环境打包好，再让 DeepSeek-R1 这个开源推理模型跑在你自己机器上。整件事不涉及把数据交出去，也不依赖外部 API，真正做到了“自己掌控模型、自己掌控数据”。这篇记录适合刚接触 Linux 的小白，也适合想了解本地模型部署细节的开发者。我会把每一步的为什么也讲清楚，不只是给命令，还会告诉你哪些坑值得提前避开。

1. 为什么要在本地搭AI助手：从痛点说起

1.1 你其实不需要把数据交给云端

很多人第一次用上大模型都是通过网页版聊天窗口。输入一个问题，几秒钟后得到回答，很方便，但代价是你的对话内容会传到别人的服务器上。对于日常闲聊、写文案、查资料，这或许没什么。可一旦涉及工作文档、代码片段、个人笔记，甚至企业内部资料，心里总会有点不踏实。本地部署一个 AI 助手，模型权重在你自己的磁盘里，推理过程在你自己的 CPU 或 GPU 上完成，所有输入输出都不出这台机器。它的意义不是让你脱离互联网，而是让你拥有一个完全私密的、随时可控的问答环境。

另外还有延迟和成本的问题。调用云端 API 通常按 token 计费，每次交互都有开销。自己本地部署的模型，只要硬件允许，你可以随便用，不用担心费用。虽然顶级大模型的本地版本在绝对能力上可能比不上云端最大的模型，但作为日常助手，它已经足够好用，而且响应速度完全取决于你自己的硬件，没有网络波动带来的不确定性。

1.2 为什么选Docker和DeepSeek-R1组合

Docker 的核心价值是“环境一致性”。模型推理框架往往依赖特定版本的 CUDA、Python、动态链接库，手动安装很容易把系统搞乱。比如你装了 PyTorch 需要的 CUDA 版本，又发现另一个工具需要不同版本，冲突就来了。Docker 把运行环境封装在镜像里，容器内部用什么版本，跟宿主系统无关，互不干扰。卸载也简单，删除容器和镜像即可，不会残留一堆乱七八糟的依赖。

DeepSeek-R1 是近期关注度很高的开源推理模型，它的特色是“推理过程可见”，面对复杂问题会先展示自己的思考链，再给出总结。它有很多不同参数规模的版本，最小的一两个版本在普通 CPU 上也能跑，适合初体验；大一点的版本需要一定显存，但效果更好。开源意味着模型权重可以下载到本地，配合 Docker 里的推理服务，就构成了一个不依赖任何外部商业接口的完整 AI 助手方案。

1.3 硬件要求与性能预期

先别急着动手，看看自己的机器配置能跑到什么程度。DeepSeek-R1 的官方提供了多种蒸馏版本，参数量从 1.5B 到 70B 不等。这里的“B”是 billion，代表十亿参数。参数越多，模型智商上限越高，但占用的内存和算力也越大。

如果只有 CPU 没有独立显卡，也不是完全不能玩。小尺寸模型用 CPU 推理，速度取决于内存带宽和 CPU 指令集。以 7B 量化版为例，在日常家用 CPU 上大概每秒能生成 5~10 个 token，足够用来慢慢回答。有 N 卡且安装了 CUDA 支持，速度会有几十倍的提升。所以这篇教程会同时覆盖纯 CPU 和 GPU 两种路径，大家按自己的硬件情况选择。

2. 环境准备：干净利落装好Docker和显卡支持

2.1 先确认你的Ubuntu版本和内核

大部分 Ubuntu 版本都可以跑 Docker，但不同的发行版版本对应不同的安装源和内核特性，最好先确认一下。打开终端，执行：

lsb_release -a uname -m

lsb_release -a会显示当前系统的版本号。我建议用 Ubuntu 22.04 LTS 或 24.04 LTS，这两个版本都处于长期支持状态，Docker 官方对它们的适配最完善。uname -m用来确认 CPU 架构，绝大部分 PC 输出是x86_64，如果是 ARM 开发板，比如树莓派，那输出是aarch64，后续拉取镜像时要选择对应平台版。

还有一个容易被忽略的点：Docker 依赖 Linux 内核的一些特性，老内核可能出问题。最好是 5.10 以上。执行uname -r就能看到内核版本。如果你用的是 20.04 之前的版本，建议先升级系统，不要硬上。

2.2 安装Docker引擎的两种方式

Ubuntu 下安装 Docker 最推荐的方式是使用官方仓库，这样能保证你拿到的是最新稳定版。全套流程就是更新索引、安装依赖、导入 Docker 的 GPG 密钥、添加软件源、再安装 Docker 引擎。一步步来：

sudo apt update sudo apt install ca-certificates curl gnupg lsb-release -y 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 sudo chmod a+r /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 docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

安装完成后，别急着直接用。Docker 刚装好时，docker命令需要sudo权限才能执行。每次都用sudo很麻烦，可以把当前用户加进docker用户组：

sudo usermod -aG docker $USER newgrp docker

然后验证一下：

docker run hello-world

看到Hello from Docker!就说明没问题了。如果这里网络下载镜像卡住，可以考虑给 Docker 配置国内镜像加速源。编辑/etc/docker/daemon.json，把 registry-mirrors 指向可用的加速地址，重启 Docker 服务即可。不过具体地址在不同网络环境下差异很大，这个要根据自己的实际网络情况调整。

另一种安装方式是直接用 Ubuntu 自带的apt装docker.io，优点是省事，缺点是版本一般比较旧，功能可能不全。对于需要跑 GPU 容器的场景，我建议用官方源安装，兼容性更好。

2.3 NVIDIA GPU支持（没有显卡可跳过）

如果你的机器有 NVIDIA 显卡，并且想让 Docker 容器直接利用 GPU，需要装两样东西：显卡驱动和 NVIDIA Container Toolkit。驱动可以通过ubuntu-drivers devices查看推荐版本，然后安装：

sudo ubuntu-drivers autoinstall sudo reboot

重启后运行nvidia-smi应该能看到显卡信息，比如驱动版本和显存大小。这一步比装 Docker 本身更容易踩坑。很多服务器主板上旧驱动残留会导致新驱动加载失败，建议在纯命令行环境中用sudo apt purge nvidia-*彻底清理后再装。

接着配置 NVIDIA Container Toolkit。官方给出了 apt 仓库方式：

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 sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

完成后可以用一条命令验证 Docker 是否能看到 GPU：

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

如果输出里的 GPU 信息出现在容器内，那么生产环境已经就绪。整个过程总结下来就是先把驱动装好，再让 Docker 的工具链知道如何调用 GPU。每次升级驱动后，理论上不需要重新配置 toolkit，但如果遇到could not select device driver "" with capabilities: [[gpu]]这样的报错，多半是 toolkit 没配置好或者 Docker 没有重启。

3. 一站式部署：从拉取镜像到运行DeepSeek-R1

3.1 拉取并启动Ollama容器

在本地运行大模型，最省心的服务是 Ollama。它把模型下载、推理调度、API 暴露都做成了简单命令，而且官方提供了 Docker 镜像。直接用 Docker 跑 Ollama，好处是后续想换模型、升级版本都很方便，不会在系统里留下复杂的环境痕迹。

如果你有 NVIDIA GPU，启动命令是：

docker run -d --gpus=all \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ --restart unless-stopped \ ollama/ollama

如果没有独立显卡，就去掉--gpus=all：

docker run -d \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ --restart unless-stopped \ ollama/ollama

先解释一下各参数的含义。-d让容器后台运行；--gpus=all允许容器访问所有可用的 NVIDIA GPU；-v ollama:/root/.ollama是数据卷，把模型和配置持久化到 Docker 管理的卷里，即使容器被删除，模型文件也不会丢；-p 11434:11434把容器内部的 11434 端口映射到宿主机上，这个端口是 Ollama API 的默认端口；--name ollama给容器起名方便管理；--restart unless-stopped表示只要不是手动停止，开机后容器会自动拉起，这对想长期运行的朋友很重要。

用docker ps查看容器状态，如果 STATUS 显示Up，说明服务正常。这个镜像比较大，首次拉取可能需要一些时间，耐心等待。

3.2 在容器里拉取DeepSeek-R1模型

Ollama 容器跑起来后，需要往容器里下载模型。模型不是和容器绑定的，而是通过 ollama pull 命令从模型库拉取。进入容器执行命令：

docker exec -it ollama ollama pull deepseek-r1:7b

这里deepseek-r1:7b是模型的名称和标签。如果你内存紧张，可以先用 1.5b 版本试试水：

docker exec -it ollama ollama pull deepseek-r1:1.5b

下载过程会显示进度条。模型文件一般有几个 GB，比如 7B 的量化版大约 4.7GB，取决于网络速度。下载完成后，模型就存放在容器内部的/root/.ollama/models目录中，并且因为之前挂载了数据卷，重启容器也不会丢失。

如果想看本机已经下载了哪些模型，可以执行：

docker exec -it ollama ollama list

输出会列出模型名、大小和修改时间。这时候模型还只是静静地躺在磁盘里，需要用ollama run才能真正交互。

3.3 让AI助手跑起来：交互测试

接下来就是最有成就感的一步。在终端执行：

docker exec -it ollama ollama run deepseek-r1:7b

看到>>> Send a message提示符后，就可以输入问题了。比如输入请解释一下什么是水循环，模型会先输出一段思考过程（这是 R1 的特点），然后给出最终回答。要退出交互模式，输入/bye即可。

这个交互体验适合在终端里操作，但并不好看。尤其当你把 AI 助手作为日常工具时，每次都打开终端有点劝退。而且这种方式只在本机能用，手机、平板没法访问。所以下一步我们再加一个好看的 Web 界面。

3.4 用Open WebUI给AI助手加上聊天界面

Open WebUI 是一个开源项目，可以把它看作本地版的“聊天机器人网页壳”。它连接到 Ollama 的 API，在浏览器里提供类似 ChatGPT 的界面，还支持多用户、对话历史、文件上传等功能。部署方式也简单，直接跑一个容器：

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

注意这个容器需要能够访问到宿主机上的 Ollama 服务。在 Linux 环境下，Ollama 容器监听的是宿主机 11434 端口，open-webui 容器通过host.docker.internal这个特殊域名来访问宿主机。--add-host参数把该域名映射到宿主机的网关地址，这样就可以解析了。如果你用的 Docker 版本比较新，也可以省略这个参数，但带上比较保险。

首次启动后，打开浏览器访问http://你的服务器IP:3000，注册一个管理员账号，然后在设置里配置 Ollama 的地址为http://host.docker.internal:11434，保存后就能在下拉菜单里看到已经下载的 deepseek-r1 模型。选择模型就可以对话了。

这里有个小细节：如果之前只是用终端跑 Ollama，open-webui 和 Ollama 的容器必须同时运行。--restart always保证了开机自动启动，但前提是 Docker 服务本身也要设为开机自启。对于 server 版 Ubuntu，安装 Docker 时会自动配置。

4. 配置进阶：局域网访问、API调用与参数调优

4.1 局域网设备访问本地助手

刚才说的“浏览器访问”如果是在同一台 Ubuntu 机器上操作，直接访问localhost:3000就行。但如果想用手机、平板或办公室另一台电脑访问，就要搞清楚网络端口和防火墙的问题。

默认情况下，Ubuntu 的防火墙是关闭的，但某些安全加固过的系统会启用 UFW。查看端口状态：

sudo ufw status

如果显示Status: active，需要放行 3000 和 11434 端口：

sudo ufw allow 3000/tcp sudo ufw allow 11434/tcp

然后确认宿主机的 IP 地址，用ip addr查看局域网 IP，比如192.168.1.100。在手机浏览器输入http://192.168.1.100:3000就能打开 Open WebUI 了。

不过这里有一个安全提示：如果这台机器暴露在公网，不要轻易把 3000 和 11434 端口映射到公网。Open WebUI 虽然有账号系统，但默认密码策略较弱，API 端口则是完全裸奔的，任何人只要能访问到 11434 端口就能调用你的模型算力。所以我一直建议这类服务只在可信内网里使用。如果确实需要远程访问，最好通过带认证的反向代理来保护。

4.2 用Python调用Ollama API

Open WebUI 适合人来聊天，但有时候我们想让自己的程序也能调用 AI 助手。Ollama 默认就提供了 REST API，地址是http://宿主机IP:11434/api/generate。比如用 Python 的requests库：

import requests import json url = "http://localhost:11434/api/generate" data = { "model": "deepseek-r1:7b", "prompt": "用一句话解释什么是递归", "stream": False } resp = requests.post(url, json=data) print(resp.json()["response"])

这个接口会在生成完整个回答后才把结果返回，适合简单调用。如果希望像流式输出那样一个字一个字往外蹦，可以把stream设为True，然后按行处理返回数据。对于写一个命令行小助手或者对接其他服务，这个 API 就是唯一需要记住的入口。

还有一种更高级的调用方式是使用 OpenAI 兼容接口。Ollama 启动后，/v1/chat/completions端点也默认存在。之前用过 OpenAI SDK 的话，只要把base_url改成本地地址，模型名改为deepseek-r1:7b，就可以无缝衔接，代码改动非常小。这让本地模型可以轻松塞进原来的 AI 应用框架里。

4.3 显存/内存不足时的量化选择与参数调整

模型在下载时，默认会使用一种经过量化的版本。量化可以理解成把模型参数里的浮点数“压缩”成更小的整数类型，用少量精度换来体积和内存占用大幅下降。Ollama 给同一个模型提供了不同量化等级，标签会带q4_0、q5_k_m、q8_0之类后缀。不写后缀时，Ollama 会选择默认的量化版本，通常是在质量和体积之间比较平衡的选择。

如果你的机器内存实在紧张，可以尝试更小参数的模型，比如deepseek-r1:1.5b。如果仍感觉慢，还可以修改 Ollama 的并发参数。在启动容器时设置环境变量OLLAMA_NUM_PARALLEL：

docker run -d ... -e OLLAMA_NUM_PARALLEL=1 ...

这里的数字代表同时处理的请求数。默认值在容器里是 4 或 8，但本地内存有限时，并发过高会导致所有请求都排队，体验反而更差。把它设为 1，虽然不能同时服务多个会话，但单个对话的响应和稳定性都会好不少。

如果你用 GPU 跑模型，建议时刻关注显存占用。跑 7B 模型大约需要 6~8GB 显存，14B 量化版需要 10GB 左右。用nvidia-smi查看显存使用情况，如果某个时刻显存不够，Ollama 会把部分层数据换到内存再换回显存，速度会断崖式下降。我试过这种方式，几乎等半分钟才出来一个词，基本没法用。

5. 常见问题与排查实录

5.1 Docker命令权限不足

装完 Docker 后，如果执行docker ps报错permission denied，说明当前用户不在 docker 用户组。执行sudo usermod -aG docker $USER后，需要重新登录或者运行newgrp docker让组权限立即生效。注意不要用 sudo 去跑 docker，这样虽然能用，但容易让后续文件权限混乱。

另一种情况是用户已经在 docker 组里，但 Docker 守护进程没启动。执行：

sudo systemctl status docker

如果显示inactive (dead)，启动它：

sudo systemctl start docker sudo systemctl enable docker

最后一个命令是让 Docker 开机自启。很多服务器重启后出现“Docker 为什么不见了”的困惑，就是因为之前没有 enable。

5.2 容器起不来或无法拉取镜像

启动 Ollama 容器时如果卡在Pulling阶段，大概率是网络问题。Docker Hub 的镜像拉取在国内经常不稳定，特别是需要下载几个 GB 的镜像时。除了配置 registry-mirrors，还可以直接把镜像下载下来后导出再导入，不过步骤太麻烦，一般不建议。

还有一种常见错误是端口被占用。如果 11434 或者 3000 端口已经被其他程序占用，容器会启动失败。用sudo ss -tlnp | grep 11434查看是谁占用了端口，然后改掉或者停掉占用服务。如果你之前已经跑过一个 Ollama 容器，新容器名字又要用ollama，也会报错。先docker rm -f ollama删掉旧容器再重试。

5.3 GPU完全没被识别

在容器里运行 Ollama 时，如果日志显示“no nvidia gpu found”，先回到宿主机确认nvidia-smi是否正常。如果宿主机没问题，那就是容器缺少 GPU 运行时。最常见的错误是 Docker 的默认运行时没换成 nvidia，要重新执行nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart docker。

也有一种容易误判的情况：你装的是 Docker Desktop for Linux，它内部有一层虚拟机，GPU 透传需要额外设置。这时候用命令行里的 docker 也许会走错误运行时。最简单的判据是执行docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi，如果报could not select device driver，就是 toolkit 没配好，如果是Unknown runtime specified nvidia，可能是 Docker 版本太老不支持--gpus参数。后者的解决方案是换成-e NVIDIA_VISIBLE_DEVICES=all用 nvidia-docker 插件形式跑，但就复杂了，不如直接升级 Docker。

5.4 模型生成速度慢或卡死

如果模型输出速度特别慢，先检查是不是在纯 CPU 推理。7B 模型在 CPU 上确实快不了，建议先换 1.5B 模型确认整体流程正常。再有就是内存不足，模型在推理时频繁使用 swap 交换空间，会让人感觉像卡死。用free -h查看内存剩余，如果 swap 占用太高，说明内存瓶颈严重。

这时可以考虑把 OLLAMA_NUM_PARALLEL 调低，或者干脆关掉其他大进程。另外，Ollama 默认会把模型常驻内存，第一次加载需要时间，之后对话会更快。如果你断断续续地使用，可能每次都要重新加载模型，这时可以把OLLAMA_KEEP_ALIVE环境变量调大，比如-e OLLAMA_KEEP_ALIVE=3600，让模型在内存里多待一小时。注意这会更占内存，内存有限的情况下不建议。

5.5 其他避坑经验

还有几个很实际的细节。一是磁盘空间。模型文件很占空间，7B 版 4GB 起步，Open WebUI 的镜像也有几个 GB，如果系统盘剩余空间不足，拉取会失败。建议把 Docker 的数据根目录改到大分区。编辑/etc/docker/daemon.json，加入"data-root": "/home/docker-data"，然后重启 Docker。二是容器时区问题，Ollama 日志里的时间如果不像东八区，可以给容器传-e TZ=Asia/Shanghai。

另外，想彻底重新部署时，直接用：

docker rm -f ollama open-webui docker volume prune

把容器和数据卷都删掉。模型文件会被一并清除，所以执行前先确认自己是否还需要那些模型。

最后说点个人体会

我从零开始搭这套本地 AI 助手，前前后后也折腾了不少时间。最深的体会是：不要指望一步到位直接上 70B 模型，先拿一个小模型把流程跑通，再逐步换大模型，这个顺序能省掉非常多排查问题的时间。Docker 的好处在这一路体现得很明显，就算我把容器折腾坏，删掉重来也就一两分钟，不会污染宿主机。DeepSeek-R1 的表现超出我的预期，哪怕是 7B 版本，用来分析代码、写周报、解释概念也够用。有时候它会在回复前自言自语一大段思考过程，看它“推理”还挺有意思。这篇记录里所有命令我都尽量用的最直接方式，希望你能少走点弯路，顺利把属于自己的 AI 助手跑起来。