1. 为什么我决定不再给云端 API 打工1.1 一个让我彻底破防的账单夜晚去年冬天的一个晚上我盯着后台的 API 消费明细整个人是懵的。那个月我做了三个小工具一个帮团队整理会议纪要的助手、一个给客户做文档问答的机器人、还有一个自己用的代码片段检索器。三个东西加起来一个月烧掉了将近四百块。钱不算多但问题在于——我根本不知道这些钱花在哪了。哪个请求贵、哪个模型被反复调用、哪次是测试时忘了关循环全都是一笔糊涂账。更让我难受的是那种被掐着脖子的感觉。接口一限流我的工具就瘫密钥一泄露账单就失控服务商一调整策略我前一天还能用的功能第二天就报错。我试过在代码里加各种重试、加缓存、加降级但本质上还是在别人的地基上盖房子地基一抖我这边全塌。后来我算了一笔账我手头有一台闲置的迷你主机32G 内存带一块不算顶级的显卡。如果把这台机器利用起来跑本地模型日常那些整理纪要文档问答代码检索的活儿其实根本用不着云端的大模型。真正需要云端算力的只有那些复杂推理、长文档深度分析、或者本地模型明显搞不定的场景。于是就有了这套**「本地优先、云端兜底」**的私有 AI 平台。核心思路特别简单能本地跑的绝不走云端本地跑不动的再交给云端而且云端只作为最后一道保险不是主力。这套东西我用 Dify 做编排层Ollama 做本地模型运行时DeepSeek 做云端兜底搭完之后每个月的 API 支出直接降到了原来的十分之一不到而且响应速度反而更快了——因为大部分请求根本不出我的局域网。1.2 这套平台到底适合谁先说清楚这套方案不是给所有人准备的。如果你只是偶尔用用聊天窗口那直接用现成的服务最省事。但如果你符合下面任意一条这套东西值得你花一个周末折腾一下你手头有闲置的电脑或迷你主机想把它变成一台随时可用的 AI 服务器你每个月在 API 上的支出超过一百块且大部分是重复性的日常任务你对数据隐私有要求不希望自己的文档、代码、会议记录离开本地网络你想学 Dify、Ollama 这些工具但一直找不到一个完整的实战项目练手你受够了云端服务的限流和不确定性想要一个自己能完全掌控的方案。我搭这套东西前后花了大概两个周末中间踩了不少坑也走了不少弯路。下面我把整个思路、选型理由、实操步骤、还有那些文档里不会写的坑全部摊开讲一遍。你照着做大概率能少走一半的弯路。1.3 整体架构长什么样在动手之前先把架构想清楚不然装到一半会乱。我这套平台分三层第一层是接入层也就是 Dify。所有对外的入口都在这里——网页对话、API 接口、工作流编排、知识库管理全由 Dify 统一处理。用户或者我自己的工具只跟 Dify 打交道不直接碰后面的模型。第二层是模型路由层这是整套方案的核心。Dify 里配置了多个模型供应商Ollama 指向本地模型DeepSeek 指向云端接口。通过 Dify 的模型配置和工作流逻辑我可以决定哪些任务走本地、哪些走云端。简单任务默认走本地本地模型返回质量不达标或者任务复杂度超过阈值时自动切换到云端。第三层是模型运行时层本地这边是 Ollama 在跑各种开源模型云端那边是 DeepSeek 的 API。Ollama 负责把模型加载进内存、处理推理请求、返回结果它对上层暴露一个兼容 OpenAI 格式的接口Dify 直接就能对接。这三层的好处是解耦。哪天我想换本地模型只动 Ollama 那一层哪天我想换云端供应商只动 Dify 里的配置哪天我想加一个新的接入方式也只动 Dify。每一层都可以独立替换不会牵一发动全身。提示架构设计阶段最重要的不是选哪个模型而是想清楚什么任务走本地、什么任务走云端这条分界线。这条线画错了后面怎么调都别扭。2. 工具选型为什么是 Dify Ollama DeepSeek2.1 Dify 凭什么做编排层市面上做 AI 应用编排的工具不少我最后选 Dify理由很实在。第一是它自带知识库和 RAG 流水线。我要做的文档问答最麻烦的不是模型而是文档解析、切分、向量化、检索这一整套流程。Dify 把这些都封装好了我上传文档、选好切分策略、配好向量模型它就能跑起来。自己从零搭这一套光调切分参数就能调一个星期。第二是它的工作流编排足够灵活。我可以在一个工作流里放多个模型节点前面用本地模型做初筛后面用云端模型做精修中间还能加条件判断、代码执行、HTTP 请求。这种本地云端的混合逻辑用 Dify 的工作流画出来特别直观。第三是它部署简单。Dify 社区版用 Docker Compose 就能拉起来官方给的配置文件基本开箱即用。我这种不想在部署上花太多时间的人这点很关键。当然它也有坑。比如那个经典的unstructured api url is not configured for doc file processing报错就是文档处理服务没配好导致的还有an error occurred during credentials validation这种凭证校验失败多半是模型供应商的地址或密钥填错了。这些后面会细说。2.2 Ollama 为什么是本地运行时的首选本地跑模型的方案有好几个Ollama、vLLM、还有直接用 llama.cpp。我选 Ollama核心原因是它对个人开发者最友好。vLLM 性能确实强吞吐量高但它的部署复杂度也高配置项多对显卡显存的要求也更苛刻。llama.cpp 足够轻量但你要自己处理模型格式转换、量化、参数调优门槛不低。Ollama 刚好卡在中间一条ollama run命令就能把模型跑起来模型管理、显存调度、接口暴露它全帮你做了同时性能也够个人和小团队用。Ollama 默认监听11434端口暴露的是兼容 OpenAI 的接口Dify 里直接选 Ollama 供应商填上地址就能用。这个兼容性省了我大量对接工作。不过 Ollama 也有它的问题。最典型的就是下载慢——默认从官方源拉模型国内网络环境下经常龟速甚至断流。解决办法是用离线安装包或者配置国内镜像源。另外它跑模型时偶尔会报500 internal server error: llama-server process这类错误多半是显存不够或者模型文件损坏后面排查章节会讲。2.3 DeepSeek 做云端兜底的三个理由云端兜底我选 DeepSeek不是因为它最便宜而是因为它在性价比和稳定性上最均衡。第一它的 API 价格在同类里属于很能打的尤其是输入 token 的定价做兜底这种低频调用成本几乎可以忽略。第二它的模型能力足够强本地模型搞不定的复杂推理、长文档分析交给它基本都能得到靠谱结果。第三它的接口兼容 OpenAI 格式Dify 里配置起来跟配其他供应商没区别。这里要提醒一句DeepSeek 的 API 密钥格式是sk-开头的一长串配置时千万别填错。我见过太多人报unexpected status 401 unauthorized: incorrect api key provided这个错九成是密钥复制时多了空格或者少了几位。另外它的上下文长度很大但也不是无限的遇到maximum context length is 1048576 tokens这种报错说明你塞进去的内容确实太长了得在 Dify 里做截断或者分段。2.4 三者组合的化学反应单独看这三个工具每个都有替代品。但组合在一起它们形成了一个很舒服的分工层级工具职责替代方案编排层Dify应用编排、知识库、工作流、API 网关FastGPT、Flowise本地运行时Ollama本地模型加载与推理vLLM、llama.cpp云端兜底DeepSeek复杂任务、长上下文处理其他兼容 OpenAI 的云服务Dify 负责决定谁来干活Ollama 负责本地能干的活DeepSeek 负责本地干不了的活。三者通过标准接口连接谁出问题换谁不影响其他部分。这种松耦合的设计是我踩了无数次坑之后最满意的地方。3. 本地环境搭建从零把 Ollama 跑起来3.1 硬件准备与模型选型先说硬件。我这台机器是 32G 内存加一块 12G 显存的显卡。这个配置能跑什么模型直接决定了整套平台的体验。模型选型有个简单的估算方法模型参数量乘以量化位数再除以 8就是大概需要的显存。比如一个 7B 参数的模型用 4 位量化大概需要 7 × 4 / 8 3.5G 显存加上推理时的额外开销留 5G 左右比较稳妥。14B 的模型 4 位量化大概要 8G 到 10G 显存。32B 的模型 4 位量化就要 20G 往上了12G 显存基本没戏。我实际用的组合是这样的日常对话和简单问答跑一个 7B 到 8B 的通用模型响应快占用低代码相关任务跑一个专门的代码模型7B 左右对代码理解明显更好文档问答这个其实主要靠 Dify 的 RAG 流水线模型用通用的就行关键是检索质量。注意别一上来就想着跑最大的模型。我一开始非要跑 32B结果显存爆了系统疯狂用内存交换响应慢到没法用。后来退回到 8B体验反而好得多。本地模型的核心优势是快和私密不是最强。3.2 Ollama 安装的两种路径Ollama 安装有两条路在线安装和离线安装。在线安装最简单官方提供了一键脚本。Linux 下执行安装命令它会自动下载二进制、配置系统服务、启动守护进程。macOS 和 Windows 也有对应的安装包双击就行。但国内网络环境下在线安装经常卡在下载模型这一步。这时候有两个办法办法一是配置镜像源。Ollama 支持通过环境变量指定模型下载的源地址把它指向国内可访问的镜像下载速度会快很多。具体配置方式是在启动 Ollama 服务前设置环境变量不同系统的设置方式略有差异。办法二是用离线安装包。先把模型文件通过其他方式下载到本地然后手动导入。Ollama 的模型文件是分层的导入时用ollama create命令配合一个 Modelfile 就能把本地文件注册成可用模型。这个方式适合网络实在不通的情况。我自己的做法是Ollama 本体用在线安装本体不大下载很快模型用镜像源拉。这样最省事。3.3 验证 Ollama 是否正常工作装完之后别急着接 Dify先在本地验证一遍。打开终端执行ollama list这个命令会列出本地已有的模型。如果是刚装好列表是空的正常。然后拉一个模型试试ollama pull qwen2.5:7b拉完之后再ollama list应该能看到这个模型。接着直接跟它对话ollama run qwen2.5:7b进入交互界面后随便问一句比如你好帮我写一个 Python 的快速排序。如果它能正常回复说明 Ollama 本体没问题。最后验证接口。Ollama 默认在11434端口暴露 HTTP 接口用 curl 测一下curl http://localhost:11434/api/tags这个接口会返回本地所有模型的列表。如果返回了 JSON 数据说明接口正常Dify 那边就能对接了。提示如果ollama run时报500 internal server error: llama-server process先检查显存是不是不够。用nvidia-smi看一下显存占用如果已经满了换个更小的模型或者关掉其他占显存的程序。3.4 让 Ollama 开机自启并稳定运行个人用的话Ollama 装完默认就会作为系统服务运行开机自启。但有几个细节要注意。第一是监听地址。默认 Ollama 只监听127.0.0.1也就是只有本机能访问。如果你想让局域网里的其他设备也能用需要把它改成监听0.0.0.0。这个通过设置OLLAMA_HOST环境变量来实现。改完之后记得重启服务。第二是模型常驻内存。Ollama 默认会在模型一段时间不用后把它从显存里卸载下次用再重新加载。这个加载过程可能要几秒到十几秒。如果你希望常用模型一直待命可以设置OLLAMA_KEEP_ALIVE环境变量把它设成一个较大的值或者-1永久保留。代价是显存一直被占着自己权衡。第三是并发数。Ollama 默认一次只处理一个请求如果你有多个任务同时来后面的会排队。可以通过OLLAMA_NUM_PARALLEL调整并发数但要注意显存够不够支撑多个请求同时推理。4. Dify 部署与模型对接实战4.1 Dify 的 Docker 部署流程Dify 社区版官方推荐用 Docker Compose 部署。流程不复杂但有几个地方容易出问题。第一步把 Dify 的代码仓库克隆到本地。第二步进入docker目录把环境变量示例文件复制成正式的环境变量文件。第三步根据需要修改环境变量比如端口号、数据库密码这些。第四步执行docker compose up -d启动所有服务。启动过程会拉取好几个镜像Dify 的 API 服务、Web 前端、PostgreSQL 数据库、Redis 缓存、还有向量数据库。第一次启动会比较慢取决于网络。全部拉起来之后访问配置的端口应该能看到 Dify 的初始化页面让你设置管理员账号。这里有个 Windows 用户常踩的坑Docker Desktop 的资源限制。Windows 下 Docker 默认给容器的内存可能不够Dify 跑起来会各种报错。解决办法是在 Docker Desktop 的设置里把内存调大至少给 8G16G 更稳妥。4.2 在 Dify 里配置 Ollama 供应商Dify 跑起来之后进设置里的模型供应商页面找到 Ollama点添加模型。需要填的关键信息有两个模型名称和基础地址。模型名称就是你在 Ollama 里ollama list看到的那个名字比如qwen2.5:7b。基础地址填 Ollama 服务的地址如果 Dify 和 Ollama 在同一台机器上但 Dify 跑在 Docker 里这里要注意——Docker 容器里的localhost指的是容器自己不是宿主机。这是新手最容易卡住的地方。解决办法有两个一是用宿主机的局域网 IP 代替localhost比如http://192.168.1.100:11434二是在 Docker Compose 里配置host.docker.internal这个特殊域名它指向宿主机。填完之后点保存Dify 会做一次凭证校验。如果报an error occurred during credentials validation八成是地址填错了或者 Ollama 没在监听那个地址。回去检查 Ollama 的OLLAMA_HOST设置确认它监听的地址和 Dify 里填的一致。4.3 配置 DeepSeek 作为云端兜底Ollama 配好之后同样在模型供应商页面找到 DeepSeek添加模型。需要填的是API 密钥和模型名称。密钥从 DeepSeek 的开发者后台获取格式是sk-开头的一长串。模型名称填你要用的那个比如deepseek-chat。这里最常见的错误就是unexpected status 401 unauthorized: incorrect api key provided。这个报错基本只有一个原因密钥不对。可能是复制的时候带了空格可能是密钥已经失效也可能是把别的服务的密钥填进来了。仔细核对一遍重新复制粘贴一般就能解决。配好之后建议在 Dify 里建一个最简单的对话应用分别选 Ollama 的模型和 DeepSeek 的模型各测一次确认两条路都通。这一步别省后面工作流出问题时你才能快速判断是编排逻辑的问题还是模型对接的问题。4.4 模型路由策略的设计两条路都通了之后就要设计什么任务走哪条路的策略。我的策略分三档第一档纯本地。日常对话、简单问答、格式转换、文本摘要这类任务全部走 Ollama。这些任务对模型能力要求不高本地模型完全够用而且响应快、不花钱。第二档本地优先云端兜底。文档问答、代码解释这类任务先用本地模型试如果本地模型返回的结果明显不靠谱比如答非所问、胡编乱造再走云端。这个判断逻辑可以在 Dify 的工作流里用条件节点实现。第三档直接云端。复杂推理、长文档深度分析、需要最新知识的任务直接走 DeepSeek。这些任务本地模型确实搞不定硬撑只会浪费时间。在 Dify 的工作流里这个策略通过问题分类器节点加条件分支节点来实现。问题分类器先判断任务类型然后条件分支决定走哪个模型节点。整个逻辑画出来一目了然改起来也方便。5. 知识库与 RAG 流水线的搭建5.1 文档上传与解析的坑Dify 的知识库功能是我用它的主要原因之一。上传文档、自动切分、向量化、检索一条龙。但文档解析这一步坑特别多。最常见的就是unstructured api url is not configured for doc file processing这个报错。这个错误的意思是你上传的文档格式比如 doc、docx需要用到 Unstructured 这个文档处理服务但 Dify 里没有配置它的地址。解决办法有两个。一是配置 Unstructured 服务Dify 的 Docker Compose 里其实包含了这个服务但默认可能没启用需要在环境变量里把它打开并配置好地址。二是把文档转成纯文本或 Markdown 再上传这样就绕过了复杂的文档解析Dify 内置的简单解析器就能处理。我自己的做法是能转 Markdown 就转 Markdown。Markdown 结构清晰、解析稳定、切分效果好比直接传 docx 省心得多。实在要传 PDF也尽量先用工具转成文本再上传。5.2 切分策略的选择文档切分是 RAG 效果的关键。切得太碎检索出来的片段缺乏上下文切得太大检索精度下降还会浪费 token。Dify 提供了几种切分方式。我常用的是按分隔符切分配合合适的块大小和重叠。块大小我一般设在 500 到 800 个字符之间重叠设 50 到 100 个字符。这个范围是试出来的——太小了检索片段不完整太大了检索不准。对于结构化的文档比如技术手册、产品文档我会用按标题切分让每个章节成为一个独立的块。这样检索出来的片段天然带有章节上下文效果比机械按字数切好很多。提示切分策略没有万能解一定要拿你自己的文档试。上传之后用几个典型问题去检索看返回的片段是不是你期望的那几段。不对就调参数调到满意为止。5.3 向量模型的选择Dify 的知识库需要配一个向量模型来做嵌入。这个模型负责把文本转成向量检索时再算相似度。向量模型可以走 Ollama 本地也可以走云端。我建议向量模型走本地因为嵌入这个操作调用频繁走云端成本会累积得很快而且嵌入对模型能力要求不高本地的小模型完全够用。Ollama 里可以拉专门的嵌入模型比如nomic-embed-text这类。拉下来之后在 Dify 的知识库设置里选它作为嵌入模型就行。注意嵌入模型的维度要和向量数据库的配置匹配不匹配会报错。5.4 检索效果的调优知识库搭好之后检索效果需要反复调。Dify 提供了几种检索方式向量检索、全文检索、混合检索。向量检索擅长语义匹配你问怎么退款它能找到退货流程相关的段落。全文检索擅长关键词精确匹配你搜一个具体的错误码它能精准定位。混合检索把两者结合效果通常最好但配置也最复杂。我的经验是先用混合检索调好权重。如果发现语义匹配太多导致答非所问就调高全文检索的权重如果发现关键词匹配太死导致漏掉相关内容就调高向量检索的权重。这个权重没有标准值完全看你的文档和问题类型。另外重排序这个功能值得开。它会在初步检索出一批候选片段后用一个专门的重排序模型再精排一遍把最相关的排到前面。开了之后检索质量通常有明显提升代价是多一次模型调用。6. 常见问题排查与避坑实录6.1 模型对接类问题速查这类问题占了新手报错的一大半整理成表格方便对照报错信息可能原因解决办法incorrect api key provided密钥错误、失效、或格式不对重新复制密钥检查有无空格credentials validation失败供应商地址填错或服务未启动检查地址、确认服务在运行unstructured api url is not configured文档处理服务未配置配置 Unstructured 或转 Markdown 上传maximum context length超限输入内容超过模型上下文限制在 Dify 里做截断或分段处理llama-server process错误显存不足或模型文件损坏换小模型或重新拉取模型6.2 性能与资源类问题响应慢是最常见的抱怨。排查顺序是这样的先看是不是模型太大导致显存不够系统在用内存交换再看是不是 Ollama 的模型被卸载了每次请求都要重新加载最后看是不是 Dify 的检索环节太慢比如知识库太大、检索候选太多。显存爆了通常发生在同时跑多个模型或者并发请求太多的时候。解决办法是限制 Ollama 的并发数或者错峰使用。如果实在不够就换更小的量化版本。Docker 容器吃内存是 Windows 用户的常见问题。Dify 那一套服务加起来内存占用不小。给 Docker 分配足够的内存或者把不用的服务停掉能缓解不少。6.3 数据迁移与备份Dify 的数据主要存在 PostgreSQL 和向量数据库里。迁移的时候这两个都要备份。PostgreSQL 用标准的备份命令导出就行。向量数据库要看具体用的是哪个Dify 默认用的是 Weaviate 或 Qdrant各自有备份方式。最省事的办法是把整个 Docker 数据卷打包迁移时整体搬过去。缺点是体积大优点是绝对不会漏东西。我自己的做法是定期把数据卷打包备份到另一块硬盘同时把 Dify 的应用配置导出成 YAML 文件单独存一份。这样即使数据卷坏了应用配置还在重建起来也快。6.4 我踩过的三个印象最深的坑第一个坑是 Docker 网络。我一开始怎么都连不上 Ollama报了一堆连接错误。折腾了半天才发现Dify 跑在 Docker 里容器里的localhost根本不是宿主机。改成宿主机的局域网 IP 之后一次就通了。这个坑我后来在好几个朋友那里都见过属于必踩项。第二个坑是模型下载。我一开始用默认源拉模型一个 7B 的模型拉了两个小时还没拉完中间还断了一次。后来配了镜像源同样的模型十分钟就拉完了。这个体验差距太大了强烈建议一开始就把镜像源配好。第三个坑是知识库切分。我一开始用默认参数切分一份技术文档结果检索出来的片段全是半截话答非所问。后来把块大小调大、加了重叠、改成按标题切分效果立刻就不一样了。切分这件事真的值得花时间调。7. 这套平台跑起来之后我的真实感受7.1 成本与体验的实际变化搭好之后我统计了一个月的数据。之前纯用云端 API月支出大概四百块。现在本地承担了大约八成的请求量云端只处理剩下两成的复杂任务月支出降到了四十块左右。省下来的钱不算多但那种掌控感是钱买不来的。响应速度方面本地模型因为不出局域网首字延迟明显更低。日常问答基本是秒回比云端快不少。只有走云端兜底的那些复杂任务速度跟以前差不多。7.2 什么任务适合本地什么任务必须云端用了一个月我对这条分界线有了更清楚的认识。适合本地的格式转换、文本摘要、简单问答、代码补全、日常对话、文档初筛。这些任务本地模型做得又快又好完全没必要走云端。必须云端的复杂逻辑推理、长文档深度分析、需要最新知识的问答、多步骤的规划任务。这些任务本地模型要么做不了要么做得一塌糊涂硬撑只会浪费时间。介于两者之间的中等复杂度的文档问答、代码解释、内容改写。这些任务本地模型能给出个大概但质量不稳定。我的做法是本地先跑一遍结果不满意再走云端。7.3 后续可以怎么扩展这套平台搭好之后扩展空间很大。可以加更多的本地模型针对不同任务用不同的模型比如代码用一个、通用对话用一个、嵌入用一个。可以加缓存层把常见问题的答案缓存起来进一步减少模型调用。可以加监控记录每个请求走了哪条路、耗时多少、成本多少让整个系统的运行状况一目了然。还可以把 Dify 的 API 暴露给其他工具让这套平台成为整个工作流的 AI 中枢。我最近在试的是把一些重复性的工作流固化下来比如收到文档自动摘要并归档代码提交自动生成变更说明这类。Dify 的工作流编排能力做这些事很顺手配好之后基本就是全自动运行。最后分享一个我用了很久的小技巧给本地模型和云端模型分别建一个测试用例集。每次调整配置或者换模型都拿这个用例集跑一遍对比结果。这样你能清楚地知道改动带来了什么影响而不是凭感觉判断好像变好了。这个习惯帮我省了很多来回折腾的时间。