1. 为什么要在 macOS 12.7.6 上折腾 Ollama Dify老实说2025 年还在 macOS 12.7.6 上折腾 Ollama 和 Dify大部分人听到的反应是那台机器是不是太老了。但实际场景里这种需求一点都不少手头有台 Intel 芯片的老 MacBook装不了新系统或者单位配发的机器就是被钉死在 Monterey 版本上但你又想拿它做本地大模型实验。macOS 12.7.6 是 Monterey 的最终维护版本系统层面足够稳定用来跑 Ollama 和 Dify 这套本地大模型组合完全可行只是有几个坑需要提前绕开。这套组合能解决什么问题简单说Ollama 负责在本地跑大模型比如 Qwen、Llama、DeepSeek 这类开源模型Dify 负责在上面搭建带工作流、知识库、Agent 的 AI 应用。你可以不写一行代码就通过 Dify 的界面拖出一个上传 PDF 让 AI 按你的格式总结的应用底层推理全部走本地模型数据不出机器。适合谁想私有化部署 AI 应用的开发者、做 LLM 应用原型验证的产品经理、以及单纯想在老 Mac 上玩玩本地大模型但不想碰繁琐推理代码的爱好者。我实测下来这套组合在 macOS 12.7.6 上不仅能跑而且只要把版本选对、配置改对稳定性相当不错。这篇文章就把我从零开始到跑通的完整过程写出来包括为什么这样选型、每一步的具体操作以及我在实际部署中踩过的所有坑。尤其是镜像拉不下来、Dify 连不上 Ollama、模型推理慢这三个老大难全部有对应解法。1.1 这套组合能干什么先对齐一下概念。Ollama 是一个本地大模型运行时它帮你把 Llama、Qwen、DeepSeek 这些开源模型下载到本地通过一句ollama run就能在终端里跟模型对话同时它还提供了一个 OpenAI 兼容的 HTTP API方便其他程序调用。Dify 则是一个开源的 LLM 应用开发平台你可以把它理解成大模型时代的低代码平台可视化编排工作流、管理 Prompt、挂知识库做 RAG、发布成可访问的 Web 应用。两者结合之后典型的使用场景包括本地知识库问答把公司内部文档、个人笔记导入 Dify 知识库用本地模型做检索增强生成隐私数据不出内网。工作流自动化Dify 里可以把意图识别 - 调用工具 - 模型生成编排成一条流水线比如自动把会议录音转写成结构化纪要。Agent 原型验证Dify 1.x 支持 Agent 节点配合 Ollama 的本地模型可以先验证工具调用逻辑再切换到云端大模型上生产。这套组合最大的价值是可控和可玩。数据完全在自己手里模型随便换流程随便改折腾坏了也不心疼。1.2 版本选择与兼容性判断先说结论Ollama 官方要求 macOS 12.0 及以上所以 macOS 12.7.6 是满足条件的但如果你是 Intel 芯片的 Mac需要注意 Ollama 在 Intel 平台上有少量性能折损这是底层指令集决定的没办法。Dify 本身没有 macOS 版本的概念它是跑在 Docker 里的所以系统兼容性取决于 Docker Desktop 是否支持你的系统版本。这里有个关键点Docker Desktop 4.x 系列支持 macOS 12但较新的 4.30 版本在部分老 Intel 机器上偶发资源占用过高的问题。如果你在启动 Dify 时发现 Docker 虚拟机异常卡顿建议安装 Docker Desktop 4.24 左右的版本稳定性更好。Dify 方面我部署时用的社区版 1.17.1这个版本对 Docker Compose 的兼容性比较友好官方说支持 1.x 和 2.x但我实测用 Compose V2也就是docker compose命令最顺畅老式的docker-compose命令在部分步骤上会有兼容提示。2. 部署前的整体规划与关键选型2.1 Ollama 与 Dify 各自扮演的角色在动手之前有必要把架构理清楚。Ollama 是模型推理层它干的事很纯粹加载模型、接受请求、返回 token。Dify 是应用编排层它干的事很杂管理知识库、编排工作流、处理对话状态、调用外部工具。Dify 本身不包含模型推理能力它通过模型供应商这个抽象层把 Ollama、OpenAI、通义千问等不同来源的模型统一接入。理解了这个分工你就能明白为什么部署顺序必须是先 Ollama 后 DifyDify 启动后需要能访问到 Ollama 的 API 才能完成模型配置。而且两者是独立的进程Ollama 监听 11434 端口Dify 的前端服务监听 80 端口互不冲突。还有一个容易被忽略的角色向量数据库。Dify 做知识库时需要把文档切片后做 embedding并用向量数据库存储。Dify 默认使用 Weaviate这个组件也跑在 Docker 里Dify 的 docker-compose 文件里已经包含它不需要单独安装。但这也意味着部署 Dify 会比预想的更吃内存后面会细说。2.2 硬件资源评估与预期效果部署前先评估硬件避免跑起来了但卡得没法用。我用的是 Intel MacBook Pro 16 英寸内存 16GB实测效果如下组件内存占用说明Docker Desktop 虚拟机4~6GB承载 PostgreSQL、Redis、Weaviate、API、Worker、Nginx 等容器Ollama 服务4~8GB具体取决于模型大小7B 模型约占用 4~5GB 内存macOS 系统及其他3~5GB系统自带占用所以结论很清晰16GB 内存是底线8GB 内存的老 Mac 跑 7B 模型会非常吃力强烈建议只跑 3B 级别的小模型。模型选择方面Intel Mac 上没有 GPU 加速Metal 支持有限CPU 推理 7B 模型的速度大约在每秒 5~10 个 token体感能用但不快适合异步任务不适合实时对话。如果只是验证流程建议先用qwen2.5:3b跑通再根据实际需求换更大的模型。磁盘空间也要提前规划。Dify 的一堆镜像大约占 6~8GBQwen 7B 模型约 4.7GB3B 约 2GB再加上海量日志和依赖建议预留至少 30GB 可用空间。系统数据本来就占用大的老 Mac部署前先清理一下。2.3 安装顺序和目录规划我的建议安装顺序是安装 Ollama拉取并测试模型。安装 Docker Desktop验证 Docker 环境可用。获取 Dify 源码配置环境变量启动容器。在 Dify 后台配置 Ollama 供应商验证对话链路。目录规划方面Ollama 的模型默认存储在~/.ollama/models这个目录可以改但我建议保持默认因为 Dify 对接时只需要访问 API 端口不涉及模型文件路径。Dify 的部署目录我放在~/dev/dify下方便管理。注意 Dify 项目里的docker文件夹是部署目录不是代码目录很多人第一次看到会疑惑后面的配置都在这个文件夹里进行。3. Ollama 安装与模型拉取实操3.1 安装包获取与下载提速Ollama 在 macOS 上的安装非常简单从官网或者 GitHub Releases 下载Ollama-darwin.zip解压后把Ollama.app拖进 Applications 文件夹即可。但很多人第一步就卡住了——下载速度极慢几十 MB 的安装包能下半小时。解决思路有两个。第一个是不要直接在浏览器里下载而是用下载工具加速比如迅雷或 aria2复制下载链接后扔进下载工具实测速度能提升数倍。第二个是如果你的磁盘上恰好有别人拷给你的安装包直接复用即可Ollama 的安装包没有机器绑定。安装完成后第一次启动 Ollama 应用会弹出菜单栏图标提示已经运行。此时打开终端执行ollama --version能看到版本号就说明安装成功。注意Ollama 启动后会自动在后台运行如果终端里执行ollama命令提示找不到检查是否把Ollama.app正常拖入了 Applications 文件夹或者重新打开一次应用。3.2 启动、验证与常用命令Ollama 的命令行工具用起来很顺核心命令就几个# 查看当前已下载的模型 ollama list # 拉取模型7B 模型约 4.7GB ollama pull qwen2.5:7b # 直接对话 ollama run qwen2.5:7b # 查看服务状态Ollama 默认监听 11434 端口 ollama serve这里有几个细节需要解释。ollama run会同时启动服务和进入交互对话如果你已经通过菜单栏启动了 Ollama终端里的ollama run会直接复用已经运行的服务不会重复起端口。ollama serve主要用于手动前台启动服务调试时很有用如果 Dify 连接不上 Ollama可以先在前台跑一个ollama serve看日志输出。拉取模型时如果没有进度条或者速度骤降不用慌这是 Ollama 的正常表现。它在下载大文件时会不定期更新进度中间可能卡很久然后突然跳一大截。实测最稳妥的方法是避开网络高峰比如凌晨拉取大模型成功率更高。另外拉取中断后重新执行ollama pull会断点续传这一点做得不错。3.3 模型选择与存储路径管理模型选型直接决定后面的体验。我的建议是模型参数量Intel Mac 体验适用场景qwen2.5:3b3B流畅每秒 15~25 token流程验证、简单问答qwen2.5:7b7B可用每秒 5~10 token中文能力更好复杂任务llama3.2:3b3B流畅英文任务工具调用deepseek-r1:7b7B偏慢推理型任务如果 Mac 只有 16GB 内存我建议同时保留 3B 和 7B 两个模型。平时测试用 3B 快速验证真正需要质量时切换到 7B。不要贪多每下载一个模型都是几个 GB 的磁盘和内存开销。关于存储路径Ollama 默认用~/.ollama/models存模型文件。这个文件夹会越来越大如果想迁移到外部硬盘可以设置环境变量OLLAMA_MODELS指向新路径但要注意Dify 访问 Ollama 走的是 HTTP API跟模型文件路径无关所以迁移不影响对接只影响 Ollama 自己读取模型。macOS 上设置环境变量的方式是launchctl setenv OLLAMA_MODELS /Volumes/External/ollama-models设置后需要完全退出 Ollama 再启动才能生效。4. Dify 部署全流程4.1 Docker Desktop 准备Dify 完全运行在 Docker 中所以 Docker Desktop 是前置条件。前面提过Docker Desktop 4.24 左右的版本在 macOS 12 上更稳定如果你用的新版有问题可以去 Docker 官方文档下载历史版本。安装 Docker Desktop 后进入 Settings - Resources把内存调到至少 6GB推荐 8GB。这一步非常关键我一开始用默认的 2GB 内存Dify 启动后 PostgreSQL 和 Weaviate 频繁崩溃日志里全是 OOM Killed。CPU 核心数保持默认即可。磁盘镜像大小建议调到 40GB 以上避免空间不足。还要注意 Docker Desktop 的文件共享路径设置。Dify 挂在容器里的docker目录涉及文件读写如果 Docker Desktop 提示共享文件夹权限问题需要在 Settings - File Sharing 中添加你存放 Dify 项目的目录。4.2 获取 Dify 源码与配置文件Dify 的安装方式是通过 GitHub 获取源码然后在源码中的docker目录下用 Docker Compose 启动。这里的源码不是要编译而是取它打包好的部署配置。# 方式一git clone推荐方便后续更新 git clone https://github.com/langgenius/dify.git ~/dev/dify # 方式二直接下载 release 压缩包解压后同样进入 docker 目录拿到项目后进入docker目录cd ~/dev/dify/docker # 复制环境变量模板 cp .env.example .env这步cp .env.example .env是 Dify 部署的必经之路热搜词里那个在 dify-main 的 docker 文件夹路径下右键打开 cmd 输入 cp .env.example说的就是这一步Windows 上是在命令行里执行macOS 上直接在终端执行即可。.env文件里包含了所有服务的配置默认值可以直接用但有几个需要改EXPOSE_NGINX_PORT默认 80如果 80 端口被占用改成 8080 之类的端口后面访问 Dify 就要带端口号。POSTGRES_PASSWORD、REDIS_PASSWORD这些密码默认值在局域网环境建议改掉本机使用无所谓。向量数据库默认是weaviate保持默认即可。4.3 启动 Dify 并完成初始化启动命令非常简单docker compose up -d但这里有个大坑首次启动需要拉取约 8 个镜像包括 dify-api、dify-web、postgres、redis、weaviate、sandbox、nginx、ssrf_proxy总大小超过 6GB。在国内网络环境下这一步失败概率极高报错基本是failed to pull image ... timed out。解决镜像拉取失败的办法我实测有效的有三个方向第一给 Docker 配置镜像加速器。编辑~/.docker/daemon.json没有就新建加入{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com, https://docker.nju.edu.cn ] }保存后重启 Docker Desktop。注意这些公共镜像加速器时灵时不灵如果某个失效了就换一个。第二针对单个镜像反复重试。如果docker compose up -d拉到一半失败可以把失败的镜像单独拉一遍再重新updocker pull langgenius/dify-api:1.17.1单独拉镜像时容易看到具体的报错也更容易重试成功。第三如果网络实在是连 Docker Hub 都不稳那就找一台网络好的机器把镜像docker save成 tar 包拷贝到本地后docker load导入。这个方法适合内网环境步骤不复杂但需要你手上刚好有另一台能正常拉镜像的机器。镜像拉取完成后再次执行docker compose up -d看到所有容器都是running状态就算成功了docker compose ps然后打开浏览器访问http://localhost如果改了EXPOSE_NGINX_PORT则访问http://localhost:改后的端口首次访问会进入初始化页面设置管理员邮箱和密码。这一步完成后Dify 基本就绪。5. 打通 Dify 与 Ollama 的对接配置5.1 配置模型供应商Dify 初始化后登录管理员账号点击页面右上角头像 - 设置 - 模型供应商在列表里找到 Ollama点击安装。配置表单里只需要填几个关键字段模型名称填你通过 Ollama 拉取的完整模型名比如qwen2.5:7b要和ollama list里看到的一模一样多一个字符都不行。API Base URL这是最容易配错的地方。因为 Dify 跑在 Docker 容器里而 Ollama 跑在宿主机上容器内不能直接用127.0.0.1访问宿主机必须用 Docker Desktop 提供的特殊域名host.docker.internal。所以填写http://host.docker.internal:11434。模型类型对话类模型选LLM嵌入类模型选Text Embedding。如果你用的是 Docker Desktop 4.xhost.docker.internal是自动支持的不需要额外配置。如果你把 Ollama 也塞进了 Docker 里跑那 API 地址要填 Ollama 容器的地址但我们这里 Ollama 是原生跑在 macOS 上的所以固定填host.docker.internal。5.2 模型类型与名称的匹配规则Dify 里配置 Ollama 时有一个很容易踩的坑同一个模型名在对话模型和Embedding 模型两个入口都要分别配置。知识库功能需要 embedding 模型。Ollama 上可以做 embedding 的模型有nomic-embed-text、mxbai-embed-large等需要先用ollama pull拉下来然后在 Dify 的Embedding 模型里配置同一个 Ollama 供应商填模型名对应的 embedding 模型。Dify 对 Ollama 的调用走的是 OpenAI 兼容接口所以大部分配置项比如 temperature、max_tokens 等都用默认值问题不大。但要注意Dify 1.x 版本对模型有Function Calling能力检测Ollama 3B 级别的小模型对函数调用的支持不稳定如果在编排 Agent 时发现工具调用失效换 7B 模型试试或者检查模型是否支持 function calling。5.3 验证对话链路配置完成后在 Dify 首页点击创建空白应用选聊天助手在右上角模型选择器里选刚才配置的 Ollama 模型然后输入一句测试文本看是否能正常回复。我实测遇到的典型情况是模型配置正确但回复时报错Connection error或者Failed to connect to Ollama。排查步骤是# 1. 确认 Ollama 服务正常 curl http://localhost:11434/api/tags # 2. 确认容器内能访问宿主机 Ollama docker exec -it docker-api-1 curl http://host.docker.internal:11434/api/tags第二步如果失败大概率是 Docker Desktop 的host.docker.internal没生效重启 Docker Desktop 后重试。如果容器内访问成功但 Dify 还是报错检查.env文件里是否改过OLLAMA_HOST之类的配置或者后端 API 容器是否完整重启过。有一次我改了 API Base URL 后忘了重启容器Dify 一直报旧地址连接失败所有配置都不生效。重启 API 容器就好docker compose restart api worker6. 常见问题与踩坑速查表6.1 镜像拉取失败这是 Dify 部署里最集中的失败点前面的解决方案已经说了这里把排查顺序整理成速查表问题判断方法解决方案拉取连接超时报错含timed out、connection refused配置 registry-mirrors 后重启 Docker拉取速度极慢进度条长时间不动单镜像单独拉取或改用离线 tar 包导入某个镜像始终失败单独docker pull该镜像看具体报错换镜像加速器或找一个网络好的机器导包补充一条经验如果你在公司内网环境网络策略可能会拦截 Docker Hub这时镜像加速器和离线导入都可能失效最靠谱的办法是找 IT 要一个内网镜像仓库的地址配到daemon.json里。6.2 Docker 容器无法连接 Ollama症状Dify 对话时提示连不上 Ollama。排查顺序确认 Ollama 在宿主机正常curl http://localhost:11434/api/tags。确认 Docker 容器能访到宿主机docker exec -it docker-api-1 curl http://host.docker.internal:11434/api/tags。确认 Dify 模型供应商地址填的是http://host.docker.internal:11434不是127.0.0.1。确认修改配置后容器已重启docker compose restart api worker。如果你用的是 Podman 等其他容器运行时host.docker.internal可能不存在需要改成宿主机在 Docker 网桥上的 IP一般是172.17.0.1。用 Docker Desktop 则不必担心这个。6.3 模型推理速度慢 / 内存不足Intel Mac 上没有 GPU 加速跑 7B 模型推理确实慢这是硬件瓶颈无解。但有一些优化手段应用层优化把 Dify 的max_tokens从默认 2048 降到 512减少单次生成量体感会快很多。模型层优化换量化版本模型比如qwen2.5:7b-q4_K_M约 4.2GB比默认的7b占用更小。Ollama 拉取时指定 tag 即可。系统层优化确保没有其他大任务拉满 CPU避免系统内存吃紧触发换页。如果容器频繁被 OOM Kill回到 Docker Desktop 设置里把内存调大并确认 macOS 的活动监视器里没有其他进程占内存。6.4 重启后服务失效macOS 重启后Ollama 默认不会自动启动Dify 的 Docker 容器也不会自动启动。需要手动执行# 启动 Ollama菜单栏打开或执行 open -a Ollama # 启动 Dify 容器 cd ~/dev/dify/docker docker compose start如果你希望开机自动启动Docker Desktop 可以在设置里开启Start Docker Desktop when you sign inOllama 可以在系统设置 - 通用 - 登录项里添加。这套配置弄好之后重启后只要点两下就能恢复服务。还有一个小细节Dify 的容器在宿主机重启后有时会处于异常状态docker compose ps看到restarting状态先docker compose down再docker compose up -d通常能解决。6.5 使用过程中的日常维护部署跑通只是开始日常使用还有一些小事Dify 的日志会无限增长尤其是 PostgreSQL 和 Weaviate 的日志。建议定期执行docker compose exec api sh -c cd /app/api flask dump_enhance_info不需要日常跑更实用的是用 Docker 的日志轮转配置在 Docker Desktop 设置里可以限制日志文件大小或者在/etc/docker/daemon.json里加log-driver: json-file, log-opts: {max-size: 10m, max-file: 3}。更新 Dify 时先备份.env文件然后git pull拉最新代码再docker compose down docker compose up -d。如果docker compose up报了配置兼容错误多半是新版本镜像需要更新的配置字段先看docker compose config校验一下。Ollama 模型定期清理ollama rm 模型名避免磁盘被塞满。写在最后一点实际操作中的体会前面把完整的部署流程和坑都写了一遍最后分享几个我多次操作后的个人体会。第一这套组合在 macOS 12.7.6 上跑通不难难的是合理预期。Intel Mac 的 CPU 推理能力有限不要指望它能像云端 API 一样秒回。把它当成可用于原型验证的本地环境来用心态会平和很多实际完成一轮知识库问答大约需要 10~30 秒作为实验环境完全够用。第二Dify 和 Ollama 的版本不要追求最新追求已知能正常工作的组合。比如我到现在仍然使用 Dify 1.17.1而不是追着最新版本跑。Dify 每个版本都会调整模型供应商的对接逻辑有时升级后 Ollama 就配置不上排查起来非常费劲。社区版先确认 release note 里没有模型接入相关的 breaking change再决定是否升级。第三整个部署过程中最值得投入时间去理解的是 Docker 的端口映射和容器间通信机制。Dify 连不上 Ollama 这类问题本质上就是容器内如何访问宿主机服务的网络概念问题。搞懂host.docker.internal的原理后你不仅会配 Ollama以后任何需要把宿主机服务暴露给容器的场景你都能举一反三。最后再分享一个小技巧如果只是想快速验证 Ollama 和 Dify 的对接不必一次拉太多模型。先用qwen2.5:3b跑通全链路确认 Dify 的对话和工作流正常再决定是否拉 7B 或者更多模型。这样即使中间出了问题排查的变量也少很多。把这个环境当沙盒来玩翻车了随时 down 掉重新来成本很低但学到的东西一点不少。