DeepSeek本地部署实战：从Ollama到Open WebUI再到LoRA微调

简介：面向AI新手与DeepSeek爱好者的保姆级部署教程文档，围绕DeepSeek在线访问拥堵、响应不稳定的问题，给出了完整的本地化解决方案：从零讲解如何在个人电脑上部署DeepSeek大模型，并配套WebUI可视化界面与数据投喂训练方法。资源包为单个docx文档，大小2.76MB，内容以图文步骤为主，覆盖Ollama安装与命令行验证、DeepSeek R1按显存选型及下载命令、命令行与模型交互、Page Assist插件搭配联网搜索、nomic-embed-text嵌入，以及AnythingLLM工作区配置与聊天模型/代理模型选择等完整流程。文档特别针对零基础用户优化，详细标注每一步的操作位置、下载指令和参数设置，并在数据投喂环节给出“投喂前无法回答、投喂后准确回答”的验证思路，帮助读者避开常见坑位。全文按“本地部署—WebUI可视化—数据投喂训练”三阶段循序渐进，即使没有AI基础也能照着完成。目前已有1186人学习下载，适合希望摆脱在线拥堵、自建专属大模型知识库或深入体验DeepSeek的读者收藏使用。

1. DeepSeek本地部署到底是什么：先跑通推理，再谈训练

DeepSeek本地部署不是把模型下载下来那么简单，而是一条完整链路：用 Ollama 把 DeepSeek 的开源权重跑在自己电脑上，用 Open WebUI 把它变成浏览器里的聊天窗口，再通过知识库投喂或 LoRA 微调让这个 AI 学会你的业务数据。这篇保姆级教程按新手路径走，先在一台 16G 内存的普通电脑或一张入门显卡上把对话跑通，再决定要不要动训练。完成后你会得到一个能回答内部问题的本地大语言模型。注意，这里的 WebUI 是大模型聊天界面，别和画图的 Stable Diffusion WebUI 搞混。

2. 部署前的硬件门槛与模型选型：为什么新手先选 Ollama 而不是 vLLM

很多新手的第一步就搞错了方向：搜到"本地部署大语言模型"，然后照着某条命令去拉一个 70B 的模型，结果等了半天模型下载完，机器也卡死了。这不是命令错了，是模型档位选错了。DeepSeek 官方开源的 V3/R1 主模型是千亿级 MoE 架构，根本不是个人电脑能跑的；在 Ollama 仓库里能拉到并真正跑起来的，是它的蒸馏系列和代码模型。这一点先立住，后面所有步骤才不走样。

2.1 先算清机器门槛：AI大模型本地部署配置的三块硬指标

本地部署大语言模型，配置上先看三块：模型权重占多大、你的内存和显存装不装得下、上下文窗口能吃多长。先有数字再下命令，能省一整天的折腾。下表是我常用的选型对照，Ollama 标签里的 q4 表示 4bit 量化。

表里的"q4"值得多说一句：原始 FP16 权重的 7B 模型约 14GB，4bit 量化后压到 4～5GB，换来的是模型精度略有下降，但日常问答完全够用。Ollama 拉官方标签时默认就带量化，不用手动指定。16G 内存无独显的机器，7B 是舒适区；有 8G 显存，7B 能跑得很快，但别同时把上下文拉满。

第三块硬指标是上下文长度，最容易被人忽略。模型标称能接 32K，但实际内存是按"模型权重 + KV cache"一起算的，上下文开得越大，KV cache 越吃内存，8G 显存上开到 16K 很容易直接 OOM。新手先按 4K 用，后面摸清硬件余量再慢慢加。

2.2 为什么新手路线选 Ollama 而不是 vLLM

现在社区里第一梯队的大模型本地部署工具是 Ollama、llama.cpp、vLLM 三套。Ollama 相当于把 llama.cpp 的编译、GGUF 下载、量化选择、OpenAI 兼容接口全部打包了，一条命令就把模型跑起来，所以我给新手的建议永远是先走 ollama本地部署大语言模型 这条路，它能让你把注意力放在数据和效果上，而不是搭环境。

vLLM 是高性能推理引擎，企业里 vllm部署deepseek 很常见，吞吐率高，适合几十个人并发调用。但它的正确使用场景是 Linux 服务器 + CUDA 环境 + 大显存，新手在这一步会被编译依赖和采样参数挨个劝退。判断标准很简单：你只是想要一个自己随时能聊、能接 API 的本地大模型，选 Ollama；你在搭一个要给一整个团队用的服务，再回来研究 vLLM。本文后面所有步骤都基于 Ollama。

2.3 安装 Ollama 与拉取模型的最小命令

# Windows/macOS 直接去官网下载安装包；Linux 用官方安装脚本 curl -fsSL https://ollama.com/install.sh | sh # 拉取 7B 蒸馏版，默认就是 q4 量化 ollama pull deepseek-r1:7b # 进入交互式对话 ollama run deepseek-r1:7b # 查看模型到底加载到了 GPU 还是内存（排错第一命令） ollama ps

第一行是 Linux 的官方安装脚本，Windows/macOS 下载图形安装包一样效果。ollama pull deepseek-r1:7b会从模型库拉取已经量化好的权重，拉完直接ollama run进入对话。ollama ps是本地部署最常用的排错命令，推理变慢时先看它：如果模型没进显存，说明驱动或安装包有问题。

两个环境变量值得记一下。OLLAMA_HOST=0.0.0.0 ollama serve让 Ollama 监听所有网卡，后面 WebUI 用 Docker 部署时必须靠它互通；OLLAMA_MODELS可以改模型存放目录，系统盘小的机器建议直接指到数据盘。交互式对话里输入/set parameter num_ctx 8192能临时拉长上下文，但硬件占用会同步上涨，量力而行。

3. WebUI 可视化：用 Open WebUI 把命令行变成聊天窗口

命令行跑通只完成了一半。真正让本地部署变得可用的，是 WebUI 可视化这一步。Open WebUI 是目前最主流的大模型聊天界面，支持多模型切换、参数面板、知识库挂载，界面干净，但新手也容易在这里翻车：pip 装完打不开、打开只有前端框架、模型列表是空的。这一章把两种装法和接线方式一次说清。

3.1 Open WebUI 的两种装法：pip 和 Docker，我推荐哪种

先给结论：机器上已经装了 Docker 就用 Docker，一条命令、以后升级方便；没有 Docker 就 pip，注意包名和启动命令，别装错。

# pip 装 Open WebUI，注意包名是 open-webui pip install open-webui # 一定要用这个命令启动完整后端 open-webui serve

重点在第二行。Open WebUI 是前后端一体的应用，必须由后端进程同时提供 API 和页面；如果只把前端静态文件打开，就会看到报错"您正在使用不受支持的方法(仅运行前端服务)。请通过后端启动服务"。很多人 pip 装 WebUI 失败，十有八九是卡在这里——要么包名装错，要么启动命令不对。

docker run -d \ -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ ghcr.io/open-webui/open-webui:main

Docker 命令里，-p 3000:8080把容器内 8080 端口映射到宿主机 3000；-v open-webui:/app/backend/data把你的账号和聊天记录持久化到卷里，不然以后升级容器一切归零；--add-host=host.docker.internal:host-gateway是让容器访问宿主机的关键，Windows 新版 Docker 尤其吃这一套。

3.2 把 Open WebUI 接到 Ollama：地址、模型下拉框和首轮对话

同一台机器上，Open WebUI 默认会找http://127.0.0.1:11434，启动后注册账号、新建对话，模型下拉框里应该直接出现 deepseek-r1:7b。看不到模型先别慌，九成是接线问题：Ollama 没对外开放，或 Open WebUI 跑在容器里够不着宿主机的 11434 端口。

# 让 Ollama 监听所有网卡，供 WebUI 容器访问 OLLAMA_HOST=0.0.0.0 ollama serve

然后去 Open WebUI 的管理员面板，把 Ollama 接口地址改成http://host.docker.internal:11434（Docker 部署）或宿主机实际 IP。改完刷新页面，模型就会出现在下拉框。如果还是没有，返回启动open-webui serve的终端看日志，里面有它实际请求 Ollama 的地址和具体报错。

3.3 首轮对话前调好的三个参数：温度、上下文长度、系统提示词

温度是最常被乱调的。DeepSeek 蒸馏模型做代码、数学这类确定性问题，温度开高就会开始编；做文案、头脑风暴才需要调高。上下文长度不要一上来就拉满，之前说过，KV cache 是和权重抢内存的。系统提示词写在对话设置里，我一般写"你是一个严谨的助手，不知道就直接说不知道"，这四个效果比任何参数都明显。

WebUI 可视化还有一个容易被忽略的价值：同一个界面里可以同时加载原始 DeepSeek 和后面微调出来的模型，做对比测试非常顺手。这也是我建议新手别跳过 WebUI 直接拿 API 调试的原因——看得见的对比，才知道数据投喂到底有没有效果。

4. 数据投喂训练AI：先走 RAG 知识库，再考虑 LoRA 微调

"数据投喂"这个词害人不浅，新手以为把几篇文档塞给模型就是训练。实际上有两条完全不同的路线：RAG 知识库投喂，不改权重，让模型"照着资料答"；LoRA 微调，真正改动权重，让模型学会你的领域风格。我的建议是先用知识库解决 80% 的需求，等确认值得投入训练再上 LoRA。

4.1 Open WebUI 知识库投喂：上传文档→建集合→挂到聊天

Open WebUI 内置了知识库功能，操作路径很直观：

1. 打开管理员面板，进入"知识库"，新建一个集合，命名成"产品手册"这种看得懂的名字。
2. 上传 PDF、Markdown、TXT 都行，系统会自动切片。
3. 新建对话时，在输入框上方挂载这个知识集。
4. 提问时明确写"只依据我提供的资料回答，资料里没有的就说不知道"。

背后的机制其实不复杂：文档被切块、向量化，提问时把最相关的几块拼到上下文里让模型照着答。它不算训练，但能解决"让 AI 懂业务资料"的大部分场景。和 Open WebUI 类似思路的产品很多，FastGPT、Dify 也都能接 ollama 本地部署的大模型做知识库，本地方案先验证效果，再决定要不要换平台。

4.2 训练 AI 的正确姿势：数据集格式和数量门槛

技术社区里聊"如何训练属于自己的 AI"，默认已经排除了从零预训练——那需要几万张卡。多数人说的是指令微调：给模型看一批"问题 + 期望回答"的样本，让它学会你的业务话术。全量微调要在多卡上跑，新手别碰；LoRA 只训练新增的低秩矩阵，单卡 16G 显存就能跑，这才是最值得投入的方向。

{ "instruction": "请根据产品说明书回答：标准保修期是多久？", "input": "产品说明书：标准保修期自签收之日起12个月……", "output": "标准保修期为自签收之日起12个月。" }

这是最常用的 Alpaca 格式，一行为一条，instruction是提问，input是给模型的参考材料，output是期望回答。划重点：output 是训练信号，字段为空等于让模型学空气。数据量别抠门，几百条能感觉到变化，1000 条以上才稳定；少于 50 条开训基本是白费，过拟合会让模型只会复读。

清洗比数量更重要。我一般跑三件事：按 instruction 文本去重、删掉 output 里的明显错误答案、检查有没有把"拒绝回答"的开场白灌进去——模型会把那套语气也一并学走。

4.3 最小微调流程：LLaMA-Factory + QLoRA，16G 显存可跑

这一步我用 Qwen2.5-7B-Instruct 做基座演示。原因有两个：Ollama 里的 deepseek-r1:7b 本身就是 Qwen-7B 蒸馏出来的，微调流程完全同源；另外 DeepSeek 的开源协议对二次训练有限制条款，练习微调用同架构的 Qwen 基座更省心。你要的结果是"训练出属于自己的 AI"，这个流程放回 DeepSeek 蒸馏模型上也完全跑得通。

pip install llama-factory

数据集放到 LLaMA-Factory 的 data 目录后，编辑data/dataset_info.json，加上这段注册信息：

"my_deepseek_data": { "file_name": "my_deepseek_data.jsonl", "formatting": "alpaca" }

file_name对应你放到 data 目录下的 jsonl，formatting告诉它用什么解析格式。不注册的话训练脚本会直接报"找不到数据集"。我第一次跑这个流程就在这里卡了半小时，以为是路径问题，其实是注册表没写。

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset my_deepseek_data \ --finetuning_type lora \ --quantization_bit 4 \ --lora_rank 8 \ --output_dir outputs/my_lora \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 4 \ --learning_rate 2e-4 \ --cutoff_len 1024

参数说明：quantization_bit 4是 QLoRA 的 4bit 量化，把基座压到 4bit 载入，这是 16G 显存跑 7B 的关键；lora_rank 8是低秩矩阵的秩，起步用 8；gradient_accumulation_steps 4配合 batch_size 2，等效凑出一个 8 的 batch；learning_rate 2e-4是 LoRA 常见区间，不要动辄给到 1e-3；cutoff_len 1024会把超长样本截断，如果你的数据里有大段材料，先按 90% 样本的长度统计再设。

llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path outputs/my_lora \ --template qwen \ --finetuning_type lora \ --export_dir outputs/my_model # 先转成 GGUF，再压成 q4_k_m python convert_hf_to_gguf.py outputs/my_model --outfile my-model.gguf --outtype f16 llama-quantize my-model.gguf my-model-q4.gguf q4_k_m

导出时先不量化，得到 FP16 合并模型，再用 llama.cpp 的转换脚本和量化工具压成 q4_k_m。注意两条命令是两个工具：convert_hf_to_gguf.py负责格式转换，llama-quantize负责压缩，别拿刚导出的原始目录直接喂给 Ollama。

FROM ./my-model-q4.gguf TEMPLATE "{{- if .System }}{{ .System }} {{ end }}{{ .Prompt }}" SYSTEM "你是基于 Qwen 训练的内部业务助手，回答简洁、直接，不要编造数据。"

ollama create my-ai -f Modelfile ollama run my-ai

Modelfile 里最要命的是 TEMPLATE。很多新手导出后直接ollama create，得到的模型答非所问，就是模板没配对。最稳的做法：去 Ollama 仓库里找到对应 Qwen 系模型的 Modelfile，把它的 TEMPLATE 和 stop 参数原样抄下来，只换第一行的 FROM。建好之后回到 Open WebUI 刷新，下拉框里就会出现 my-ai，可以和原始 DeepSeek 并列对比。

提示：训练产物会影响同一基座的其他能力，练习阶段建议用独立基座，不要拿生产用的模型直接叠 LoRA。

5. 新手避坑：本地部署与数据投喂常见的 5 个翻车点

这些坑我基本都踩过一遍，按现象、原因、解决三段给你写，遇到对应报错直接对号入座。

5.1 部署与 WebUI 环节的 3 个高频坑

坑1 现象：pip 装 Open WebUI 后打开页面，任何操作都报"您正在使用不受支持的方法(仅运行前端服务)。请通过后端启动服务"。 原因：只启动了前端静态文件，没有拉起后端 API。常见于直接双击打开了打包生成的 index.html，或者用了旧版的不完整启动方式。 解决：用open-webui serve启动完整后端；Docker 部署的检查端口映射和容器是否在跑。记住 Open WebUI 是前后端一体应用，前端单独打开只是半个产品。

坑2 现象：ollama pull拉到一半卡住，或者最后一步报 checksum mismatch。 原因：网络中断或磁盘剩余空间不够，模型分片下载不完整，留下残片。 解决：先ollama rm deepseek-r1:7b删掉残片，腾出至少两倍于模型体积的磁盘空间，然后重新ollama pull。如果反复失败，检查 OLLAMA_MODELS 指向的分区是否快满了。

坑3 现象：明明有 NVIDIA 显卡，推理却奇慢无比，ollama ps显示模型一直在 CPU 上跑。 原因：安装包没带 GPU 支持，或显卡驱动太老、显卡架构太旧。 解决：去官网重新下载带 GPU 支持的安装包，更新 NVIDIA 驱动，重启后ollama ps确认显存出现在列表里。如果是 2015 年前的显卡架构，基本就别指望 GPU 了，老老实实用 1.5b 模型。

5.2 数据投喂与微调环节的 2 个坑

坑4 现象：微调完，模型回答永远只有"你好"，或者不断重复系统提示词。 原因：数据集里 output 字段为空，或 JSONL 有一行少引号导致整条样本被静默跳过；更常见的是 LoRA 加载时模板对不上。 解决：训练前用一段 Python 脚本逐行json.loads校验文件；训练后先用 LLaMA-Factory 的 chat 界面加载 adapter 对答几句，确认效果再导出；Modelfile 的 TEMPLATE 从官方模版抄，不要自己发明。

坑5 现象：训练 loss 一开始就在 5 以上甚至 NaN，或者 loss 降到 0.1 但验证效果依然很差。 原因：学习率太大；数据量太少导致过拟合；cutoff_len 太小把长样本截断成乱码。 解决：学习率回落到 1e-4～2e-4；数据量低于 500 条时改用 lora_rank 4，epoch 控制在 3 以内；先统计样本长度分布，把 cutoff_len 设到能完整放下 90% 样本的位置。

6. 验证你的 AI 真的学会了：留出集、AB 对比和一个复盘习惯

训练脚本退出不等于训练成功。真正的验收发生在验证集上。我每次只拿 9 成数据训练，留 1 成当考卷，考卷覆盖三类问题：事实题、边界题、风格题。

验证时直接在 Open WebUI 里开两个会话，一个挂原始 DeepSeek，一个挂 my-ai，问同一组问题。如果微调后的版本在边界题上开始胡编，说明数据里的错误信号太多，先回去清洗而不是继续加训。用ollama run my-ai "标准保修期是多久"这种一行命令也能快速抽测，但多模型对比一定要在 WebUI 里做，视觉差异比 loss 曲线更直观。

另外养成两个习惯。第一，每次微调都用"模型名_日期_数据集名"命名，比如 my-ai_20250203_v1，原始基座永远不覆盖，这是你随时能回头的后悔药。第二，训练日志里找到 val_loss 那一列，验证损失开始回升就是过拟合信号，直接停掉，别等 epoch 跑完。

我自己翻过最大的车，是把没清洗的对话记录直接灌进去训练，结果模型学会了一嘴口头禅，领域知识没涨多少，语气倒是学得格外像。最后只能回滚上一个版本重来。从那以后我的规矩是：数据先跑去重脚本，模型命名带日期，基座永不覆盖。希望帮到你。

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