本地优先云端兜底：Dify+Ollama+DeepSeek 私有AI平台实战

每个月账单出来的时候，我都有一种强烈的“被绑架感”。明明只是做点文本摘要、知识库问答，API 调用量却像拧开了的水龙头一样停不住，费用蹭蹭往上走。后来更麻烦的是数据安全问题，公司内部有一批文档不能直接往外传，但业务又确实需要 AI 来帮忙处理。所以我在去年底折腾了一套“本地优先、云端兜底”的私有 AI 平台：应用编排交给 Dify，本地模型统一由 Ollama 管理，复杂任务再交给 DeepSeek API 来兜底。

这套架构跑通之后，效果比我想象中好很多，月度 API 开销直接降了一个数量级，内部数据请求也基本都在本地闭环了。这篇文章就把我的搭建过程、踩过的坑、调优参数全部摊开讲，想搭私有 AI 平台的朋友可以直接照着抄作业。

1. 先算一笔账：为什么说别再给 API 打工

1.1 API 账单到底是怎么悄悄变大的

很多人一开始都觉得，大模型 API 按 token 计费，单个请求没多少钱，能贵到哪里去？我一开始也是这么想的，直到认真看了账单才发现，消耗量根本不是按“单个请求”放大，而是按“调用次数 × 每次上下文长度”放大的。

举个实际场景：我想让模型总结一个 5000 字的技术文档。如果直接把整篇文档塞进提示词，一次就要消耗 5000 多 token（约 3000 多汉字）。这还只是输入，输出摘要再加个几百 token。表面看一次没多少钱，但如果你每天要处理几十份文档，再叠加日常问答、代码生成、日志分析，一个月下来轻轻松松跑几千万 token。我自己的账单峰值是一个月几十万 tokens 的十倍不止，这不是夸张，是真实发生的。

更坑的是，很多团队为了保证效果，会同时接好几家 API，同一问题轮流问，选最优答案再返回。这种方式单次质量确实更好，但 API 费用也直接乘以 N，纯纯地给平台方打工。

1.2 比成本更要命的是数据控制权

成本虽然肉疼，但真正逼着我把这套系统做出来的，是数据控制权问题。

公司内部文档里有客户信息、报价、不公开的技术方案，这些东西如果每天通过 API 传到云端，你根本不知道平台那边会用这些数据做什么。虽然主流厂商都承诺不拿用户数据训练，但这只是“声明”，内部合规评审根本不买账。而且长文档要分 chunk 切分后多次请求，数据在网络上多传一次，风险就多一分。

本地模型虽然能力上限不如云端旗舰，但至少我能明确知道：数据没有离开这台机器。这一点对我来说是最底层的需求，能力可以不够强，但不能失控。

1.3 为什么不是“纯本地”，而是“云端兜底”

有人可能会问，既然怕数据外传，那干脆全部本地部署，一个 API 都不碰不就行了？

现实原因有两个：一是开源模型的复杂推理能力跟商用旗舰模型还是有差距，尤其是长文档语义理解、复杂代码生成这类任务，本地小模型经常会输出明显的“幻觉内容”；二是本地机器的 GPU 资源有限，总不能让每个员工的问题都挤在一张显卡上排队。更合理的做法是把请求分流：能本地处理的本地处理，本地搞不定的、数据敏感度不高的任务再走云端。

这就是我标题里说的“本地优先、云端兜底”，不是二选一，而是两条腿走路。

2. 整体方案选型：Dify、Ollama、DeepSeek 分别扮演什么角色

2.1 三件套各管什么

先说 Dify。它本质上是一个 LLM 应用开发平台，负责把模型、知识库、工作流、API 接口这些东西串起来。你可以把它理解成一个“AI 应用的操作系统”：不需要写大量胶水代码，用图形化界面就能搭出聊天机器人、知识库问答、Agent 工作流。它自带模型供应商接入、知识库切分、Prompt 管理和访问控制，非常成熟。

Ollama 负责干苦力活——在本地运行开源模型。它把模型下载、推理、端口暴露都封装得非常干净，一条命令就能把一个模型跑起来，还会自动做显存管理和模型量化。用 Ollama 拉取和运行模型，比自己去配 Python 环境、加载权重、写推理服务要省事太多。

DeepSeek 在这个体系里承担“模型来源”的角色，而且其实是两部分：一部分是 DeepSeek 开源出来的 R1 系列蒸馏版模型，可以放到 Ollama 里本地跑；另一部分是 DeepSeek 官方 API，通过 Dify 的供应商配置接入云端。两者共用同一套模型生态，提示词风格也一致，切换起来几乎没有额外成本。

2.2 一个请求在系统里是怎么流转的

我实际搭好的流程是这样的：

用户进来一个问题，先落到 Dify 的工作流入口。工作流第一个节点是路由判断，用一个本地小模型快速判断这个请求是简单还是复杂。如果只是“公司餐补政策是什么”、“某份文档里的联系方式”这种简单检索，直接分流到 Ollama 本地的 DeepSeek R1 蒸馏版；如果是“帮我分析这三十页合同的潜在风险”这种复杂推理，就切到 DeepSeek 云端 API。

这种设计的好处很明显：高频低难度的问题不花钱，低频高难度的问题才花钱，整体成本自然就降下来了。而且就算 DeepSeek 云端 API 哪天出故障、限流了，本地的路径仍然能兜住大部分请求，不会整个 AI 助手瘫痪。

2.3 为什么不用 LangChain 或 LlamaIndex 自己搭

我在选型阶段其实也考虑过直接用 LangChain 写编排，或者用 LlamaIndex 做知识库索引。后来放弃了，原因不复杂：这两套框架自由度很高，但意味着所有东西都要自己维护，知识库切分、向量检索、Agent 路由、权限管理都要写代码。对一个既要管业务又要折腾 AI 基础设施的小团队来说，维护成本太高了。

Dify 的价值在于把工程化的东西都做完了。我要做的只是配置模型供应商、上传知识库、拖拽工作流节点，剩下的基础设施它帮我扛了。后来团队里不懂代码的同事也能在 Dify 界面上调整提示词和知识库，这个优势是代码框架给不了的。

3. Ollama 本地模型层搭建：从安装到跑通 DeepSeek

3.1 下载太慢的解决办法：国内镜像站与离线安装包

Ollama 的安装本身不复杂，最让人崩溃的是下载过程。官方服务器的下载速度在部分地区非常感人，经常卡在几个 KB/s，我之前第一次装就等了大半天。

后来我换了两个思路解决。一个是直接用国内镜像站下载安装包，很多高校和云厂商都做了镜像同步，速度能跑到几 MB/s 甚至更快。另一个是用离线安装包：在一台网络好的机器上下好安装文件和模型文件，拷贝到目标机器上直接装。Windows 下 Ollama 的安装包是 exe，双击就能装，装好之后把 Ollama 的模型目录整个复制过去，改一下环境变量指向目录就行，根本不用在内网机器上重新拉模型。

这里有个关键环境变量需要记住：OLLAMA_MODELS，它指定模型文件存放位置。如果你想把模型放到 D 盘或专门的存储目录，在系统变量里新增这个变量，指向目标路径，然后重启 Ollama 服务。默认路径在 C 盘用户目录下，放多了容易占满系统盘。

安装完成后，命令行敲ollama -v，能看到版本号就说明装好了。如果提示找不到命令，检查一下安装路径有没有进入 PATH。

3.2 模型选型和显存规划：DeepSeek R1 该拉哪个尺寸

Ollama 跑 DeepSeek 系模型，核心看你的显卡显存够不够。DeepSeek R1 是推理模型，官方出了蒸馏版，不同版本显存占用差异很大，我实际拉过 1.5b、7b、14b，简单整理一下：

显存的占用不只是模型体积这么简单。模型实际运行的时候，除了加载权重，还要留出 KV Cache（也就是推理时上下文注意力计算的缓存区域）和基本的运行开销。所以一个 4.7GB 的 7b 模型，8GB 显存的机器跑起来其实已经很紧张了，上下文一长就容易崩。我的建议是：16GB 显存优先跑 14b，这是性价比最高的档位；24GB 显存可以考虑 32b；如果你只有 8GB 显存，安心用 7b。

拉模型和运行都靠命令：

ollama pull deepseek-r1:7b ollama run deepseek-r1:7b

第一次运行会自动加载，之后再次调用会快很多。如果中途报显存不够，或者推理速度慢到无法接受，就换小一号的模型，别硬撑。

3.3 一个容易忽略的细节：怎么关掉 R1 模型的“碎碎念”

DeepSeek R1 是推理模型，默认会在输出正式回答之前，先输出一大段思考过程（reasoning）。这在技术上有价值，但在产品里很烦人，用户看到的回答前总有一堆“嗯，用户问的是……我需要先分析……”之类的自言自语。

网上不少帖子在问“如何关闭 ollama 里 gemma4 的思考过程”，其实这个问题在 DeepSeek R1 上也一样存在。我的解决办法有两个：

第一种是模型层调参数。在 Ollama 0.6 之后的版本里，部分模型的思考模式可以通过参数控制，但 R1 蒸馏版的思考行为是模型内建的，直接关不干净。更可靠的做法是在提示词里明确要求“直接给出答案，不要输出推理过程”，有一定效果，但偶尔还是会漏出来一点。

第二种是我强烈推荐的方案：在 Dify 工作流里做后处理。Ollama 通过 OpenAI 兼容接口返回的内容里，推理过程和正式回答通常分成不同字段。在 Dify 的 LLM 节点后面加一个变量提取器，把推理内容单独拆出来丢到临时变量里，最终只把正式回答返回给用户。这样不管模型怎么想，用户看到的就是干净的回答，而且推理内容还能存到日志里，方便你复盘。

4. Dify 部署与配置实录：一次跑通，少绕弯路

4.1 Windows 上部署 Dify：走 Docker 路线最省心

Dify 官方推荐用 Docker Compose 部署，我在 Windows 上也是这么干的。首先确保装了 Docker Desktop，并且把后端切换成 WSL2，这一步非常关键，否则后面跨文件系统挂载会很慢，有时还会出现各种诡异权限问题。

然后找一个干净目录，克隆或下载 Dify 的源代码包，进入 docker 目录，复制环境变量模板：

cp .env.example .env

先别急着启动，打开 .env 看一眼，重点检查几个字段：SECRET_KEY、POSTGRES_PASSWORD、把EXPOSE_NGINX_PORT设成你自己想要的访问端口。.env里的配置会在第一次启动时初始化，后期再改有些字段不会生效。

确认没问题后执行：

docker compose up -d

第一次启动会拉一堆镜像，这个过程也容易卡住，解法跟 Ollama 下载慢一样，给 Docker 配置国内镜像源，或者提前在有网络的机器上把镜像导出再导入。启动完成后，浏览器访问http://localhost:你的端口/install，设置管理员账号，就进入主界面了。

这里提个醒：Dify 每次升级版本都建议先备份数据。备份不是把整个 docker 目录拷走就行，而是要分别处理数据库、向量库、对象存储和 Redis，我在第七节会细说。

4.2 SSL 错误和外呼失败的排查思路

我在部署过程中遇到最多的报错有两类，一类是浏览器端访问 Dify 的 SSL 错误，另一类是 Dify 内部调用云端 API 时出现的 SSL 验证失败。

浏览器端的 SSL 错误，基本上是你自己做了 HTTPS 反向代理，但证书链配置不完整，或者证书和域名不匹配导致的。这个跟 Dify 本身关系不大，重点检查 Nginx 配置、证书路径有没有写对。如果只是内网临时用，直接 HTTP 访问更省心。

真正容易让人一头雾水的是第二种：Dify 容器往外请求模型 API 时报 SSL 相关错误，典型日志是CERTIFICATE_VERIFY_FAILED。出现这个问题的原因通常是容器里的系统时间不对，或者 CA 证书不完整。我做过的有效处理有：

• 先检查容器时间：docker exec 容器名 date，如果时间和本地差很多，多半会导致证书校验失败，重启 Docker Desktop 一般能解决。
• 把宿主机的 CA 证书挂载进容器，或者在某些环境变量里指定额外的 CA 证书路径。
• 如果你在网络出口比较特殊的办公网里跑，可能还需要调整容器的 DNS 或 Keepalive 设置。

这类问题排查起来有点玄学，但方向就三个：时间、证书、网络出口。按这个顺序查，基本都能找到原因。

4.3 接入 DeepSeek API：一次性把 Key 配对

Dify 里接入 DeepSeek API 的位置很好找：设置 → 模型供应商 → DeepSeek → 填写 API Key。看似简单，我却在 401 错误上栽了一个大跟头，日志反复报unexpected status 401 unauthorized: incorrect api key provided: sk-svcac***。

看到sk-svcac***这个前缀的时候，第一反应别去检查你自己的 API Key。这个前缀说明 Dify 用的是它自己生成或保存的服务端 Key，而不是你在 DeepSeek 官网申请的那个sk-开头的账号 Key。出现这种情况，多半是 Dify 的.env里某个模型供应商变量残留了旧值，或者你之前保存过一个失效的 Key，新的请求还带着旧凭证。

我的排查顺序是这样的：

第一步，先单独验证 Key 本身有没有问题。在命令行用 curl 直接请求 DeepSeek 的接口：

curl https://api.deepseek.com/models \ -H "Authorization: Bearer sk-你自己申请的key"

如果这个请求返回正常模型列表，说明 Key 没问题，问题出在 Dify 配置上。如果返回 401，说明 Key 本身失效了，去 DeepSeek 开放平台重新生成一个。

第二步，回到 Dify 后台，在模型供应商页面重新填写 Key，保存前注意看有没有多余的空格或换行，这种低级错误非常常见。有些 API Key 是一长串，复制的时候容易带个换行符，肉眼看不出来，401 却报得毫不留情。

第三步，如果填对了还报错，就去查.env里有没有跟 DeepSeek 相关的变量，确认没有旧 Key 覆盖。改完.env之后要重启容器：

docker compose up -d --force-recreate

5. 知识库与文档处理：最容易把人绊倒的配置区

5.1 Dify 知识库流水线工作原理

Dify 知识库默认的处理流程是：上传文档 → ETL 解析 → 分段切块 → Embedding 向量化 → 存入向量数据库 → 检索召回。看起来简单，但每一步都可能出问题，而且问题报错信息往往很隐蔽。

最常见的报错是dify unstructured api url is not configured for doc file processing.。这个报错的意思是：你在知识库的 ETL 配置里选择了用 unstructured 进行文档解析，但系统里没有配置对应的UNSTRUCTURED_API_URL环境变量。

unstructured 是一个专门做文档解析的开源工具，能把 PDF、DOCX、PPT 等内容提取成结构化文本。Dify 支持在 ETL 方式里选择“unstructured”作为解析器，但你必须给它提供一个可用的 API 地址。如果你没配，系统就用不了这个解析器，文档上传后直接卡住。

5.2 unstructured 和 MinerU 两种解析路线怎么选

我测试下来，知识库解析方案基本分两派。

第一派是 unstructured。它的优势是 Dify 官方集成度高，部署一个 unstructured API 服务后，把地址填到环境变量里就能用。网上有很多 docker 编排示例，把 unstructured-api 单独跑起来，然后在.env里填地址：

UNSTRUCTURED_API_URL=http://你的地址:8000 UNSTRUCTURED_API_KEY=你的密钥

第二派是 MinerU。这工具在复杂 PDF 解析上表现得非常好，尤其是带公式、多栏排版、扫描件的内容，它能输出结构清晰的 Markdown。MinerU 也有 API 版本，你可以把解析结果拿到之后，再作为文本喂给 Dify 知识库。唯一的麻烦是它对显存有一点要求，而且需要自己处理任务调度，不像 unstructured 那样和 Dify 无缝衔接。

我实际在用的组合是：普通 Word 和 Excel 文档，直接用 Dify 内置解析，稳定够用；扫描版 PDF 和复杂排版的文档，丢给 MinerU 转成 Markdown，再传到 Dify 知识库。这种混合路线兼顾了省心和效果。

5.3 命中率差的调试心得：问题常常出在解析环节

不少朋友遇到知识库“答非所问”就急着换 Embedding 模型，其实很多时候问题根本不在向量化，而是源头解析就坏了。

我有一个真实的案例：某份 PDF 是从扫描件转的，ETL 解析出来的内容全是乱码和碎行。上传之后检索倒是能检到，但检到的 chunk 本来就是坏的，模型拿到坏数据自然给不出好答案。后来换了 MinerU 重新解析，效果立刻就不一样了。

所以遇到知识库回答质量差，我的排查顺序是：先看解析出来的是什么，再查切块是否合理，最后才考虑改 Embedding 模型。Dify 后台可以查看每个文档的分段内容，这一步一定要养成习惯。

6. 工作流与上下文管理：别让超长 token 报错打断你的方案

6.1 上下文长度限制报错：不是模型不够强，是设计不够聪明

工作流跑起来之后，我遇到的另一个高频报错是：

400 this model's maximum context length is 1048576 tokens. However...

这个报错看起来很吓人，1,048,576 个 token，也就是模型上下文上限已经达到百万级别。你还会超？说明你确实往模型里塞了海量内容。实际上，这个报错在 Dify 里最常见的原因不是单次请求塞爆了百万 token，而是工作流的上下文变量被反复叠加，每一轮对话都把前面的历史、中间结果、检索内容全部带上，累加之后触发了模型上限。

我在一个长文本分析工作流里就踩过这个坑：一次处理三十页 PDF，解析出的全文放在一个变量里，后面每个节点都把全文传给同一个模型，导致同一份全文在多个环节被重复计费、重复占上下文。直到报错才意识到，这个设计是错的。

正确的做法是：把文档解析、分段摘要、汇总输出拆成三个环节，分段摘要时只把当前段的内容传给模型，不把全文带上；汇总时再把各段摘要拼接起来。这样模型每次拿到的上下文都很短，既不会超限，也省钱，速度还快。

6.2 用路由节点实现“本地优先”的实际配置

Dify 工作流里实现“本地优先、云端兜底”的核心是路由判断。我用的方案是在工作流入口加一个 LLM 节点，提示词大致是：

判断用户问题是否属于以下类型之一：需要长文档分析、复杂多步推理、高难度代码生成。 如果是，输出 {"route": "cloud"}；否则输出 {"route": "local"}。 只输出 JSON，不要解释。

然后把输出接一个 IF/ELSE 节点，两个分支分别指向 Ollama 的本地模型节点和 DeepSeek 云端模型节点。两个分支指向同一个变量输出，最终把结果返回给用户。

这个方案跑起来之后效果非常稳。日常那些“查一下某某文档里有没有提到某某条款”的业务，全部落在本地路径上，响应速度在 1 秒左右，不花一分钱。只有那种需要认真推理的问题才走云端，调用量直接少了一个数量级。

7. 常见问题排查速查表：照着查比看文档高效

我把部署和使用过程中遇到的问题整理成一张速查表，遇到问题直接对号入座，比翻社区快得多。

Dify 迁移这个事我多说一句。很多人在同一台机器上升级版本，直接docker compose down && docker compose up -d，表面上看数据还在，因为容器卷还在。但一旦机器换了、或者你想把整套系统搬到另一台服务器，只拷贝项目目录是不够的。

正确姿势是把容器卷里的内容完整导出，Postgres 数据可以用pg_dump导出成 SQL，向量数据读出来导出成备份文件，对象存储里的上传文件也要单独拷走。迁移到新机器后先恢复数据库，再启动 Dify，不然知识库索引和文件对不上，检索结果全乱。

8. 一些实际踩坑之后的个人体会

这套“本地优先、云端兜底”的私有 AI 平台搭好之后，我最大的感受是：你不需要追求“最强的模型”，你需要的是“最合算的工作分配”。

本地模型并不是免费的，它也有隐形开销：硬件折旧、电费、调试时间。但这些东西是一次性投入和固定成本，用起来没有边际费用，尤其对高频请求来说，本地路径几乎是零成本。而云端 API 是按量付费，适合对付那些低频但要求高的复杂任务。把这两种资源分开调度，才是私有 AI 平台真正划算的地方。

另外一个体会是：遇到问题先看日志，别急着换组件。Dify 的容器日志、Ollama 的日志、模型供应商的调用记录，这些信息比任何论坛帖子都准确。我前面提到的 401 和上下文超长问题，如果一开始就静下心看完整日志，可能半小时就能定位，而不是在界面里反复重试。

这套架构后续还能继续扩展。比如可以把 Dify 接到企业微信或飞书机器人上，让同事们在聊天工具里直接调用内部知识库；也可以给 Ollama 加一块独立显卡，本地模型再上一个档次；甚至可以在 Jetson Orin 这种边缘设备上部署精简版模型，做到真正离线的现场问答。这些方向我都已经在陆续尝试，等跑出稳定的实践再来分享一轮。

最后给大家一个最实用的建议：别一上来就把整个系统部署得花里胡哨。先让 Ollama 跑通本地模型，再让 Dify 跑通一个最简单的聊天应用，最后才考虑加知识库、加路由、加多租户。每一步都验证没问题了再往下走，这样踩坑成本最小，也最容易排错。你自己搭过一遍就明白了，这套东西真正难的不是装起来，而是让它稳定地服务日常业务。