几天前DeepSeek大火的时候我就在朋友圈看到一堆人转发它的评测。说实话模型本身确实很强但大部分人试完网页版之后就停了。为什么因为单靠一个聊天框你没法把自己的文档、业务逻辑、私有知识揉进去也没法让它在不同任务之间自动流转。这也是我后来决定在Mac上跑一套本地AI工作流的原因——把DeepSeek这种模型能力装进一个真正能干活、能编排、能落地的容器里。而Dify恰好补上了这个最核心的拼图开源、可视化、本地部署配合DeepSeek后等于把玩具变成了工具。这篇文章就来拆解我在Mac上从零搭这套组合的全部过程包括安装、配置、工作流编排以及过程中踩进去又爬出来的各种坑。1. 为什么是Dify DeepSeek这套组合到底解决什么问题1.1 从碎片化调用API到可视化工作流如果你是做技术开发的可能体会过这种状态项目里东拼西凑调各个大模型的API前面用OpenAI后面又接个LangChain结构稍微复杂一点代码维护成本立刻指数上涨。我有段时间就在Jupyter里反复实验Prompt每次都写几十行代码去调API、解析JSON改一个参数就得重跑一遍。也许不是不能跑但总觉得哪里不对劲。Dify解决的是把模型调用变成搭积木。它是一个开源的大语言模型应用开发平台安装之后你能在网页界面上完成模型管理、Prompt编排、知识库集成和Agent构建。不需要自己写一个完整的前后端也不需要维护复杂的调度逻辑。工作流中的每个节点就是一项功能比如知识检索、LLM、条件分支、代码执行你只需要拖拽和连线就能拼出一个能跑的AI应用。这套模型跟DeepSeek结合起来就很舒服。DeepSeek是国产开源大模型既有官方API可以使用也有蒸馏版本可以本地部署。模型本身能力在线推理、写作、代码生成都有不错的表现。而Dify提供了封装层让我不用关心调用细节把DeepSeek作为一个能力底座挂进去然后在这个底座之上随便搭东西。1.2 DeepSeek为什么值得当主力模型DeepSeek-R1系列出来后很多人都拿它跟多家海外模型对比。从使用角度讲它的核心优势有几方面推理能力强在数学、代码、逻辑推理类任务上表现扎实适合做需要多步分析的Agent底座。上下文支持长最新模型可以容纳很长的对话历史这意味着把它接入知识库问答时一次性给足背景信息不用太担心截断。成本敏感用户友好API定价比主流海外模型便宜很多有缓存机制不会在调试阶段烧掉太多预算。开源生态丰富有多个量化版本普通Mac也能通过Ollama跑起来数据完全不离开本机。但我也得说个实话本地部署的DeepSeek蒸馏版比如7B/8B跟API版的满血版还是有差距。遇到复杂推理任务小模型容易一本正经地胡说八道。所以我的个人经验是如果只是做个人实验或对隐私要求极高本地部署可以如果真正要投入生产还是用官方API更稳。后面我会详细拆这两种接入方式。2. Mac上的环境准备Docker、镜像加速与Dify安装2.1 安装Docker Desktop以及国内镜像加速的配置Dify官方推荐用Docker Compose部署所以Mac上的第一步是把Docker装好。最直接的方式是去Docker官网下载Docker Desktop for Mac装上之后在终端里执行docker version确认。如果你习惯用Homebrew也可以brew install --cask docker有些人在安装Homebrew时会卡住多半是网络源的问题。国内环境建议把Homebrew的下载源替换成清华或中科大的镜像具体做法网上都有这里不展开。装好Docker Desktop后一定要在启动前先把镜像加速配置好不然后面拉取Dify等镜像时大概率超时。打开Docker Desktop - Settings - Docker Engine在registry-mirrors里添加你自己的加速地址。比如阿里云容器镜像服务的专属加速地址每个人都是独立域名也可以填公共的镜像加速地址。配置完之后点Apply Restart。提示加速器不是代理它只是镜像仓库的缓存副本。配置加速器后拉取Docker Hub上公开镜像的速度会明显提升这是合规、稳定的做法。2.2 使用docker compose拉起Dify社区版Dify社区版部署方式很简单官方仓库里已经写好了docker-compose文件。我建议直接采用指定版本的方式下载避免最新代码引入不稳定因素。例如当前热门的社区版1.17.1版本git clone https://github.com/langgenius/dify.git cd dify git checkout 1.17.1 cd docker cp .env.example .env docker compose up -d首次执行会拉取后端API、Worker、Web前端、PostgreSQL、Redis、Sandbox等镜像。镜像数量不算少但配置完加速器后整体时间还能接受。等日志里出现api和worker相关的启动成功输出后浏览器访问http://localhost即可看到Dify界面。如果Mac的80端口已被占用可以在.env文件里修改EXPOSE_NGINX_PORT比如改成8080访问时就用http://localhost:8080。2.3 拉取镜像失败时的排查思路拉取镜像失败是Dify部署中排名前三的坑。我自己也遇到过现象是执行docker compose up -d后卡在Pulling阶段下载速度为零或者报EOF、timeout错误。排查链路大概是这样的先确认Docker Desktop已经启动按住菜单栏的Docker鲸鱼图标看状态。确认registry-mirrors是否生效在终端执行docker info在输出里找到Registry Mirrors如果能看到你填的地址说明Docker读取到了。如果已经配置了加速器依然拉取失败大概率是某个镜像名称不再托管在Docker Hub上而是需要从GitHub Container Registry拉取。这种情况Docker的镜像加速器帮不上忙需要单独检查docker-compose.yaml里有没有image: ghcr.io/...开头的镜像。可以给Docker Desktop配置HTTP代理但如果你完全没有代理条件看能否切换到国内可以拉取的替代镜像源。也可以先把失败的镜像一个一个手动docker pull找出具体是哪个仓库的镜像卡住再对症下药。我实际部署时还遇到过一次端口冲突导致PostgreSQL容器反复重启。排查方法是看到某个容器状态为Restarting执行docker logs 容器名看日志报错。如果是端口冲突直接修改.env中POSTGRES_PORT即可。3. DeepSeek的两种接入姿势本地Ollama与官方API3.1 本地部署DeepSeek模型的硬件门槛与实际体验DeepSeek开源了一系列可商用模型其中蒸馏版本可以通过Ollama在Mac上跑。Ollama是一个极简的本地模型运行工具支持Apple Silicon加速。安装很简单brew install ollama装好之后拉取一个适合自己内存的模型。以我的MacBook Pro16GB内存为例跑deepseek-r1:7b算是流畅的跑14b会明显吃紧推理速度变慢甚至内存压力增大。如果你用的是Mac mini M2 32GB可以尝试更大的模型。ollama pull deepseek-r1:7b ollama run deepseek-r1:7b本地部署的好处是数据不出机器适合处理完全不能外传的文档。但实际体验上7B模型用于简单问答还行用于复杂推理时经常会出现自相矛盾。所以我的定位是本地模型作为私密数据的快速消化器和API宕机时的兜底方案真正的生产主力还是官方API。3.2 通过Ollama在Mac上跑DeepSeek具体分三步启动Ollama后台服务安装完成后直接运行ollama serve或者如果你是通过桌面端安装的它会自动随登录启动。下载模型执行ollama pull deepseek-r1:7b。这一步会从模型仓库下载数GB的数据需要一些时间。验证可用性新开一个终端执行以下curl命令如果返回JSON格式的响应说明本地接口已经通了curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 什么是Dify }要注意Ollama的接口地址是http://localhost:11434这个信息后面在Dify配置时要用到。另外Dify容器里访问宿主机时不能直接用localhost而是要用host.docker.internal这一点很多人第一次都会忽略后面我会单独讲。3.3 官方API接入方式与费用预估DeepSeek官方API的申请流程非常顺畅去开放平台注册账号、创建API Key然后充值一点点钱就能开始调用。接口兼容OpenAI格式所以Dify里可以直接选DeepSeek供应商填入API Key就完成接入了。费用方面DeepSeek官方API是按token计费。以我测试的V3和R1模型来说输入百万token几块钱输出百万token十几块到几十块钱具体以官网实时报价为准。对有缓存机制的场景命中的输入token会更便宜。整体算下来个人搭建的工作流日常跑量不多每个月甚至花不到一杯咖啡的钱。那么问题来了本地模型和API该怎么选我给一个很现实的建议场景推荐方式隐私文档处理、离线环境本地Ollama复杂推理、高准确率问答官方API学习调参、功能Demo本地Ollama免费生产级、多人使用官方API稳定4. 在Dify中配置DeepSeek供应商4.1 在Dify中添加模型供应商进入Dify后台点击头像下方或左侧菜单里的设置选择模型供应商。页面会列出已经支持的各类模型平台。我们要添加两类Ollama用于接入本地DeepSeek。DeepSeek用于接入官方API。对Ollama点击进入供应商配置页后需要填写两个关键字段API Base URL填写http://host.docker.internal:11434。因为Dify容器在Docker内部直接填localhost会指向容器自身导致无法访问宿主机上的Ollama。Model Name填写你在ollama list中看到的模型名称比如deepseek-r1:7b。完成之后Dify会自动向Ollama发一个验证请求。如果配置正确就能看到绿色提示并能在页面下方看到模型列表被动态加载出来。对DeepSeek官方API配置更简单API Key填你在DeepSeek开放平台创建的Key。其余参数保持默认即可。4.2 参数含义与推荐值配置完供应商后在具体应用里选择模型时会看到一组参数理解它们对工作流效果影响很大。Temperature温度取值范围0~2。值越低输出越稳定、保守值越高越发散。知识库问答建议设0.1~0.3创意写作可以设0.7以上。Top P核采样概率配合Temperature控制输出多样性。一般保持默认0.7或调成0.9即可。Max Tokens限制单次生成的最大token数。知识库回答通常设1000足够了。如果文档摘要任务长可以提高到2000以上。注意不要超出模型的最大上下文。Context Length上下文长度如果是通过Ollama配置本地模型这里设成4096或更高但要考虑内存占用。在Dify中配置好的模型参数会以模型配置的形式存在每个应用可以不同。实际调试时我习惯先调Temperature再调Max Tokens其他参数很少动。4.3 验证连通性与常见报错在模型供应商页面配置完通常会有测试按钮。点击后如果返回一段正常文本就表示通了。我在这个环节遇到过几个报错按热词里出现频率给大家排一下序Ollama: Failed to connect这多半是Base URL配置错了。确认是不是用了host.docker.internal而不是localhost。model not found模型名写错了。先执行ollama list查看准确名称注意名称里的版本后缀必须一致。deepseek request extension preparation failed这个报错我在官方API接入时见过一次通常是网络代理环境干扰或者API Key配置有隐藏空格。重新复制粘贴密钥检查环境变量后再次尝试。Connection error可能是Dify后端到目标接口的网络不通。本地Ollama的话先保证Ollama已经启动官方API的话确认网络能访问到开放平台域名。排查的时候记住一条核心原则一层一层拆。先确保命令行里直接调用目标模型是通的再去排查Dify本身的配置不要跳步。5. 从零搭建一条可落地的AI工作流5.1 创建知识库并完成文档分段与索引Dify的一大核心功能是知识库。我用的场景是把零散的产品说明、内部FAQ、操作手册整理成一个可检索的私有知识库。操作路径左侧菜单找到知识库点创建知识库上传PDF、Markdown或TXT文件。上传完后Dify会进行文档分段和索引。关键点在于分段设置。Dify提供两种模式通用分段按字符长度切分适合大多数场景。父子分段先切出段落再切出句子级片段兼顾精确召回和上下文完整。适合文档结构比较复杂的知识库。我通常选择通用分段把分段长度设置为500字符左右分段重叠设为50。这两个值决定检索时的碎片粒度分段太长命中后信息宽泛分得太细又可能丢失上下文。500/50是我试过比较平衡的一组值。索引方式上Dify提供高质量和经济型两种。高质量模式会用向量模型把文本转成向量检索效果更好建议直接选这个。经济型模式用关键词匹配速度快但召回质量会下降适合不需要语义理解的场景。5.2 编排知识问答Agent工作流知识库建好之后就可以在工作流里真正用起来了。在Dify的工作区新建一个空白应用选择Agent类型然后进入编排界面。我想要的是一个基于知识库回答问题的Agent用户提问后系统先检索知识库中相关文档片段再交给DeepSeek整理成自然语言回答。编排步骤如下添加开始节点定义输入变量query类型为Paragraph。添加知识检索节点关联之前创建的知识库TopK设置为3Score阈值设为0.5低于这个分数的片段基本不相关可以过滤掉。添加LLM节点选择DeepSeek模型在系统提示词模板里写入你是企业内部知识助手。请严格基于上下文中提供的内容回答问题。 如果上下文中没有相关内容请直接回答知识库中未找到相关信息不要编造。 上下文 {{#context#}}这里的{{#context#}}会自动引用前面知识检索节点的输出。将开始节点连接到知识检索节点再把知识检索节点连接到LLM节点最后把LLM节点连接到结束节点输出变量设为LLM的text字段。点击预览按钮输入一个问题测试效果。这个工作流看起来简单但已经解决了不基于事实胡说八道的核心问题。因为你给模型限定了必须依据检索到的上下文模型就无法凭空捏造。5.3 将工作流发布为Web应用并接入API编排完成后点击右上角发布Dify会生成一个Web App的访问链接。你可以直接打开这个链接在浏览器里跟Agent对话也可以把它嵌入自己的网站。如果想通过API调用Dify提供了标准的运行工作流接口。从应用详情页的API访问面板里可以看到完整的调用说明。基本原理是curl -X POST http://localhost/api/v1/workflows/run \ -H Authorization: Bearer app-xxxxx \ -H Content-Type: application/json \ -d { inputs: { query: 公司年假制度是什么 }, response_mode: blocking, user: test-user }需要把URL和Authorization替换成你自己的应用ID和API密钥。如果Dify部署在http://localhost测试环境直接发这个请求就能拿到结果。这一层接口接好之后你就可以把工作流嵌入到任何业务系统里比如内部IM机器人、工单系统、CRM。这里我想特别提一个更贴近热词的场景专利相关辅助。我认识的一些知识产权服务人员会把专利公开文本、审查指南、常见问答导入知识库然后用这个工作流帮他们快速检索相关专利点、生成初判意见。Dify的知识检索加上DeepSeek的总结能力能大幅节省翻阅文档的时间。当然最终的专业判断还是得由人来完成但AI已经把最脏最累的信息梳理工作干掉了。6. 进阶玩法、性能优化与避坑清单6.1 多模型路由与成本控制Dify工作流不止能做串行编排还能做条件分支。这让多模型路由变成了很实用的省钱策略。举个例子在用户提问进来后加一个问题分类节点用一个小而快的模型判断这个问题属于知识库问题还是闲聊问题。如果是知识库问题就走知识检索DeepSeek完整链路如果是闲聊问题就直接用一个轻量模型回答不走知识检索省掉一次向量化调用和一次大模型长上下文推理的开销。实际效果很直观知识库问答的token消耗主要集中在长上下文和检索结果上面。用轻量模型先做分流可以把无关问题的成本压到最低。在Dify里实现这个并不复杂用一个LLM节点加一个条件分支节点就够了LLM节点负责分类输出一个JSON比如{category: kb}。条件分支节点判断category的值分别为kb和other建立两条路径。6.2 工作流上下文变量与条件分支条件分支是Dify工作流里最容易被忽略但用好了又最提升体验的功能。除了上面说的成本控制它还能处理各种业务异常。我搭过一个私密文档审查流程用户提交一段文字工作流先判断文字中是否包含客户姓名、手机号、身份证号等敏感信息。如果包含就走脱敏处理分支让DeepSeek对敏感信息做替换如果不包含就直接进入下一步摘要生成。这完全靠Dify的条件分支按不同类型触发不同节点全程不需要后端代码。另一个常踩的坑是变量引用不规范。工作流里引用节点输出时模板中用的变量名必须跟节点实际输出的字段名完全一致。比如知识检索节点输出的是result但你写成了context最后LLM拿到的就是空值回答就会语无伦次。建议每次改完节点后都点一下预览检查看传入LLM的上下文是否真的有内容。6.3 我的实测经验与几个最容易被忽略的坑整套搭建完成后我用了大概两周期间踩过几个不查文档根本发现不了的坑集中写出来帮大家节省排查时间。坑1Dify容器访问宿主机Ollama必须用host.docker.internal这个问题前面提过但值得再强调一次。在Dify配置Ollama时API Base URL如果写成http://localhost:11434Dify容器会把请求发到容器自己的回环地址而不是Mac宿主机。正确写法是http://host.docker.internal:11434。Docker Desktop在Mac上默认支持这个域名。坑2DeepSeek API的Base URL在Dify的DeepSeek供应商配置里一般只需要填API Key。但如果你通过OpenAI-API-compatible方式手动接入就需要注意Base URL要以/v1结尾比如https://api.deepseek.com/v1。漏掉/v1会导致请求404。坑3上下文长度溢出本地模型如果设置过大Context LengthOllama会因内存不足而崩溃或无限重试。跑deepseek-r1:7b时我建议保持在4096附近。虽然模型本身支持更长但Mac内存有限过长的上下文会拖慢推理速度甚至OOM。坑4知识库召回效果好与坏主要是分段参数的锅如果你发现Agent回答经常说知识库中找不到但文档里明明有答案先别骂模型。去知识库设置里把分段长度调小到300~400TopK提高到4~5。我们提供的文档可能包含大量长段落切分过粗时向量召回的精读会下降。这个调整往往比换模型更有效。坑5Dify升级要留后路Dify社区版更新很快热词里就有dify 1.17.1更新。升级时千万不要想当然地直接在原目录git pull然后docker compose up -d。数据库结构变更可能导致数据丢失或启动失败。稳妥的方法是先备份.env文件和PostgreSQL数据卷再执行升级。可以在部署目录里用docker compose down清理容器但不要加-v参数否则数据卷也被删了。升级完成后再检查一下数据是否完整。实际操作下来这套Dify与DeepSeek的组合已经成了我日常处理信息的中枢。无论是写文档时让AI帮我起稿还是把零散资料变成可检索的知识库甚至是在团队内部做一个专属问答机器人基本都是可视化编排点几下就能完成。过去这些事要么散落在不同脚本里要么只能交给外部平台数据和流程都不受控。现在所有数据都在Mac本机模型可以按场景随意切换整个工作流的每一步都看得见、改得动。如果你也在考虑搭建自己的本地AI工作流这套组合确实值得一试唯一要提前准备的心理预期就是刚开始配置时可能会遇到一些网络和容器的小障碍但只要按链路一层层排查多数都能在十分钟内解决。 
长河君 · 2026/9/17 3:33:19 · 阅读 1.2k Mac本地部署Dify与DeepSeek：从零搭建可视化AI工作流
几天前DeepSeek大火的时候我就在朋友圈看到一堆人转发它的评测。说实话模型本身确实很强但大部分人试完网页版之后就停了。为什么因为单靠一个聊天框你没法把自己的文档、业务逻辑、私有知识揉进去也没法让它在不同任务之间自动流转。这也是我后来决定在Mac上跑一套本地AI工作流的原因——把DeepSeek这种模型能力装进一个真正能干活、能编排、能落地的容器里。而Dify恰好补上了这个最核心的拼图开源、可视化、本地部署配合DeepSeek后等于把玩具变成了工具。这篇文章就来拆解我在Mac上从零搭这套组合的全部过程包括安装、配置、工作流编排以及过程中踩进去又爬出来的各种坑。1. 为什么是Dify DeepSeek这套组合到底解决什么问题1.1 从碎片化调用API到可视化工作流如果你是做技术开发的可能体会过这种状态项目里东拼西凑调各个大模型的API前面用OpenAI后面又接个LangChain结构稍微复杂一点代码维护成本立刻指数上涨。我有段时间就在Jupyter里反复实验Prompt每次都写几十行代码去调API、解析JSON改一个参数就得重跑一遍。也许不是不能跑但总觉得哪里不对劲。Dify解决的是把模型调用变成搭积木。它是一个开源的大语言模型应用开发平台安装之后你能在网页界面上完成模型管理、Prompt编排、知识库集成和Agent构建。不需要自己写一个完整的前后端也不需要维护复杂的调度逻辑。工作流中的每个节点就是一项功能比如知识检索、LLM、条件分支、代码执行你只需要拖拽和连线就能拼出一个能跑的AI应用。这套模型跟DeepSeek结合起来就很舒服。DeepSeek是国产开源大模型既有官方API可以使用也有蒸馏版本可以本地部署。模型本身能力在线推理、写作、代码生成都有不错的表现。而Dify提供了封装层让我不用关心调用细节把DeepSeek作为一个能力底座挂进去然后在这个底座之上随便搭东西。1.2 DeepSeek为什么值得当主力模型DeepSeek-R1系列出来后很多人都拿它跟多家海外模型对比。从使用角度讲它的核心优势有几方面推理能力强在数学、代码、逻辑推理类任务上表现扎实适合做需要多步分析的Agent底座。上下文支持长最新模型可以容纳很长的对话历史这意味着把它接入知识库问答时一次性给足背景信息不用太担心截断。成本敏感用户友好API定价比主流海外模型便宜很多有缓存机制不会在调试阶段烧掉太多预算。开源生态丰富有多个量化版本普通Mac也能通过Ollama跑起来数据完全不离开本机。但我也得说个实话本地部署的DeepSeek蒸馏版比如7B/8B跟API版的满血版还是有差距。遇到复杂推理任务小模型容易一本正经地胡说八道。所以我的个人经验是如果只是做个人实验或对隐私要求极高本地部署可以如果真正要投入生产还是用官方API更稳。后面我会详细拆这两种接入方式。2. Mac上的环境准备Docker、镜像加速与Dify安装2.1 安装Docker Desktop以及国内镜像加速的配置Dify官方推荐用Docker Compose部署所以Mac上的第一步是把Docker装好。最直接的方式是去Docker官网下载Docker Desktop for Mac装上之后在终端里执行docker version确认。如果你习惯用Homebrew也可以brew install --cask docker有些人在安装Homebrew时会卡住多半是网络源的问题。国内环境建议把Homebrew的下载源替换成清华或中科大的镜像具体做法网上都有这里不展开。装好Docker Desktop后一定要在启动前先把镜像加速配置好不然后面拉取Dify等镜像时大概率超时。打开Docker Desktop - Settings - Docker Engine在registry-mirrors里添加你自己的加速地址。比如阿里云容器镜像服务的专属加速地址每个人都是独立域名也可以填公共的镜像加速地址。配置完之后点Apply Restart。提示加速器不是代理它只是镜像仓库的缓存副本。配置加速器后拉取Docker Hub上公开镜像的速度会明显提升这是合规、稳定的做法。2.2 使用docker compose拉起Dify社区版Dify社区版部署方式很简单官方仓库里已经写好了docker-compose文件。我建议直接采用指定版本的方式下载避免最新代码引入不稳定因素。例如当前热门的社区版1.17.1版本git clone https://github.com/langgenius/dify.git cd dify git checkout 1.17.1 cd docker cp .env.example .env docker compose up -d首次执行会拉取后端API、Worker、Web前端、PostgreSQL、Redis、Sandbox等镜像。镜像数量不算少但配置完加速器后整体时间还能接受。等日志里出现api和worker相关的启动成功输出后浏览器访问http://localhost即可看到Dify界面。如果Mac的80端口已被占用可以在.env文件里修改EXPOSE_NGINX_PORT比如改成8080访问时就用http://localhost:8080。2.3 拉取镜像失败时的排查思路拉取镜像失败是Dify部署中排名前三的坑。我自己也遇到过现象是执行docker compose up -d后卡在Pulling阶段下载速度为零或者报EOF、timeout错误。排查链路大概是这样的先确认Docker Desktop已经启动按住菜单栏的Docker鲸鱼图标看状态。确认registry-mirrors是否生效在终端执行docker info在输出里找到Registry Mirrors如果能看到你填的地址说明Docker读取到了。如果已经配置了加速器依然拉取失败大概率是某个镜像名称不再托管在Docker Hub上而是需要从GitHub Container Registry拉取。这种情况Docker的镜像加速器帮不上忙需要单独检查docker-compose.yaml里有没有image: ghcr.io/...开头的镜像。可以给Docker Desktop配置HTTP代理但如果你完全没有代理条件看能否切换到国内可以拉取的替代镜像源。也可以先把失败的镜像一个一个手动docker pull找出具体是哪个仓库的镜像卡住再对症下药。我实际部署时还遇到过一次端口冲突导致PostgreSQL容器反复重启。排查方法是看到某个容器状态为Restarting执行docker logs 容器名看日志报错。如果是端口冲突直接修改.env中POSTGRES_PORT即可。3. DeepSeek的两种接入姿势本地Ollama与官方API3.1 本地部署DeepSeek模型的硬件门槛与实际体验DeepSeek开源了一系列可商用模型其中蒸馏版本可以通过Ollama在Mac上跑。Ollama是一个极简的本地模型运行工具支持Apple Silicon加速。安装很简单brew install ollama装好之后拉取一个适合自己内存的模型。以我的MacBook Pro16GB内存为例跑deepseek-r1:7b算是流畅的跑14b会明显吃紧推理速度变慢甚至内存压力增大。如果你用的是Mac mini M2 32GB可以尝试更大的模型。ollama pull deepseek-r1:7b ollama run deepseek-r1:7b本地部署的好处是数据不出机器适合处理完全不能外传的文档。但实际体验上7B模型用于简单问答还行用于复杂推理时经常会出现自相矛盾。所以我的定位是本地模型作为私密数据的快速消化器和API宕机时的兜底方案真正的生产主力还是官方API。3.2 通过Ollama在Mac上跑DeepSeek具体分三步启动Ollama后台服务安装完成后直接运行ollama serve或者如果你是通过桌面端安装的它会自动随登录启动。下载模型执行ollama pull deepseek-r1:7b。这一步会从模型仓库下载数GB的数据需要一些时间。验证可用性新开一个终端执行以下curl命令如果返回JSON格式的响应说明本地接口已经通了curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 什么是Dify }要注意Ollama的接口地址是http://localhost:11434这个信息后面在Dify配置时要用到。另外Dify容器里访问宿主机时不能直接用localhost而是要用host.docker.internal这一点很多人第一次都会忽略后面我会单独讲。3.3 官方API接入方式与费用预估DeepSeek官方API的申请流程非常顺畅去开放平台注册账号、创建API Key然后充值一点点钱就能开始调用。接口兼容OpenAI格式所以Dify里可以直接选DeepSeek供应商填入API Key就完成接入了。费用方面DeepSeek官方API是按token计费。以我测试的V3和R1模型来说输入百万token几块钱输出百万token十几块到几十块钱具体以官网实时报价为准。对有缓存机制的场景命中的输入token会更便宜。整体算下来个人搭建的工作流日常跑量不多每个月甚至花不到一杯咖啡的钱。那么问题来了本地模型和API该怎么选我给一个很现实的建议场景推荐方式隐私文档处理、离线环境本地Ollama复杂推理、高准确率问答官方API学习调参、功能Demo本地Ollama免费生产级、多人使用官方API稳定4. 在Dify中配置DeepSeek供应商4.1 在Dify中添加模型供应商进入Dify后台点击头像下方或左侧菜单里的设置选择模型供应商。页面会列出已经支持的各类模型平台。我们要添加两类Ollama用于接入本地DeepSeek。DeepSeek用于接入官方API。对Ollama点击进入供应商配置页后需要填写两个关键字段API Base URL填写http://host.docker.internal:11434。因为Dify容器在Docker内部直接填localhost会指向容器自身导致无法访问宿主机上的Ollama。Model Name填写你在ollama list中看到的模型名称比如deepseek-r1:7b。完成之后Dify会自动向Ollama发一个验证请求。如果配置正确就能看到绿色提示并能在页面下方看到模型列表被动态加载出来。对DeepSeek官方API配置更简单API Key填你在DeepSeek开放平台创建的Key。其余参数保持默认即可。4.2 参数含义与推荐值配置完供应商后在具体应用里选择模型时会看到一组参数理解它们对工作流效果影响很大。Temperature温度取值范围0~2。值越低输出越稳定、保守值越高越发散。知识库问答建议设0.1~0.3创意写作可以设0.7以上。Top P核采样概率配合Temperature控制输出多样性。一般保持默认0.7或调成0.9即可。Max Tokens限制单次生成的最大token数。知识库回答通常设1000足够了。如果文档摘要任务长可以提高到2000以上。注意不要超出模型的最大上下文。Context Length上下文长度如果是通过Ollama配置本地模型这里设成4096或更高但要考虑内存占用。在Dify中配置好的模型参数会以模型配置的形式存在每个应用可以不同。实际调试时我习惯先调Temperature再调Max Tokens其他参数很少动。4.3 验证连通性与常见报错在模型供应商页面配置完通常会有测试按钮。点击后如果返回一段正常文本就表示通了。我在这个环节遇到过几个报错按热词里出现频率给大家排一下序Ollama: Failed to connect这多半是Base URL配置错了。确认是不是用了host.docker.internal而不是localhost。model not found模型名写错了。先执行ollama list查看准确名称注意名称里的版本后缀必须一致。deepseek request extension preparation failed这个报错我在官方API接入时见过一次通常是网络代理环境干扰或者API Key配置有隐藏空格。重新复制粘贴密钥检查环境变量后再次尝试。Connection error可能是Dify后端到目标接口的网络不通。本地Ollama的话先保证Ollama已经启动官方API的话确认网络能访问到开放平台域名。排查的时候记住一条核心原则一层一层拆。先确保命令行里直接调用目标模型是通的再去排查Dify本身的配置不要跳步。5. 从零搭建一条可落地的AI工作流5.1 创建知识库并完成文档分段与索引Dify的一大核心功能是知识库。我用的场景是把零散的产品说明、内部FAQ、操作手册整理成一个可检索的私有知识库。操作路径左侧菜单找到知识库点创建知识库上传PDF、Markdown或TXT文件。上传完后Dify会进行文档分段和索引。关键点在于分段设置。Dify提供两种模式通用分段按字符长度切分适合大多数场景。父子分段先切出段落再切出句子级片段兼顾精确召回和上下文完整。适合文档结构比较复杂的知识库。我通常选择通用分段把分段长度设置为500字符左右分段重叠设为50。这两个值决定检索时的碎片粒度分段太长命中后信息宽泛分得太细又可能丢失上下文。500/50是我试过比较平衡的一组值。索引方式上Dify提供高质量和经济型两种。高质量模式会用向量模型把文本转成向量检索效果更好建议直接选这个。经济型模式用关键词匹配速度快但召回质量会下降适合不需要语义理解的场景。5.2 编排知识问答Agent工作流知识库建好之后就可以在工作流里真正用起来了。在Dify的工作区新建一个空白应用选择Agent类型然后进入编排界面。我想要的是一个基于知识库回答问题的Agent用户提问后系统先检索知识库中相关文档片段再交给DeepSeek整理成自然语言回答。编排步骤如下添加开始节点定义输入变量query类型为Paragraph。添加知识检索节点关联之前创建的知识库TopK设置为3Score阈值设为0.5低于这个分数的片段基本不相关可以过滤掉。添加LLM节点选择DeepSeek模型在系统提示词模板里写入你是企业内部知识助手。请严格基于上下文中提供的内容回答问题。 如果上下文中没有相关内容请直接回答知识库中未找到相关信息不要编造。 上下文 {{#context#}}这里的{{#context#}}会自动引用前面知识检索节点的输出。将开始节点连接到知识检索节点再把知识检索节点连接到LLM节点最后把LLM节点连接到结束节点输出变量设为LLM的text字段。点击预览按钮输入一个问题测试效果。这个工作流看起来简单但已经解决了不基于事实胡说八道的核心问题。因为你给模型限定了必须依据检索到的上下文模型就无法凭空捏造。5.3 将工作流发布为Web应用并接入API编排完成后点击右上角发布Dify会生成一个Web App的访问链接。你可以直接打开这个链接在浏览器里跟Agent对话也可以把它嵌入自己的网站。如果想通过API调用Dify提供了标准的运行工作流接口。从应用详情页的API访问面板里可以看到完整的调用说明。基本原理是curl -X POST http://localhost/api/v1/workflows/run \ -H Authorization: Bearer app-xxxxx \ -H Content-Type: application/json \ -d { inputs: { query: 公司年假制度是什么 }, response_mode: blocking, user: test-user }需要把URL和Authorization替换成你自己的应用ID和API密钥。如果Dify部署在http://localhost测试环境直接发这个请求就能拿到结果。这一层接口接好之后你就可以把工作流嵌入到任何业务系统里比如内部IM机器人、工单系统、CRM。这里我想特别提一个更贴近热词的场景专利相关辅助。我认识的一些知识产权服务人员会把专利公开文本、审查指南、常见问答导入知识库然后用这个工作流帮他们快速检索相关专利点、生成初判意见。Dify的知识检索加上DeepSeek的总结能力能大幅节省翻阅文档的时间。当然最终的专业判断还是得由人来完成但AI已经把最脏最累的信息梳理工作干掉了。6. 进阶玩法、性能优化与避坑清单6.1 多模型路由与成本控制Dify工作流不止能做串行编排还能做条件分支。这让多模型路由变成了很实用的省钱策略。举个例子在用户提问进来后加一个问题分类节点用一个小而快的模型判断这个问题属于知识库问题还是闲聊问题。如果是知识库问题就走知识检索DeepSeek完整链路如果是闲聊问题就直接用一个轻量模型回答不走知识检索省掉一次向量化调用和一次大模型长上下文推理的开销。实际效果很直观知识库问答的token消耗主要集中在长上下文和检索结果上面。用轻量模型先做分流可以把无关问题的成本压到最低。在Dify里实现这个并不复杂用一个LLM节点加一个条件分支节点就够了LLM节点负责分类输出一个JSON比如{category: kb}。条件分支节点判断category的值分别为kb和other建立两条路径。6.2 工作流上下文变量与条件分支条件分支是Dify工作流里最容易被忽略但用好了又最提升体验的功能。除了上面说的成本控制它还能处理各种业务异常。我搭过一个私密文档审查流程用户提交一段文字工作流先判断文字中是否包含客户姓名、手机号、身份证号等敏感信息。如果包含就走脱敏处理分支让DeepSeek对敏感信息做替换如果不包含就直接进入下一步摘要生成。这完全靠Dify的条件分支按不同类型触发不同节点全程不需要后端代码。另一个常踩的坑是变量引用不规范。工作流里引用节点输出时模板中用的变量名必须跟节点实际输出的字段名完全一致。比如知识检索节点输出的是result但你写成了context最后LLM拿到的就是空值回答就会语无伦次。建议每次改完节点后都点一下预览检查看传入LLM的上下文是否真的有内容。6.3 我的实测经验与几个最容易被忽略的坑整套搭建完成后我用了大概两周期间踩过几个不查文档根本发现不了的坑集中写出来帮大家节省排查时间。坑1Dify容器访问宿主机Ollama必须用host.docker.internal这个问题前面提过但值得再强调一次。在Dify配置Ollama时API Base URL如果写成http://localhost:11434Dify容器会把请求发到容器自己的回环地址而不是Mac宿主机。正确写法是http://host.docker.internal:11434。Docker Desktop在Mac上默认支持这个域名。坑2DeepSeek API的Base URL在Dify的DeepSeek供应商配置里一般只需要填API Key。但如果你通过OpenAI-API-compatible方式手动接入就需要注意Base URL要以/v1结尾比如https://api.deepseek.com/v1。漏掉/v1会导致请求404。坑3上下文长度溢出本地模型如果设置过大Context LengthOllama会因内存不足而崩溃或无限重试。跑deepseek-r1:7b时我建议保持在4096附近。虽然模型本身支持更长但Mac内存有限过长的上下文会拖慢推理速度甚至OOM。坑4知识库召回效果好与坏主要是分段参数的锅如果你发现Agent回答经常说知识库中找不到但文档里明明有答案先别骂模型。去知识库设置里把分段长度调小到300~400TopK提高到4~5。我们提供的文档可能包含大量长段落切分过粗时向量召回的精读会下降。这个调整往往比换模型更有效。坑5Dify升级要留后路Dify社区版更新很快热词里就有dify 1.17.1更新。升级时千万不要想当然地直接在原目录git pull然后docker compose up -d。数据库结构变更可能导致数据丢失或启动失败。稳妥的方法是先备份.env文件和PostgreSQL数据卷再执行升级。可以在部署目录里用docker compose down清理容器但不要加-v参数否则数据卷也被删了。升级完成后再检查一下数据是否完整。实际操作下来这套Dify与DeepSeek的组合已经成了我日常处理信息的中枢。无论是写文档时让AI帮我起稿还是把零散资料变成可检索的知识库甚至是在团队内部做一个专属问答机器人基本都是可视化编排点几下就能完成。过去这些事要么散落在不同脚本里要么只能交给外部平台数据和流程都不受控。现在所有数据都在Mac本机模型可以按场景随意切换整个工作流的每一步都看得见、改得动。如果你也在考虑搭建自己的本地AI工作流这套组合确实值得一试唯一要提前准备的心理预期就是刚开始配置时可能会遇到一些网络和容器的小障碍但只要按链路一层层排查多数都能在十分钟内解决。