1. 为什么要在本地跑DeepSeek加知识库把大模型跑在自己电脑上再挂一个私有知识库这件事在两年前还是实验室里的玩法现在已经成了很多技术团队和个人的日常操作。核心驱动力其实就三条数据不出本机、调用不花钱、断网也能用。尤其是做企业内训、法律条文检索、医疗问答、农业种植手册这类场景资料本身就不适合往外传本地部署几乎是唯一解。DeepSeek 这个系列模型最近热度很高推理能力和中文理解都在线配合 Ollama 做本地推理引擎再叠一层 RAG 知识库整套链路就通了。Ollama 的好处是把模型下载、量化、加载、API 暴露这些脏活全包了你只需要一条命令就能把模型拉起来。知识库这块Dify 是目前上手最快的选择可视化流水线、支持多种文档格式、自带向量检索零代码也能搭起来。这套组合适合谁我梳理了一下大概三类人最需要一是手里有大量私有文档、想做成问答机器人的开发者二是想学 RAG 但不想一上来就啃 LangChain 源码的初学者三是公司内网环境、外网访问受限、必须离线跑模型的运维同学。如果你属于这三类中的任何一类下面这套流程可以直接抄。不过我得先说清楚本地部署不是点一下按钮就完事中间会踩到不少坑。我前后折腾了三四轮遇到过模型下载卡死、Docker 端口冲突、知识库检索返回空结果这几个典型问题后面会逐个拆解。先把整体思路讲明白再动手。2. 整体方案设计与选型考量2.1 为什么是 Ollama 而不是 vLLM很多人一提到本地推理就想到 vLLM确实 vLLM 的吞吐量在高并发场景下很能打PagedAttention 那套显存管理机制不是盖的。但问题是vLLM 对硬件要求高部署复杂度也高你得配 CUDA 环境、编译依赖、调 tensor parallel对个人开发者来说门槛偏高。Ollama 走的是另一条路开箱即用。它内置了模型量化、GPU 加速、模型管理一条ollama run就能跑起来。对于个人知识库这种低并发场景Ollama 完全够用而且它默认暴露 OpenAI 兼容的 API 接口Dify 可以直接对接省掉大量适配工作。我实测下来同一台机器上跑 DeepSeek-R1 的 7B 量化版本Ollama 的响应速度在日常问答场景下完全可接受首 token 延迟大概 1 到 2 秒后续生成速度在 15 到 25 token/s 之间。这个数据对于个人使用绰绰有余。2.2 知识库为什么选 Dify知识库这块可选方案很多FastGPT、RAGFlow、AnythingLLM、Dify 都能做。我最终选 Dify 的原因有三个第一它的 RAG 流水线是可视化的文档解析、分段、向量化、检索、重排每一步都能看到出问题好排查。第二它支持的知识库格式很全PDF、Word、Markdown、TXT、HTML 都能吃甚至可以直接同步网页内容。第三它对模型接入很友好Ollama 的 API 地址填进去就能用不需要写代码。RAGFlow 的解析能力确实更强尤其是对复杂 PDF 表格的处理但它的部署更重对机器要求也更高。如果你只是做个人知识库Dify 的性价比更高。2.3 整体架构长什么样整套系统的数据流是这样的你的文档先上传到 DifyDify 调用嵌入模型把文档切片转成向量存进向量数据库。当你提问时Dify 先把问题转成向量去向量库里检索最相关的几个片段然后把片段和问题一起拼成 prompt发给 Ollama 上的 DeepSeek 模型模型生成答案返回。这里有两个模型在干活一个是嵌入模型负责把文本转成向量一个是生成模型负责回答问题。嵌入模型可以用 Ollama 上的nomic-embed-text或者bge-m3生成模型就是 DeepSeek。两者都跑在 Ollama 上统一管理。提示嵌入模型和生成模型可以跑在同一台 Ollama 上但如果你的机器显存紧张建议嵌入模型用 CPU 跑生成模型用 GPU 跑避免显存争抢。3. 环境准备与 Ollama 部署实操3.1 硬件和系统的最低要求先说底线配置不然装到一半发现跑不动就尴尬了。DeepSeek-R1 的 7B 量化版本最低需要 8GB 显存或者 16GB 内存纯 CPU 推理。如果想跑 14B 版本建议 16GB 显存起步。32B 版本就别想了除非你有 24GB 以上的显存。系统方面Windows、macOS、Linux 都支持。Windows 建议 Win10 以上macOS 建议 M 系列芯片Linux 推荐 Ubuntu 20.04 以上。我自己的测试机是 Ubuntu 22.04 RTX 3060 12GB跑 7B 模型很流畅。磁盘空间要留够Ollama 的模型文件默认存在用户目录下一个 7B 量化模型大概 4 到 5GB加上 Dify 的 Docker 镜像和向量数据建议至少留 50GB 空闲空间。3.2 Ollama 安装与国内加速Ollama 的安装本身很简单Linux 下一条命令curl -fsSL https://ollama.com/install.sh | sh但问题在于模型下载走的是官方源国内下载速度可能很慢甚至卡住不动。这是第一个高频报错点。解决办法是配置国内镜像源。Ollama 支持通过环境变量指定模型下载地址你可以在启动服务前设置export OLLAMA_HOST0.0.0.0 export OLLAMA_MODELS/data/ollama/models把模型存储路径改到大盘上避免系统盘被撑爆。然后拉取模型时如果官方源太慢可以手动下载模型文件放到对应目录。Ollama 的模型文件格式是 GGUF你可以在模型社区找到对应的量化版本下载后放到~/.ollama/models/blobs目录下再通过 Modelfile 导入。我实测下来用国内镜像源拉取deepseek-r1:7b速度能从几十 KB/s 提升到几 MB/s差距非常明显。3.3 拉取 DeepSeek 模型并验证模型拉取命令ollama pull deepseek-r1:7b拉完之后验证一下ollama run deepseek-r1:7b如果能进入交互界面输入“你好”能正常回复说明模型跑通了。这时候 Ollama 默认在11434端口暴露了 API你可以用 curl 测试curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 介绍一下你自己 }返回 JSON 就说明 API 正常。这一步很关键因为后面 Dify 就是通过这个 API 来调用模型的。注意如果你修改了 Ollama 的监听地址为0.0.0.0记得检查防火墙规则避免端口暴露到公网。本地使用的话保持127.0.0.1更安全。3.4 嵌入模型的准备知识库需要嵌入模型来做向量化Ollama 上可以直接拉ollama pull nomic-embed-text这个模型体积小跑起来快适合做嵌入。如果你对中文检索效果要求更高可以换bge-m3它对中文的语义理解更好但体积也更大。拉完之后同样验证一下curl http://localhost:11434/api/embeddings -d { model: nomic-embed-text, prompt: 测试文本 }返回一个向量数组就说明正常。4. Dify 部署与知识库流水线搭建4.1 Docker 部署 Dify 的完整步骤Dify 官方推荐用 Docker Compose 部署先把仓库克隆下来git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env然后启动docker compose up -d启动完成后访问http://localhost:3000第一次进入会让你设置管理员账号。这里有个坑Dify 默认会启动好几个容器包括 API、Worker、Web、PostgreSQL、Redis、Weaviate 等如果你的机器内存不够可能会启动失败。建议至少给 Docker 分配 8GB 内存。启动后检查容器状态docker compose ps所有容器都是running状态才算正常。如果有容器反复重启用docker compose logs [容器名]看日志排查。4.2 接入 Ollama 模型进入 Dify 后台点击右上角头像进入“设置” - “模型供应商”找到 Ollama点击“添加模型”。这里需要填两个关键信息模型名称和基础 URL。模型名称填deepseek-r1:7b基础 URL 填http://host.docker.internal:11434。注意如果你是在 Linux 上跑 Dockerhost.docker.internal可能不生效需要换成宿主机的实际 IP比如http://172.17.0.1:11434。填完之后点“保存”Dify 会自动测试连接。如果提示连接失败大概率是网络不通检查一下 Ollama 是否监听在0.0.0.0以及防火墙是否放行。嵌入模型同理在 Ollama 供应商下再添加一个nomic-embed-text类型选“Text Embedding”。4.3 创建知识库并上传文档回到 Dify 主界面点击“知识库” - “创建知识库”输入名称选择嵌入模型为刚才添加的nomic-embed-text。然后上传文档。Dify 支持批量上传PDF、Word、Markdown、TXT 都能吃。上传后进入分段设置这里有几个参数需要调分段标识符默认是\n\n也就是按空行分段。如果你的文档结构比较规整可以改成按标题分段。分段最大长度默认 500 字符建议改成 800 到 1000太短会导致语义不完整太长会稀释检索精度。分段重叠长度默认 50建议改成 100 到 150避免段落边界处的信息丢失。设置完成后点“保存并处理”Dify 会开始解析文档、分段、向量化。这个过程耗时取决于文档数量和机器性能一般几十页的文档几分钟就能处理完。4.4 测试检索效果知识库建好后先别急着接应用先在知识库的“召回测试”里验证一下。输入一个你文档里明确有答案的问题看看能不能召回相关片段。如果召回结果为空或者召回的片段跟问题不相关说明分段或嵌入模型有问题。这时候可以调整分段长度或者换一个嵌入模型再试。我踩过的一个坑是文档里有大量表格按默认分段切完之后表格内容被切得七零八落检索效果很差。后来改成按标题分段并且把表格单独转成 Markdown 格式再上传效果就好了很多。5. 三个高频报错的排查与解决5.1 报错一模型下载卡住或速度极慢这是最常见的问题表现为ollama pull命令执行后进度条长时间不动或者速度只有几十 KB/s。原因很直接Ollama 默认从官方源拉取模型国内网络访问不稳定。解决办法有三个第一配置国内镜像源。在启动 Ollama 前设置环境变量指向国内的模型镜像地址。具体地址可以在技术社区找到最新的可用源。第二手动下载 GGUF 文件。去模型社区找到对应的量化版本用下载工具拉下来然后通过 Modelfile 导入echo FROM ./deepseek-r1-7b-q4.gguf Modelfile ollama create deepseek-r1:7b -f Modelfile第三如果只是临时用一下可以先用小模型测试流程比如qwen2:1.5b体积小下载快等流程跑通了再换大模型。提示手动下载 GGUF 文件时注意选择正确的量化版本。Q4_K_M 是性价比最高的选择Q5 和 Q8 精度更高但体积也更大Q2 和 Q3 体积小但精度损失明显。5.2 报错二Dify 连接 Ollama 失败这个报错通常表现为在 Dify 里添加 Ollama 模型时提示“连接失败”或“模型不可用”。排查思路分三步第一步确认 Ollama 服务是否正常运行。在宿主机上执行curl http://localhost:11434/api/tags如果能返回模型列表说明 Ollama 本身没问题。第二步确认 Docker 容器能否访问宿主机。进入 Dify 的 API 容器docker exec -it docker-api-1 bash curl http://host.docker.internal:11434/api/tags如果这里不通说明是网络问题。Linux 下host.docker.internal默认不解析需要在docker-compose.yml里给 API 容器加一行extra_hosts: - host.docker.internal:host-gateway然后重启容器。第三步确认 Ollama 监听地址。默认 Ollama 只监听127.0.0.1Docker 容器访问不到。需要改成0.0.0.0export OLLAMA_HOST0.0.0.0然后重启 Ollama 服务。5.3 报错三知识库检索返回空结果这个报错最隐蔽因为流程看起来都正常但提问时模型回答“我不知道”或者返回无关内容。原因通常有三个一是嵌入模型没配对。检查知识库使用的嵌入模型和查询时使用的嵌入模型是否一致。如果建库时用的是nomic-embed-text查询时也必须用同一个不能混用。二是分段设置不合理。如果分段太长一个片段里包含多个主题检索时向量会被稀释导致匹配不准。如果分段太短语义不完整也会影响检索。建议分段长度在 800 到 1000 字符之间重叠 100 到 150 字符。三是向量数据库没索引成功。在 Dify 的知识库页面查看文档状态如果显示“处理中”或“失败”说明向量化没完成。这时候可以重新处理文档或者检查 Docker 日志看有没有报错。我遇到过一次文档上传后一直卡在“排队中”后来发现是 Worker 容器挂了。重启 Worker 容器后重新处理就好了。5.4 常见问题速查表问题现象可能原因解决方法模型下载卡住官方源网络不稳定配置国内镜像源或手动下载 GGUFDify 连接 Ollama 失败监听地址或网络不通改 Ollama 监听为 0.0.0.0加 extra_hosts知识库检索为空嵌入模型不一致或分段不合理统一嵌入模型调整分段长度文档一直排队中Worker 容器异常重启 Worker 容器重新处理文档模型回复慢显存不足或模型太大换小模型或量化版本关闭其他占显存程序Docker 启动失败内存不足给 Docker 分配至少 8GB 内存6. 实操心得与性能调优建议6.1 模型选择上的取舍DeepSeek 系列有多个尺寸7B、14B、32B 都有。我的建议是先用 7B 跑通流程确认整条链路没问题再根据实际效果决定要不要换更大的模型。7B 模型在知识库问答场景下只要检索质量过关回答质量是够用的。14B 在复杂推理上明显更好但显存占用翻倍。32B 除非你有专业卡否则别碰。另外DeepSeek-R1 系列有“思考过程”的输出有时候会显得啰嗦。如果你不需要看推理过程可以在 prompt 里加一句“直接给出答案不要展示推理过程”能省不少 token。6.2 知识库分段的经验值分段这件事没有万能参数但有几个经验值可以参考技术文档分段 800 到 1000 字符重叠 100 字符按标题分段效果最好。法律条文分段 500 到 800 字符重叠 150 字符因为条文之间关联性强重叠多一点能保留上下文。会议纪要分段 300 到 500 字符重叠 50 字符因为纪要本身比较碎分段小一点更精准。表格数据建议先转成 Markdown 再上传分段按行分每行一个片段。我试过把一份 200 页的产品手册按默认参数上传检索效果很差后来改成按章节标题分段召回准确率明显提升。6.3 显存不够怎么办如果显存不够有几个办法可以缓解第一用更小的量化版本。Q4_K_M 比 Q8 省一半显存精度损失在可接受范围内。第二把嵌入模型放到 CPU 上跑。嵌入模型计算量小CPU 跑完全没问题能省出显存给生成模型。第三限制并发数。Ollama 默认允许并行处理多个请求显存不够时会 OOM。可以通过环境变量OLLAMA_NUM_PARALLEL1限制为单请求。第四如果实在跑不动可以考虑用 API 替代本地模型。DeepSeek 官方 API 价格不贵知识库部分仍然本地跑这样既能保证数据安全又能降低硬件门槛。6.4 数据备份与迁移知识库建好之后记得定期备份。Dify 的数据存在 PostgreSQL 和向量数据库里直接备份 Docker 卷就行docker compose down tar -czvf dify-backup.tar.gz ./volumes docker compose up -d模型文件在~/.ollama/models目录下也可以直接打包迁移到另一台机器。迁移后记得修改 Ollama 的模型路径配置指向新位置。7. 后续扩展方向这套本地知识库跑通之后能扩展的方向很多。比如接入微信公众号文章用 Dify 的网页同步功能定期抓取比如把知识库接到企业微信或飞书机器人上做成内部问答助手比如用 Dify 的工作流功能把知识库检索和外部 API 调用串起来做更复杂的业务逻辑。我个人比较看好的一个方向是“多知识库路由”。Dify 支持创建多个知识库你可以按业务线拆分然后在应用里根据问题类型自动路由到对应的知识库。这样检索范围更小准确率更高。另一个方向是结合重排序模型。Dify 支持接入重排序模型在向量检索之后再做一次精排能显著提升召回质量。Ollama 上有bge-reranker可以用配置也不复杂值得一试。最后再分享一个小技巧如果你的文档更新频繁建议开启 Dify 的“自动同步”功能把知识库和文档源绑定这样文档改了之后知识库会自动更新不用手动重新上传。这个功能在团队协作场景下特别实用。