简介：这是一份面向AI应用开发者与运维工程师的DeepSeek本地部署实操文档，围绕在Windows、macOS与Linux等环境中运行DeepSeek-R1展开，适合具备基础命令行与容器化概念、希望开展模型测试或生产环境预研的技术人员。内容按Ollama安装、模型版本与显存适配、Docker及Open WebUI可选集成、命令行与图形界面调用等环节组织，并给出对应操作指令与注意事项。资源包共1个docx文件，约15KB，篇幅紧凑，便于按步骤查阅和落地。已有5397人学习，说明其在本地大模型部署场景中具有较高参考价值。读者可据此快速理清从环境准备、组件安装到模型运行与WebUI接入的完整链路，结合显存选择1.5B至70B等不同规模模型，减少配置反复试错，并为后续AI项目研究与应用测试提供可复用的操作依据。

1. 从一个跑不动的 32B 说起：显存上限决定你该装哪个尺寸

前几天帮人收拾一台装了一半的机器：Ollama 装好了，模型下到六成，命令行里敲下ollama run deepseek-r1:32b，风扇转了十分钟，吐出来几个接不上的字符。这台笔记本是 8G 显存。DeepSeek 本地部署最常见的翻车点从来不是 Ollama 装不上，而是模型尺寸和显存对不上——装得下不等于跑得动，跑得动不等于回得快。Ollama 负责把权重拉下来并加载进显存，Docker 和 Open WebUI 负责把它包成一个能对话的网页，这四件套凑齐，才算一套完整的 AI 模型本地环境。这套流程适合想把模型留在自己机器上、又不想碰编译和推理框架的人，也适合需要给模型套一层图形界面做演示的开发者。往下按顺序走，每一步都给出可复制的命令和失败时的观察点。

2. 装 Ollama 之前先定版本：Windows、macOS、Linux 三条下载路径

装 Ollama 这件事本身不难，难的是在点下载之前把硬件数值确认清楚。我在不同机器上装过七八次，出问题的几乎都集中在两处：一是把模型装到只剩十几 G 的系统盘，二是拉完了才发现显存不够。所以这一章的顺序是「先量硬件 → 再选安装包 → 最后验证服务在不在」，不要跳过前面的部分。

2.1 先看硬件再点下载：三个必须先确认的数值

在下载页面上选择系统版本之前，先打开终端把三个数字记下来：显存、内存、磁盘剩余。显存决定你能跑多大的模型，内存决定加载时会不会把系统卡死，磁盘决定你能装几个模型。三个数值里，显存是最关键的那个。

Linux 下我最常用的两条命令：

# 查看 NVIDIA 显卡型号与显存总量（单位 MiB） nvidia-smi --query-gpu=name,memory.total --format=csv # 查看内存与各挂载点剩余空间，-h 让人眼可读 free -h && df -h

nvidia-smi输出的显存是 MiB，除以 1024 就是 GB。如果你的机器没有独显，这条命令会直接报「command not found」，那基本就意味着只能跑 1.5B 这一档，后面的 7B 以上就不用想了。

Windows 下别用Win32_VideoController的AdapterRAM字段查显存，这个字段在显存超过 4G 时会溢出成一个荒唐的数字，很多人被它骗过：

# 型号能看，显存不可信，仅作参考 Get-CimInstance Win32_VideoController | Select-Object Name, AdapterRAM # 有 NVIDIA 显卡的话，这条才准 nvidia-smi --query-gpu=name,memory.total --format=csv

没有nvidia-smi的话，任务管理器 → 性能 → GPU 里那行「专用 GPU 内存」是准的。macOS 上统一内存和显存共享，system_profiler SPDisplaysDataType里看到的数值只能当上限参考，实际能分给模型的部分要打折，我一般按总内存的六到七成估算。

2.2 Windows 端的安装与托盘常驻

打开 Ollama 官网，点右上角的 Download，选 Windows。安装包不大，双击后一路默认即可，不需要改安装路径，也不需要勾选额外组件。安装完成后最直观的标志是系统托盘多了一个常驻图标，这个图标在就说明后台服务已经起来了。

装完先别急着拉模型，先把服务状态确认一遍。开一个新的 PowerShell 窗口：

# 确认命令行工具进 PATH 了，有版本号输出就说明安装成功 ollama --version # 确认后台进程存在 Get-Process ollama # 直接问服务要模型列表，返回 JSON 就说明 11434 端口在监听 Invoke-RestMethod http://127.0.0.1:11434/api/tags

这三条的顺序是有讲究的。ollama --version成功只代表可执行文件在 PATH 里，不代表服务在跑；Get-Process确认进程；Invoke-RestMethod才是真正打了一次 HTTP 请求，能通说明整个链路都活着。我遇到过装完之后托盘图标在、但端口没起来的情况，原因基本是安装过程中杀毒软件拦了自启项，重新运行一次安装包选「修复」就好。

提示：Windows 上 Ollama 默认监听127.0.0.1:11434，只对本机开放。这是好事，不要为了「让别的机器也能访问」随手改成0.0.0.0，那等于把没有鉴权的推理接口挂到局域网上。

2.3 macOS 与 Linux：安装包之外的命令行方式

macOS 端官网给的是 dmg，分 Apple Silicon 和 Intel 两个包，M 系列芯片一定选 Apple Silicon 那个，装错版本会通过 Rosetta 转译运行，速度掉得很难看。装完把应用拖进「应用程序」，第一次启动会请求一个后台服务授权，同意之后菜单栏出现图标。习惯用包管理器的，brew install ollama也能装，但要注意它和 dmg 版本不要同时存在，两套服务抢同一个端口时表现是「模型列表突然空了」，很迷惑。

Linux 上最省事的是官方那一行安装脚本：

# 下载并执行官方安装脚本，会自动识别架构并注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh # 确认服务状态，正常应显示 active (running) sudo systemctl status ollama # 设置开机自启并立即启动 sudo systemctl enable --now ollama # 查看服务日志，排查启动失败时第一时间看这里 journalctl -u ollama -n 50 --no-pager

这里有个新手很容易踩的点：Linux 上服务已经由 systemd 管着了，就不要再手动执行ollama serve，那会报端口占用然后退出，看起来像是「装坏了」。判断方法很简单，systemctl status ollama是 active 就说明服务没问题，接下来的所有操作都只是客户端命令。

3. 拉取 DeepSeek-R1 模型：1.5B 到 70B 的显存对照与命令拆解

模型仓库里同一系列会挂好几个尺寸，标签看起来只差一个数字，实际差的是几倍的下载量和完全不同的响应速度。这一章把尺寸选择、下载命令、存储位置三件事拆开讲，因为这三件事里任何一件判断错，后面都要推倒重来。

3.1 模型标签对照表：先看显存再看硬盘

官方给出的对应关系是：普通个人电脑显卡和硬盘都一般，用 1.5B；8G 显存可以用 7B 或 8B；12G 到 16G 显存用 14B；24G 显存用 32B；40G 以上显存才考虑 70B。我把这些整理成一张表，顺手补上大致下载体积，方便你判断磁盘够不够：

体积那一列是量化后的权重文件大小，实际占用会比表里略大一点，因为还有配置和分词器文件。选尺寸时按显存那一列走，不要按硬盘走——硬盘大只能说明你下得动，不代表跑得动。我第一次装的时候就犯过这个错，1T 硬盘觉得自己什么都能装，结果 32B 加载完直接开始用内存做交换，一个短问题等了两分钟。

3.2 ollama run 的下载过程与中断重试

官网模型页的右侧有一个复制按钮，点一下拿到完整命令，比如ollama run deepseek-r1:32b。粘到命令行里回车就开始下载了。第一次执行会先拉 manifest，再按层拉 blob，终端里显示的百分比是针对当前层的，不是整体，所以会出现「卡在 100% 不动」的错觉，其实是在等下一层。

我一般把「下载」和「运行」拆成两步做，排错时边界清楚很多：

# 第一步只下载，不进入交互模式 ollama pull deepseek-r1:8b # 第二步确认模型已经在本地清单里 ollama list # 第三步才真正加载并进入对话 ollama run deepseek-r1:8b

ollama pull的好处是失败了可以无脑重跑，它会复用已经下完的层，不会从头开始。ollama run在下载阶段被 Ctrl+C 打断时，下一次运行也能续上，但终端里的提示不如pull直白。如果你的网络在下载大层时反复中断，先跑pull，成功了再run，这是我在带宽不稳的机器上固定用的顺序。

ollama list的输出里有两列值得看：SIZE 是模型占用，MODIFIED 是最后使用时间。如果 SIZE 明显小于 3.1 那张表里的数值，说明权重没下完整，直接重新pull。另外ollama run支持--verbose参数，能看到 tokens/s 之类的推理统计，评估「这个尺寸在我机器上到底能不能用」时，比凭感觉快慢靠谱。

3.3 把模型挪到大盘：OLLAMA_MODELS 迁移

默认情况下模型放在用户目录下的.ollama/models，Windows 是%USERPROFILE%\.ollama\models，macOS 和 Linux 是~/.ollama/models。这个位置的麻烦在于系统盘通常不大，装两个 14B 就红了。改存储位置靠环境变量OLLAMA_MODELS，改完必须重启服务才生效。

Windows 上我一般写成用户级永久变量，而不是只在当前窗口设：

# 写入用户级环境变量，重启终端后仍有效 [Environment]::SetEnvironmentVariable("OLLAMA_MODELS","D:\ollama\models","User") # 确认写入成功 [Environment]::GetEnvironmentVariable("OLLAMA_MODELS","User")

写完之后从托盘退出 Ollama 再重新启动，然后ollama list应该是空的——这是正常的，因为新目录里还没有模型。把旧目录里的models文件夹整个搬过去，再ollama list就能看到原来的模型了。很多人卡在这一步，以为模型丢了，其实只是路径换了。

Linux 上 systemd 服务不读用户环境变量，得用 override：

# 生成 override 配置，编辑器里填入下面的内容 sudo systemctl edit ollama

[Service] Environment="OLLAMA_MODELS=/data/ollama/models"

改完执行sudo systemctl daemon-reload && sudo systemctl restart ollama，再ollama list验证。注意目标目录的属主必须是运行 ollama 的那个用户，一般是ollama，权限不对的表现是服务起得来但拉模型时报 permission denied。

4. Docker 与 Open WebUI 集成：把命令行包成网页

到这一步为止，模型只能在终端里用。Open WebUI 的作用是给 Ollama 套一层网页界面，有会话历史、模型切换、参数面板。它是通过 Docker 跑的，所以顺序是「装 Docker → 起容器 → 让容器找到宿主机的 Ollama」。那两条长命令看起来吓人，拆开其实每个参数都有明确用途。

4.1 Docker Desktop 安装：默认勾选、重启、条款

去 Docker 官网下载 Windows 版，安装过程中所有选项保持默认，尤其是「使用 WSL 2 作为后端」这一项不要取消，取消之后容器启动会慢一个数量级。安装完成后会要求重启系统，这一步不能省，WSL 组件需要重启才能注册。重启后首次启动 Docker Desktop，会弹出服务条款，同意之后要求注册或登录账号——这个账号只是桌面端登录用，和模型、数据都没关系。

装完先在 PowerShell 里确认引擎活着：

# 客户端版本 docker --version # 引擎信息，能看到 Server Version 和内核才算真的起来了 docker info # 拉一个极小的镜像验证拉取链路 docker run --rm hello-world

docker info报「Cannot connect to the Docker daemon」是最常见的开局问题，八成是 Docker Desktop 还没启动完成，托盘图标转圈的时候命令就会失败，等它变成稳定的鲸鱼图标再试。如果一直转圈，检查 BIOS 里虚拟化有没有开，这个坑在品牌整机上出现频率不低。

4.2 docker run 那条长命令逐段拆

Open WebUI 的项目主页上有一句「If Ollama is on your computer, use this command」，复制出来是这样一条：

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

挨个说清楚，出问题时才知道该动哪一段：

关于最后那个:main标签，我的习惯是先用它跑通，确认版本可用之后换成具体的版本号标签，避免哪天自动拉到新版本行为变了。这条不是官方要求，是血泪经验：滚动标签意味着你今天的「能跑」明天不一定复现。

执行完之后用两条命令确认容器状态：

# 看容器是否 Up，端口映射是否正确 docker ps --filter name=open-webui # 实时看启动日志，正常会看到 uvicorn 监听 8080 docker logs -f open-webui

日志里出现Uvicorn running on http://0.0.0.0:8080就是起好了，按 Ctrl+C 退出日志跟随不会停容器。

4.3 容器怎么找到宿主机的 Ollama

这是整套流程里最容易断的一环。容器有自己的一套网络栈，容器里的127.0.0.1指的是容器自己，不是你的 Windows 主机。所以 Open WebUI 要访问宿主机的 Ollama，必须走host.docker.internal这个特殊域名。Docker Desktop 在 Windows 和 macOS 上会自动维护这条解析，Linux 上则要靠--add-host那条参数手动加。

验证方式是从容器内部发请求：

# 在容器里请求宿主机的 Ollama 模型列表 docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags

返回一段 JSON，里面有models数组，说明链路通了；返回Connection refused或者卡住不动，就是没通。没通的排查顺序是：先在宿主机上curl http://127.0.0.1:11434/api/tags确认 Ollama 本身没问题，再确认容器启动命令里带没带--add-host，最后看宿主机的防火墙有没有拦 11434。

注意：不要在容器里配置OLLAMA_BASE_URL=http://127.0.0.1:11434，这个地址在容器内部指向它自己，症状是网页能打开但模型下拉框永远是空的，很多人会误以为是模型没下载。

4.4 首次进入 WebUI：账号、模型列表与端口

浏览器打开http://localhost:3000，第一次访问会要求注册一个账号。这里注册的第一个用户自动成为管理员，账号密码存在容器卷里，删容器不删卷就一直有效。注册时填的邮箱不需要真实可用，本地环境没人给你发验证信。

登录进去之后，正常情况下左上角的模型下拉里应该直接出现你已经pull过的模型。如果没有，先点设置里的连接配置，确认 Ollama 的地址是http://host.docker.internal:11434，保存后刷新页面。这一步做完，命令行和网页两条使用路径就都通了。

网页端相比命令行的优势在于可以随时切换模型、调整温度之类的参数、保留多轮会话。命令行适合验证，网页适合日常用，我一般是先用命令行确认模型能出结果，再去网页里干活。

5. 部署排查：五个把我卡住的现场

这一章记录的是我自己遇到过的、并且在别人机器上重复出现过的五个问题。每个都按「现象 → 原因 → 解决」写，遇到对应症状可以直接对着做。

5.1 现象：pull 卡在某一层长时间不动

现象是终端里显示pulling manifest或者某一层的百分比，十几分钟没有任何变化，按回车也没反应。原因通常有两个：一是大层在下载过程中连接断了，客户端在静默重试；二是磁盘已经写满，写入失败但没有立刻抛出错误。这两种情况表面现象一模一样，所以要先看磁盘再看网络。

解决办法是先看剩余空间，Windows 用Get-PSDrive，Linux 用df -h，对一下 3.1 那张表的体积，空间不够就先清理。空间够的话直接 Ctrl+C 中断，重新执行ollama pull 模型名，它会把已完成的层跳过，从断点继续。我遇到过连续三次中断都在同一层的，那基本是网络链路问题，换个时间段重试比反复折腾参数有效。

5.2 现象：WebUI 能打开，但模型下拉框是空的

现象是网页正常加载、能注册能登录，但选模型的框里什么都没有，页面上还可能有连接失败的提示。原因是 Open WebUI 容器没有连到宿主机的 Ollama，常见于 Linux 上漏了--add-host参数，或者配置里把地址写成了127.0.0.1。

解决办法是先执行docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags，通不过就删掉容器重建，命令里确保带上--add-host=host.docker.internal:host-gateway。重建时注意保留-v open-webui:/app/backend/data，否则账号和聊天记录会一起丢。重建后进设置页面确认连接地址，保存并刷新。

5.3 现象：3000 端口打不开，浏览器一直转圈

现象是http://localhost:3000打不开，连接被拒绝或者超时，但docker ps看着容器好像还在。原因可能是容器启动后立刻退出了（docker ps看不到，得用docker ps -a），也可能是 3000 端口被别的程序占了。Docker Desktop 没启动完成时也会这样。

解决办法按顺序走：先docker ps -a看 STATUS 那一列，如果是Exited，用docker logs --tail 100 open-webui看退出原因，最常见的是卷权限问题；如果容器是Up，用netstat -ano | findstr :3000查端口占用，换成-p 3001:8080重新起一个；如果docker ps直接报错连不上引擎，那就是 Docker Desktop 没起来，等它启动完成。

5.4 现象：32B 装上了，但回复慢得像断网

现象是模型能加载、能出字，但每个字都要等很久，任务管理器里 GPU 占用不高而内存占用爆炸。原因是显存不够，Ollama 把一部分层放到了 CPU 或者内存上跑，速度会掉一个数量级。这个不是配置错误，是硬件和尺寸不匹配。

解决办法是先确认到底跑在哪：ollama ps会显示每个已加载模型和它的处理器分布，如果显示的不是全 GPU，就说明有层被卸载到了 CPU。这时候只有两条路——换更小的尺寸，或者关掉其他占显存的程序（浏览器硬件加速、游戏、设计软件）。我一般直接降一档，32B 换 14B，实际体验提升远大于硬撑。

5.5 现象：重启电脑后 WebUI 打不开，要手动 start

现象是每次重启之后网页都打不开，必须手动打开 Docker Desktop 再docker start open-webui。原因不是--restart always失效了，而是这个策略只在 Docker 守护进程起来之后才生效，而 Docker Desktop 本身没有设置开机自启，守护进程压根没启动。

解决办法是打开 Docker Desktop 的设置，在 General 里勾上「Start Docker Desktop when you sign in to your computer」。勾上之后重启验证一次：不碰任何东西，直接开浏览器访问 3000，能进就对了。这个设置项改的是桌面端的自启，和容器的重启策略是两层，缺一层都做不到真正的开机即用。

6. 装完怎么验证跑通：三条命令确认模型、端口与 WebUI 联通

装完之后不要只看「网页能打开」就认为完事了。网页能打开只证明容器活着，不证明模型能推理，也不证明容器和 Ollama 之间通。我现在固定用三条命令做收尾验证，分别对应服务、推理、联通三件事，任何一条不过就回到对应章节。

第一条，确认 Ollama 服务在监听并能返回模型清单：

# 返回 JSON，models 数组里应该有你已经 pull 的模型 curl -s http://127.0.0.1:11434/api/tags

这条通不过，问题在 Ollama 本身，回去看第 2 章的服务状态。返回里models是空数组，说明模型没下完整，回第 3 章重新pull。

第二条，绕过所有界面直接打一次推理接口，这是最硬的一条验证：

# stream 设为 false，一次性拿到完整结果，方便判断是否真的生成了内容 curl -s http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:8b", "prompt": "用一句话说明什么是容器", "stream": false }'

返回里response字段有正常文字，说明模型加载、推理、输出整条链路没问题。如果这里报model not found，是模型名写错了，用ollama list里的完整名字；如果卡很久才返回，回 5.4 看是不是显存不够。

第三条，从容器内部验证到宿主机的通路：

# 在 Open WebUI 容器里请求宿主机 Ollama，返回 JSON 即为联通 docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags

三条都过，再打开http://localhost:3000发一句话，这次基本不会出意外。为了以后排查方便，我把这套检查整理成一张对照表：

从那以后我每次装完这套环境，不管机器多新、配置多高，都强制把这三条命令走一遍再交付，因为「网页能打开」这个信号太弱了，弱到足以掩盖后面所有的坑。有几次就是靠第二条命令发现模型只下了一半，避免了在演示现场翻车。希望帮到你。

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