DeepSeek R1 本地部署与知识库搭建完整教程

简介：这份PDF教程面向希望在本机运行大语言模型的开发者、研究者与普通用户，解决云端依赖、部署流程复杂以及数据隐私顾虑等问题。内容围绕Ollama工具安装、DeepSeek R1模型部署、Cherry-Studio界面化对话以及本地知识库搭建四条主线展开，并给出7B、13B、33B等不同版本对应的内存配置参考，帮助读者按自身硬件选择合适模型。资源包共1个PDF文件，约1.46MB，以图文步骤形式呈现，便于按章节对照操作。教程还涵盖API密钥创建、模型配置、知识库新建与文件添加等环节，读者可据此完成从命令行验证到界面化交互的完整流程，并理解本地部署在数据安全与隐私保护方面的优势。目前已有2034人学习，适合作为入门到进阶的实操参考。

1. 从一台离线笔记本说起：DeepSeek R1 本地部署到底解决什么问题

上个月帮一个做医疗信息化的朋友处理数据，他们有一批病历文本要跑语义检索，但合规要求写得死死的——数据不能出内网。他问我有没有办法在断网的笔记本上跑一个能对话、能查资料的大模型。我给他装了一套 Ollama + DeepSeek R1 + Cherry-Studio 的组合，从下载到跑通知识库问答，前后不到两小时。这套流程就是这份《DeepSeek R1 本地部署及搭建本地知识库完整教程.pdf》要讲的东西，核心链路是：Ollama 负责在本地拉起 DeepSeek R1 模型，Cherry-Studio 负责给它套一个能上传文件、能建知识库的图形界面。适合三类人：一是数据敏感、不能走云端 API 的从业者；二是想低成本试水本地大模型、不想折腾编译环境的开发者；三是需要给团队搭一个内网可用的问答入口、又不想写前端的技术负责人。整条链路不依赖外部网络请求，模型推理全在本机完成，这是它和调云端接口最本质的区别。

2. Ollama 安装与 DeepSeek R1 模型拉取：从零到命令行对话

2.1 Ollama 是什么，为什么选它而不是自己编译 llama.cpp

Ollama 是一个把大模型本地部署这件事封装到极致的开源工具。它的价值不在于推理性能有多强，而在于它把模型下载、量化格式转换、GPU/CPU 调度、API 服务这几件事全部收进了一个可执行文件里。你不需要装 CUDA 工具链，不需要手动下载 GGUF 文件再写加载脚本，一条ollama run命令就能把模型拉起来。

常见做法是自己用 llama.cpp 编译再加载 GGUF，好处是可控性高、能精细调参，但代价是每次换模型都要重新确认量化版本、上下文长度、显存分配。Ollama 把这些默认值都预设好了，对刚接触本地部署大语言模型的人来说，省掉的不是一步两步，而是整个环境配置阶段。它同时暴露了一个兼容 OpenAI 格式的本地 API 接口，默认监听11434端口，这意味着后面 Cherry-Studio 或者你自己写的 FastAPI 脚本都能直接调它。

选 Ollama 的另一个理由是模型库更新快。DeepSeek R1 发布后很短时间内就在 Ollama 官方库上线了从 1.5B 到 671B 的多个蒸馏版本，直接ollama pull就能拿到，不需要自己去 HuggingFace 找量化文件再转换。

2.2 Windows 下的安装步骤与验证

安装本身没有太多可讲的，下载OllamaSetup.exe一路下一步即可。但有几个细节值得注意：默认安装路径在 C 盘用户目录下，模型文件也会存在那里，一个 7B 模型的量化文件大约 4-5 GB，如果你 C 盘空间紧张，建议在安装前先规划好磁盘。安装完成后打开命令行，执行：

ollama --version

看到版本号输出就说明安装成功。如果提示'ollama' 不是内部或外部命令，说明安装程序没有把路径写进系统环境变量，手动把 Ollama 安装目录加到 PATH 里，或者重启一次终端。

接下来验证服务是否在跑：

ollama list

这个命令会列出本地已经拉取的模型。第一次执行时列表是空的，但只要能正常返回表头，就说明 Ollama 的后台服务已经起来了。如果报连接错误，检查一下系统托盘里有没有 Ollama 的图标，没有的话手动启动一次。

注意：Windows 下 Ollama 默认以当前用户身份运行后台服务，如果你用的是公司电脑、有权限限制，可能会遇到服务起不来的情况。这时候用管理员身份打开终端，执行ollama serve手动拉起。

2.3 根据硬件配置选 DeepSeek R1 版本

DeepSeek R1 在 Ollama 库里有多个参数规模的版本，选错了要么跑不动，要么浪费硬件。教程里给了一个粗略的参考：8GB RAM 对应 7B 模型，16GB 对应 13B，32GB 对应 33B。这个对应关系是偏保守的，实际体验中还要看你的显存和是否用 GPU 加速。

如果你有 8GB 显存的显卡，跑 7B 或 8B 版本是比较舒服的，推理速度能到每秒十几个 token。如果只有核显或者纯 CPU，7B 也能跑，但速度会降到每秒 2-5 个 token，对话体验会明显变慢。我一般建议第一次部署的人从 7B 或 8B 起步，跑通了再根据需求往上换。

拉取模型的命令直接从 Ollama 库页面复制：

ollama run deepseek-r1:8b

执行后会自动下载模型文件，下载完成后直接进入交互式对话界面。你可以输入一句话测试，比如「用一句话解释什么是向量数据库」，看到模型正常回复就说明推理链路通了。退出交互界面用/bye。

提示：如果下载速度慢，可以尝试在非高峰时段拉取，或者检查本机网络是否有对 Ollama 模型仓库的访问限制。模型文件下载到一半中断的话，重新执行ollama run会断点续传，不用删了重来。

3. Cherry-Studio 接入本地模型：把命令行对话变成图形界面

3.1 为什么需要一层图形界面

命令行里跟模型对话，测试阶段够用，但一旦要建知识库、要上传文档、要在多个会话之间切换，命令行的效率就跟不上了。Cherry-Studio 解决的就是这个问题：它把 Ollama 的本地 API 包装成一个桌面客户端，支持多会话管理、Markdown 渲染、文件上传和知识库检索。

这里有一个容易混淆的点：教程里提到了去硅基流动官网注册账号，但这并不意味着你的对话数据走了云端。注册账号是为了获取一个 API 密钥格式的凭证，Cherry-Studio 用它来标识客户端身份，实际的模型推理请求仍然发往你本机的http://localhost:11434。你可以理解为：账号是门禁卡，但计算发生在你自己家里。

3.2 安装与模型配置的具体操作

下载Cherry-Studio-0.9.19-setup.exe后安装，首次打开会引导你添加模型提供商。选择 Ollama 作为提供商，API 地址填http://localhost:11434，密钥栏留空或者随便填一个占位符都行，因为本地 Ollama 默认不校验密钥。

配置完成后，在模型列表里应该能看到你刚才用ollama run拉下来的deepseek-r1:8b。选中它，新建一个对话，发一条消息测试。如果 Cherry-Studio 报连接失败，按这个顺序排查：

# 第一步：确认 Ollama 服务在跑 ollama list # 第二步：确认 API 端口有响应 curl http://localhost:11434/api/tags

curl返回 JSON 格式的模型列表，说明 API 正常。如果curl不通但ollama list正常，检查 Cherry-Studio 里填的地址是不是写成了127.0.0.1而 Ollama 只绑定了localhost，两者在部分 Windows 版本上解析行为不一致，统一改成http://127.0.0.1:11434通常能解决。

3.3 对话参数怎么调

Cherry-Studio 的模型设置里有几个参数值得关注。temperature控制回复的随机性，做知识库问答时建议调到 0.1-0.3，让模型尽量基于检索到的内容回答而不是自由发挥。context length决定模型能记住多长的上下文，8B 模型默认 4096 或 8192，如果你上传的文档片段比较长，适当调大，但注意调太大会吃内存。top_p一般保持默认的 0.9 就行。

我自己的习惯是：日常对话用 temperature 0.7，知识库问答单独建一个会话把 temperature 压到 0.2。这样同一个模型不用重新加载，切换会话就能切换行为模式。

4. 本地知识库搭建：从上传文件到检索增强问答

4.1 知识库的工作原理与 Cherry-Studio 的实现方式

本地知识库的本质是检索增强生成（RAG）。你上传的文档被切分成若干文本块，每个块通过一个嵌入模型转成向量存进本地向量库。当你提问时，系统先把问题也转成向量，在向量库里找最相似的几个文本块，把它们和你的问题一起拼成提示词发给大模型。模型看到的就不只是你的问题，还有从文档里检索出来的相关段落，回答自然更贴合你的资料。

Cherry-Studio 把这一套流程做成了图形化操作：新建知识库、拖入文件、选择嵌入模型、等待索引完成。嵌入模型可以用 Ollama 里拉一个小的专用模型，比如nomic-embed-text，也可以用 Cherry-Studio 内置的默认选项。如果追求完全离线，建议用 Ollama 拉嵌入模型：

ollama pull nomic-embed-text

然后在 Cherry-Studio 的知识库设置里把嵌入模型指向它。这个模型只有几百 MB，对内存几乎没压力。

4.2 新建知识库并导入文件的操作步骤

在 Cherry-Studio 左侧栏找到知识库入口，点击新建，给它起一个能看懂的名字，比如「产品文档库」。创建完成后进入知识库详情页，有两种添加文件的方式：直接拖拽文件到窗口，或者点击添加文件按钮选择。支持的文件格式常见的有 PDF、TXT、Markdown、Word 文档。

文件添加后不会立刻可用，需要等待索引完成。索引过程就是前面说的切块和向量化。一个几十页的 PDF 大概需要几十秒到一两分钟，取决于你的 CPU 和嵌入模型的大小。索引完成后文件状态会变成「已索引」或类似的标识。

注意：如果 PDF 是扫描件、里面全是图片没有文字层，索引会失败或者索引出一堆空白。这种情况需要先用 OCR 工具把 PDF 转成可选中文本的格式再导入。纯图片的知识库，Cherry-Studio 当前版本处理不了。

4.3 对话时如何正确调用知识库

知识库建好之后，回到对话界面，在输入框附近会有一个选择知识库的入口。勾选你刚才建的知识库，然后再提问。这时候模型的回答会优先参考知识库里的内容。

这里有一个实操中很容易翻车的点：很多人建完知识库直接问了一个知识库里没有的问题，发现模型回答得跟没建库一样，就以为知识库没生效。实际上 RAG 的逻辑是「检索不到相关内容时，模型回退到自身知识回答」。要验证知识库是否真的在工作，问一个只有你上传的文档里才有的细节，比如文档里某个特定型号的参数，看模型能不能准确说出来。

如果模型回答的内容明显来自文档但格式混乱，检查一下文档切块的粒度。Cherry-Studio 默认的切块大小对中文文档有时偏大，一个块里混了多个主题，检索精度会下降。可以在知识库设置里把块大小调小一些，比如从默认的 1000 字符调到 500 左右，重叠区域保持 50-100 字符。

5. 避坑与排查：本地部署中最容易翻车的五个地方

5.1 模型拉取到一半报磁盘空间不足

现象是ollama run执行到一半突然报错退出，提示no space left on device或者 Windows 下提示磁盘写入失败。原因是 Ollama 默认把模型存在 C 盘用户目录下的.ollama\models文件夹里，一个 8B 模型加上缓存可能占到 6-8 GB，C 盘剩余空间不够就断了。

解决办法有两个：一是清理 C 盘腾出至少 15 GB 空间；二是把模型存储路径改到其他盘。Windows 下设置环境变量OLLAMA_MODELS指向新路径，比如D:\ollama-models，然后重启 Ollama 服务。已经下载了一半的模型文件在旧路径下，改完路径后需要重新拉取，但之前下载的层文件如果还在，Ollama 会尝试复用。

5.2 Cherry-Studio 连不上 Ollama 的 API

现象是 Cherry-Studio 里测试连接一直转圈或者报connection refused。最常见的原因是 Ollama 的后台服务没有随系统启动。Windows 下 Ollama 安装后默认会加一个开机启动项，但如果你用优化软件清理过启动项，或者手动关过服务，它就不会自动起来。

先确认服务状态：打开任务管理器看有没有ollama.exe进程。没有的话，在终端执行ollama serve手动启动，这个命令会占用当前终端窗口，不要关掉。然后回到 Cherry-Studio 重新测试连接。如果还是不通，把 API 地址从localhost换成127.0.0.1再试，Windows 下这两个主机名的解析优先级有时会导致连接走错协议栈。

5.3 知识库索引完成但问答时检索不到内容

现象是文件显示已索引，但提问时模型回答完全不引用文档内容。原因通常是嵌入模型和查询时的嵌入模型不一致。比如建库时用的是 Cherry-Studio 内置的嵌入模型，后来你在设置里改成了 Ollama 的nomic-embed-text，但知识库没有重建索引，导致向量空间对不上，检索自然失效。

解决办法是删除知识库重新建，或者在知识库设置里找到重建索引的选项，用当前配置的嵌入模型重新跑一遍索引。换嵌入模型必须重建索引，这是 RAG 系统的一条硬规则，没有捷径。

5.4 模型回复速度突然变慢

现象是刚开始对话时回复挺快，聊了十几轮之后每个字都像挤牙膏。原因是上下文长度在累积。每一轮对话都会把之前的聊天记录一起发给模型，上下文越长，推理耗时越大。8B 模型在 4096 上下文时可能每秒出 15 个 token，到 8192 时就降到 8 个。

解决办法是定期新建会话，不要让一个会话无限聊下去。Cherry-Studio 支持多会话，把不同主题的对话分开，每个会话的上下文就不会互相拖累。另外在模型设置里把上下文长度设一个上限，比如 4096，超过之后自动截断最早的对话轮次，虽然会丢失一点记忆，但速度能稳住。

5.5 中文文档索引后检索精度差

现象是上传了中文 PDF，提问时检索出来的段落跟问题相关性很低。原因是默认的文本切块策略是按字符数硬切，中文没有空格分隔，一个块可能从句子中间断开，语义完整性被破坏。

改善方法是把块大小调小、重叠区域调大。比如块大小从 1000 降到 400，重叠从 50 提到 100。这样每个块更可能包含一个完整的语义单元，检索时的向量匹配也更准。如果 Cherry-Studio 支持按标点符号切分的选项，优先选那个。另外，PDF 里的表格和图片说明文字在切块时容易被切散，如果文档里表格多，考虑先把表格转成 Markdown 再导入。

6. 进阶技巧：用 API 把本地模型接进自己的工具链

Cherry-Studio 适合日常对话和知识库管理，但如果你想把本地部署的 DeepSeek R1 接进自己的脚本、自动化流程或者内部系统，直接调 Ollama 的 API 更灵活。Ollama 暴露的接口兼容 OpenAI 的/v1/chat/completions格式，这意味着你之前为云端 API 写的代码，改一下base_url就能跑在本地模型上。

import requests # Ollama 的 OpenAI 兼容接口地址 url = "http://127.0.0.1:11434/v1/chat/completions" payload = { "model": "deepseek-r1:8b", # 换成你本地拉取的模型名 "messages": [ {"role": "system", "content": "你是一个严谨的技术助手，回答尽量简洁。"}, {"role": "user", "content": "Ollama 默认监听哪个端口？"} ], "temperature": 0.2, # 知识型问答压低随机性 "stream": False # 先关流式，方便调试 } resp = requests.post(url, json=payload, timeout=120) data = resp.json() print(data["choices"][0]["message"]["content"])

这段代码的关键参数有三个：model必须和你ollama list里看到的名称完全一致，大小写和冒号后的 tag 都不能错；temperature在自动化场景里建议设 0.1-0.3，减少输出波动；timeout要给够，本地模型首次加载到内存可能需要几十秒，设太短会直接超时。

如果你要接知识库检索，思路是在发请求之前先用向量相似度从你的文档库里捞出相关段落，拼进system或user消息里。Cherry-Studio 帮你做了这一步，但自己写脚本的好处是能把检索逻辑和业务规则绑在一起，比如只检索某个部门目录下的文档、或者对检索结果做二次排序。

验证 API 是否正常，除了跑上面的 Python 脚本，还可以用 curl 快速测：

curl http://127.0.0.1:11434/v1/models

返回的 JSON 里应该包含你本地所有已拉取的模型。这个接口在调试 Cherry-Studio 连接问题时也用得上，能快速区分是 Ollama 服务的问题还是客户端配置的问题。

我自己的习惯是：每次换模型或者改嵌入模型之后，先用 curl 确认 API 活着，再用一个最小化的 Python 脚本跑一轮问答，确认推理链路通了，最后才打开 Cherry-Studio 做界面操作。这样出问题的时候能快速定位是哪一层断了，不用在图形界面里瞎点。从那以后我每次部署新模型都强制走一遍这个顺序，省下来的排查时间比写脚本的时间多得多。希望帮到你。

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