本地优先云端兜底：Dify+Ollama+DeepSeek私有AI平台搭建指南

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

1.1 一个让我彻底破防的账单夜晚

去年年底的一个晚上，我盯着后台的 API 消费账单看了很久。那个月我做了三个小工具：一个帮团队整理会议纪要，一个给客户做文档问答，还有一个是给自己用的代码片段检索。三个项目加起来，调用量并不算夸张，但账单数字还是让我心里咯噔一下。更让我难受的是，其中两个项目其实只是内部小范围使用，数据量不大，却因为每次都要走云端接口，成本被硬生生抬了起来。

那一刻我意识到一个问题：我一直在给 API 打工。我的工具、我的数据、我的使用习惯，全都绑在别人的计费表上。只要调用量一涨，成本就跟着涨；只要网络抖一下，工具就卡住；只要对方调整策略，我就得连夜改代码。这种感觉非常被动。

后来我开始认真研究本地部署这条路。目标很明确：能本地跑的绝不走云端，本地跑不动的再交给云端兜底。这套思路我称之为「本地优先、云端兜底」。它不是要彻底抛弃云端，而是把云端从「唯一选项」降级为「备用方案」。这样一来，日常高频、数据敏感、成本敏感的请求全部在本地消化，只有遇到超大模型、超长上下文或者本地资源不够的情况，才把请求转发到云端。

1.2 这套平台到底能做什么

我最终搭出来的这套私有 AI 平台，核心由三块组成：Dify 负责应用编排和界面，Ollama 负责本地模型运行，DeepSeek 负责云端兜底。整套东西跑在一台自己攒的机器上，通过 Docker 管理，日常使用体验和云端服务几乎没有差别。

具体来说，它能做这几件事：

• 本地对话：日常问答、文案润色、代码解释，全部走本地模型，不产生任何外部调用费用。
• 知识库问答：把团队文档、产品手册、个人笔记丢进去，Dify 负责切分和检索，Ollama 负责生成回答，数据不出本地。
• 工作流编排：用 Dify 的可视化工作流把多个步骤串起来，比如「先检索知识库，再让模型总结，最后格式化输出」。
• 云端兜底：当本地模型搞不定，或者需要更强的推理能力时，自动切换到 DeepSeek 的云端接口。
• 多模型切换：Ollama 里可以同时装好几个模型，按任务类型切换，比如小模型做分类，大模型做生成。

适合谁来参考？我觉得有三类人最合适：一是像我这样被 API 账单教育过的独立开发者；二是对数据隐私有要求、不想把内部文档传到外部的中小团队；三是想学习本地大模型部署、但又不想一上来就啃底层框架的技术爱好者。哪怕你之前没接触过 Docker，只要跟着步骤走，也能把这套东西跑起来。

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

市面上本地部署的方案很多，我选这个组合是经过反复对比的。

先说Ollama。它的最大优势是「把模型当命令用」。你不需要关心模型格式、量化方式、推理后端，一条ollama run就能跑起来。它内置了模型管理、GPU 调度、API 服务，对新手极其友好。相比之下，直接用 llama.cpp 或者 vLLM，配置成本高很多，光是编译和参数调优就能劝退一批人。

再说Dify。它是一个开源的 LLM 应用开发平台，最大的价值在于把「模型调用、知识库、工作流、界面」这几件事整合到了一起。你可以把它理解成一个「AI 应用的操作系统」。没有它的话，我得自己写前端、自己写检索逻辑、自己管理对话历史，工作量翻好几倍。有了 Dify，我只需要在界面上拖拖拽拽，就能搭出一个可用的应用。

最后说DeepSeek。选它作为云端兜底，主要看中两点：一是它的 API 价格相对友好，二是它的模型在推理和代码任务上表现稳定。当本地模型遇到复杂逻辑或者超长上下文时，切到 DeepSeek 能明显感觉到质量提升。而且它的接口兼容 OpenAI 格式，接入 Dify 非常顺滑。

这三者组合起来，形成了一个「本地能扛就本地扛，本地扛不住就云端上」的弹性架构。下面我把整套搭建过程拆开讲。

2. 搭建前的整体设计与选型考量

2.1 架构分层：把每一层职责分清楚

在动手之前，我先把整套系统的分层想清楚了。很多人搭本地 AI 平台失败，不是因为技术难，而是因为一开始没想明白「谁负责什么」，结果装了一堆东西，互相打架。

我的分层是这样的：

这个分层的关键在于：Dify 不直接管模型，Ollama 不直接管应用，DeepSeek 只在需要时被调用。每一层通过标准接口通信，任何一层出问题，其他层不受影响。比如 Ollama 挂了，Dify 里的云端模型还能用；Dify 重启了，Ollama 里的模型不用重新加载。

2.2 硬件选型的真实考量

本地跑模型，硬件是绕不开的话题。我一开始也纠结要不要上专业显卡，后来算了一笔账，发现对大多数人来说，没必要一步到位。

我的机器配置是这样的：

• CPU：12 核
• 内存：64GB
• 显卡：一张 12GB 显存的消费级卡
• 硬盘：1TB NVMe SSD

这套配置能跑什么？实测下来，7B 到 14B 参数的模型（量化后）跑得很顺，响应速度在可接受范围内。32B 的模型勉强能跑，但速度明显下降。再大的模型就别想了，直接走云端。

这里有个经验：显存决定你能跑多大的模型，内存决定你能同时跑几个服务。Dify 本身加上数据库、向量库，大概要吃掉 4 到 6GB 内存。Ollama 加载一个 7B 量化模型，大概占 5 到 8GB 显存。所以如果你只有 16GB 内存、8GB 显存，也能跑起来，只是模型选择要保守一点。

提示：如果你用的是 Apple Silicon 的机器，统一内存架构对本地模型非常友好。16GB 统一内存的机器，跑 7B 量化模型体验不错，值得一试。

2.3 为什么用 Docker 而不是裸装

我强烈建议用 Docker 部署，原因有三个。

第一是环境隔离。Dify 依赖 PostgreSQL、Redis、向量库等一堆服务，裸装的话，版本冲突能让你怀疑人生。Docker 把这些依赖全部打包好，一条命令拉起，省心太多。

第二是迁移方便。我后来把这套东西从旧机器迁到新机器，只需要把 Docker 的数据卷打包拷过去，重新docker compose up就完事了。裸装的话，光是重装依赖就得折腾半天。

第三是清理干净。想推倒重来的时候，docker compose down -v一敲，所有容器和数据卷清空，不留任何残留。裸装的话，各种配置文件散落在系统各处，清理起来很痛苦。

当然，Docker 也有坑，比如镜像下载慢、端口冲突、数据卷权限问题。这些我在后面会专门讲怎么处理。

2.4 本地优先、云端兜底的触发逻辑

这套架构最核心的设计，是「什么时候走本地，什么时候走云端」。我的判断逻辑是这样的：

• 默认走本地：所有常规对话、知识库问答、简单生成任务，全部交给 Ollama。
• 上下文超长时切云端：本地模型上下文窗口有限，当输入超过阈值（比如 8K tokens），自动切到 DeepSeek。
• 复杂推理任务切云端：涉及多步逻辑、数学计算、复杂代码生成时，本地小模型容易出错，切云端更稳。
• 本地服务不可用时切云端：Ollama 挂了或者模型加载失败，Dify 自动降级到云端接口。

在 Dify 里实现这个逻辑，靠的是「模型路由」和「工作流条件分支」。你可以配置多个模型供应商，然后在工作流里根据条件选择用哪个。这样既保证了日常使用的低成本，又保证了关键时刻不掉链子。

3. 核心组件部署与实操要点

3.1 Docker 环境准备与常见坑

Docker 是整套系统的基础，这一步没弄好，后面全是问题。

安装 Docker Desktop（Windows / Mac）：去官网下载安装包，一路下一步。Windows 用户注意，安装时会提示启用 WSL2，一定要同意，否则 Docker 跑不起来。安装完成后，打开 Docker Desktop，等右下角图标变成绿色，说明引擎启动成功。

安装 Docker Engine（Linux）：用官方脚本安装最省事：

curl -fsSL https://get.docker.com | sh sudo systemctl enable docker sudo systemctl start docker

装完之后，把当前用户加入 docker 组，免得每次都要 sudo：

sudo usermod -aG docker $USER

然后重新登录一次，让权限生效。

常见坑一：镜像下载慢。这是国内用户最常遇到的问题。解决办法是配置镜像加速器。在 Docker Desktop 的设置里找到 Docker Engine，编辑配置文件，加入加速地址。Linux 用户则编辑/etc/docker/daemon.json：

{ "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com" ] }

改完重启 Docker 服务。实测下来，配置加速器之后，镜像下载速度能从几十 KB 提升到几 MB。

常见坑二：端口冲突。Dify 默认用 80 端口，如果你机器上已经跑了 Nginx 或者其他 Web 服务，就会冲突。解决办法是改 Dify 的.env文件，把EXPOSE_NGINX_PORT改成别的端口，比如 8080。

常见坑三：数据卷权限。Linux 下 Docker 容器里的用户和宿主机用户 UID 不一致，会导致挂载的目录没有写权限。解决办法是在.env里设置UID和GID为当前用户的值，用id命令可以查到。

注意：Docker Desktop 在 Windows 上偶尔会出现「启动后卡住」的情况，通常是 WSL2 后端的问题。重启 WSL（wsl --shutdown）再启动 Docker 通常能解决。

3.2 Ollama 部署与模型管理

Ollama 的安装非常简单，官网下载对应系统的安装包，双击安装即可。Linux 用户可以用一行脚本：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，验证一下：

ollama --version

下载模型。这是最容易卡住的地方，因为模型文件动辄几个 GB。我的经验是：

• 优先选择量化版本，比如qwen2.5:7b这种带参数标注的，体积小、速度快。
• 下载时如果速度慢，可以配置国内镜像源，或者用离线安装包的方式，先在其他地方下好，再拷到模型目录。
• 模型默认存在~/.ollama/models，Linux 下可以改环境变量OLLAMA_MODELS指定到更大的磁盘。

拉取一个模型：

ollama pull qwen2.5:7b

跑起来测试：

ollama run qwen2.5:7b

输入一句话，看看有没有回复。如果能正常对话，说明 Ollama 没问题。

让 Ollama 对外提供服务。默认情况下，Ollama 只监听本地 127.0.0.1:11434。如果 Dify 跑在 Docker 里，需要让 Ollama 监听所有网卡：

export OLLAMA_HOST=0.0.0.0:11434 ollama serve

Linux 下可以把这个写进 systemd 服务配置，让它开机自启。

常见坑一：ollama run报 500 错误。这种情况通常是模型文件损坏或者显存不足。先试试ollama rm删掉模型重新拉，如果还不行，检查显存占用，关掉其他吃显存的程序。

常见坑二：下载太慢。除了镜像源，还可以用「分时段下载」的策略，比如凌晨下载速度通常更快。另外，一些社区会提供离线模型包，下载后放到模型目录即可。

常见坑三：模型加载后响应慢。这通常是显存不够，模型被部分卸载到内存导致的。解决办法是换更小的模型，或者减少并发请求。

3.3 Dify 部署与初始化配置

Dify 的部署用官方提供的 docker compose 最省事。

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

等几分钟，让所有容器启动完成。然后用docker compose ps看看状态，确保所有服务都是 running。

初始化。浏览器打开http://localhost:8080（或者你改的端口），第一次访问会让你设置管理员账号。设置完成后进入控制台。

配置模型供应商。这是关键一步。进入「设置」→「模型供应商」，添加两个：

1. Ollama：填写 Ollama 的服务地址。如果 Dify 和 Ollama 在同一台机器，Dify 在 Docker 里，Ollama 在宿主机，地址要填宿主机的内网 IP，比如http://192.168.1.100:11434。填localhost是不行的，因为容器里的 localhost 指向容器自己。
2. DeepSeek：填写 API Key 和接口地址。DeepSeek 的接口兼容 OpenAI 格式，选择「OpenAI 兼容」类型，Base URL 填https://api.deepseek.com，然后填入你的 API Key。

常见坑一：SSL 错误。Dify 在调用外部接口时，如果遇到自签名证书或者证书链不完整，会报 SSL 错误。解决办法是在.env里设置SSL_VERIFY=false（仅限内网环境），或者把证书正确配置好。

常见坑二：凭据验证失败。添加模型供应商时提示an error occurred during credentials validation，通常是地址填错或者服务没启动。先用curl测试一下 Ollama 的接口是否可达：

curl http://192.168.1.100:11434/api/tags

如果能返回模型列表，说明 Ollama 正常，问题在 Dify 的配置上。

常见坑三：401 Unauthorized。这个错误基本就是 API Key 填错了。检查一下 Key 有没有多余空格，或者是不是复制的时候漏了字符。DeepSeek 的 Key 以sk-开头，注意区分。

常见坑四：文档处理报错unstructured api url is not configured。这是 Dify 在处理某些格式文档时，需要调用 Unstructured API 做解析，但没配置。解决办法是在.env里配置 Unstructured 的地址，或者把文档转成纯文本再上传。

3.4 DeepSeek 云端兜底接入

DeepSeek 的接入相对简单，但有几个细节要注意。

获取 API Key。去 DeepSeek 官网注册账号，在控制台创建 API Key。注意保管好，只显示一次。

在 Dify 中配置。前面已经说了，选「OpenAI 兼容」类型，Base URL 填https://api.deepseek.com，模型名称填deepseek-chat或者deepseek-reasoner。

测试连通性。配置完成后，在 Dify 的模型列表里应该能看到 DeepSeek 的模型。点测试，发一句话，看有没有回复。

常见坑一：上下文超长报错。DeepSeek 的模型有最大上下文限制，报错信息类似maximum context length is 1048576 tokens。虽然这个数字很大，但如果你把整个知识库都塞进去，还是可能超。解决办法是在工作流里做上下文裁剪，只保留最相关的片段。

常见坑二：模型名称写错。DeepSeek 的模型名称是固定的，写错了会报 400 错误。常用的有deepseek-chat（通用对话）和deepseek-reasoner（推理增强）。

常见坑三：并发限制。云端 API 通常有并发限制，请求太密集会被限流。解决办法是在 Dify 里配置重试机制，或者降低并发数。

4. 实操过程与核心环节实现

4.1 从零到一：完整部署流程

我把整个部署过程整理成了一条清晰的流水线，你可以照着走。

第一步：准备机器。确保机器满足最低配置：8 核 CPU、32GB 内存、一张能跑模型的显卡（或者 Apple Silicon）。硬盘至少留 100GB 给模型和容器。

第二步：安装 Docker。按前面说的方法装好，配置镜像加速器，验证docker run hello-world能跑通。

第三步：安装 Ollama。装好后拉一个模型，验证能对话。

第四步：部署 Dify。用 docker compose 拉起，初始化管理员账号。

第五步：打通 Dify 和 Ollama。在 Dify 里添加 Ollama 供应商，填对地址，测试连通。

第六步：接入 DeepSeek。添加云端供应商，填 API Key，测试连通。

第七步：建第一个应用。在 Dify 里创建一个「聊天助手」，模型选 Ollama 的本地模型，测试对话。

第八步：配置兜底逻辑。在工作流里加条件分支，根据输入长度或任务类型切换模型。

这套流程走下来，大概需要一到两个小时，主要时间花在下载镜像和模型上。

4.2 知识库搭建：让本地模型读懂你的文档

知识库是这套平台最有价值的部分之一。它让本地模型能够基于你的私有文档回答问题，而不需要把文档传到外部。

创建知识库。在 Dify 里点「知识库」→「创建」，填写名称和描述。

上传文档。支持 PDF、Word、Markdown、TXT 等格式。上传后，Dify 会自动做文本切分和向量化。

切分策略。这是影响效果的关键。默认的自动切分有时候会把一段完整的内容切碎，导致检索效果差。我的经验是：

• 对于结构清晰的文档（比如产品手册），用「自定义」切分，按标题层级切。
• 对于长篇文章，设置合适的块大小，一般 500 到 1000 字比较合适。
• 块之间保留一定的重叠，避免上下文断裂。

向量模型选择。Dify 默认用 OpenAI 的 embedding 模型，但这需要联网。如果你想完全本地化，可以用 Ollama 里的 embedding 模型，比如nomic-embed-text。在知识库设置里选择 Ollama 作为 embedding 供应商即可。

检索测试。文档处理完后，用几个问题测试检索效果。如果回答不准确，调整切分策略或者增加检索条数。

提示：知识库的检索质量，七分靠文档质量，三分靠参数调优。文档本身结构清晰、内容准确，比任何参数调整都管用。

4.3 工作流编排：把多个步骤串起来

Dify 的工作流功能是它区别于普通聊天工具的核心。你可以把「检索、生成、判断、格式化」这些步骤串成一条流水线。

一个典型的工作流：

1. 开始节点：接收用户输入。
2. 条件判断节点：判断输入长度是否超过阈值。
3. 知识库检索节点：从指定知识库检索相关片段。
4. LLM 节点：把检索结果和用户问题一起交给模型生成回答。
5. 条件分支：如果本地模型置信度低，切换到 DeepSeek。
6. 输出节点：格式化最终回答。

配置要点：

• 条件判断用「IF/ELSE」节点，条件可以基于变量长度、关键词匹配等。
• LLM 节点里可以配置多个模型，用变量控制选哪个。
• 输出节点支持 Markdown 格式化，让回答更易读。

常见坑：工作流里的变量传递容易出错。每个节点的输出变量名要记清楚，引用的时候别写错。建议每加一个节点就测试一次，别等全搭完再调。

4.4 模型路由与兜底策略实现

这是整套架构的灵魂。我用了两种方式实现兜底。

方式一：Dify 内置的模型路由。在应用设置里，可以配置「主模型」和「备用模型」。当主模型调用失败时，自动切到备用模型。这种方式简单，但触发条件比较单一，只适合处理服务不可用的情况。

方式二：工作流条件分支。这种方式更灵活，可以根据输入内容动态选择模型。比如：

• 输入 tokens 数小于 4000，走本地模型。
• 输入 tokens 数大于 4000，走 DeepSeek。
• 输入包含「代码」「推理」等关键词，走 DeepSeek。
• 其他情况走本地。

实现方法是在工作流里加一个「条件分支」节点，用{{#sys.query#}}的长度作为判断条件。

实测效果：日常问答 90% 走本地，响应快、零成本；遇到复杂任务自动切云端，质量有保障。整体成本比全走云端降低了大概七成。

4.5 数据迁移与备份

这套系统跑起来之后，数据就是最值钱的东西。我踩过一次坑：机器重装，忘了备份 Dify 的数据卷，结果知识库和对话记录全没了。从那以后，我养成了定期备份的习惯。

需要备份的东西：

• Dify 的 PostgreSQL 数据（应用配置、知识库元数据、对话记录）
• Dify 的存储目录（上传的文档、生成的向量）
• Ollama 的模型目录（虽然可以重新下载，但备份能省时间）

备份方法：

# 备份 PostgreSQL docker exec dify-db pg_dump -U postgres dify > dify_backup.sql # 备份数据卷 docker run --rm -v dify_data:/data -v $(pwd):/backup alpine tar czf /backup/dify_data.tar.gz /data

迁移方法：在新机器上部署好 Dify，把备份文件恢复进去，重启服务即可。

注意：迁移时要注意版本一致性。Dify 不同版本的数据结构可能不同，跨大版本迁移前先看官方升级说明。

5. 常见问题与排查技巧实录

5.1 部署阶段高频问题速查

5.2 模型调用阶段高频问题

问题一：Ollama 接口不通。先确认 Ollama 是否在运行（ollama list），再确认监听地址（OLLAMA_HOST），最后用curl测试接口。三步走下来，基本能定位问题。

问题二：Dify 调用 Ollama 超时。通常是网络问题。如果 Dify 在 Docker 里，Ollama 在宿主机，要确保容器能访问宿主机的 IP。Linux 下可以用host.docker.internal这个特殊域名（需要在 compose 文件里加extra_hosts配置）。

问题三：模型回答质量差。本地小模型的能力有限，这是客观事实。解决办法有两个：一是换更大的模型，二是优化提示词。提示词里明确角色、任务、输出格式，效果会好很多。

问题四：DeepSeek 调用报 401。检查 API Key 是否正确、是否过期、是否有余额。Key 复制时注意别带空格。

问题五：上下文超长。在工作流里加一个「文本裁剪」节点，只保留最相关的部分。或者用「摘要」节点，先把长文本压缩再传给模型。

5.3 性能优化与资源调度

优化一：模型常驻显存。Ollama 默认会在空闲一段时间后卸载模型，下次调用又要重新加载，很慢。可以设置OLLAMA_KEEP_ALIVE环境变量，让模型常驻：

export OLLAMA_KEEP_ALIVE=-1

优化二：限制并发。本地资源有限，并发太高会拖垮整个系统。在 Dify 里配置请求队列，限制同时处理的请求数。

优化三：用 SSD 存模型。模型加载速度受磁盘影响很大。把模型目录放在 NVMe SSD 上，加载速度能快好几倍。

优化四：合理选择量化等级。量化等级越高，模型越小、越快，但质量会下降。Q4 量化是质量和速度的平衡点，推荐优先选。

5.4 我踩过的三个真实坑

坑一：把 Ollama 地址填成 localhost。这个坑我踩了两次。Dify 在 Docker 里，Ollama 在宿主机，填localhost:11434永远连不上。正确做法是填宿主机的内网 IP，或者在 compose 里配置host.docker.internal。

坑二：知识库文档格式不兼容。我上传了一批扫描版 PDF，Dify 解析出来全是乱码。后来才知道，扫描版 PDF 需要 OCR 处理，Dify 默认不支持。解决办法是先用 OCR 工具转成文本，再上传。

坑三：忘记备份数据卷。前面说过，机器重装丢了数据。现在我每周自动备份一次，用 cron 定时跑备份脚本，再同步到另一块硬盘。

6. 这套平台后续还能怎么扩展

6.1 接入更多本地模型做任务分流

现在我只装了两三个模型，后续打算按任务类型装更多。比如：

• 小模型（2B 到 3B）：做意图识别、文本分类、简单抽取，速度快、占用少。
• 中模型（7B 到 14B）：做日常对话、文案生成、知识库问答。
• 大模型（32B 以上）：做复杂推理、代码生成，本地跑不动就走云端。

在 Dify 里可以配置多个模型，用工作流根据任务类型自动选择。这样既能保证效果，又能节省资源。

6.2 用 API 把能力开放给其他工具

Dify 的每个应用都可以发布成 API。这意味着我可以把这套平台的能力，接入到其他工具里。比如：

• 接入到自己的笔记软件，实现本地 AI 辅助写作。
• 接入到团队的内部系统，做智能客服。
• 接入到自动化脚本，做批量文档处理。

发布 API 的方法很简单，在应用设置里点「发布」→「API 访问」，拿到 API Key 和接口地址，就能在其他地方调用了。

6.3 多用户与权限管理

如果团队要用，就需要考虑多用户和权限。Dify 支持创建多个成员账号，可以设置不同的角色和权限。比如：

• 管理员：可以配置模型、管理知识库。
• 普通成员：只能使用应用，不能改配置。
• 访客：只能查看，不能操作。

这样既能共享资源，又能保证安全。

6.4 监控与日志

跑久了之后，监控很重要。我目前用 Docker 自带的日志功能，加上一个简单的监控脚本。主要看几个指标：

• Ollama 的显存占用和响应时间。
• Dify 的请求量和错误率。
• DeepSeek 的调用次数和费用。

这些数据能帮我判断什么时候该升级硬件，什么时候该调整模型策略。

7. 一些掏心窝子的经验

7.1 别追求一步到位

我见过太多人，一上来就想搭一个完美的系统，结果卡在某个环节就放弃了。我的建议是：先跑起来，再优化。哪怕一开始只用最简单的配置，只要能跑通，就有继续折腾的动力。我第一版部署，连知识库都没配，就是单纯的本地对话，但那个成就感已经足够让我继续下去了。

7.2 本地模型不是万能的

这一点必须说清楚。本地小模型在复杂推理、长文本理解、多语言任务上，和云端大模型差距明显。所以「本地优先、云端兜底」这个策略的核心，不是要证明本地比云端强，而是要找到一个成本和效果的平衡点。日常任务本地扛，关键任务云端上，这才是理性的做法。

7.3 数据安全是最大的收益

抛开成本不谈，这套平台给我最大的安全感，是数据不出本地。我的笔记、团队的文档、客户的资料，全都在自己的机器上处理。这种掌控感，是任何云端服务都给不了的。对于有数据隐私要求的场景，这一点比省钱更重要。

7.4 社区是最好的老师

搭建过程中遇到问题，我大部分时候是靠社区解决的。Dify 和 Ollama 的 GitHub Issues、讨论区，还有各种技术社区，里面有大量真实案例。遇到报错，先搜一下，大概率有人踩过同样的坑。实在找不到，再自己排查。

最后分享一个小技巧：每次改动配置之前，先备份。Docker 的好处就是，改坏了直接docker compose down再up，几分钟就能恢复。有了这个底气，折腾起来就大胆多了。