企业官网建设流程全解析

1. 为什么我决定不再给云端 API 打工

去年年底我算了一笔账：手上三个小项目，每个月调用云端大模型 API 的费用加起来接近四百块。钱不算多，但问题不在钱上。真正让我难受的是三件事：第一，每次调接口都要把用户输入的数据发到别人的服务器上，虽然各家都说自己合规，但我心里始终不踏实；第二，网络一抖动，整个功能就挂掉，用户那边看到的就是转圈圈；第三，我想微调一下提示词、换一个模型试试效果，得改代码、重新部署，来回折腾半小时。

后来我花了一个周末，用Dify + Ollama + DeepSeek搭了一套「本地优先、云端兜底」的私有 AI 平台。核心思路很简单：日常请求全部走本地 Ollama 跑的模型，只有当本地模型搞不定（比如上下文太长、需要更强的推理能力）的时候，才自动降级到云端 DeepSeek API。整套东西跑在 Docker 里，一台 16G 内存的迷你主机就能撑起来。

这篇文章适合谁看？如果你手上有自己的小项目、对数据隐私有基本要求、又不想每个月给 API 厂商交“保护费”，那这套方案你可以直接抄。如果你只是想了解一下 Dify 和 Ollama 怎么配合，也能从里面找到可复用的配置。我会把踩过的坑、参数怎么算、Docker 怎么配、常见报错怎么排查，全部摊开讲。

先说结论：这套方案跑通之后，我每个月的 API 费用降到了不到五十块，本地请求的响应时间稳定在 1.5 秒以内，而且数据不出内网。下面我从整体设计开始拆。

2. 整体架构设计与选型逻辑

2.1 为什么是 Dify + Ollama + DeepSeek 这个组合

选型这件事，我的原则是：每个组件只干一件事，而且这件事它得干得足够好。

Dify在这个架构里扮演的是“调度中心”和“应用层”的角色。它负责接收用户请求、管理知识库、编排工作流、决定这次请求走本地还是走云端。我试过自己写一套调度逻辑，用 FastAPI 加一堆 if-else，写到第三天就放弃了——光是对话历史管理、知识库检索、流式输出这几块就够喝一壶的。Dify 把这些都封装好了，我只需要在它的模型配置里加两个 Provider 就行。

Ollama是本地模型运行时。它的优势在于模型管理极其简单，ollama pull一下就能把模型拉下来，ollama run就能跑。而且它自带一个兼容 OpenAI 格式的 API 接口，Dify 可以直接把它当成一个 OpenAI 兼容的 Provider 来配置。我对比过直接用手动加载 GGUF 文件的方式，Ollama 在显存管理和并发处理上省心太多。

DeepSeek是云端兜底。选它而不是别的，原因有三个：一是它的 API 价格确实便宜，输入 token 的价格大概是某些主流模型的十分之一；二是它的上下文窗口够大，处理长文档的时候不会动不动就报“maximum context length”错误；三是它兼容 OpenAI 的接口格式，Dify 接入成本几乎为零。

这三个东西凑在一起，形成了一个分层结构：Ollama 扛日常流量，DeepSeek 扛峰值和复杂任务，Dify 做统一入口和路由。

2.2 「本地优先、云端兜底」到底怎么落地

很多人听到“本地优先”以为就是全部跑本地，其实不是。纯本地方案有两个硬伤：一是本地小模型的推理能力有限，遇到复杂逻辑推理或者长文档分析，效果会明显下降；二是本地机器的内存和显存有限，并发一高就排队。

我的做法是在 Dify 里配置两个模型 Provider，然后在工作流里加一个判断节点。判断逻辑大概是这样：

• 如果请求的 token 数小于 3000，且不涉及复杂推理任务，走本地 Ollama；
• 如果 token 数超过 3000，或者用户显式选择了“深度分析”模式，走云端 DeepSeek；
• 如果本地 Ollama 请求失败（比如模型加载超时、内存不足），自动重试一次，仍然失败则降级到 DeepSeek。

这个判断逻辑在 Dify 的工作流里用条件分支就能实现，不需要写代码。具体配置我后面会详细讲。

2.3 硬件和网络环境的最低要求

我把这套东西跑在一台二手迷你主机上，配置是：Intel i5-8500T、16G DDR4 内存、512G NVMe 固态。没有独立显卡，纯 CPU 推理。

实测下来，跑 7B 级别的量化模型（比如 Qwen2.5:7B 的 Q4 量化版本），响应速度大概在每秒 8 到 12 个 token。对于日常问答和文档摘要够用了。如果你有独立显卡，比如 RTX 3060 12G，那可以跑 14B 级别的模型，效果会好很多。

内存方面，16G 是底线。Ollama 加载一个 7B 的 Q4 模型大概占 5G 左右内存，Dify 的一套服务（api、worker、web、postgres、redis、weaviate）加起来大概占 3G，系统本身占 2G，剩下的留给模型推理时的上下文缓存。如果你要跑 14B 模型，建议 32G 起步。

网络方面，本地请求走 localhost，不经过外网。只有降级到 DeepSeek 的时候才需要外网连接。所以即使你的网络环境不稳定，日常使用也不受影响。

3. 核心组件部署与关键配置细节

3.1 Docker 环境准备与常见安装问题

整套东西我全部跑在 Docker 里，原因是隔离性好、迁移方便、重装系统之后一条命令就能恢复。

Windows 用户先装 Docker Desktop。这里有个坑：安装的时候如果勾选了 WSL2 后端，需要确保 BIOS 里开启了虚拟化（Intel VT-x 或 AMD-V）。我遇到过一台机器装完之后 Docker 起不来，报错说“WSL2 kernel version too old”，解决办法是在 PowerShell 里执行wsl --update更新内核。

安装完成之后，建议做两个配置调整：

• 在 Docker Desktop 的设置里，把 Resources 的内存限制调到 8G 以上。默认可能是 2G，不够用。
• 把磁盘镜像位置改到非系统盘，避免 C 盘爆满。Dify 加上几个模型，轻松占掉 20G。

Linux 用户直接用官方脚本安装 Docker Engine 和 Docker Compose 就行。注意要装docker-compose-plugin，不是老的docker-compose。这两个命令不一样，老版本不支持 Dify 的 compose 文件格式。

验证安装是否成功：

docker --version docker compose version

两个命令都能输出版本号，说明环境没问题。

3.2 Ollama 部署与模型拉取加速

Ollama 的部署有两种方式：直接装在本机，或者跑在 Docker 里。我推荐跑在 Docker 里，因为这样 Dify 和 Ollama 在同一个 Docker 网络里，互相访问用容器名就行，不用管端口映射。

Docker 跑 Ollama 的命令：

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

这条命令做了三件事：把模型文件持久化到名为ollama的 volume 里、把 11434 端口映射出来、给容器起名叫ollama。

接下来是拉模型。国内网络环境下，直接从 Ollama 官方源拉模型可能会很慢，甚至超时。我试过几个办法，最有效的是配置镜像加速。具体做法是在 Ollama 的 systemd 配置或者 Docker 环境变量里设置OLLAMA_HOST和镜像相关的参数。不过更通用的办法是：先在一台网络条件好的机器上把模型拉下来，然后整个.ollama目录拷贝到目标机器上。

模型文件的位置：

• Linux：/usr/share/ollama/.ollama/models或者~/.ollama/models
• Docker：在 volume 里，可以用docker volume inspect ollama找到具体路径

我常用的模型是qwen2.5:7b和deepseek-r1:7b。前者通用能力强，后者推理能力好。拉取命令：

docker exec -it ollama ollama pull qwen2.5:7b docker exec -it ollama ollama pull deepseek-r1:7b

拉完之后验证一下：

docker exec -it ollama ollama list

能看到模型列表就说明成功了。

注意：如果你在拉模型的时候遇到ollama run qwen3.5:2b error: 500 internal server error: llama-server process这类报错，大概率是模型文件下载不完整或者内存不足。先检查磁盘空间，再检查 Docker 的内存限制。

3.3 Dify 本地部署的完整流程

Dify 的部署比 Ollama 复杂一些，因为它依赖 Postgres、Redis、Weaviate 这几个服务。好在官方提供了 docker-compose 文件，基本上改几个配置就能跑。

第一步，克隆代码：

git clone https://github.com/langgenius/dify.git cd dify/docker

第二步，复制环境变量文件：

cp .env.example .env

第三步，修改.env里的关键配置。我一般会改这几个：

• EXPOSE_NGINX_PORT：默认是 80，如果 80 被占用了改成别的，比如 8080。
• POSTGRES_PASSWORD：改成一个强密码。
• SECRET_KEY：改成一个随机字符串，用于加密会话。

第四步，启动：

docker compose up -d

第一次启动会拉取镜像，大概需要几分钟。启动完成之后，访问http://localhost:8080就能看到 Dify 的初始化页面。

初始化的时候会让你设置管理员账号和密码。设置完成之后进入控制台，第一件事是去“设置”里配置模型 Provider。

3.4 Dify 接入 Ollama 与 DeepSeek 的配置方法

在 Dify 控制台里，点击右上角头像，进入“设置”，然后选择“模型供应商”。

接入 Ollama：

找到“Ollama”这个 Provider，点击“添加模型”。配置项如下：

• 模型名称：填qwen2.5:7b（和你拉取的模型名一致）
• 基础 URL：填http://ollama:11434（因为 Dify 和 Ollama 在同一个 Docker 网络里，直接用容器名）
• 模型类型：选“对话”
• 上下文长度：填 32768（7B 模型一般支持 32K 上下文）
• 最大 token 数：填 4096

填完之后点击“保存”，Dify 会发一个测试请求。如果配置正确，会显示“连接成功”。

接入 DeepSeek：

找到“OpenAI-API-compatible”这个 Provider（Dify 支持自定义 OpenAI 兼容接口），点击“添加模型”。配置项如下：

• 模型名称：填deepseek-chat
• API Key：填你在 DeepSeek 平台申请的 key
• 基础 URL：填https://api.deepseek.com/v1
• 模型类型：选“对话”
• 上下文长度：填 65536
• 最大 token 数：填 8192

保存之后同样会测试连接。

注意：如果你在配置的时候遇到dify an error occurred during credentials validation这个报错，先检查 API Key 有没有多余的空格，再检查基础 URL 是不是写成了https://api.deepseek.com（少了/v1）。这两个是最常见的原因。

3.5 工作流中的路由判断与降级策略

模型 Provider 配好之后，接下来是在工作流里做路由。

在 Dify 里新建一个“工作流”应用，然后添加节点。我的工作流结构是这样的：

1. 开始节点：接收用户输入。
2. 条件分支节点：判断输入长度和任务类型。
3. LLM 节点（本地）：调用 Ollama 的模型。
4. LLM 节点（云端）：调用 DeepSeek 的模型。
5. 结束节点：返回结果。

条件分支的判断条件我设了两个：

• 条件一：{{#start.query#}}的长度小于 3000 个字符。
• 条件二：{{#start.mode#}}不等于deep。

两个条件同时满足，走本地分支；否则走云端分支。

这里有个细节：Dify 的条件分支支持“与”和“或”逻辑。我选的是“与”，因为只有两个条件都满足才走本地，这样更保守一些。

降级策略是在 LLM 节点里配置的。Dify 的 LLM 节点有一个“失败重试”选项，可以设置重试次数和重试间隔。我设的是重试 1 次，间隔 2 秒。如果重试之后仍然失败，Dify 会走“异常分支”，我在异常分支里接了一个云端 LLM 节点。

这样整个链路就是：本地优先 → 本地失败重试 → 重试失败降级云端。

4. 实操过程中的关键环节与参数计算

4.1 模型选择与量化等级的计算过程

选模型这件事，不能只看参数数量。7B 的模型不一定比 14B 的差，关键看量化等级和你的硬件能不能扛住。

量化等级决定了模型占用的内存和推理速度。以 7B 模型为例：

我的 16G 内存机器，跑 Q4_K_M 是最平衡的选择。模型占 5G，Dify 占 3G，系统占 2G，还剩 6G 给上下文缓存和并发处理。

如果你有 32G 内存，可以上 14B 的 Q4_K_M，模型占 10G 左右，效果比 7B 明显好一截。

计算模型大小的公式很简单：参数量 × 每参数字节数 / 1024^3。比如 7B 模型 Q4 量化，就是7 × 10^9 × 0.5 / 1024^3 ≈ 3.3 GB。实际文件会大一些，因为还有词表和元数据。

4.2 上下文长度与 token 预算的分配

上下文长度是很多人忽略的参数。它决定了模型一次能“记住”多少内容。

Ollama 默认的上下文长度是 2048，对于长文档处理来说太短了。你可以在 Modelfile 里改，也可以通过 API 参数传。

在 Dify 的 Ollama Provider 配置里，我把上下文长度设成了 32768。但这里有个陷阱：上下文长度设得越大，占用的内存越多。32K 上下文的 7B 模型，KV Cache 大概要占 2G 到 3G 内存。

我的建议是：

• 日常问答：上下文长度设 8192 就够了。
• 文档摘要：设 16384。
• 长文档分析：设 32768，但要盯着内存使用情况。

如果你遇到api error: 400 this model's maximum context length is 1048576 tokens这类报错，说明你请求的 token 数超过了模型支持的上限。解决办法有两个：一是截断输入，只保留最相关的部分；二是换一个上下文窗口更大的模型。

4.3 知识库流水线的配置与文档处理

Dify 的知识库功能是我用得最多的。把公司内部文档、产品手册、常见问题丢进去，用户提问的时候自动检索相关内容，然后交给模型生成回答。

知识库的配置有几个关键参数：

• 分段方式：我选的是“自定义”，分段长度 500 字符，重叠 50 字符。这样既能保证语义完整，又不会让单个片段太长。
• 索引方式：选“高质量”，用 Embedding 模型做向量化。Embedding 模型我用的是 Ollama 跑的nomic-embed-text，效果不错而且免费。
• 检索方式：选“混合检索”，结合向量检索和关键词检索。实测下来比纯向量检索的召回率高 15% 左右。

文档上传的时候，如果你遇到dify unstructured api url is not configured for doc file processing这个报错，说明你上传了 Dify 默认不支持的格式（比如 PDF 里的复杂表格）。解决办法是在.env里配置 Unstructured API 的地址，或者把文档转成纯文本再上传。

我一般会把 PDF 先用工具转成 Markdown，然后再上传。这样分段效果更好，检索也更准。

4.4 本地与云端模型的性能对比实测

为了让你有个直观的感受，我拿同一个问题分别问本地 Qwen2.5:7B 和云端 DeepSeek，记录了几个指标：

从表里能看出来，本地模型在响应速度和隐私上有优势，但在复杂任务上确实不如云端。所以“本地优先、云端兜底”这个策略是合理的：日常简单任务走本地，省钱又安全；复杂任务走云端，保证效果。

5. 常见报错与排查技巧实录

5.1 API Key 与认证类报错

unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****

这个报错我遇到过三次，每次原因都不一样：

第一次是 API Key 复制的时候多了一个空格。DeepSeek 的 Key 是以sk-开头的，复制的时候很容易把末尾的空格也带进去。解决办法是在 Dify 的配置框里手动删掉末尾空格。

第二次是 Key 过期了。DeepSeek 的 Key 有有效期，过期之后需要重新生成。去 DeepSeek 平台的“API Keys”页面重新创建一个就行。

第三次是我把 Key 填到了错误的 Provider 里。Dify 里每个 Provider 的 Key 是独立的，Ollama 不需要 Key，DeepSeek 需要。填错位置就会报 401。

排查顺序：先检查 Key 有没有空格，再检查 Key 是否过期，最后检查填的位置对不对。

5.2 模型加载与内存类报错

ollama run qwen3.5:2b error: 500 internal server error: llama-server process

这个报错说明 Ollama 在加载模型的时候失败了。常见原因有三个：

• 模型文件损坏：重新ollama pull一次。
• 内存不足：检查 Docker 的内存限制，或者关掉其他占内存的程序。
• 模型格式不兼容：确认你拉的模型是 Ollama 支持的格式。

我遇到过一次是因为 Docker 的内存限制设成了 4G，而模型需要 5G。改成 8G 之后就好了。

5.3 网络与镜像源类问题

ollama下载太慢了这个问题几乎每个人都会遇到。我的解决办法是：

• 在 Docker 里跑 Ollama 的时候，把模型目录挂载到本地，然后从别的机器拷贝模型文件过来。
• 如果一定要在线拉，尽量在凌晨或者网络空闲的时候拉。
• 关注一些技术社区，有时候会有人分享打包好的模型文件。

Docker 镜像拉取慢也是类似的问题。可以在 Docker Desktop 的设置里配置镜像加速地址，或者用docker pull的时候指定国内源。

5.4 Dify 工作流上下文超长问题

dify工作流 上下文超长这个报错通常出现在多轮对话或者长文档处理的时候。

Dify 的工作流默认会把所有历史消息都传给 LLM，轮次一多，token 数就爆了。解决办法有两个：

一是在工作流里加一个“变量截断”节点，只保留最近 N 轮对话。我一般设 N=5。

二是用 Dify 的“会话变量”功能，把历史对话压缩成摘要，只传摘要而不是原文。这个配置稍微复杂一点，但效果更好。

5.5 常见问题速查表

6. 我踩过的坑和最后分享几个小技巧

第一个坑是 Docker 的网络配置。Dify 和 Ollama 如果在不同的 Docker 网络里，互相访问会失败。解决办法是把它们放到同一个 network 里，或者用host.docker.internal这个特殊域名。我在 Windows 上折腾了一个小时才发现这个问题。

第二个坑是模型版本和 Dify 的兼容性。有些新出的模型 Dify 的 Provider 还没适配，配置的时候会报错。解决办法是先用ollama run在命令行里测试一下，确认模型能正常跑，再去 Dify 里配置。

第三个坑是知识库的 Embedding 模型。Dify 默认用的是 OpenAI 的 Embedding，如果你没配 OpenAI 的 Key，知识库功能就用不了。解决办法是在 Ollama 里拉一个nomic-embed-text，然后在 Dify 的 Embedding 配置里选 Ollama。

最后分享一个小技巧：如果你想让本地模型的回答质量更高，可以在 Ollama 的 Modelfile 里加一个系统提示词。比如：

FROM qwen2.5:7b SYSTEM "你是一个专业的技术助手，回答要简洁准确，不要编造信息。"

然后用ollama create my-qwen -f Modelfile创建一个自定义模型。这样每次调用的时候都会带上这个系统提示词，省去了在 Dify 里重复配置的麻烦。

这套方案我跑了三个月，中间只重启过两次 Docker，稳定性没问题。如果你也在纠结要不要自己搭一套，我的建议是：先花一个周末把 Dify 和 Ollama 跑起来，感受一下本地模型的速度和隐私优势，然后再决定要不要接云端兜底。很多时候，本地模型已经够用了。