本地部署DeepSeek实战：从Ollama到Open WebUI与RAG知识库

简介：这是一份面向AI新手与DeepSeek爱好者的本地部署与训练完整教程，围绕“本地部署+WebUI可视化+数据投喂训练”三个环节展开，解决DeepSeek官方服务频繁卡顿、响应缓慢时如何在个人电脑上稳定使用并定制专属模型的问题。资源包为单个docx文档，共1个文件，容量仅2.76MB，无需安装环境即可直接阅读，步骤截图与命令说明均包含在内。目前已有1186人学习下载。教程以保姆级操作指引为核心，从安装Ollama到选择适配显存的DeepSeek-R1版本，再到通过Page Assist插件实现浏览器WebUI交互，并引入nomic-embed-text与AnythingLLM完成数据嵌入、工作区配置及文档投喂训练，最终可搭建出能回答私有知识的智能问答库。内容覆盖下载命令、参数设置、文件上传与Embedding全流程，并针对4GB显存等常见配置给出选型建议，无论是零基础入门还是进阶搭建知识库，都能按步骤轻松复现。

1. 本地部署DeepSeek到底图什么：一个新手花30分钟能拿到什么

DeepSeek的网页版和外接API当然省事，但把开源权重拉到本地部署是另一档事：对话记录不出内网，prompt不受服务端限流，还能把公司文档、个人笔记“数据投喂”进去，让同一个模型回答你独有的问题。这个教程不碰云服务，只讲用本机显卡或CPU把DeepSeek跑起来的路子——先装Ollama拉起模型，再通过Open WebUI获得可视化界面，最后按需求选一条数据投喂路径。适合两种人：一是想在办公网络里做私有AI助手的运维和业务同学，二是想搞懂大模型部署闭环的开发者。下面用的都是可复现命令，按顺序执行就行。

2. 用Ollama把DeepSeek跑起来：最小可用命令与大模型选型

2.1 为什么新手首选Ollama而不是直接源码运行

直接把DeepSeek的Hugging Face权重下载下来跑，听起来很硬核，实际上要过CUDA、PyTorch、Python运行环境、模型并行策略四道坎，任何一道出错都能让你耗掉一晚上。技术社区里现在做本地部署大语言模型，最主流的起点就是Ollama。它把模型下载、量化、显存管理、HTTP API封装成了一条命令，你只需要关心模型档位，不用关心底层算子在怎么调度。

Ollama在拉取模型时会自动下载量化版本，常见的是Q4_K_M这类4bit量化。量化会把模型权重从FP16压到大约四分之一大小，换来显存占用和推理速度的平衡。推理时它会把可用的层自动卸载到GPU，显存不够就退回CPU，虽然慢，但至少不会直接崩溃。对我来说，本地写代码助手、文档问答、翻译润色这类任务，用量化后的DeepSeek-R1蒸馏模型已经足够。

生产环境里大量并发请求确实会更倾向用vLLM，但那是给有QPS压力的人准备的。新手的第一台“本地大模型”没必要上那么重的方案。把Ollama跑明白，之后迁移到vLLM或llama.cpp也只是换个启动命令的事。

2.2 你的电脑适合哪个档位的DeepSeek模型

ollama里的DeepSeek-R1系列并不是同一个模型，而是官方基于Qwen和Llama蒸馏出来的多个尺寸。规格越低跑得越快，但推理和写作能力也越弱。先看清自己手里有多少显存，再决定拉哪个模型，这叫“量力而行”。下面这张表按我自己的部署经验总结，新手可以直接对照。

如果你的电脑有16G显存，比如常见的RTX 4080或4090笔记本，拉7B或14B的量化版本是最舒服的。纯CPU跑7B不是不行，只是每秒一两token的体验很容易让你怀疑人生。我通常建议新手先用7B跑通全流程，等WebUI和知识库都摸熟了，再考虑上14B。

2.3 安装Ollama并跑通第一句对话

先执行下面的安装和验证命令。Linux和macOS可以用官方脚本，Windows用户建议直接到Ollama官网下载安装包，本质没有区别。

# 安装 Ollama（Linux/macOS/WSL2 通用） curl -fsSL https://ollama.com/install.sh | sh # 验证是否装好 ollama --version # 从模型库拉取 DeepSeek-R1 7B 蒸馏版，约4.7GB ollama pull deepseek-r1:7b # 进入交互式对话 ollama run deepseek-r1:7b

第一次执行ollama pull会从模型库下载文件，速度取决于网络。下载完成后，ollama run会自动加载模型并进入交互界面。你可以试着问一句“用一句话解释什么是RAG”，模型会在你的当前终端里逐字输出。退出对话输入/bye回车即可。

交互模式适合快速验证，但WebUI和后面的数据投喂都需要OpenAI兼容的API服务。所以另开一个终端执行ollama serve，用下面的curl请求验证API端口是否正常：

# 启动Ollama后台服务，默认监听11434端口 ollama serve # 用OpenAI兼容接口发起一次对话 curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "用一句话解释什么是RAG"}], "stream": false }'

代码里model字段必须和ollama list里显示的模型名完全一致，否则会报找不到模型。stream设为false表示等完整结果返回；如果你用的是WebUI，它会自己以流式方式请求，不需要手动改。这个接口是OpenAI格式的，意味着后续很多第三方工具都可以直接接上来。

2.4 本地对话的几个必调参数

Ollama的默认参数未必适合所有问题。使用DeepSeek-R1这类推理模型，我一般会把温度控制在0.6到0.7之间，太低了显得死板，太高了容易跑偏。在ollama run的交互界面里可以直接用斜杠命令调整：

# 在交互式对话中设置参数 /set parameter temperature 0.6 /set parameter top_p 0.9 /set parameter num_ctx 8192

如果想在API调用里临时指定，就在JSON请求里加参数。num_ctx控制的是上下文窗口大小，默认只有2048，超过之后早期的对话内容会被无情丢弃。当你后面接入WebUI、上传长文档做数据投喂时，这个参数不调大，模型会“忘记”你一开始交代的事。8K对大部分个人知识库场景够用，但如果文档很长，要再往上加，同时注意显存占用会同步上涨。

3. 用Open WebUI把DeepSeek变成可视化聊天框：安装、对接与配置

3.1 两种安装方式：pip和Docker，总有一种适合你

命令行里能用Ollama对话，但对大多数人和日常办公来说，一个像ChatGPT一样的网页界面才是刚需。Open WebUI是目前技术社区里对接Ollama最成熟的可视化方案，支持多用户、知识库、联网搜索、模型切换，而且聊天记录全存在本地。

第一种方式是pip安装，适合已经有Python环境的人。先说一个常见坑：pip装webui失败往往不是因为命令不对，而是Python版本太老或依赖冲突。我建议先建独立虚拟环境，别直接往系统Python里砸：

# 建一个独立环境，避免污染系统Python python -m venv webui source webui/bin/activate # Windows 用 webui\Scripts\activate # 安装并启动 pip install -U open-webui open-webui serve

启动后访问http://localhost:3000，第一次打开会让你注册账号，这个账号是本机管理员，不需要联网验证。如果pip下载慢或反复报编译错误，最常见的做法是换成Docker启动，一次性跳过依赖地狱：

# 用Docker跑Open WebUI，端口映射到宿主机的3000 docker run -d --name open-webui \ -p 3000:8080 \ -v open-webui-data:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main

注意看端口映射，宿主机用3000，容器内部是8080，别改错方向。数据卷open-webui-data负责持久化你的账号、聊天记录和知识库，删容器不会丢数据。两种方式选一个跑通就行，不用都装。

3.2 对接Ollama：模型列表空白的常见原因

Open WebUI启动后并不知道外面有Ollama存在，它需要主动连过去。如果你用pip方式安装，默认就会尝试连接http://127.0.0.1:11434；用Docker方式跑的话，容器内的localhost不是宿主机，必须加上host.docker.internal这样的特殊域名。启动命令里加--add-host=host.docker.internal:host-gateway就是为了让容器能反向找到宿主机。

如果打开WebUI后发现模型列表空空如也，优先按顺序排查三件事：Ollama是不是还在运行、模型有没有真正下载完成、外部连接配置对不对。在设置页面找到“外部连接”，把Ollama Base URL填成http://host.docker.internal:11434或http://127.0.0.1:11434，保存后刷新页面。

还有一个报错很经典：Open WebUI提示“您正在使用不受支持的方法（仅运行前端服务）”，这是因为你用open-webui --frontend-only启动过前端，但后端服务没起来。记住正常姿势永远是open-webui serve，这个命令把前端和后端一起拉起，别再碰--frontend-only。

3.3 让WebUI更顺手的五个配置项

第一个是默认模型，在设置里把默认模型改成deepseek-r1:7b，这样每次打开不用手动切换。第二个是系统提示词，可以写“你是公司的技术助理，回答尽量简洁”，模型的回答风格会明显改变。第三个是关闭每轮对话的Markdown渲染，如果你经常看JSON或代码输出，反而更清晰。第四个是开启多用户注册权限，办公室同事也能自己建账号，聊天记录互相隔离。第五个是历史会话管理，建议设置自动清理周期，否则跑上几个月磁盘会被聊天记录塞满。

这些配置都在WebUI的“工作区”和“设置”里，改完即时生效。到了这一步，你已经有了一个私人、离线、可多用户使用的DeepSeek聊天服务。但聊天只是起点，真正让它值钱的是下一章：把自己的数据投喂进去。

4. 数据投喂训练AI：临时上下文、RAG知识库、LoRA微调的区别与落地

4.1 先分清三种“投喂”，别把RAG当微调

“数据投喂训练AI”这串字里最容易被误解的是“训练”。很多人以为把PDF传上去就是训练了，实际上绝大多数场景走的是检索增强生成，也就是RAG。我给新手梳理三种递进方案，按成本从低到高排列。

临时上下文最简单，就是你在聊天框里贴一段背景，然后提问。RAG知识库则把文档切开、向量化、存起来，每次回答先检索相关片段，再带着片段生成答案。微调是真正改变权重，让模型“记住”领域知识，但这需要数据处理和显卡资源，不是传几个文档的事。

4.2 零代码投喂：用Open WebUI自带知识库跑通RAG

Open WebUI内置了知识库功能，不需要写代码就能完成数据投喂。操作路径是：工作区 → 知识库 → 新建知识库 → 上传文档，然后在聊天页面里通过#符号引用这个知识库。模型回答时会先检索文档内容，再结合检索结果给出答案。

这个功能背后就是RAG，但它默认的分块参数不一定适合你的文档。我一般建议把分块大小设置在500到800字符之间，重叠50到80字符，这样既不会丢失段落语义，也不会让检索噪声太大。文档太长时可以先手动拆成多份再上传。要注意的是，把文件传上去之后，模型的知识截止时间不会改变，它只是“查资料”，并不是学会了。

4.3 自己写一个最小RAG脚本：LangChain加Ollama

如果WebUI内置知识库满足不了你，或你想看到检索中间结果，可以用LangChain搭一个最少可用的RAG。先确保安装了langchain、langchain-community、chromadb，同时用ollama pull nomic-embed-text拉一个本地向量模型。

from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 1. 读取本地文档，按UTF-8处理 loader = TextLoader("knowledge.txt", encoding="utf-8") docs = loader.load() # 2. 切块：chunk_size 控制每块字符数，overlap 保留上下文边界 splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80 ) chunks = splitter.split_documents(docs) # 3. 用本地Embedding模型生成向量并写入向量库 embeddings = OllamaEmbeddings(model="nomic-embed-text") db = Chroma.from_documents( chunks, embeddings, persist_directory="./chroma_db" ) # 4. 检索与问题最相关的3个片段 retriever = db.as_retriever(search_kwargs={"k": 3}) hits = retriever.invoke("报销流程是什么") for h in hits: print(h.page_content)

代码里chunk_size设成500，对大模型来说这个长度既能保留完整语义，又不会让检索结果过于冗长。overlap是80，用来避免句子正好被切断。k值设为3，检索到的片段数量会影响回答质量，太少容易漏，太多会让prompt超过上下文窗口。跑完这段代码，你会看到三个命中的文档段落，这就好比你直接看到了模型“翻开书”的过程。

真正的问答环节，还要把检索到的内容拼进prompt再发给Ollama。这个拼接逻辑就是RAG的核心：先让系统扮演“根据资料回答”的角色，再把资料作为上下文填进用户消息，最后要求模型只在找不到答案时明说不知道，不要瞎编。

4.4 LoRA微调：新人最容易高估的一步

如果RAG确实满足不了你，比如你希望模型开口就是公司固定的话术模板，或者能自动按你的JSON格式输出，这时候才需要考虑LoRA微调。用LLaMA-Factory这类开源工具，对DeepSeek-R1的1.5B蒸馏版做一次LoRA训练，是门槛最低的微调路径。

# 对DeepSeek-R1-Distill-Qwen-1.5B做LoRA监督微调 llamafactory-cli train \ --model_name_or_path deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B \ --stage sft \ --do_train \ --dataset my_dataset.json \ --finetuning_type lora \ --lora_rank 8 \ --lora_alpha 16 \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 4 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --bf16 \ --output_dir ./deepseek-lora

这段命令里，lora_rank和lora_alpha决定微调参数量和更新幅度，新手的稳妥配置是rank=8、alpha=16。per_device_train_batch_size设为1是为了降低显存压力，配合gradient_accumulation_steps做梯度累积。学习率2e-4是LoRA常见起点。数据集格式要转成包含instruction、input、output字段的JSON，几百条起步效果才可感知。

但这意味着，如果你只有几十条数据，微调大概率会把原有能力洗坏。我亲眼见过有人拿20条报销问答去微调7B模型，结果模型连正常的代码生成都不会了。微调不是传文档，是把模型的“人格”重新塑造一次，数据质量决定一切。

5. 新手翻车率最高的六个坑：现象、原因与解法

5.1 模型一运行就卡死，甚至整机无响应

现象：输入问题后CPU或GPU占用率直接顶满，等了半分钟一个字都没出，再久一点系统开始卡顿。

原因：拉了超出硬件承受能力的模型，或者num_ctx设得过大，显存被一次性吃光。

解决：先用ollama ps查看当前加载模型占用的显存，再把模型降到7B甚至1.5B重试。同时设置环境变量OLLAMA_MAX_LOADED_MODELS=1和OLLAMA_NUM_PARALLEL=1，限制同时加载的模型数量和并发请求，避免Ollama自己把资源榨干。

5.2 pip安装open-webui一直失败

现象：pip install open-webui跑到一半报编译错误，或者提示找不到匹配的版本。

原因：Python版本低于3.11，某些依赖包需要编译C扩展，网络源又比较慢。

解决：先确认python --version在3.11以上。然后用虚拟环境重装，网络不好就换国内镜像源，命令是pip install -U open-webui -i https://pypi.tuna.tsinghua.edu.cn/simple。如果还不行，果断转Docker，别在里面耗时间。

5.3 WebUI提示仅在运行前端服务，或模型列表空白

现象：打开Open WebUI看见提示“您正在使用不受支持的方法（仅运行前端服务）”，模型列表永远是空的。

原因：启动命令用了--frontend-only，只启动了静态前端，后端API没有运行；或者WebUI里的Ollama Base URL没配对。

解决：停掉进程，改用open-webui serve重启。Docker用户检查启动命令里有没有--add-host=host.docker.internal:host-gateway，然后在设置里把Ollama地址填成http://host.docker.internal:11434。

5.4 聊了几十轮之后速度越来越慢

现象：对话开头响应很快，聊二十分钟后每句话都要等很久。

原因：上下文在持续增长，num_ctx越大，每一步计算量越大；如果模型支撑不住，Ollama会不停向CPU卸载层，性能断崖下跌。

解决：把上下文窗口从默认的2048调到4096或8192，但同时观察显存。不要在一个会话里无限续聊，涉及长文档就先开新会话。WebUI里可以设置自动摘要历史记录，让早期对话压缩成摘要，而不是全程保留。

5.5 投喂了文档之后依旧答非所问

现象：明明上传了内部手册，问“报销流程是什么”，模型还是回答一堆通用内容。

原因：有三种可能——聊天时没有用#引用对应知识库；文档分块太大导致向量检索命中不了关键句；嵌入模型与文本语言不匹配。

解决：先确认对话输入框里已经有知识库标记。然后在RAG脚本里打印hits，看检索到的前三个片段是否真的包含答案。不相关就调小chunk_size到300，或者把文档按章节拆成多个文件再重新索引。

5.6 微调后模型变笨，连基础能力都丢了

现象：用LoRA训练完，模型回答自己的业务问题勉强能看，但让它写Python代码就逻辑混乱。

原因：数据集太小、太单一，训练时把模型原始能力覆盖掉了；学习率过大也会导致灾难性遗忘。

解决：微调数据量至少上千条，并且按比例混合通用数据，保留原有能力。学习率先用1e-5这种保守值，观察loss曲线再往上调。如果你只是想做知识库问答，再回去看RAG，别折腾微调。

6. 从能聊到能用：给本地DeepSeek做效果验证，再把它接进日常工具

跑通之后，下一步不是继续调参，而是建立一套验证方法，免得模型每次更新后你不知道是变好还是变坏。我的做法是准备一组固定问题，覆盖代码生成、中文摘要、知识库问答三种类型，然后写个脚本批量请求Ollama，把结果存成JSON，留着对比。

import requests questions = [ "用Python写一个二分查找函数", "把下面这段文字压缩成20字以内：本地部署大模型的关键在于显存、上下文窗口和数据质量。", "报销流程是什么？请根据资料回答。" ] for q in questions: resp = requests.post( "http://localhost:11434/v1/chat/completions", json={ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": q}], "temperature": 0.5, "stream": False } ).json() print(q, resp["choices"][0]["message"]["content"][:120])

每次换模型或调完参数就重跑一遍这份脚本，保留输出记录，你就能看清楚改动到底值不值。效果稳定之后，你的这本地方API因为是OpenAI兼容格式，可以直接接入Dify、FastGPT、企业微信机器人，甚至代码编辑器里的Codex插件。把Base URL改成http://localhost:11434/v1，密钥随便填一个就行，模型名填deepseek-r1:7b。很多工具选“自定义模型”就能识别。

我最开始也走过弯路，以为上传文档就算训练，攒了五十条问答直接上LoRA，结果模型连一句完整的话都说不利索。后来才明白，本地部署的价值不是“造一个无所不知的模型”，而是把一个可靠的底座放在自己手里，数据交给RAG，风格才交给微调。这条路一次跑通之后，你的文档、聊天记录和模型都留在本机，后续想接什么都轻松。希望帮到你。

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