简介这份教程专为想避开DeepSeek服务器拥堵、在本地自由使用开源大模型的新手用户设计完整梳理从零开始的部署、可视化交互与数据投喂训练全流程。内容按“本地部署—WebUI可视化—数据投喂训练AI”三阶段展开具体涵盖Ollama安装、按显存挑选DeepSeek-R1模型版本、Page Assist插件实现浏览器可视化对话以及借助nomic-embed-text和AnythingLLM构建私有知识库的完整操作。资源为docx文档共1个文件压缩包大小2.76MB文字步骤清晰、配有界面引导适合AI初学者边看边操作。已有1186人学习下载对于希望低成本搭建个人AI助手、建立专属知识库或了解大模型本地化落地的用户是一份可直接跟随的保姆级参考。1. DeepSeek本地部署WebUI可视化数据投喂训练AI把三件事拆成一条能走通的路“DeepSeek本地部署WebUI可视化数据投喂训练AI”这串标题看起来是三件事其实是同一条链路的三段先让 DeepSeek 跑在你自己的机器上再通过 WebUI 把黑乎乎的终端变成聊天窗口最后把手头的行业文档“投喂”给模型让它能回答你业务里的问题。这套方案最适合个人开发者、小团队以及数据不能出内网的场景。新手最容易犯的错是一上来就学微调攒显存、洗数据、跑 LoRA卡两周就放弃。这篇文章给的落地方案是本地部署选 Ollama可视化选 Open WebUI数据投喂先用 RAG把这三段跑通之后再决定要不要碰微调。2. DeepSeek本地部署实战硬件判断、Ollama安装与模型选型2.1 先算显卡账动手装之前先搞清楚该跑哪个规模的模型本地部署大语言模型最怕的不是装不上是模型拉下来之后一推理就报显存不足。DeepSeek 在 Ollama 仓库里有多个蒸馏版本从 1.5B 到 70B 都有选型直接决定你能不能顺畅地用下去。我见过不少新手直接ollama run deepseek-r1:70b然后看着终端卡死还以为是自己操作错了。先看一张基于 Q4 量化模型的参考表模型标签量化后占用显存最低内存体验评价deepseek-r1:1.5b约 1.1 GB8 GB能跑但推理能力有限deepseek-r1:7b约 4.7 GB16 GB新手首选速度与效果平衡deepseek-r1:8b约 5.2 GB16 GB与 7B 接近代码任务略好deepseek-r1:14b约 9 GB32 GB效果好一截需要 12G 以上显存deepseek-r1:32b约 20 GB64 GB接近满血体验24G 显卡可跑deepseek-r1:70b约 42 GB128 GB不建议新手碰CPU 模式基本不可用选型的原则很简单8G 显存老老实实跑 7b 或 8b12G 显存可以上 14b24G 显存跑 32b 量化版比较稳。如果你用的是 Mac 的 M 系列统一内存可以按“可用内存的一半”来预估能跑多大模型16G 内存的 Mac 跑 7b 会比较顺手。显存够不够在 Linux 上用nvidia-smi看一眼就知道Windows 上打开任务管理器看“GPU 专用内存”那一栏。提示模型文件本身也占磁盘空间7B 量化模型大约 4.7GB32B 量化模型大约 20GB。装之前给模型目录留足空间不然下载到一半磁盘写满Ollama 会直接失败。2.2 用 Ollama 跑通 DeepSeek 的最小命令与服务配置Ollama 是目前把 DeepSeek 跑在本地最省事的工具没有之一。它把模型下载、量化、运行时环境、OpenAI 兼容 API 都打包好了你在终端里敲两条命令就能进对话。以下是 Linux/macOS 的安装与启动流程# 一键安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 启动服务端默认监听 127.0.0.1:11434 ollama serve # 另开一个终端拉取并运行 DeepSeek 7B 蒸馏版 ollama run deepseek-r1:7b第一次执行ollama run时Ollama 会先把模型从仓库拉下来再进入交互界面。进入界面后直接输入问题就能对话输入/bye退出。这里需要注意ollama serve默认只监听本机后续要让 Open WebUI 容器访问必须把监听地址放开同时把模型目录从系统盘挪走避免 C 盘或系统分区被撑爆。# 自定义模型目录与监听地址按需写入 ~/.bashrc 或做成 systemd 服务 mkdir -p /data/ollama export OLLAMA_HOST0.0.0.0:11434 export OLLAMA_MODELS/data/ollama export OLLAMA_KEEP_ALIVE10m ollama serveOLLAMA_HOST0.0.0.0:11434表示允许局域网内其他机器访问这是 Open WebUI 容器访问宿主机 Ollama 的前提OLLAMA_MODELS指定模型存放路径方便迁移和备份OLLAMA_KEEP_ALIVE10m表示模型在 10 分钟内没请求就自动卸载给显存腾位置。日常管理用ollama list看本地模型ollama ps看当前加载到显存里的模型ollama rm删模型。如果把这些配置写进 systemd 服务文件开机自启会更省心这个后面会提到。2.3 模型量化与速度权衡显存不够、CPU 太慢怎么调显存不够和速度太慢几乎是本地部署 DeepSeek 的两个主要劝退点。先说显存。模型文件的量化精度直接决定占用大小Ollama 默认下载的 Q4_K_M 已经是效果和体积的折中。如果你用 14B 模型报CUDA out of memory第一时间不是换显卡而是检查两点是不是同时加载了多个模型以及上下文长度是不是设得太大。# 限制同时加载的模型数量缩短上下文长度 export OLLAMA_NUM_PARALLEL1 export OLLAMA_MAX_LOADED_MODELS1 export OLLAMA_CONTEXT_LENGTH4096 ollama serveOLLAMA_NUM_PARALLEL1表示同一时间只处理一个请求避免多个并发任务把显存挤爆OLLAMA_MAX_LOADED_MODELS1让同一个模型被不同对话复用而不是重复加载OLLAMA_CONTEXT_LENGTH4096是上下文窗口长度数值越大显存占用越高但回答长文档能力也越强。显存只有 8GB 的话直接把长度降到 2048 再跑 7B 模型会更稳。纯 CPU 模式跑 DeepSeek速度取决于内存带宽而不是 CPU 核心数。我自己用一台 32G 内存的机器跑过 14B 量化模型生成速度大约每秒 3 到 5 个 token体感上就是“打字机模式”。想快一点只能换 7B 甚至 1.5B 模型。这不是参数调优能解决的是硬件边界。先把每个变量看清楚后面遇到问题才不会一头雾水。3. 用 Open WebUI 给 DeepSeek 装可视化界面Docker 安装与联调3.1 为什么选 Open WebUI模型管理、知识库、多用户一个不少DeepSeek 在终端里跑通之后下一个自然需求是可视化。很多人搜“如何用 docker 安装 open webui”搜到一堆同类项目Tabby、AnythingLLM、Dify、RVC WebUI每个都有人推荐容易挑花眼。我身边留下的基本都是 Open WebUI因为它在“聊天界面”这个核心需求上做得最接近 ChatGPT同时把模型切换、知识库、多用户权限也一起解决了。对比项Open WebUITabbyAnythingLLM部署方式Docker 一键Docker/本地Docker/桌面版多模型管理支持下拉切换支持较弱内置知识库支持可上传文档不支持支持多用户权限完整账号体系无有限与 Ollama 集成原生自动识别需配置需配置这个表的结论很直接如果只想要一个漂亮聊天界面Tabby 足够如果重点是 RAG 知识库问答AnythingLLM 也很强但如果想把“本地部署 WebUI 数据投喂训练”串成一条完整链路Open WebUI 是那个能把三个需求都接住的项目。它不需要写前端代码也不用手动拼接 API装完容器就能用。3.2 Docker 部署 Open WebUI最小命令与数据持久化Docker 部署 Open WebUI 的标准做法是把容器跑在 Ollama 旁边。如果你是 Linux并且 Ollama 跑在宿主机上下面这条命令可以直接套用# 准备数据目录防止容器删了数据全丢 mkdir -p /opt/open-webui/data # 启动 Open WebUI 容器 docker run -d \ --name open-webui \ --restart always \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v /opt/open-webui/data:/app/backend/data \ ghcr.io/open-webui/open-webui:main-p 3000:8080把容器内部的 8080 端口映射到宿主机 3000浏览器访问http://localhost:3000即可。--add-host是 Linux 上让容器能通过host.docker.internal访问宿主机的关键Windows 和 macOS 的 Docker Desktop 不需要这行。OLLAMA_BASE_URL指向宿主机上 Ollama 的地址注意不能写http://localhost:11434在容器里 localhost 指向的是容器自己不是宿主机。-v挂载的数据目录是最后一道后悔药重启、删容器都不影响账号和知识库。注意如果你的 Ollama 也跑在 Docker 里更省事的做法是用--network host启动 Open WebUI然后直接把OLLAMA_BASE_URL写成http://localhost:11434。两种方式选一种即可别混用混用容易出现“日志里显示连接失败”的坑。3.3 让 WebUI 连上 Ollama端口验证、管理员账号与局域网访问容器起来之后先别急着注册账号按顺序做三件事。第一确认 Ollama 的接口在外网可见第二看 Open WebUI 日志有没有报错第三注册第一个管理员账号。# 在宿主机上验证 Ollama 接口 curl http://localhost:11434/api/tags # 查看 Open WebUI 容器日志排查连接问题 docker logs open-webui --tail 100curl返回的 JSON 里能看到模型列表说明 Ollama 服务正常。如果返回connection refused先回到第二章确认OLLAMA_HOST是否真的绑定了0.0.0.0。注册第一个账号时Open WebUI 会自动把它设为管理员默认配置下注册页面是开放的任何能访问这台机器 IP 的人都能注册。如果在局域网里给团队用注册完账号后去管理后台关掉“开放注册”不然你的机器会变成公开聊天室。验证通过后打开http://localhost:3000左上角模型下拉框里应该能直接看到 deepseek-r17b。到这里本地部署和 WebUI 可视化这两段已经全部打通接下来才是“数据投喂训练 AI”的重头戏。4. 数据投喂训练 AI先做 RAG 知识库再决定要不要微调4.1 搞清楚“投喂”的三层含义提示词注入、RAG 与微调该选哪个新手搜“如何训练属于自己的 AI”搜到的方案五花八门有人说要准备几十万条数据集有人说要租显卡跑微调还有人直接把 PDF 丢给模型就当训练完了。实际上“数据投喂”这个词在从业者嘴里有三层完全不同的含义选错了成本差几个数量级。投喂方式成本改变的是什么适合场景系统提示词注入零成本回答风格、角色设定让 AI 自称“小助手”、按指定格式输出RAG 知识库只需文档整理新增知识来源让 AI 回答你给的文档内容LoRA 微调需要显卡与数据集模型权重与推理习惯让 AI 掌握特定领域语气或能力判断标准很简单想让 AI 知道某件事用 RAG想让 AI 像某个人一样说话才考虑微调。绝大多数新手的真实需求是前者。比如你有一批内部 FAQ 或行业报告希望 DeepSeek 能根据这些材料回答问题RAG 就是正解。把几百份 PDF 交给 Open WebUI它会切块、向量化、检索再把命中的内容拼进提示词里。这也是我在这个标题下会优先推荐 RAG 的原因不动模型权重随时能增删知识翻车了随时能撤回像是给模型装上了外挂硬盘。4.2 RAG 切分参数怎么定chunk_size、overlap 与 top_k 的推荐区间RAG 效果好不好参数决定一半。Open WebUI 内置了基础切分能力但默认参数对中文文档不一定友好。三个核心参数必须先理解再动手chunk_size、overlap、top_k。chunk_size 是每段文本切成多少个字符。切太小上下文碎片化AI 看不全完整逻辑切太大检索命中不精准还把上下文窗口撑爆。中文场景我一般建议问答型文档用 300 到 500 字符长文总结类用 800 到 1000 字符。overlap 是相邻块之间的重叠长度目的是避免关键词正好落在切缝上导致检索不到通常取 chunk_size 的 10% 到 20%。top_k 是召回多少块内容拼给模型Open WebUI 默认的检索结果我嫌少调到 4 到 5 更合适太高容易掺入无关片段。embedding 模型的选择同样影响检索质量。Ollama 仓库里的nomic-embed-text体积小英文效果好如果你的文档以中文为主建议换成bge-m3对中文语义的理解更稳。Open WebUI 的设置页面里可以指定 embedding 模型拉取命令就一行ollama pull bge-m34.3 实测投喂把第一批 PDF 和 Markdown 导入 Open WebUI在 Open WebUI 里建知识库的路径是左侧面板找到“知识库”新建一个库比如“内部 FAQ”然后上传 PDF、Markdown、TXT 文件。上传后系统会自动完成切分和向量化。这里我给一个用 Python 预览切分效果的脚本在上传前先看看文档会被切成什么样避免把几十页 PDF 一把梭喂进去才发现检索乱套。# 切分预览脚本读入 Markdown/TXT按 500 字符切块并输出重叠区间 def chunk_text(text, size500, overlap50): chunks [] start 0 while start len(text): end start size chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks with open(你的文档.md, encodingutf-8) as f: body f.read() for i, c in enumerate(chunk_text(body)): print(f--- chunk {i} len{len(c)} ---) print(c[:80].replace(\n, ))这段代码先按 500 字符切块相邻块重叠 50 字符然后打印每一块的前 80 个字符让你直观看到哪些内容被割裂了。如果发现某一块在句子中间被硬切说明 chunk_size 不合适可以改成按段落切分先按空行拆段落再把段落合并成 500 字符左右的块。导入完成后在对话输入框底部用#选择知识库发送问题时勾选“引用文档”AI 的回答下方会列出命中了哪几个片段这是验证 RAG 是否生效的最直接方式。提示不要上传扫描版 PDFOpen WebUI 不会自动做 OCR扫描件切出来的全是乱码。先转成文本或 Markdown 再投喂效果天差地别。4.4 真要“训练”时怎么办LoRA、数据集格式与成本预期如果你试过 RAG 之后发现需要的是改变模型本身的行为比如让 DeepSeek 用中医师傅的口吻回答辨证问题那就要进入微调阶段。常见做法是用 LoRA 低秩适配在保持原模型不动的前提下训练一个适配层7B 模型微调比全参微调友好得多。工具方面LlamaFactory 是目前对新手比较友好的开源方案之一它把数据处理、训练、评估封装成了页面操作。微调用的数据集通常是 JSON 或 JSONL 格式以对话指令对为主[ { instruction: 患者头痛三天伴随恶心该怎么处理, output: 先建议休息并补充水分若症状持续应就诊排查病因。 } ]这里要泼一盆冷水微调不是“喂了数据就变聪明”而是要准备上万条高质量指令对数据清洗占整个流程 80% 的工作量。即使是 54 万条数据的领域集合新手也不建议直接全量训练先抽样几百条试跑 LoRA评估效果后再逐步加大数据量。我的建议是先做 RAG 跑通业务积累足够多的真实问答对之后再考虑微调。跳过 RAG 直接微调大概率是钱花了、卡租了、模型越训越傻。5. 新手本地部署的 5 个高频坑现象、原因与解决步骤5.1 CUDA out of memory是模型太大还是并发抢占现象用ollama run deepseek-r1:14b启动模型终端报CUDA out of memory或者 Open WebUI 里对话一提交就返回错误。原因显存不够最常见但经常被忽略的第二个原因是同时加载了多个模型或者多个对话共享一个 Ollama 服务导致显存峰值超限。解决先用ollama ps看当前有哪些模型驻留在显存里然后停止占用模型再把并发限制写进环境变量ollama stop deepseek-r1:14b export OLLAMA_NUM_PARALLEL1 export OLLAMA_MAX_LOADED_MODELS1 export OLLAMA_CONTEXT_LENGTH4096改完重启ollama serve再启动小一号的模型。如果 7B 都报显存不足检查一下显卡驱动是否被容器占用比如 Docker 容器里跑了另一个 GPU 进程。5.2 WebUI 报 Connection refusedOllama 明明在跑现象Open WebUI 能正常打开登录页但一发消息就报Ollama connection refused在宿主机上curl localhost:11434却是通的。原因容器内部的localhost指向的是容器自己不是宿主机。Open WebUI 容器访问不到 11434 端口。解决确认环境变量用的是host.docker.internal而不是localhost并在容器内做一次连通性测试docker exec open-webui curl http://host.docker.internal:11434/api/tags如果返回 JSON 正常说明网络链路通了回 WebUI 刷新页面重试。如果是 Linux 且没加--add-host容器里根本解析不了host.docker.internal需要重建容器并加上那行参数。这条排查顺序能省一个小时的胡思乱想。5.3 投喂了文档回答却完全没用上知识库现象知识库里已经上传了文档对话里也选中了知识库但 AI 的回答看起来还是凭模型自身知识在胡编引用的片段一个都没有。原因三种可能。第一提问时没有在输入框里用#选知识库只是建了库没激活第二embedding 模型是英文导向的中文文档向量化效果差导致检索不到相关内容第三top_k 太小命中的块被过滤掉了。解决先确认对话输入框下方确实激活了知识库并打开“引用文档”开关。然后把 embedding 模型换成bge-m3重新构建一次知识库。最后把 top_k 从默认值调到 4 或 5。判断是否生效看回答下方有没有出现“引用文档片段”没有就是检索链路断了。5.4 Docker 容器一重启账号、模型、知识库全没了现象用docker rm删掉容器再重新跑登录账号不存在了知识库也空了像是一切回到出厂状态。原因数据没有持久化。Open WebUI 的应用数据写在容器内部/app/backend/data目录容器删除后这部分数据跟着销毁。解决用docker inspect open-webui查看挂载情况如果 Mounts 里是空的说明你启动时漏了-v参数。重新创建容器时加上-v /opt/open-webui/data:/app/backend/data以后升级镜像时只要不动这个数据目录账号、文档、对话记录都在。这个坑我踩过一次之后凡是涉及 Docker 的部署第一件事就是确认数据目录挂载没有挂载等于裸奔。5.5 纯 CPU 跑大模型慢到崩溃量化等级选错了现象对话生成一个字要转好几秒浏览器里一直转圈一个简单问题回答完要等一分钟以上。原因不是机器差是模型规模和量化等级没匹配硬件。纯 CPU 模式下跑 14B 以上的模型内存带宽就是瓶颈神仙也救不了。解决把模型换成deepseek-r1:7b或1.5b再缩短上下文长度到 2048同时把对话历史关闭减少每次请求的输入长度。环境变量这样设置export OLLAMA_CONTEXT_LENGTH2048 export OLLAMA_KEEP_ALIVE2mOLLAMA_KEEP_ALIVE2m让模型两分钟不用就被卸载避免长期驻留占着内存。CPU 跑模型的体验上限就在那里与其调参折腾不如直接换小模型。记住一个原则本地部署的调试顺序永远是“先换小模型验证链路再逐步加大规模”而不是一开始就挑战最大号。6. 让这套本地 AI 真正能用导入领域数据、验证效果与控制成本6.1 用“三问验证法”判断 RAG 投喂是否成功所有链路跑通后别急着大规模导数据先用三组问题验证整套系统是不是真的在按预期工作。第一问这个问题的答案是不是只存在于你的文档里如果模型凭公开知识就能答对说明不了知识库的价值。第二问答案是否忠于原文还是模型自己脑补了细节RAG 的常见翻车是模型把检索到的片段和自身知识混在一起编出原文没有的内容。第三问连续问同一主题的不同侧面回答是否稳定知识库的切分方式不同检索命中的片段也不同如果时好时坏回到第四章调切分参数。验证时我会准备一组对照问题分别关掉和打开知识库各问一遍把两次回答存下来对比。打开知识库后回答中应该明显多出文档里的术语、数字和表述习惯。如果没变化优先怀疑 embedding 模型和 chunk_size而不是怀疑方案本身。垂直领域数据比如中医问答、法律条款、内部流程文档建议按主题拆成多个知识库而不是混在一个大库里。混库会导致检索时命中文案和其他文档的概率几乎一样高噪声很大。我自己走过一段弯路第一次做知识库投喂时贪心把几百份 PDF 一次性灌进去结果切分混乱检索效果差到让人崩溃后来改成按主题分库、每库文档控制在几十份以内、chunk_size 固定在中文问答更友好的 400 到 500 字符效果才稳定下来。数据投喂这个方向不是数据越多越好而是检索越精准越好。先把 20 篇高质量文档跑出稳定效果再考虑扩到 200 篇、2000 篇这个过程也能帮你判断是否真的需要走到微调那一步。成本方面本地部署本质上是用电费和硬件投入换数据和对话的私密性。7B 模型在消费级显卡上跑一轮推理的成本几乎可以忽略真正贵的是你的调试时间。先在 RAG 上拿到可用的业务效果再决定要不要为微调租卡是这套链路里性价比最高的路线。希望帮到你。本文还有配套的精品资源点击获取