本地部署DeepSeek全栈指南：Ollama与Open WebUI集成

简介：这份资源面向具备基础命令行与容器化概念、希望将预训练语言模型落地到本地环境的开发者与研究人员，提供DeepSeek-R1从Ollama安装到模型运行、再到WebUI集成的完整部署指引。内容围绕机器学习与AI模型部署展开，覆盖不同硬件显存下的模型尺寸选择、Docker容器化平台配置以及Open WebUI图形化界面的搭建思路，帮助读者在Windows、macOS或Linux环境中完成从命令行到可视化交互的部署链路。资源包为1个docx文档，约15KB，以文字说明与操作指令为主，便于按步骤对照执行。目前已有5396人学习下载，适合需要手把手部署参考、快速验证本地推理流程的工程师，也可作为AI项目研究前的环境准备资料。

1. 从一张显卡到一套本地推理栈：DeepSeek 部署到底在装什么

很多人第一次听到“本地部署 DeepSeek”，脑子里浮现的是把几百 GB 的权重拖进硬盘、再配一堆编译参数。实际跑一遍会发现，真正要装的东西分三层：最底下是模型运行引擎 Ollama，中间是模型权重本身（DeepSeek-R1 的 1.5B 到 70B 若干档），最上面是可选的图形界面 Open WebUI。三层各管各的事，装错顺序或者版本对不上，就会出现“命令敲了没反应”“网页打不开”“模型加载到一半卡死”这类玄学问题。

这套流程适合两类人：一类是手上有独立显卡、想把推理放在自己机器上跑的开发；另一类是做 AI 应用验证、需要反复调同一个模型但不想每次都走云端接口的工程师。它不解决训练问题，也不承诺替代线上 API，核心价值是把“模型跑起来”这件事从黑匣子变成你能看见进程、能改参数、能断网复现的本地服务。下面按安装顺序拆开讲，每一步都给出可抄的命令和参数含义。

2. Ollama 安装与模型拉取：命令、显存档位与下载中断处理

2.1 安装 Ollama 与验证服务状态

Ollama 是这套栈的底座，负责加载模型权重、管理推理进程、暴露本地 API。安装方式按系统分：Windows 和 macOS 直接下安装包，Linux 用一条脚本。装完之后不要急着拉模型，先确认服务在跑。

Windows 下安装完成后，系统托盘会出现一个常驻图标，这代表后台服务已经启动。macOS 装完会在菜单栏出现同样图标。Linux 用下面这条：

# Linux 一键安装 Ollama，脚本会自动注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh # 查看服务是否在监听 11434 端口 ss -tlnp | grep 11434 # 查看已安装的 Ollama 版本，确认不是过旧版本 ollama --version

逻辑说明：install.sh做三件事——下载二进制、创建ollama用户、注册 systemd 服务。ss那条是确认 11434 端口被占用，这是 Ollama 默认的 API 端口，后面 Open WebUI 要靠它通信。ollama --version用来排除“装了但 PATH 没生效”的情况，如果提示 command not found，检查/usr/local/bin是否在 PATH 里。

参数说明：11434 是默认端口，如果被占用，可以通过环境变量OLLAMA_HOST改，但改完之后 Open WebUI 的连接地址也要跟着改，这是后面避坑章要展开的点。

2.2 按显存选模型档位：1.5B 到 70B 的对应关系

DeepSeek-R1 在 Ollama 上提供多个尺寸，选错档位的直接后果是模型加载失败或者推理慢到不可用。下面这张表是按显存粗选的对应关系，注意这里说的是显存不是内存，核显机器要按共享显存打折看。

拉模型的命令就是ollama run加档位名，第一次执行会先下载再进入交互：

# 拉取并运行 32B 档位，首次执行会下载权重 ollama run deepseek-r1:32b # 如果只想下载不进入交互，用 pull ollama pull deepseek-r1:32b # 查看本地已经拉了哪些模型 ollama list

逻辑说明：run和pull的区别在于前者下载完直接进对话，后者只下载。批量部署时我一般先用pull把权重拉好，再统一run，避免下载中途被打断后反复重来。ollama list用来确认模型是否完整落盘，如果列表里有但大小明显偏小，说明下载没完成。

参数说明：档位名里的32b是参数量标识，不是量化等级。Ollama 默认会用 Q4 级别的量化，所以 32B 模型实际占用显存比理论值低，但别按理论值去卡显存下限，留 2G 余量比较稳。

2.3 下载中断与代理配置的边界

模型权重动辄十几 GB，下载中断是高频问题。Ollama 的下载走的是它自己的拉取逻辑，断点续传支持有限，常见做法是配一个镜像源或者用系统级代理。这里只讲配置方式，不展开网络细节：

# Linux/macOS 下设置 Ollama 服务级环境变量 # 编辑 systemd 配置或 shell profile，加入镜像地址 export OLLAMA_HOST=127.0.0.1:11434 # Windows 下在系统环境变量里新增 OLLAMA_MODELS 指定模型存储路径 # 默认路径在 C 盘，权重多了会撑爆系统盘

逻辑说明：OLLAMA_MODELS是很多人忽略的变量，默认模型存在用户目录下，C 盘空间不够时下载会失败但报错信息很含糊。提前改到大容量盘能省掉一次翻车。OLLAMA_HOST一般不用改，除非端口冲突。

参数说明：环境变量改完要重启 Ollama 服务才生效，Windows 下是退出托盘图标再重新启动，Linux 下是systemctl restart ollama。

3. Docker 与 Open WebUI 集成：容器网络、端口映射与首次登录

3.1 Docker 安装与重启后的状态确认

Open WebUI 官方推荐用 Docker 跑，因为它的依赖链比较长，裸装容易在 Python 版本上卡住。Docker 安装本身没难度，Windows 下全默认选项，装完必须重启一次，这一步不能省，否则 WSL2 后端没初始化，容器起不来。

重启后要做两件事：同意条款、确认 Docker 引擎在运行。命令行里验证：

# 确认 Docker 引擎状态 docker info # 如果这条报错，说明 Docker Desktop 没启动或 WSL2 后端异常 docker ps

逻辑说明：docker info输出里能看到 Server 段才算引擎正常，只有 Client 段说明引擎没起来。docker ps列出运行中的容器，空列表是正常的，报错才是问题。

参数说明：Windows 下 Docker Desktop 默认用 WSL2 后端，如果机器上 WSL 没装，安装程序会提示，按提示装完再重启一次。

3.2 Open WebUI 容器启动命令逐段拆解

官方给的那条docker run命令很长，逐段拆开看每个参数在干什么，改的时候才知道动哪里：

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

逻辑说明：-d是后台运行；-p 3000:8080把容器内 8080 映射到宿主机 3000，所以浏览器访问的是 3000 端口；--add-host让容器内能用host.docker.internal这个域名指回宿主机，Open WebUI 靠它连宿主上的 Ollama；-v把数据卷挂出来，聊天记录和配置不会随容器删除丢失；--restart always保证开机自启；最后是镜像地址。

参数说明：如果 3000 端口被占，改冒号左边的数字即可，比如-p 3001:8080。host.docker.internal在 Linux 上默认不生效，需要--add-host显式加，这也是为什么这条命令里带了它。

3.3 首次登录与模型连接验证

容器起来后浏览器打开http://localhost:3000，第一次会要求注册账号，这个账号是本地存在数据卷里的，跟任何线上服务无关。注册完进去，如果左侧模型列表是空的，说明 Open WebUI 没连上 Ollama。

验证连接的方式是进设置里看 Ollama 地址，默认应该是http://host.docker.internal:11434。如果连不上，先在宿主机上确认 Ollama 在跑：

# 宿主机上直接调 Ollama API，确认模型列表能返回 curl http://localhost:11434/api/tags # 如果这条通但 WebUI 里不通，问题在容器网络 # 进容器内部测连通性 docker exec -it open-webui curl http://host.docker.internal:11434/api/tags

逻辑说明：第一条 curl 验证 Ollama 本身正常，第二条进容器验证跨容器网络。两条都通但 WebUI 还连不上，就是 WebUI 配置里的地址写错了，去设置里改。

参数说明：/api/tags是 Ollama 列出本地模型的接口，返回 JSON 里能看到已拉取的模型名。这个接口也是排查“模型拉了但 WebUI 看不到”的第一站。

4. 避坑与排查：端口冲突、显存溢出与容器网络三类高频问题

4.1 现象：Ollama 命令敲了没反应，托盘图标也不见

原因：Windows 下安装包没装完就被中断，或者杀毒软件拦了后台进程。Linux 下是 systemd 服务没起来。

解决：Windows 重新跑一遍安装包，装完看托盘；Linux 用systemctl status ollama看服务状态，起不来就看journalctl -u ollama的日志。别急着重装，先看日志。

4.2 现象：模型拉到一半报错，重新 pull 又从零开始

原因：Ollama 的断点续传在部分网络环境下不生效，尤其是大文件下载被中断后。

解决：先确认OLLAMA_MODELS指向的盘有足够空间，空间不足是中断的常见原因。然后换一个网络时段重试，或者配镜像源。已经下了一半的可以试着再 pull 一次，部分版本能续上，续不上就删掉重来，别反复试浪费带宽。

4.3 现象：32B 模型加载后推理极慢，风扇狂转

原因：显存不够，模型被部分卸载到内存甚至 CPU 推理。Ollama 不会明确报“显存不足”，只会变慢。

解决：用nvidia-smi看推理时显存占用，如果接近满且 GPU 利用率低，就是显存瓶颈。降一档模型，或者关掉其他占显存的程序。别指望调参能救，档位选错就是选错。

4.4 现象：Open WebUI 页面能开，但模型列表空白

原因：容器内连不上宿主机的 Ollama，通常是host.docker.internal解析失败或端口不对。

解决：按 3.3 的两条 curl 逐层排查。Linux 下确认启动命令带了--add-host，Windows 下确认 Docker Desktop 的 WSL2 后端正常。如果改过 Ollama 端口，WebUI 设置里的地址也要同步改。

4.5 现象：重启电脑后 WebUI 打不开，容器不见了

原因：启动命令没加--restart always，或者 Docker Desktop 没设开机自启。

解决：重新跑一遍带--restart always的启动命令，数据卷还在，聊天记录不会丢。Docker Desktop 设置里把开机自启打开。

5. 进阶：用 API 直连替代 WebUI，以及一套可复用的验证习惯

WebUI 适合交互式使用，但做应用集成时更常用的是直接调 Ollama 的 API。它的接口兼容 OpenAI 格式，意味着你之前写的调用代码改个 base_url 就能用：

import requests # Ollama 的 OpenAI 兼容接口，注意路径是 /v1/chat/completions url = "http://localhost:11434/v1/chat/completions" payload = { "model": "deepseek-r1:32b", "messages": [ {"role": "user", "content": "用一句话说明本地推理的优势"} ], "stream": False } resp = requests.post(url, json=payload, timeout=120) print(resp.json()["choices"][0]["message"]["content"])

逻辑说明：model字段填的是ollama list里显示的完整模型名，填错会返回 model not found。stream设 False 方便调试，生产环境可以开流式。timeout要给足，32B 模型首次推理有加载时间，超时设短了会误判为失败。

参数说明：base_url 里的端口跟 Ollama 配置一致，默认 11434。如果走容器内的服务调，地址换成host.docker.internal。

验证一套部署是否真的可用，我习惯走三步：第一步ollama list确认模型完整；第二步curl /api/tags确认 API 活着；第三步用上面这段 Python 发一条真实请求，确认推理链路通。三步都过，才算部署完成，而不是看到 WebUI 页面能打开就收工。

从那以后我每次部署完都强制走一遍这三步验证，因为页面能开但模型连不上这种情况太常见了，光看界面判断不了底层状态。希望帮到你。

本文还有配套的精品资源，点击获取