DeepSeek本地部署实战：基于Ollama的模型运行与WebUI集成指南

简介：这是一份围绕DeepSeek-R1本地部署的实战型技术文档，面向机器学习与AI应用开发者，适合已掌握基础命令行与容器概念的工程师、研究人员在Windows、macOS或Linux环境下快速搭建推理环境。资源包共1个文件，以docx格式呈现，整体大小仅15KB，内容高度浓缩，重点覆盖Ollama安装与配置、模型版本选型、Docker容器化部署以及Open WebUI图形界面集成等关键环节。文中按显存容量给出了1.5B、7B、8B、14B、32B、70B等多档模型的选择建议，同时兼顾命令行调用与浏览器图形界面两种使用方式，并包含组件安装时的账号注册、参数核对等注意事项，可帮助读者避免常见部署踩坑。该文档发布后已有5393人浏览学习，对准备将DeepSeek-R1用于AI项目研究或生产环境验证的工程人员具有直接参考价值。

1. DeepSeek本地部署到底解决什么问题：先想清楚再动手

前些天一个老同事问我：能不能把DeepSeek装到自己电脑上，再给团队弄一个能打开的聊天页面？我的答复是一条固定链路：Ollama做模型运行环境，拉取DeepSeek的R1系列模型，再挂一个WebUI界面。跑通之后，团队成员打开浏览器就能对话，所有数据留在本机，不经过任何外部服务。

这篇笔记就是这条链路从零到一的完整记录，覆盖Ollama安装、DeepSeek模型选型与量化、推理参数调整、WebUI集成，以及我实际踩过的几个坑。命令按部署顺序排列，可直接复制，参数会解释为什么这么设，而不是让你拿到就盲目照抄。

适合三类人：想私有化使用大模型的开发者，要给团队搭内部AI助手的后端或运维工程师，以及正在评估本地大模型可行性的选型决策者。如果你只是想在网页上体验对话效果，这套流程同样适用。

先说清边界：本地部署目标是DeepSeek开源的R1系列蒸馏版，从1.5B到70B；原版671B的超大MoE在消费级硬件上跑不动，全文以R1系列为对象。硬件门槛比我预想的低，但也不是零门槛，后面会有一张表帮你对号入座。

2. Ollama安装与初始化：把模型运行环境先立起来

很多人第一次部署都会以为“装了Ollama就等于有了DeepSeek”，这是个误区。Ollama是一个模型运行环境，负责把下载好的模型权重加载进显存、执行推理、管理上下文缓存，并对外提供HTTP API。模型本身则是另一回事：DeepSeek的R1系列权重。两者更像是“引擎和汽油”的关系，引擎装好不代表有油，油加错型号引擎也跑不顺。这一章先把底座立稳，后面所有环节都建立在它之上。

2.1 为什么选Ollama：运行环境和模型是两个概念

先把这个关系拆开。Ollama管理的对象是GGUF格式的模型权重文件，它处理层叠加载、量化格式选择、GPU/CPU的设备分配，还内置了一个监听11434端口的API服务。你通过ollama pull拿到的，是权重和一份模型描述；通过ollama run触发的，是引擎加载权重后的推理过程。这两个动作分开理解，后面排查问题才不迷糊。

选Ollama而不是自己编译其他推理框架，我主要看四点。第一，命令统一：拉模型、跑模型、看列表、删模型全是单条命令，几乎没有学习成本。第二，自动调度：它能根据显存大小自动决定模型层放在GPU还是CPU，并对量化格式有默认优化，新手不用碰CUDA层面的细节。第三，自带API服务：装完默认监听11434端口，后面接WebUI或自研系统都不用额外写服务层。第四，跨平台一致：Linux、Windows、macOS上行为基本一致，团队不同机器可以共用一套操作文档。

也有反例。如果追求极致控制，可以直接编译llama.cpp再自己写调度脚本，但调试成本高，对多数只想私有化用DeepSeek的人来说性价比低。如果只想要纯本地GUI聊天，也可以选带界面的桌面软件，但这类工具弱在脚本化和API对接，后续想做自动化基本没戏。这套方案里Ollama的位置是“稳定的运行底座”，把模型和界面两件事解耦开，出问题的时候更好定位。

2.2 Linux服务器与Windows本机的安装命令差异

Linux通常是最省心的部署环境，一条命令装完还能注册成systemd服务：

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

脚本会检测发行版、下载对应二进制并注册ollama服务，默认开机自启。装完先确认版本和初始状态：

ollama --version ollama list

ollama list此时输出一个空表，不是故障，只是还没拉取任何模型。如果输出的是错误信息，多半是服务没起来，Linux下用systemctl status ollama看一眼状态。

Windows和macOS更简单。Windows下可以用winget install Ollama.Ollama，或者去官网下载安装包，装完托盘常驻；macOS用户用Homebrew执行brew install ollama即可。这里要提醒一个几乎所有人都会踩的点：模型默认存放位置。

Windows默认模型文件落在当前用户目录下的.ollama\models，C盘空间紧张的话尽早迁走：

# PowerShell 临时设置，只对当前会话生效 $env:OLLAMA_MODELS = "D:\ollama-models" ollama serve

Linux上用systemd方式运行的话，临时环境变量不会被服务读取，正确做法是写进服务配置：

sudo systemctl edit ollama # 在打开的编辑器中加入下面两行： # [Service] # Environment="OLLAMA_MODELS=/data/ollama/models"

改完执行sudo systemctl daemon-reload和sudo systemctl restart ollama。这里的逻辑很关键：终端里的export只对手动启动的进程生效，systemd服务有自己独立的环境。我第一次就是把OLLAMA_MODELS写在启动脚本里，结果服务重启后依然往默认目录写，差点把系统盘塞满。

提示：判断模型存到了哪里，用ollama list看SIZE列，再配合du -sh检查对应目录，比猜靠谱。

2.3 验证服务与最小链路：拉大模型之前先做两分钟体检

在拉一个4GB往上的模型之前，先花两分钟确认服务活着、GPU能被识别。先探API：

curl http://127.0.0.1:11434/api/tags

返回类似{"models":[]}的JSON说明API服务正常。连接失败就去查服务状态，Linux看systemctl status ollama，Windows看托盘图标是否变成正常态。

GPU识别用nvidia-smi确认驱动和CUDA版本正常，然后用最小的DeepSeek模型做链路冒烟测试：

ollama pull deepseek-r1:1.5b ollama run deepseek-r1:1.5b "用一句话介绍你自己"

这一步的价值是用最小成本验证“下载→加载→推理→输出”整条链路，比直接拉7B模型发现问题再回头排查快得多。输出正常后输入/bye退出对话。1.5B模型能力有限，测试完可以删掉，或留着当简单的语法修正工具。Apple Silicon的Mac不需要额外配置，模型加载由Metal后端自动处理；Linux和Windows的NVIDIA显卡则依赖驱动，驱动太老会在下一章直接暴露成“GPU占用0”的怪问题。

3. 下载并运行DeepSeek模型：选型、量化与显存预算

这一章是全篇的核心，对应“深度模型运行”这件事。Ollama装好只是有了引擎，真正决定体验的是三件事：选哪个规格的模型、用什么量化、推理参数怎么设。这三件事都围绕一个硬约束：显存和内存预算。预算算错了，后面所有优化都是空谈。

3.1 R1系列模型怎么选：一张表看清硬件门槛

DeepSeek在Ollama上提供的R1系列主要是蒸馏版：1.5B、7B、14B、32B基于Qwen底座，8B、70B基于Llama底座。底座差异直接影响中文表现和生态兼容，选型时不要只看参数规模。下表是默认Q4_K_M量化下的参考值，显存需求会因上下文长度浮动：

7B和8B都是小规格，选哪个看用途：偏中文场景选7B，Qwen的tokenizer和中文对齐更好；偏英文和长文处理选8B。14B是我个人认为“能跑”和“好用”的分界线，7B做多步推理时经常逻辑断链，14B明显扎实，代价是显存需求翻倍。

32B在24GB显卡上是性价比很高的选择，代码和数学推理能力接近满血版的体验，但注意它接近显存上限，留给上下文的余量很小。70B就不是给单张消费级显卡准备的了，通常要双卡或48GB以上，个人用户建议先放弃。显存不是唯一指标，推理速度还受内存带宽影响，Mac统一内存在跑大模型时反而有优势，这也是很多人在M系列芯片上跑32B的原因。

3.2 拉取模型与首次对话：最小命令组合

选好规格后，执行拉取和进入对话：

# 拉取模型，默认使用Q4_K_M量化 ollama pull deepseek-r1:7b # 直接进入交互对话 ollama run deepseek-r1:7b

拉取过程会按层分片下载并做校验，如果中途中断，重新执行ollama pull会从断点续传，不要急着ollama rm后重来，那是浪费带宽。多个模型共享相同层时，Ollama会复用已有文件，所以先拉7B再拉14B，重复下载的部分其实不多。

进入对话后在>>>提示符下输入问题，比如让它写一段代码：

>>> 用Python写一个二分查找，并说明时间复杂度

R1系列的特点是会先输出一段思考过程再给答案，这是正常的，不需要关闭。退出对话输入/bye。

跑起来之后验证显存占用：

nvidia-smi

重点看ollama进程占用的显存大小，以及ollama ps命令的输出：

ollama ps

输出里有PROCESSOR列，显示100% GPU说明模型完整跑在显卡上，显示100% CPU或GPU/CPU混合说明显存放不下，已在用内存兜底。这一步几乎每次部署都要看，它是判断“环境对不对”的第一手证据。

3.3 量化级别与推理参数：四个必调项

量化是本地部署绕不开的概念。简单说，它把模型权重从高精度压缩到低精度以换显存空间。Q4_K_M是默认值，也是大多数场景的甜点：体积比半精度缩小约四倍，质量损失肉眼难辨。如果显存有余量，可以用Q8_0获得接近无损的效果，代价是内存占用翻倍；显存实在紧张才考虑Q2_K，但推理质量下降明显，不推荐做主力。

按需拉取指定量化：

ollama pull deepseek-r1:14b:q8_0

标签语法是模型:版本:量化。什么时候值得用Q8_0？16GB显存的机器跑14B的Q4_K_M只占10GB，还剩6GB余量，这时候升级到Q8_0反而能物尽其用；但如果同时想开长上下文，余量就得让给KV cache，量化级别就要降回去。这是显存预算的动态平衡，没有绝对答案。

推理参数我最常调四个，通过Modelfile固化：

FROM deepseek-r1:14b PARAMETER temperature 0.6 PARAMETER top_p 0.9 PARAMETER num_ctx 8192 PARAMETER repeat_penalty 1.1 SYSTEM """你是一位严谨的代码评审助手，用中文回答，先指风险再给修改建议。"""

然后用一条命令构建成本地模型：

ollama create code-review-ds14 -f Modelfile ollama run code-review-ds14

参数含义如下。temperature控制随机性，代码和逻辑推理建议0.5到0.7，创意写作才拉高到0.9以上；R1系列的思考链特性决定了它的温度不能调太高，否则思维会发散。top_p是核采样阈值，0.9是比较稳妥的起点，和temperature配合使用，两者都调低会让输出更保守。num_ctx是上下文窗口长度，默认值偏小，长对话会在前面几轮时就丢记忆，但每调大一倍，KV cache对显存的占用也近似翻倍，显存紧张时先砍它。repeat_penalty针对中文输出里常见的重复问题，1.1是安全的起点，遇到复读机现象可以再往上加到1.3。

这些参数也可以写在API请求的options字段里，按请求覆盖默认值，这在第四章会用到。

3.4 显存不足时的降级方案：CPU推理与逐层卸载

显存不够时Ollama不会直接拒绝运行，而是把放不下的层放到CPU上。这个行为可控：在Modelfile里设PARAMETER num_gpu 0强制纯CPU推理，或设一个正整数让指定数量的层跑在GPU。纯CPU推理14B的Q4模型，速度大约每秒2到5个token，当个慢速聊天机器人还行，写代码会急死人。

我的建议是，一旦发现PROCESSOR列显示混合模式，先别急着加参数，按3.1的显存表降一个模型档位，或者把num_ctx从8192降到4096。这两个动作比调num_gpu更有价值，因为它们保住的是“显存里能装下全部模型层”的前提。强制逐层卸载适合临时救急，不适合作为长期生产配置。

注意：Mac用户不需要做这些。Metal后端直接利用统一内存，显存和内存是同一块池子，同等内存下能跑的模型规格比NVIDIA单卡更宽，这也是Mac跑大模型在这个社区里受欢迎的原因。

4. WebUI集成：把命令行服务变成可点开的聊天界面

命令行跑通只是第一步，交付给团队用必须有界面。这一章做两件事：用Docker拉起Open WebUI，以及解决“容器怎么找到Ollama”这个最常见的连通性问题。不想装Docker的人可以直接跳到4.3，用API对接自研系统，同样是一条正经路。

4.1 Open WebUI：Docker一条命令拉起界面

前提是机器上已经装好Docker。Open WebUI官方镜像的启动方式：

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

逐项说明。-d是后台运行；-p 3000:8080把宿主机3000端口映射到容器内的8080。--add-host host.docker.internal:host-gateway这行在Linux上必不可少，它让容器里能通过host.docker.internal这个域名访问宿主机，macOS和Windows的Docker Desktop默认支持这个域名，Linux则必须手动加。OLLAMA_BASE_URL告诉WebUI去哪里找Ollama的API，这里指向的就是宿主机。-v open-webui_data:/app/backend/data用命名卷保存账号、会话和配置，容器删了数据还在。--restart always保证机器重启后界面自动拉起。

启动后浏览器访问http://localhost:3000，第一次注册的账号会成为管理员。进主界面后在左上角模型选择器里找deepseek-r1:7b，如果列表为空，点刷新按钮重新拉取Ollama的模型列表。这里有个常识性误区：不要因为机器有NVIDIA显卡就去拉:cuda版的WebUI镜像，推理全部发生在Ollama进程里，WebUI只负责渲染和传参，用基础镜像就够了。

4.2 让Ollama对局域网和容器可见：OLLAMA_HOST配置实战

开箱状态下Ollama只监听127.0.0.1，这意味着两件事都做不了：容器访问不到宿主机，局域网里的同事也连不上。必须把监听地址放开。Linux下用systemd的改法：

sudo systemctl edit ollama

在编辑器中写入：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

然后重载并重启：

sudo systemctl daemon-reload sudo systemctl restart ollama

Windows下在“系统属性→环境变量”里新建OLLAMA_HOST，值为0.0.0.0:11434，然后彻底退出托盘中的Ollama进程再重新启动。验证监听状态：

ss -lntp | grep 11434

看到0.0.0.0:11434说明已经对外监听。从另一台机器测试：

curl http://<服务器IP>:11434/api/tags

能返回模型列表就说明局域网通路没问题。这里涉及一个基础但常被忽略的点：OLLAMA_HOST=0.0.0.0是绑定含义不是“允许所有人访问”的含义，绑定只是让服务监听所有网卡接口，真正的访问控制要靠防火墙。如果只给团队内网用，在防火墙里限制11434和3000端口的来源IP段比裸奔稳妥。端口映射到公网的事不建议做，本地部署的意义就在于数据不出内网。

4.3 不装Docker的轻量接入：直接用Ollama HTTP API对接现有系统

如果你的团队已经有内部应用，不想要一个独立聊天界面，Ollama自带的HTTP API就是现成的对接层。先手动测一发：

curl http://127.0.0.1:11434/api/chat \ -d '{ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "用三句话解释什么是KV Cache"}], "stream": false }'

这里有两条主要API：/api/generate接收单条prompt，适合一次性文本生成；/api/chat接收带角色的对话消息列表，适合多轮对话。stream字段控制返回方式：false是一次性返回完整JSON，true是逐行返回增量，前者调试方便，后者在界面上能实现打字机效果。生产对接时建议用stream模式，首字延迟会比等整段生成完短很多。

Python对接的参考写法：

import requests def chat_once(model: str, prompt: str) -> str: resp = requests.post( "http://127.0.0.1:11434/api/chat", json={ "model": model, "messages": [{"role": "user", "content": prompt}], "stream": False, "options": {"temperature": 0.6}, }, timeout=120, ) resp.raise_for_status() return resp.json()["message"]["content"] if __name__ == "__main__": print(chat_once("deepseek-r1:7b", "写一段快速排序"))

两个要点：一是options字段可以在单次请求里覆盖Modelfile的默认参数，适合不同场景用不同温度；二是timeout必须给足，长文本生成经常超过requests默认的几十秒，到时候报超时错容易误判成服务故障。另有一个实用接口/api/tags，自研系统的模型下拉列表直接从这里拉，不要写死在配置里。

5. 本地部署避坑指南：最常翻车的五个现场

到目前为止的部署链路里，90%的问题集中在这五个场景。我按“现象→原因→解决”写，每条都是我实际撞过的墙，能帮你少走一半弯路。

5.1 大模型拉取到一半失败，进度条长时间不动

现象：ollama pull下载几个GB后进度卡住，或直接报EOF、connection reset。

原因：网络中断或代理环境不稳定是最常见的；另一个隐蔽原因是磁盘空间不足，Ollama下载时会写临时文件，空间满会在最后写入层文件时报错，看起来像网络问题。

解决：先看磁盘余量，再重启服务重试：

df -h # 确认 OLLAMA_MODELS 所在分区有足够余量 sudo systemctl restart ollama

重新执行同样的pull命令即可断点续传，不要ollama rm之后从头拉。连续失败就换个更小的量化标签，或者干脆换一个网速更稳定的时段。这里没有玄学，网速和磁盘就是全部变量。

5.2 模型能对话，GPU占用却是0

现象：ollama run能正常输出，但nvidia-smi里看不到ollama进程，速度慢得像幻灯片。

原因：多数是CUDA环境没被Ollama识别，Linux下常见的是显卡驱动太老，或Ollama服务启动时用的用户环境缺少CUDA路径；另一种情况是显存不足，Ollama自动回退成CPU推理，但界面不会主动告诉你。

解决：用ollama ps看PROCESSOR列，是100% GPU就不用管；显示100% CPU或GPU/CPU混合，先更新显卡驱动再重启服务。如果驱动没问题，就是模型超过了显存容量，按3.1的表格降一档模型，或者调小num_ctx给推理腾空间。很多人说Ollama的设备分配是玄学，其实九成是驱动版本或显存预算出了问题，不是玄学。

5.3 WebUI连不上Ollama：connection refused

现象：Open WebUI页面报“Failed to connect to Ollama”，或者模型列表一直为空。

原因：容器里的localhost指向容器自己，不指向宿主机；Ollama默认又只监听127.0.0.1，容器网络的bridge模式下根本路由不到。两个条件缺一个都会报这个错。

解决：在宿主机上先自测：

curl http://localhost:11434/api/tags

能返回模型列表，说明Ollama本身没问题，问题在连通路径。确认docker run命令里加了--add-host host.docker.internal:host-gateway，且OLLAMA_BASE_URL用的是http://host.docker.internal:11434而不是localhost。再按4.2把OLLAMA_HOST改成0.0.0.0。改完依次重启Ollama和WebUI容器，基本十分钟内能恢复。

5.4 长对话越聊越慢，最后进程被系统杀掉

现象：开场几轮响应很快，十几轮后速度明显下降，有时整个进程被杀。

原因：多轮对话里KV cache随每句话增长，占用的显存不是文本大小，而是模型层数乘以注意力头数再乘以上下文长度，增长比想象中快。num_ctx设得越大，KV cache上限越高，显存被吃光的风险也越大。

解决：显存紧张时优先把num_ctx从8192降到4096；再配合OLLAMA_KEEP_ALIVE环境变量控制模型驻留时间，避免频繁换入换出。WebUI侧也可以限制单会话的消息轮数。如果业务确实需要长上下文，唯一的出路是换大显存或降模型档位，这事没有免费午餐。

5.5 环境变量改了不生效，重启又回到老样子

现象：终端里执行export OLLAMA_HOST=0.0.0.0后服务确实监听了，但机器一重启又回到127.0.0.1。

原因：Linux上Ollama以systemd服务运行，终端export的环境变量不会传给服务；Windows上服务读取的是系统级环境变量，不是PowerShell会话里的临时变量。

解决：Linux用sudo systemctl edit ollama写入Environment，Windows在系统环境变量里持久化设置。改完用ss -lntp确认监听地址已经变成0.0.0.0:11434，不要凭感觉判断。

6. 进阶调优：三个验证动作，确认这套部署值不值

部署完成后先别急着宣传，用三个动作验证它到底能扛多少活。

第一个动作是量化单请求耗时。用curl拿到完整的生成耗时：

curl -o /dev/null -s -w "总耗时:%{time_total}s\n" \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1:7b","prompt":"介绍一下你自己","stream":false}' \ http://127.0.0.1:11434/api/generate

这个时间包含排队和完整生成，适合做基准线。连续跑三次取中位数，比单次结果可靠。如果目标是多人使用，把OLLAMA_NUM_PARALLEL设为2或4再测一次，观察总耗时和显存变化。每个并行槽位都独占一份KV cache，显存预算要把这部分算进去，这也是为什么16GB显卡跑7B能扛并发，跑14B就只能老实串行。

第二个动作是用Modelfile把角色固化下来，让团队拿到的是“助手”而不是“裸模型”。把3.3的配置扩展成团队专用的评审助手：

FROM deepseek-r1:14b PARAMETER temperature 0.5 PARAMETER num_ctx 8192 SYSTEM """你是团队内部的代码评审助手，只针对Python和SQL给意见，先指风险再给改法，不写客套话。"""

ollama create review-bot -f Modelfile

构建完成后，WebUI里刷新模型列表就能看到review-bot。同一份权重可以挂多个角色，团队内部一个模型文件解决不同场景，不用每次对话都写冗长的system prompt。

第三个动作是养成记录习惯。我会把Modelfile提交到团队仓库，旁边写清硬件规格，因为同一份配置在16GB和24GB机器上表现完全不同，接手的人看到显存规格才能判断该不该调num_ctx。日志方面，Linux下用journalctl -u ollama -f实时看推理日志，配合nvidia-smi监控显存曲线，基本能覆盖日常排障。这套流程跑熟之后，DeepSeek本地部署就不再是三天两头要救火的事，而是一个稳定运行的基础设施。希望帮到你。

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