简介面向希望摆脱云端依赖、实现AI知识库本地化部署的技术爱好者与开发者这份资源以DeepSeek与Dify为核心提供一套低门槛的完整落地指引解决大模型环境配置繁琐、部署链路不清晰等常见问题。压缩包内为1个PDF文件共1.47MB以图文笔记形式分步呈现关键操作界面与命令便于对照实操。目前已有2338人学习适合对Ollama、Docker、Dify等工具链缺乏系统认知的初学者。PDF内容从Windows 11系统环境变量设置切入依次覆盖Ollama安装、DeepSeek-R1及bge-m3模型拉取、Docker Desktop配置、Dify源码部署与参数调整直至本地地址访问、模型接入和知识库创建并完整演示了从上传文本到配置向量检索、再到与聊天助手对话的全流程。读者可借此建立起本地大模型知识库的完整实施路径显著降低试错成本快速搭建起可离线使用的AI知识库应用。1. DeepSeek Dify 本地部署知识库为什么数据不出内网RAG 依然能跑把 DeepSeek 和 Dify 都部署到本地再挂一个知识库——这套 DeepSeek Dify 本地部署知识库的组合是我见过性价比最高的私有大模型落地路径。这个方案的核心诉求很直接模型权重在本地跑文档切片和向量也全在本地处理不依赖外部 API同时又能借助 Dify 把上传、分段、召回、对话串成一条完整流水线。适合三类人有数据合规要求的企业内部 IT、做私有化交付的集成商、以及想在本地捣鼓 RAG 的开发者。反直觉的一点是门槛比想象低一台 16G 显存的机器就能跑通真正浪费时间的不是部署是后面那些看似没技术含量的配置和调优。2. 部署前先定三件事模型路线、Dify 架构与向量库选型2.1 模型选型Ollama、vLLM 还是 llama.cpp做本地部署大语言模型第一步不是装软件而是选模型分发路线。我见过太多人一上来就拉镜像、起容器最后卡在显存上。先把三条最常见的路线说清楚。Ollama 适合单机、小显存、快速验证。它把模型权重打包成 GGUF 格式自动处理 KV cache 量化和上下文管理一条命令就能把 DeepSeek 的蒸馏版模型跑起来。缺点是并发吞吐一般多路聊天和频繁调用时排队会比较明显。vLLM 适合显存 24G 以上、或者有多卡的生产环境。它做 PagedAttention吞吐量明显高于 Ollama且自带 OpenAI 兼容 API。坏处是配置重Python 环境、CUDA 版本都得自己维护。如果你以后要对外做私有化交付建议一开始就选 vLLM。llama.cpp 是 CPU 友好路线量化比特可以压得很低老机器、无独显的服务器也能跑但推理服务要自己处理并发和接口封装工程量大。个人建议先用 Ollama 把链路跑通等并发上来了再平移 vLLM。两者都暴露 OpenAI 兼容接口Dify 那边只需改一个 Base URL迁移成本很低。对比项OllamavLLMllama.cpp上手难度低中高中显存建议6G 起24G 起可无独显并发吞吐中高低OpenAI 兼容 API原生原生需自行封装适合场景本地验证、个人办公生产、私有化交付老旧设备、边缘机器显存预期按常见配置给一个参考8G 显存能跑 7B 蒸馏版的 Q4 量化模型本体约 4.7GB推理时留出 KV cache 余量刚好16G 显存可以跑 14B32G 可以尝试 32B。注意 Ollama 里的 DeepSeek 是官方蒸馏版不是 671B 的原始 V3/R1名字一般是 deepseek-r1:7b 或 deepseek-r1:14b。原始 671B 权重几百 GB个人机器不用考虑。选型还要考虑一层知识库的 embedding 模型也要占显存。如果把 embedding 和 LLM 放在同一张卡上记得给 embedding 留 12G 余量否则模型加载会失败。这个小细节很多人忽略等到文档批量上传时才发现排队排到天荒地老。2.2 Dify 的部署形态与资源预期Dify 本质是一个开源知识库与 LLM 应用编排平台。用 docker compose 拉起来后你会发现它是一个全家桶前端 web、API 服务、worker 异步任务、nginx、PostgreSQL、Redis还有向量数据库。每个组件各司其职缺一个知识库流程就跑不通。这里先建立一个完整的数据链认知文档上传后worker 负责解析和分段然后调用 embedding 模型生成向量写入向量库用户提问时API 服务先把问题向量化从向量库里召回相关分段拼进 prompt再调用本地 DeepSeek 生成答案。Dify 的知识库流水线说的就是这条链。资源预期方面如果模型推理也在这台机器上要把显存和内存合并计算。16G 显存加 32G 内存的机器跑起来比较舒服纯 CPU 跑 7B 不是不行但要接受每 token 几十毫秒以上的速度体验很差。如果分开部署Dify 主机 8 核 16G 内存就够了。我一般会把 LLM 推理服务和 Dify 分开带 GPU 的机器跑 Ollama 或 vLLM普通服务器跑 Dify中间用内网地址互通。这样做的好处是扩并发时只动推理机器不用动整个 Dify 全家桶。条件不允许时也可以放一台机器但优先保证显存不被 web 前端、后台任务抢走。2.3 向量库与 embedding 模型中文文档怎么选Dify 官方 docker compose 中默认带的是 Weaviate想换 Qdrant 可以在 .env 里改 VECTOR_STORE 配置。选型依据不复杂数据量在几万条分段以内Weaviate 够用有地理检索需求或者想要更丰富的过滤能力可以上 Qdrant如果团队本来就统一用 PostgreSQLpgvector 也是一个省事的选项。embedding 模型才是影响召回质量的关键。中文场景我推荐 bge 系列比如 bge-m3 或 bge-small-zh-v1.5它们可以通过 Ollama 的 embedding 接口接入 Dify。英文为主的文档可以用 nomic-embed-text 之类但如果文档里中英混杂bge-m3 的多语言效果更稳。这个环节省不得embedding 差后面检索结果一定差。索引方式也要现在定Dify 数据集里的高质量模式会为每个分段生成向量并保留全文索引支持混合检索经济模式只做关键词匹配不生成向量省资源但召回明显变差。本地只要显存不算太紧一律选高质量。检索时FAQ 型文档适合用混合检索向量召回语义相似、全文召回精确匹配长报告型文档以向量检索为主。现在还有一个小点容易忽略RAG 知识库能存储图片吗能存但图片本身不参与向量匹配除非你的 embedding 模型支持多模态。本地部署的 bge 系列是纯文本模型所以图片要么不放要么配一段足够详细的文字说明让说明文本承担检索任务。这一点先记住后面传文档时用得上。3. 用 Ollama 在本地跑起 DeepSeek最小命令与三个必调参数3.1 安装 Ollama 并拉取 DeepSeek 模型安装 Ollama 非常简单macOS 和 Windows 都可以直接下载安装包Linux 用官方脚本一行装完。装好之后拉模型、起服务、验证推理三条命令就能走完最小链路。# 1. 安装Linux / macOS 通用脚本Windows 请下载安装包 curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取 DeepSeek 7B 蒸馏版约 4.7GBQ4 量化 ollama pull deepseek-r1:7b # 3. 确认本地模型列表记下准确的模型名和 tag ollama list # 4. 交互式验证问一句话能正常回答就说明模型可用输入 /bye 退出 ollama run deepseek-r1:7b 你好用一句话介绍你自己这段命令的逻辑是先把模型权重落到本地再用交互模式做冒烟测试。ollama list 很重要Dify 配置供应商时填写的模型名必须以这里的输出为准很多人随手写成 deepseek-r1 结果匹配不上。ollama run 进入交互会话后第一次提问会有一段加载时间这是正常的模型要先把权重读进显存。参数说明deepseek-r1:7b 是 DeepSeek-R1-Distill-Qwen-7B 的 Q4 量化版跑在 8G 显存的机器上刚好。如果你的显存只有 6G可以换 deepseek-r1:1.5b显存 16G 可以上 14b。模型不是越大越好知识库问答场景里7B 配合好的检索效果比 32B 配合烂检索更实用。3.2 让模型服务常驻并发、加载数与驻留时间的三个参数ollama run 是前台交互模式Dify 需要的是一个长期在后台服务的接口。这里要执行 ollama serve让 Ollama 监听 11434 端口并提供 OpenAI 兼容 API。Ollama 默认只监听 127.0.0.1Dify 如果是用 Docker 部署的容器里访问不到宿主机的 localhost必须把监听地址放开。同时还要调整三个环境变量否则知识库用起来会频繁排队。# 推荐写入 systemd 服务文件的 Environment 字段或写入 shell profile export OLLAMA_HOST0.0.0.0:11434 # 允许局域网和 Docker 容器访问 export OLLAMA_NUM_PARALLEL2 # 同时处理的请求数8G 显存建议 1-224G 可以开 4 export OLLAMA_MAX_LOADED_MODELS2 # 最多同时驻留几个模型LLM embedding 至少 2 export OLLAMA_KEEP_ALIVE30m # 模型驻留时间频繁问答时不要用默认 5m # 启动服务前台观察日志确认无报错后可按需系统化 ollama serve这几个参数是本地知识库能否顺畅运行的关键。OLLAMA_NUM_PARALLEL 开大了会爆显存现象是请求返回 llama runner process has terminated开小了多人同时问答会排队。OLLAMA_MAX_LOADED_MODELS 至少要 2因为后面还要加载 bge-m3 这类 embedding 模型如果设成 1LLM 和 embedding 会互相挤掉每次调用都重新加载模型延迟翻倍。OLLAMA_KEEP_ALIVE 设成 30m 到 1h 之间避免频繁加载卸载模型。macOS 上如果用 launchctl 管理 Ollama需要去 plist 里改 EnvironmentVariablesLinux 上如果用了 systemd改 /etc/systemd/system/ollama.service 后要 systemctl daemon-reload 再重启。参数写错位置不生效这是新手最常见的问题之一。3.3 用 curl 验证 OpenAI 兼容接口Dify 接入 Ollama 之前先手动调一次接口确认链路是通的。Ollama 自带 OpenAI 兼容的 /v1/chat/completions 和 /v1/embeddings这一步能提前暴露九成以上的配置问题。# 验证聊天接口 curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 什么是 RAG}], stream: false } # 验证 embedding 接口bge-m3 需要先 pull ollama pull bge-m3 curl http://localhost:11434/v1/embeddings \ -H Content-Type: application/json \ -d {model: bge-m3, input: 知识库测试}聊天接口返回 choices 数组里带 content 字段说明 DeepSeek 推理正常embedding 接口返回一个 1024 维的向量数组说明向量能力可用。这两条命令我在每次部署时都会先跑一遍避免后面 Dify 报错时还要来回猜。这里也顺便回答一个高频问题DeepSeek API 如何调用本地部署之后调用入口就是这个 11434 端口的兼容接口所有支持 OpenAI 格式的上层应用都可以直接对接。区别只是 API key 随便填一个非空字符串因为本地服务不校验。后面 Dify 走 Docker 容器访问宿主机时URL 要把 localhost 换成 host.docker.internal这一点到第 4 章配置时会再碰到。4. 部署 Dify 并接入 DeepSeek从 Docker Compose 到首个知识库应用4.1 用 Docker Compose 启动 Dify 全家桶Dify 官方仓库自带 docker 编排文件clone 下来改一改 .env 就能起。整个编排里包含 api、worker、web、nginx、PostgreSQL、Redis 和向量数据库启动后是一个完整体系不是单容器。# 拉取代码注意当前目录建议单独建一个 dify 目录 git clone https://github.com/langgenius/dify.git cd dify/docker # 从模板复制环境变量文件首次部署必须做这一步 cp .env.example .env # 启动全部容器首次会拉取镜像耗时较长 docker compose up -d # 查看组件状态STATUS 为 Up 才算正常 docker compose ps这段操作里cp .env.example .env 是最容易被跳过的步骤跳过之后 docker compose 会因为缺少环境变量直接报错。docker compose ps 输出里如果某个容器反复 Restarting先别急着重装用 docker compose logs 容器名 看日志定位。Dify 默认通过 80 端口对外提供页面第一次访问 http://你的服务器IP/install 会进入初始化向导让你设置管理员邮箱和密码。如果宿主机 80 端口已被占用编辑 .env 里的 EXPOSE_NGINX_PORT8080然后重新 docker compose up -d --force-recreate 生效。改 .env 之前建议先备份一份cp .env .env.bak这就是你的后悔药防止改乱了回不去。4.2 把 DeepSeek 和 embedding 模型配置成供应商Dify 管理后台左侧菜单进入设置 → 模型供应商找到 Ollama 类型添加两个模型一个 LLM 用于对话一个 Embedding 用于知识库向量化。配置项LLM 填法Embedding 填法模型类型LLMEmbedding模型名称deepseek-r1:7b必须与 ollama list 一致bge-m3Base URLhttp://host.docker.internal:11434http://host.docker.internal:11434上下文长度4096按实际模型能力填不填API Key任意非空字符串任意非空字符串关键点是 Base URL 不能写 localhostDify 的 API 容器和 worker 容器都是独立网络命名空间localhost 指向容器自己访问不到宿主机。Docker 提供 host.docker.internal 这个特殊域名指向宿主机所以要用它。如果你不是用 Docker 而是直接在宿主机跑 Dify这里才能写 http://localhost:11434。填完点击测试如果报 An error occurred during credentials validation不要先怀疑 Dify回到第 3 章的 curl 命令确认宿主机上接口是否正常、模型名是否一致、URL 是否多了或少了斜杠。这个错误在社区里出现频率极高九成以上是 URL 或者模型名拼写问题。提示本地方案没有密钥验证API Key 填任意非空字符串即可不要把云端服务的密钥概念带进来。4.3 创建首个知识库分段、索引与召回参数模型供应商配置好之后就可以创建知识库了。Dify 里操作路径是知识库 → 创建知识库 → 上传文档 → 设置分段与索引 → 保存。这一步的参数直接决定问答效果值得花半小时逐项调。配置项推荐值说明分段方式自定义分隔符中文文档用默认空行分段经常一段几千字必须改自定义分隔符。换行按句子边界断段语义更完整最大分段长度500 tokens太长召回噪声大太短上下文碎片多分段重叠50 tokens防止跨段语义被切断索引方式高质量同时建向量和全文索引支持混合检索召回设置 TopK35分段越多TopK 越小Score 阈值0.40.5低于阈值的段落不进入上下文检索方式混合检索FAQ 与长文档兼顾上传时要注意Dify 的解析器对纯文本 Markdown 和 Word 文档支持较好扫描版 PDF 直接传进来很可能乱码。我的习惯是先对 PDF 做一次解析转换把内容整理成干净的 Markdown 再上传。Dify 知识库能存储图片但图片不参与向量匹配如果你必须放图请在图旁边写详细的文字描述。批量导入场景下也可以走 API。常见做法是先创建数据集再逐个上传文档文件import requests # 在 Dify 的 API 访问页面创建密钥后替换下面的 token headers {Authorization: Bearer dataset-xxx} # 1. 创建数据集high_quality 对应网页端的“高质量”索引 r requests.post(http://your-dify-host/v1/datasets, json{name: 运维手册, indexing_technique: high_quality, permission: only_me}, headersheaders) dataset_id r.json()[id] # 2. 按文件创建文档Dify 会异步解析并完成分段、向量化 with open(runbook.md, rb) as f: r requests.post( fhttp://your-dify-host/v1/datasets/{dataset_id}/document/create_by_file, data{name: runbook.md}, files{file: f}, headersheaders, ) print(r.status_code, r.text)这段 Python 的作用是把本地文档批量灌入知识库适合做成定时同步脚本。要注意 authorization 的密钥去 Dify 后台 API 访问页面生成不同版本菜单名略有差异上传后文档状态是排队中异步完成如果一直排队请直接看第 5 章避坑。对大多数团队来说网页端上传已经够用API 的价值是在持续更新的文档体系里做自动化流水线。4.4 在应用编排中把知识库接进对话并防上下文超长知识库建好后还差最后一步创建一个对话应用把知识检索节点接到 LLM 节点上。操作路径是应用 → 创建应用 → Chatbot → 进入编排 → 添加知识检索节点 → 选择刚建的数据集 → 连到 LLM 节点。这里最容易翻车的是上下文超长。Dify 工作流里知识检索节点会把命中的分段作为上下文传给 LLM 节点如果 TopK 设了 5、每个分段 500 tokens再加对话历史、系统提示词一次请求很容易超过本地模型的上下文窗口。7B 蒸馏模型的可用上下文有限超长后请求直接失败。解法有两层第一层在知识检索节点把 TopK 降到 3Score 阈值调高到 0.45 左右让更少但更相关的分段进入 prompt第二层在 LLM 节点把上下文变量用文本处理节点截断或者限制输出最大 token 数。还有一个长期方案是给对话历史加压缩节点把早期消息摘要后再拼接适合长会话场景。记住一句话本地模型上下文窗口小不是缺陷把进入 prompt 的内容当成稀缺资源来管理就对了。5. 避坑DeepSeek Dify 本地部署的 5 个高频翻车点这一章写的是我自己踩过、也在群里反复出现的血泪经验。每条按现象 → 原因 → 解决的顺序讲排查时可以直接对照。5.1 Dify 报 An error occurred during credentials validation现象在模型供应商页面点击测试Dify 直接报这个错模型一个都连不上。原因九成是 Base URL 写错或模型名不匹配。常见错误包括写了 localhost 而不是 host.docker.internal、URL 漏了 http:// 前缀、模型名写成 deepseek-r1 而 ollama list 里实际是 deepseek-r1:7b。还有很小一部分是 Ollama 服务根本没起来。解决先在宿主机执行 curl http://localhost:11434/v1/chat/completions 确认接口通再进 Dify 把 Base URL 改成 http://host.docker.internal:11434模型名严格复制 ollama list 的输出。如果走的是 OpenAI-API-compatible 供应商而不是 Ollama 类型API Key 填任意非空字符串即可本地不校验。这条排查顺序固定下来以后遇到供应商测试失败半小时内能解决。5.2 知识库文档一直排队中状态卡住现象上传文档后数据集里文档状态长时间停在排队中既不报错也不完成。原因文档解析和向量化由 worker 容器异步执行排队中说明 worker 没有拿到任务或者根本处理不过来。常见触发点有三个embedding 模型没配好、worker 容器挂了、单文档太大导致分段任务太多。解决先 docker compose ps 确认 worker 容器是 Up再用 docker compose logs worker -f 看日志。如果是 embedding 调用报错回到模型供应商页面把 embedding 模型修好如果日志里显示一条条分段在慢慢处理那就是 CPU 推理太慢把文档拆小、关掉其他占显存的任务或者换一个更轻量的 embedding 模型比如 bge-small-zh-v1.5。提示修改 embedding 模型或分段设置后旧数据集不会自动重建需要删除重建否则改动不生效。5.3 对话上下文超长请求直接失败现象知识库能正常检索但一问长问题或连续对话几轮就报上下文超长Dify 工作流节点直接变红。原因知识检索节点返回的分段数量多、每段又长加上对话历史累积超出了本地模型上下文窗口。Dify 默认不会帮你自动裁剪超了就是硬失败。解决从源头控制知识检索节点的 TopK 和 Score 阈值把分段长度从 800 降到 500 以下在 LLM 节点设置最大输出 token并给 prompt 设计明确的只依据知识库内容回答约束。长对话场景建议在合适的地方插入历史消息压缩节点而不是让所有历史一直堆着。排查时有个技巧把 LLM 节点入参在日志里打出来看看实际拼了多少 token比瞎调参数高效得多。5.4 PDF 解析乱码、表格和扫描件召回差现象传进去的 PDF 问起来答非所问或者干脆乱码表格里的数据完全召不回。原因Dify 内置解析器对文本型 PDF 支持尚可但扫描件、带复杂表格的 PDF 基本无能为力。扫描件本质是图片不 OCR 直接解析当然出来一堆乱码表格转成文本后丢失行列关系检索时自然找不到对应字段。解决先把 PDF 用专业工具转成 Markdown 再上传。我常在本机跑一个 MinerU 做解析把扫描件、公式、表格一并转成干净的 Markdown然后传这个 Markdown 进 Dify分段效果明显变好。日常办公文档里Word 和 Markdown 格式的解析最省心PDF 能转就先转转不了的就要接受它的召回上限。5.5 重启后服务起不来或访问页面报证书错误现象改了 .env 重启 Dify几个容器反复重启或者浏览器访问页面时提示证书错误。原因端口冲突、向量库数据卷异常、.env 配置被改坏是容器起不来的三大原因。证书错误则常见于容器系统时间与宿主机不同步或反向代理证书链不完整。解决先 docker compose ps 看哪个容器不是 Up再用 docker compose logs 容器名 看具体报错。端口冲突就把 EXPOSE_NGINX_PORT 改掉然后 --force-recreate向量库数据卷异常时备份卷后重建对应的数据库服务证书问题先检查服务器时间date -R时间偏差大会导致证书校验失败同步时间后再刷新页面。这里还要说一句改 .env 后必须 docker compose up -d --force-recreate光 restart 不一定生效很多人在这里反复重启都无效。6. 把知识库准确率提上去召回评估、内容源扩展与长期维护6.1 先建一个回归问题集再谈调优不要拿一两个 demo 问题验证完就上线。我的做法是从真实业务里挑 10 条问题整理成一个固定的回归问题集每次改动分段、embedding、检索参数后重新跑一遍对比。Dify 知识库页面的召回测试功能可以直接输入 query 看召回的 top5 分段这一步能直观判断检索是否相关。如果 top5 里相关的不足 3 条通常先换 embedding 或调分段而不是去调 prompt。判断相关的标准也简单看这段内容能不能直接支撑回答而不是看它和问题长得像不像。6.2 中文文档的分段规则值得单独打磨中文文档用默认空行分段效果很差因为中文段落长、空行少。自定义分隔符填 。 之后再配合 500 tokens 最大长度和 50 tokens 重叠召回质量会有肉眼可见的提升。这套参数调起来像玄学其实一半的问题出在分段上另一半才轮到 embedding。至于知识库能不能用在小模型上——能而且这是本地部署最实用的一条经验检索质量往往比模型参数更能决定回答下限。6.3 把公众号文章变成知识库的内容源团队文档里大量内容在公众号文章里。公众号没有开放的 API我常用的做法是先把文章正文复制到本地清理掉广告和无关导航存成 Markdown 再上传或者用正文提取工具把 URL 转成干净文本再走 API 导入。动态渲染的页面不要指望 Dify 内置的网页抓取能拿到正文抓回来往往是空的先落成本地文件是最省心的路径。我现在的习惯是每搭一个知识库先跑一遍那 10 条回归问题逐个看召回段落再调参数而不是拿着 demo 问题自嗨。本地 DeepSeek Dify 这条路7B 模型加 50 份文档起步已经足够验证价值先把链路跑通再谈扩量和优化。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek+Dify本地部署知识库：RAG实践与避坑指南
简介面向希望摆脱云端依赖、实现AI知识库本地化部署的技术爱好者与开发者这份资源以DeepSeek与Dify为核心提供一套低门槛的完整落地指引解决大模型环境配置繁琐、部署链路不清晰等常见问题。压缩包内为1个PDF文件共1.47MB以图文笔记形式分步呈现关键操作界面与命令便于对照实操。目前已有2338人学习适合对Ollama、Docker、Dify等工具链缺乏系统认知的初学者。PDF内容从Windows 11系统环境变量设置切入依次覆盖Ollama安装、DeepSeek-R1及bge-m3模型拉取、Docker Desktop配置、Dify源码部署与参数调整直至本地地址访问、模型接入和知识库创建并完整演示了从上传文本到配置向量检索、再到与聊天助手对话的全流程。读者可借此建立起本地大模型知识库的完整实施路径显著降低试错成本快速搭建起可离线使用的AI知识库应用。1. DeepSeek Dify 本地部署知识库为什么数据不出内网RAG 依然能跑把 DeepSeek 和 Dify 都部署到本地再挂一个知识库——这套 DeepSeek Dify 本地部署知识库的组合是我见过性价比最高的私有大模型落地路径。这个方案的核心诉求很直接模型权重在本地跑文档切片和向量也全在本地处理不依赖外部 API同时又能借助 Dify 把上传、分段、召回、对话串成一条完整流水线。适合三类人有数据合规要求的企业内部 IT、做私有化交付的集成商、以及想在本地捣鼓 RAG 的开发者。反直觉的一点是门槛比想象低一台 16G 显存的机器就能跑通真正浪费时间的不是部署是后面那些看似没技术含量的配置和调优。2. 部署前先定三件事模型路线、Dify 架构与向量库选型2.1 模型选型Ollama、vLLM 还是 llama.cpp做本地部署大语言模型第一步不是装软件而是选模型分发路线。我见过太多人一上来就拉镜像、起容器最后卡在显存上。先把三条最常见的路线说清楚。Ollama 适合单机、小显存、快速验证。它把模型权重打包成 GGUF 格式自动处理 KV cache 量化和上下文管理一条命令就能把 DeepSeek 的蒸馏版模型跑起来。缺点是并发吞吐一般多路聊天和频繁调用时排队会比较明显。vLLM 适合显存 24G 以上、或者有多卡的生产环境。它做 PagedAttention吞吐量明显高于 Ollama且自带 OpenAI 兼容 API。坏处是配置重Python 环境、CUDA 版本都得自己维护。如果你以后要对外做私有化交付建议一开始就选 vLLM。llama.cpp 是 CPU 友好路线量化比特可以压得很低老机器、无独显的服务器也能跑但推理服务要自己处理并发和接口封装工程量大。个人建议先用 Ollama 把链路跑通等并发上来了再平移 vLLM。两者都暴露 OpenAI 兼容接口Dify 那边只需改一个 Base URL迁移成本很低。对比项OllamavLLMllama.cpp上手难度低中高中显存建议6G 起24G 起可无独显并发吞吐中高低OpenAI 兼容 API原生原生需自行封装适合场景本地验证、个人办公生产、私有化交付老旧设备、边缘机器显存预期按常见配置给一个参考8G 显存能跑 7B 蒸馏版的 Q4 量化模型本体约 4.7GB推理时留出 KV cache 余量刚好16G 显存可以跑 14B32G 可以尝试 32B。注意 Ollama 里的 DeepSeek 是官方蒸馏版不是 671B 的原始 V3/R1名字一般是 deepseek-r1:7b 或 deepseek-r1:14b。原始 671B 权重几百 GB个人机器不用考虑。选型还要考虑一层知识库的 embedding 模型也要占显存。如果把 embedding 和 LLM 放在同一张卡上记得给 embedding 留 12G 余量否则模型加载会失败。这个小细节很多人忽略等到文档批量上传时才发现排队排到天荒地老。2.2 Dify 的部署形态与资源预期Dify 本质是一个开源知识库与 LLM 应用编排平台。用 docker compose 拉起来后你会发现它是一个全家桶前端 web、API 服务、worker 异步任务、nginx、PostgreSQL、Redis还有向量数据库。每个组件各司其职缺一个知识库流程就跑不通。这里先建立一个完整的数据链认知文档上传后worker 负责解析和分段然后调用 embedding 模型生成向量写入向量库用户提问时API 服务先把问题向量化从向量库里召回相关分段拼进 prompt再调用本地 DeepSeek 生成答案。Dify 的知识库流水线说的就是这条链。资源预期方面如果模型推理也在这台机器上要把显存和内存合并计算。16G 显存加 32G 内存的机器跑起来比较舒服纯 CPU 跑 7B 不是不行但要接受每 token 几十毫秒以上的速度体验很差。如果分开部署Dify 主机 8 核 16G 内存就够了。我一般会把 LLM 推理服务和 Dify 分开带 GPU 的机器跑 Ollama 或 vLLM普通服务器跑 Dify中间用内网地址互通。这样做的好处是扩并发时只动推理机器不用动整个 Dify 全家桶。条件不允许时也可以放一台机器但优先保证显存不被 web 前端、后台任务抢走。2.3 向量库与 embedding 模型中文文档怎么选Dify 官方 docker compose 中默认带的是 Weaviate想换 Qdrant 可以在 .env 里改 VECTOR_STORE 配置。选型依据不复杂数据量在几万条分段以内Weaviate 够用有地理检索需求或者想要更丰富的过滤能力可以上 Qdrant如果团队本来就统一用 PostgreSQLpgvector 也是一个省事的选项。embedding 模型才是影响召回质量的关键。中文场景我推荐 bge 系列比如 bge-m3 或 bge-small-zh-v1.5它们可以通过 Ollama 的 embedding 接口接入 Dify。英文为主的文档可以用 nomic-embed-text 之类但如果文档里中英混杂bge-m3 的多语言效果更稳。这个环节省不得embedding 差后面检索结果一定差。索引方式也要现在定Dify 数据集里的高质量模式会为每个分段生成向量并保留全文索引支持混合检索经济模式只做关键词匹配不生成向量省资源但召回明显变差。本地只要显存不算太紧一律选高质量。检索时FAQ 型文档适合用混合检索向量召回语义相似、全文召回精确匹配长报告型文档以向量检索为主。现在还有一个小点容易忽略RAG 知识库能存储图片吗能存但图片本身不参与向量匹配除非你的 embedding 模型支持多模态。本地部署的 bge 系列是纯文本模型所以图片要么不放要么配一段足够详细的文字说明让说明文本承担检索任务。这一点先记住后面传文档时用得上。3. 用 Ollama 在本地跑起 DeepSeek最小命令与三个必调参数3.1 安装 Ollama 并拉取 DeepSeek 模型安装 Ollama 非常简单macOS 和 Windows 都可以直接下载安装包Linux 用官方脚本一行装完。装好之后拉模型、起服务、验证推理三条命令就能走完最小链路。# 1. 安装Linux / macOS 通用脚本Windows 请下载安装包 curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取 DeepSeek 7B 蒸馏版约 4.7GBQ4 量化 ollama pull deepseek-r1:7b # 3. 确认本地模型列表记下准确的模型名和 tag ollama list # 4. 交互式验证问一句话能正常回答就说明模型可用输入 /bye 退出 ollama run deepseek-r1:7b 你好用一句话介绍你自己这段命令的逻辑是先把模型权重落到本地再用交互模式做冒烟测试。ollama list 很重要Dify 配置供应商时填写的模型名必须以这里的输出为准很多人随手写成 deepseek-r1 结果匹配不上。ollama run 进入交互会话后第一次提问会有一段加载时间这是正常的模型要先把权重读进显存。参数说明deepseek-r1:7b 是 DeepSeek-R1-Distill-Qwen-7B 的 Q4 量化版跑在 8G 显存的机器上刚好。如果你的显存只有 6G可以换 deepseek-r1:1.5b显存 16G 可以上 14b。模型不是越大越好知识库问答场景里7B 配合好的检索效果比 32B 配合烂检索更实用。3.2 让模型服务常驻并发、加载数与驻留时间的三个参数ollama run 是前台交互模式Dify 需要的是一个长期在后台服务的接口。这里要执行 ollama serve让 Ollama 监听 11434 端口并提供 OpenAI 兼容 API。Ollama 默认只监听 127.0.0.1Dify 如果是用 Docker 部署的容器里访问不到宿主机的 localhost必须把监听地址放开。同时还要调整三个环境变量否则知识库用起来会频繁排队。# 推荐写入 systemd 服务文件的 Environment 字段或写入 shell profile export OLLAMA_HOST0.0.0.0:11434 # 允许局域网和 Docker 容器访问 export OLLAMA_NUM_PARALLEL2 # 同时处理的请求数8G 显存建议 1-224G 可以开 4 export OLLAMA_MAX_LOADED_MODELS2 # 最多同时驻留几个模型LLM embedding 至少 2 export OLLAMA_KEEP_ALIVE30m # 模型驻留时间频繁问答时不要用默认 5m # 启动服务前台观察日志确认无报错后可按需系统化 ollama serve这几个参数是本地知识库能否顺畅运行的关键。OLLAMA_NUM_PARALLEL 开大了会爆显存现象是请求返回 llama runner process has terminated开小了多人同时问答会排队。OLLAMA_MAX_LOADED_MODELS 至少要 2因为后面还要加载 bge-m3 这类 embedding 模型如果设成 1LLM 和 embedding 会互相挤掉每次调用都重新加载模型延迟翻倍。OLLAMA_KEEP_ALIVE 设成 30m 到 1h 之间避免频繁加载卸载模型。macOS 上如果用 launchctl 管理 Ollama需要去 plist 里改 EnvironmentVariablesLinux 上如果用了 systemd改 /etc/systemd/system/ollama.service 后要 systemctl daemon-reload 再重启。参数写错位置不生效这是新手最常见的问题之一。3.3 用 curl 验证 OpenAI 兼容接口Dify 接入 Ollama 之前先手动调一次接口确认链路是通的。Ollama 自带 OpenAI 兼容的 /v1/chat/completions 和 /v1/embeddings这一步能提前暴露九成以上的配置问题。# 验证聊天接口 curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 什么是 RAG}], stream: false } # 验证 embedding 接口bge-m3 需要先 pull ollama pull bge-m3 curl http://localhost:11434/v1/embeddings \ -H Content-Type: application/json \ -d {model: bge-m3, input: 知识库测试}聊天接口返回 choices 数组里带 content 字段说明 DeepSeek 推理正常embedding 接口返回一个 1024 维的向量数组说明向量能力可用。这两条命令我在每次部署时都会先跑一遍避免后面 Dify 报错时还要来回猜。这里也顺便回答一个高频问题DeepSeek API 如何调用本地部署之后调用入口就是这个 11434 端口的兼容接口所有支持 OpenAI 格式的上层应用都可以直接对接。区别只是 API key 随便填一个非空字符串因为本地服务不校验。后面 Dify 走 Docker 容器访问宿主机时URL 要把 localhost 换成 host.docker.internal这一点到第 4 章配置时会再碰到。4. 部署 Dify 并接入 DeepSeek从 Docker Compose 到首个知识库应用4.1 用 Docker Compose 启动 Dify 全家桶Dify 官方仓库自带 docker 编排文件clone 下来改一改 .env 就能起。整个编排里包含 api、worker、web、nginx、PostgreSQL、Redis 和向量数据库启动后是一个完整体系不是单容器。# 拉取代码注意当前目录建议单独建一个 dify 目录 git clone https://github.com/langgenius/dify.git cd dify/docker # 从模板复制环境变量文件首次部署必须做这一步 cp .env.example .env # 启动全部容器首次会拉取镜像耗时较长 docker compose up -d # 查看组件状态STATUS 为 Up 才算正常 docker compose ps这段操作里cp .env.example .env 是最容易被跳过的步骤跳过之后 docker compose 会因为缺少环境变量直接报错。docker compose ps 输出里如果某个容器反复 Restarting先别急着重装用 docker compose logs 容器名 看日志定位。Dify 默认通过 80 端口对外提供页面第一次访问 http://你的服务器IP/install 会进入初始化向导让你设置管理员邮箱和密码。如果宿主机 80 端口已被占用编辑 .env 里的 EXPOSE_NGINX_PORT8080然后重新 docker compose up -d --force-recreate 生效。改 .env 之前建议先备份一份cp .env .env.bak这就是你的后悔药防止改乱了回不去。4.2 把 DeepSeek 和 embedding 模型配置成供应商Dify 管理后台左侧菜单进入设置 → 模型供应商找到 Ollama 类型添加两个模型一个 LLM 用于对话一个 Embedding 用于知识库向量化。配置项LLM 填法Embedding 填法模型类型LLMEmbedding模型名称deepseek-r1:7b必须与 ollama list 一致bge-m3Base URLhttp://host.docker.internal:11434http://host.docker.internal:11434上下文长度4096按实际模型能力填不填API Key任意非空字符串任意非空字符串关键点是 Base URL 不能写 localhostDify 的 API 容器和 worker 容器都是独立网络命名空间localhost 指向容器自己访问不到宿主机。Docker 提供 host.docker.internal 这个特殊域名指向宿主机所以要用它。如果你不是用 Docker 而是直接在宿主机跑 Dify这里才能写 http://localhost:11434。填完点击测试如果报 An error occurred during credentials validation不要先怀疑 Dify回到第 3 章的 curl 命令确认宿主机上接口是否正常、模型名是否一致、URL 是否多了或少了斜杠。这个错误在社区里出现频率极高九成以上是 URL 或者模型名拼写问题。提示本地方案没有密钥验证API Key 填任意非空字符串即可不要把云端服务的密钥概念带进来。4.3 创建首个知识库分段、索引与召回参数模型供应商配置好之后就可以创建知识库了。Dify 里操作路径是知识库 → 创建知识库 → 上传文档 → 设置分段与索引 → 保存。这一步的参数直接决定问答效果值得花半小时逐项调。配置项推荐值说明分段方式自定义分隔符中文文档用默认空行分段经常一段几千字必须改自定义分隔符。换行按句子边界断段语义更完整最大分段长度500 tokens太长召回噪声大太短上下文碎片多分段重叠50 tokens防止跨段语义被切断索引方式高质量同时建向量和全文索引支持混合检索召回设置 TopK35分段越多TopK 越小Score 阈值0.40.5低于阈值的段落不进入上下文检索方式混合检索FAQ 与长文档兼顾上传时要注意Dify 的解析器对纯文本 Markdown 和 Word 文档支持较好扫描版 PDF 直接传进来很可能乱码。我的习惯是先对 PDF 做一次解析转换把内容整理成干净的 Markdown 再上传。Dify 知识库能存储图片但图片不参与向量匹配如果你必须放图请在图旁边写详细的文字描述。批量导入场景下也可以走 API。常见做法是先创建数据集再逐个上传文档文件import requests # 在 Dify 的 API 访问页面创建密钥后替换下面的 token headers {Authorization: Bearer dataset-xxx} # 1. 创建数据集high_quality 对应网页端的“高质量”索引 r requests.post(http://your-dify-host/v1/datasets, json{name: 运维手册, indexing_technique: high_quality, permission: only_me}, headersheaders) dataset_id r.json()[id] # 2. 按文件创建文档Dify 会异步解析并完成分段、向量化 with open(runbook.md, rb) as f: r requests.post( fhttp://your-dify-host/v1/datasets/{dataset_id}/document/create_by_file, data{name: runbook.md}, files{file: f}, headersheaders, ) print(r.status_code, r.text)这段 Python 的作用是把本地文档批量灌入知识库适合做成定时同步脚本。要注意 authorization 的密钥去 Dify 后台 API 访问页面生成不同版本菜单名略有差异上传后文档状态是排队中异步完成如果一直排队请直接看第 5 章避坑。对大多数团队来说网页端上传已经够用API 的价值是在持续更新的文档体系里做自动化流水线。4.4 在应用编排中把知识库接进对话并防上下文超长知识库建好后还差最后一步创建一个对话应用把知识检索节点接到 LLM 节点上。操作路径是应用 → 创建应用 → Chatbot → 进入编排 → 添加知识检索节点 → 选择刚建的数据集 → 连到 LLM 节点。这里最容易翻车的是上下文超长。Dify 工作流里知识检索节点会把命中的分段作为上下文传给 LLM 节点如果 TopK 设了 5、每个分段 500 tokens再加对话历史、系统提示词一次请求很容易超过本地模型的上下文窗口。7B 蒸馏模型的可用上下文有限超长后请求直接失败。解法有两层第一层在知识检索节点把 TopK 降到 3Score 阈值调高到 0.45 左右让更少但更相关的分段进入 prompt第二层在 LLM 节点把上下文变量用文本处理节点截断或者限制输出最大 token 数。还有一个长期方案是给对话历史加压缩节点把早期消息摘要后再拼接适合长会话场景。记住一句话本地模型上下文窗口小不是缺陷把进入 prompt 的内容当成稀缺资源来管理就对了。5. 避坑DeepSeek Dify 本地部署的 5 个高频翻车点这一章写的是我自己踩过、也在群里反复出现的血泪经验。每条按现象 → 原因 → 解决的顺序讲排查时可以直接对照。5.1 Dify 报 An error occurred during credentials validation现象在模型供应商页面点击测试Dify 直接报这个错模型一个都连不上。原因九成是 Base URL 写错或模型名不匹配。常见错误包括写了 localhost 而不是 host.docker.internal、URL 漏了 http:// 前缀、模型名写成 deepseek-r1 而 ollama list 里实际是 deepseek-r1:7b。还有很小一部分是 Ollama 服务根本没起来。解决先在宿主机执行 curl http://localhost:11434/v1/chat/completions 确认接口通再进 Dify 把 Base URL 改成 http://host.docker.internal:11434模型名严格复制 ollama list 的输出。如果走的是 OpenAI-API-compatible 供应商而不是 Ollama 类型API Key 填任意非空字符串即可本地不校验。这条排查顺序固定下来以后遇到供应商测试失败半小时内能解决。5.2 知识库文档一直排队中状态卡住现象上传文档后数据集里文档状态长时间停在排队中既不报错也不完成。原因文档解析和向量化由 worker 容器异步执行排队中说明 worker 没有拿到任务或者根本处理不过来。常见触发点有三个embedding 模型没配好、worker 容器挂了、单文档太大导致分段任务太多。解决先 docker compose ps 确认 worker 容器是 Up再用 docker compose logs worker -f 看日志。如果是 embedding 调用报错回到模型供应商页面把 embedding 模型修好如果日志里显示一条条分段在慢慢处理那就是 CPU 推理太慢把文档拆小、关掉其他占显存的任务或者换一个更轻量的 embedding 模型比如 bge-small-zh-v1.5。提示修改 embedding 模型或分段设置后旧数据集不会自动重建需要删除重建否则改动不生效。5.3 对话上下文超长请求直接失败现象知识库能正常检索但一问长问题或连续对话几轮就报上下文超长Dify 工作流节点直接变红。原因知识检索节点返回的分段数量多、每段又长加上对话历史累积超出了本地模型上下文窗口。Dify 默认不会帮你自动裁剪超了就是硬失败。解决从源头控制知识检索节点的 TopK 和 Score 阈值把分段长度从 800 降到 500 以下在 LLM 节点设置最大输出 token并给 prompt 设计明确的只依据知识库内容回答约束。长对话场景建议在合适的地方插入历史消息压缩节点而不是让所有历史一直堆着。排查时有个技巧把 LLM 节点入参在日志里打出来看看实际拼了多少 token比瞎调参数高效得多。5.4 PDF 解析乱码、表格和扫描件召回差现象传进去的 PDF 问起来答非所问或者干脆乱码表格里的数据完全召不回。原因Dify 内置解析器对文本型 PDF 支持尚可但扫描件、带复杂表格的 PDF 基本无能为力。扫描件本质是图片不 OCR 直接解析当然出来一堆乱码表格转成文本后丢失行列关系检索时自然找不到对应字段。解决先把 PDF 用专业工具转成 Markdown 再上传。我常在本机跑一个 MinerU 做解析把扫描件、公式、表格一并转成干净的 Markdown然后传这个 Markdown 进 Dify分段效果明显变好。日常办公文档里Word 和 Markdown 格式的解析最省心PDF 能转就先转转不了的就要接受它的召回上限。5.5 重启后服务起不来或访问页面报证书错误现象改了 .env 重启 Dify几个容器反复重启或者浏览器访问页面时提示证书错误。原因端口冲突、向量库数据卷异常、.env 配置被改坏是容器起不来的三大原因。证书错误则常见于容器系统时间与宿主机不同步或反向代理证书链不完整。解决先 docker compose ps 看哪个容器不是 Up再用 docker compose logs 容器名 看具体报错。端口冲突就把 EXPOSE_NGINX_PORT 改掉然后 --force-recreate向量库数据卷异常时备份卷后重建对应的数据库服务证书问题先检查服务器时间date -R时间偏差大会导致证书校验失败同步时间后再刷新页面。这里还要说一句改 .env 后必须 docker compose up -d --force-recreate光 restart 不一定生效很多人在这里反复重启都无效。6. 把知识库准确率提上去召回评估、内容源扩展与长期维护6.1 先建一个回归问题集再谈调优不要拿一两个 demo 问题验证完就上线。我的做法是从真实业务里挑 10 条问题整理成一个固定的回归问题集每次改动分段、embedding、检索参数后重新跑一遍对比。Dify 知识库页面的召回测试功能可以直接输入 query 看召回的 top5 分段这一步能直观判断检索是否相关。如果 top5 里相关的不足 3 条通常先换 embedding 或调分段而不是去调 prompt。判断相关的标准也简单看这段内容能不能直接支撑回答而不是看它和问题长得像不像。6.2 中文文档的分段规则值得单独打磨中文文档用默认空行分段效果很差因为中文段落长、空行少。自定义分隔符填 。 之后再配合 500 tokens 最大长度和 50 tokens 重叠召回质量会有肉眼可见的提升。这套参数调起来像玄学其实一半的问题出在分段上另一半才轮到 embedding。至于知识库能不能用在小模型上——能而且这是本地部署最实用的一条经验检索质量往往比模型参数更能决定回答下限。6.3 把公众号文章变成知识库的内容源团队文档里大量内容在公众号文章里。公众号没有开放的 API我常用的做法是先把文章正文复制到本地清理掉广告和无关导航存成 Markdown 再上传或者用正文提取工具把 URL 转成干净文本再走 API 导入。动态渲染的页面不要指望 Dify 内置的网页抓取能拿到正文抓回来往往是空的先落成本地文件是最省心的路径。我现在的习惯是每搭一个知识库先跑一遍那 10 条回归问题逐个看召回段落再调参数而不是拿着 demo 问题自嗨。本地 DeepSeek Dify 这条路7B 模型加 50 份文档起步已经足够验证价值先把链路跑通再谈扩量和优化。希望帮到你。本文还有配套的精品资源点击获取