企业官网建设流程全解析

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 后 Dify"：Dify 启动后需要能访问到 Ollama 的 API 才能完成模型配置。而且两者是独立的进程，Ollama 监听 11434 端口，Dify 的前端服务监听 80 端口，互不冲突。

还有一个容易被忽略的角色：向量数据库。Dify 做知识库时需要把文档切片后做 embedding，并用向量数据库存储。Dify 默认使用 Weaviate，这个组件也跑在 Docker 里，Dify 的 docker-compose 文件里已经包含它，不需要单独安装。但这也意味着部署 Dify 会比预想的更吃内存，后面会细说。

2.2 硬件资源评估与预期效果

部署前先评估硬件，避免跑起来了但卡得没法用。我用的是 Intel MacBook Pro 16 英寸，内存 16GB，实测效果如下：

所以结论很清晰：16GB 内存是底线，8GB 内存的老 Mac 跑 7B 模型会非常吃力，强烈建议只跑 3B 级别的小模型。模型选择方面，Intel Mac 上没有 GPU 加速（Metal 支持有限），CPU 推理 7B 模型的速度大约在每秒 5~10 个 token，体感"能用但不快"，适合异步任务，不适合实时对话。如果只是验证流程，建议先用qwen2.5:3b跑通，再根据实际需求换更大的模型。

磁盘空间也要提前规划。Dify 的一堆镜像大约占 6~8GB，Qwen 7B 模型约 4.7GB，3B 约 2GB，再加上海量日志和依赖，建议预留至少 30GB 可用空间。系统数据本来就占用大的老 Mac，部署前先清理一下。

2.3 安装顺序和目录规划

我的建议安装顺序是：

1. 安装 Ollama，拉取并测试模型。
2. 安装 Docker Desktop，验证 Docker 环境可用。
3. 获取 Dify 源码，配置环境变量，启动容器。
4. 在 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 模型选择与存储路径管理

模型选型直接决定后面的体验。我的建议是：

如果 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拉到一半失败，可以把失败的镜像单独拉一遍再重新up：

docker 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.x，host.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 worker

6. 常见问题与踩坑速查表

6.1 镜像拉取失败

这是 Dify 部署里最集中的失败点，前面的解决方案已经说了，这里把排查顺序整理成速查表：

补充一条经验：如果你在公司内网环境，网络策略可能会拦截 Docker Hub，这时镜像加速器和离线导入都可能失效，最靠谱的办法是找 IT 要一个内网镜像仓库的地址，配到daemon.json里。

6.2 Docker 容器无法连接 Ollama

症状：Dify 对话时提示连不上 Ollama。

排查顺序：

1. 确认 Ollama 在宿主机正常：curl http://localhost:11434/api/tags。
2. 确认 Docker 容器能访到宿主机：docker exec -it docker-api-1 curl http://host.docker.internal:11434/api/tags。
3. 确认 Dify 模型供应商地址填的是http://host.docker.internal:11434，不是127.0.0.1。
4. 确认修改配置后容器已重启：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 in"，Ollama 可以在系统设置 -> 通用 -> 登录项里添加。这套配置弄好之后，重启后只要点两下就能恢复服务。

还有一个小细节：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 掉重新来，成本很低，但学到的东西一点不少。