简介这是一份围绕 DeepSeek 本地部署与私有知识库搭建的实操教程适合具备一定技术基础、希望在本地运行大模型的学习者或研发团队。内容以 Ollama 为核心详细说明不同硬件配置下的模型选型、DeepSeek-R1 从 1.5b 到 70b 的安装运行、命令行操作、环境变量修改与模型管理并补充 Cherry Studio 构建私有知识库的方法便于企业或团队在内网落地定制化问答系统。压缩包内为 1 个 docx 文档整体约 2.8MB文档结构清晰、步骤完整。该资源已有 16452 人学习下载。除本地部署全流程外还提供官方下载地址、备用链接、视频教程入口和在线演示环境信息并针对网络风险给出更换 API 的应急方案帮助用户规避安全故障。读者可按照文档逐级实践从轻量 1.5B 版本起步再依据显卡与内存条件升级到更大规模模型最终完成本地化和私有知识库的集成。1. 本地部署 DeepSeek先搞清你在解决什么问题把公司合同、个人笔记交给在线大模型时很多人心里都犯嘀咕这些数据是不是已经被拿去训练了。本地部署 DeepSeek 就是把模型真正跑在自己电脑上Ollama 负责运行模型ChatBox 提供聊天界面Cherry Studio 把私人文档变成可检索的私有知识库全套流程不依赖外网也不用把文件上传到任何第三方服务器。这篇教程适合三类人一是对数据敏感的内容从业者二是经常在离线环境写代码的开发者三是不想按 Token 付费、想低成本体验大模型的个人用户。先说一个反直觉的结论本地跑的 deepseek-r1 蒸馏版7B/14B在知识广度和复杂推理上确实不如在线满血版但一旦接上私有知识库让它基于你自己的文档回答问题垂直场景下的可用性反而比通用在线模型高。后面每一章都会落到可复现的命令和参数上。2. Ollama 部署 DeepSeek从下载慢到跑起来2.1 为什么选择 Ollama 而不是裸跑 GGUFDeepSeek 开源模型的原始权重是 PyTorch 格式直接跑要配 Python 环境和推理框架非常折腾。Ollama 把这个过程封装成了「一行命令」它内部基于 llama.cpp 做推理自动判断 GPU/CPU 负载把模型统一转成 GGUF 格式来加载对外暴露一个 OpenAI 兼容的 HTTP API。常见做法是用 Ollama 作为本地运行时理由是它让你把注意力放在应用层而不是推理层。如果你要的是生产级高并发那通常会上 vLLM 或 SGLang它们吞吐更高但配置复杂度也上了一个量级。个人电脑和中小团队的内网环境里Ollama 是最省心的选择这也是它成为「ollama 本地部署」这个搜索关键词下默认方案的原因。2.2 安装 OllamaWindows 和 Linux 的两种落地路径安装 Ollama 本身并不难难的是国内网络环境下两个下载环节安装包下载和模型文件下载。Windows 用户直接从官网下载安装包如果速度不理想可以从国内软件镜像站下载离线安装包或者让内网同事传一份已下载好的安装包分发。Linux 用户通常用官方安装脚本也可以下载 .deb 或 .rpm 离线包后用 dpkg 或 rpm 安装效果一样。安装之前先规划好模型存储位置。Windows 上如果 C 盘空间紧张我一般会先建一个环境变量再安装setx OLLAMA_MODELS D:\ollama\models设置完重新打开终端再执行ollama serve或直接让系统服务启动。Linux 下修改存储路径要用 systemd 的方式sudo systemctl edit ollama在打开的编辑器中写入[Service] EnvironmentOLLAMA_MODELS/data/ollama/models然后执行systemctl daemon-reload systemctl restart ollama。这段操作的关键点是环境变量在 Ollama 启动时读取改完之后必须重启 Ollama 服务才生效。Windows 用户如果发现不生效十有八九是没重启终端或服务。模型文件本身是 GGUF 格式里面打包了量化后的权重和推理所需元数据这也是为什么OLLAMA_MODELS路径下会看到一堆带哈希值的目录。2.3 拉取 DeepSeek 模型与确认显卡调用模型选择要结合硬件deepseek-r1:1.5b约 1.1GBdeepseek-r1:7b约 4.7GBdeepseek-r1:14b约 9GB。内存 16GB 的机器建议从 7B 起步32GB 内存可以试 14B。ollama pull deepseek-r1:7b ollama list ollama psollama list查看本地已有模型ollama ps查看当前加载的模型运行在 GPU 还是 CPU。如果ollama ps里 PROCESSOR 列显示 GPU说明显卡调用成功显示 CPU 且输出很慢就是模型太大塞不进显存回退到 CPU 计算了。NVIDIA 显卡在 Windows 下基本开箱即用Ollama 自带 CUDA 支持AMD 显卡要确认是否被识别识别不到就只能用 CPU 跑。ollama pull网络不理想时另一个常见做法是去 ModelScope魔搭社区下载 DeepSeek 的 GGUF 文件再手动导入# 写一个 ModelfileFROM 指向下载好的 .gguf 文件 FROM D:\models\deepseek-r1-7b-q4_k_m.gguf # 用 Modelfile 创建本地模型 ollama create deepseek-r1:local -f Modelfile这样导入的模型和ollama pull拉下来的模型在使用上没有区别解决了「模型下载慢」这个最大的痛点。下载慢的另一个隐藏问题是中断后续传不可靠所以建议一次性下完别反复按ctrlc。3. ChatBox 接入 Ollama一个 API 地址搞定聊天界面3.1 为什么选 ChatBox命令行里ollama run deepseek-r1:7b虽然能聊但对话记录、上下文管理和多轮体验都太原始。ChatBox 是常见的桌面级前端免费支持把 Ollama 当作模型提供方接入也支持接入 OpenAI 等在线服务界面体验和商用聊天软件接近。安装包从官网或 GitHub Releases 下载国内直接下安装包问题不大。ChatBox 的定位就是「本地模型的聊天壳」它不参与推理也不存你的业务数据所有请求都发给本地 API。这让它非常适合和 Ollama 搭配一个负责模型调度一个负责交互互相不干扰。3.2 配置步骤从打开设置到开始对话ChatBox 的配置逻辑是「模型提供方 模型名」。打开设置找到模型提供方选择 Ollama填两个关键信息API 地址http://127.0.0.1:11434模型名称deepseek-r1:7b保存后新建对话选择deepseek-r1:7b即可开始。这里的 API 地址指向 Ollama 默认监听的本地端口默认只允许本机访问不需要额外暴露。如果 Ollama 装在另一台机器上才需要把 IP 换成那台机器的内网 IP。这个配置过程的底层原理很简单ChatBox 把用户输入组装成 OpenAI 格式的请求体POST 到 Ollama 的/v1/chat/completions端点Ollama 完成推理后把结果原样返回。有个容易被忽略的参数是上下文长度。Ollama 的默认上下文窗口通常只有 2K 到 4K对话稍微长一点前面的内容就被截断或直接报错。ChatBox 的模型设置里一般有上下文长度选项建议直接设到 8192 或 16384前提是你的内存扛得住。上下文越大单次请求消耗的显存和内存也越大。3.3 「无法缓冲请求正文」是什么问题检索「chatbox 无法缓冲请求正文 超出长度限制」的人很多这个报错在接入早期我也见过。现象是粘贴一大段代码或长文后ChatBox 直接提示请求正文超长对话发不出去。原因分两层第一层是 Ollama 的 num_ctx 小请求内容超过模型能接受的上下文窗口第二层是单条消息本身过长触发了服务端的缓冲上限。解决办法按优先级来清空当前对话或删掉消息里的超长内容在 ChatBox 里把上下文长度调大如果客户端没有暴露这个选项就用 Modelfile 固定上下文FROM deepseek-r1:7b PARAMETER num_ctx 32768ollama create deepseek-r1:7b-ctx32k -f Modelfile之后在 ChatBox 模型名里选deepseek-r1:7b-ctx32k。注意这个操作会增加显存占用7B 模型开 32K 上下文16GB 内存会比较吃力建议配合虚拟内存使用。4. Cherry Studio 私有知识库让 DeepSeek 回答你的私人文档4.1 知识库的工作原理ChatBox 解决的是「聊天」问题Cherry Studio 解决的是「让模型知道你的文档」问题。它内部走的是标准的 RAG检索增强生成流程先把文档按长度切块然后用嵌入模型把每个块转成向量存进本地向量库提问时把问题也转成向量做相似度检索把最相关的几个块拼进 Prompt交给 DeepSeek 生成回答。这个流程里有两个模型在协作负责生成的 DeepSeek 和负责向量化的嵌入模型。向量化这一步完全可以用 Ollama 跑本地的嵌入模型比如nomic-embed-text或bge-m3。中文文档优先推荐bge-m3它对中文和长文本的支持比nomic-embed-text更友好。嵌入模型很小普通 CPU 也能跑不用太担心资源占用。4.2 配置步骤Ollama 嵌入模型 知识库关联先在 Ollama 里拉取嵌入模型ollama pull bge-m3 ollama pull deepseek-r1:7b然后在 Cherry Studio 设置中添加 Ollama 提供方API 地址同样是http://127.0.0.1:11434。此时提供方下面会列出刚才下载的模型把deepseek-r1:7b设为对话模型把bge-m3设为嵌入模型。接着创建知识库打开知识库页面新建知识库选择嵌入模型bge-m3拖入 PDF、Markdown 或 TXT 文档等向量化完成看到文档状态变为「就绪」在对话页面打开知识库关联开关选择刚建的知识库。配置成功后提问Cherry Studio 会先检索再回答回答内容里通常带着引用来源。这一步验证的不只是「能不能答」而是「答案是否基于你的文档」。如果答得完全像通用大模型在自由发挥说明知识库没有被真正检索到要回查关联开关和嵌入模型配置。常见做法是切块和向量化在本地完成整个过程不产生网络请求所以私有知识库的数据边界是可控的。4.3 chunk 大小、检索数量与相似度阈值的经验值知识库效果好不好参数影响很大。常用初始值如下参数建议取值影响切块大小 chunk_size400-600 字符太小语义被切断太大检索噪声高重叠长度 overlap50-100 字符保证切块边界语义连贯检索数量 topK3-5越多上下文越全但无关内容也越多相似度阈值0.35-0.5低于阈值的块会被过滤切块大小是新手最容易忽略的。默认值如果太大一段跨多个主题的文档会被塞进同一个向量检索时容易带出无关内容太小则语义不完整。400 到 600 字符对绝大多数技术文档是可靠起点。topK 宁缺毋滥5 个通常够用超过 8 个之后回答会开始「串味」。如果是团队场景FastGPT 或 Dify 也是常见的落地方式原理完全一样只是它们把知识库、工作流和权限做成了 Web 服务对个人来说 Cherry Studio 这类桌面工具更轻也更容易复现。5. 本地部署避坑清单5 个让新手翻车的细节5.1 模型下载慢到想放弃现象ollama pull卡在几 KB/s进度条一整晚没动。原因模型托管在海外 registry国内直连速度不理想。解法到 ModelScope 下载同版本 GGUF 文件用 Modelfile 导入本地导入后ollama list能看到自定义模型名。另外把模型目录放在剩余空间最大的盘上SSD 和 HDD 的加载速度差别在 14B 以上模型上非常明显。5.2 显存不够导致的速度玄学现象对话时风扇狂转一个字一个字蹦出来。原因模型超出显存容量后Ollama 会把部分层卸载到内存甚至 CPU 计算。解法先用ollama ps看 PROCESSOR 列确认模型跑在 GPU 还是 CPU换成更小的量化版本或直接降级到 7B。还可以设置环境变量OLLAMA_MAX_LOADED_MODELS1避免同时加载多个模型把显存占满。这个现象最容易骗人表面上看模型「能跑」实际速度和可用性完全不合格属于典型的本地部署玄学。5.3 改了存储路径却不生效现象环境变量设了OLLAMA_MODELS模型还是往 C 盘写。原因Windows 下服务已在旧环境变量下启动Linux 下 systemd 服务没有重新加载配置。解法Windows 用setx设置后务必重新打开终端并重启 Ollama 服务Linux 用systemctl edit ollama写入 Environment然后daemon-reload和restart。要迁移已有模型直接把整个 models 目录拷到新位置再重启比重新下载快得多。5.4 请求正文超过长度限制现象ChatBox 或 Cherry Studio 里粘贴长文后报「无法缓冲请求正文」。原因num_ctx 太小请求内容超过模型上下文上限。解法先清空对话或缩短消息然后在客户端调大上下文长度再不行就用 Modelfile 固定num_ctx 32768并重建模型。需要注意上下文翻倍会带来显存和内存占用上升改完以后观察一下内存水位。5.5 端口暴露与仅本地访问现象局域网里其他机器能访问你的 11434 端口。原因为了远程调用把 Ollama 的监听地址改成了0.0.0.0。解法默认不要改监听地址Ollama 本身就只监听127.0.0.1ChatBox、Cherry Studio 都在本机运行完全不需要对外开放。如果确实要在局域网内用把监听地址写成内网 IP 而不是0.0.0.0并且不要把端口映射到公网。这个端口后面就是完整的大模型调用能力裸奔到公网等于把后门钥匙挂在门口。6. 进阶用 Python 把本地模型变成你自己的 API 服务最后分享一个常用的进阶技巧不依赖 ChatBox 的图形界面用 Python 直接调用 Ollama 的/api/chat接口把本地模型变成可复用的自动化服务。整个过程只需要 requests不需要额外安装 SDKimport requests resp requests.post( http://127.0.0.1:11434/api/chat, json{ model: deepseek-r1:7b, messages: [{role: user, content: 用三句话解释 RAG}], stream: False, options: { num_ctx: 32768, temperature: 0.7, }, }, timeout120, ) data resp.json() print(data[message][content])这段代码的核心是options里的两个参数num_ctx直接控制上下文窗口不需要在客户端设置temperature控制回答的随机性。做信息抽取类任务时把 temperature 降到 0.2 左右做创意写作再调回 0.7 以上。stream设为False能拿到完整响应方便调试正式服务里建议改成True前端可以边生成边显示。写完之后用三个命令验证部署是否健康ollama list确认模型存在ollama ps确认模型加载在 GPU再跑一遍上面的脚本确认 API 通。如果要做成团队内部服务可以再用 FastAPI 包一层把校验、日志和模型切换收口到一个小服务里核心逻辑就是上面这几行请求代码。我自己的习惯是把常用 Prompt 模板也收进配置文件这样换模型型号只需要改一个字段不用动代码。这条路的坑在前几章几乎都踩过最早 7B 模型下载失败三次后来学会了用 GGUF 导入第一次开 32K 上下文把 16GB 内存吃满才知道知识库和上下文都要算资源账。现在把模型文件像备份一样归档把上下文参数写进 Modelfile整条链路反而比在线 API 更让人放心希望帮到你。本文还有配套的精品资源点击获取