简介：面向在 Apple Silicon（M1/M2）上运行大语言模型的 macOS 用户，这份 Ollama 安装包以标准 .app 形式打包，可直接在 Mac 上安装使用，解决新架构下软件兼容与本地部署 DeepSeek-R1 等模型的配置难题。压缩包为 zip 格式，共 127 个文件，大小约 185.25MB，内容以 Electron 框架资源、dylib 动态库、plist 配置、pak 资源文件及多个 Ollama Helper 组件为主，也包含应用图标、代码签名等 macOS 必需文件，属于典型的应用程序完整分发结构，安装后无需额外处理依赖。目前已有 319 人学习下载，适合希望快速上手本地模型推理的技术爱好者。通过这款安装包，用户可获得开箱即用的 Ollama 环境，免去手动编译或环境配置的麻烦，同时利用 M1/M2 芯片的算力顺畅运行 DeepSeek-R1，体验本地化、低延迟的 AI 服务。对关注大模型私有化部署的开发者来说，它也是一份可直接落地的参考方案，可帮助理解 .app 在 Apple Silicon 上的组织方式与运行依赖，并为后续扩展模型、调优参数提供基础。
1. 为什么 M1/M2 Mac 上的 Ollama 安装包，值得单独写一篇
Ollama 的 Mac 版安装包（支持 M1/M2）要解决的问题很具体：在 Apple Silicon 上把大型语言模型跑成一台本地服务，让 FastAPI、Dify、Cherry Studio 这类工具可以把它当成私有模型后端来调用。很多新手从官网下载完安装包，双击装好后却栽在架构、路径和模型存储这三件事上。M1/M2 的 arm64 架构决定了它和 Intel Mac 的下载包不通用；如果装错版本，或者把模型默认塞进已经紧张的系统盘，体感立刻从“本地部署真香”滑向“为什么跑不起来”。这篇文章要写的，就是这个安装包背后真实会被踩的坑，以及能抄作业的落地步骤。
2. 下载与安装：把 Ollama 装到 M1/M2 的两种可靠路径
2.1 用 Homebrew 安装：一条命令背后的架构细节
先说最常见也最省事的路径：Homebrew。M1/M2 上的 Homebrew 默认装在 /opt/homebrew，Intel Mac 装在 /usr/local，这是 Apple Silicon 装置的第一道暗门。命令行输入which brew看看前缀；前缀是 /opt/homebrew，说明你这台 brew 是 arm64 原生版本，后面 ollama 也会拉 arm64 构建，性能才完整。若前缀还是 /usr/local，说明你的 brew 是被旧迁移或 Rosetta 转换过的，建议先重装 brew 再继续，否则即使装好 ollama，模型推理时也会有转译损耗，这在跑 7B 以上模型时非常明显。
打开终端执行：
# 可以用 uname 先确认当前架构 uname -m # 期望看到 arm64；如果是 x86_64，说明终端进程可能运行在 Rosetta 下 # 在 arm64 环境下直接安装 brew install ollama # 安装结束后验证 CLI 可用 ollama --version这段命令的逻辑并不复杂，但有个容易被忽略的参数：brew 会自动检测当前终端架构，因此“在 Rosetta 终端里装 ollama”会装到 Intel 兼容目录。运行 uname -m 那一步，就是给自己一个后悔药——如果看到 x86_64，别急着装，重新用原生终端打开，或者用arch -arm64 zsh开一个新 shell 再跑。安装完成后，brew 会把 ollama 可执行文件放进 /opt/homebrew/bin，这个目录默认已在 PATH 里，所以 ollama --version 通常能直接命中。
如果这一步没输出版号，原因大概率不是你操作有误，而是 Homebrew 自身的链接失效。后面第 4 章的避坑环节会专门说命令找不到的处理办法。这里先记一个判断技巧：用which -a ollama能看到命令实际位置；如果输出出现在 /opt/homebrew/bin，就说明 brew 链路正常，剩下多半是当前终端缓存问题。
2.2 手动安装 pkg 包：M1/M2 离线安装的兜底方案
不是所有人都能顺利用 brew，比如公司 Mac 的软件管理策略禁止命令行安装，或者下载太慢、带宽紧张导致 brew 拉取依赖时中途卡死。这种时候，官方提供的 Mac 版安装包，也就是 .dmg 或 .pkg 形式，才是兜底方案。下载时注意一个关键字：Apple Silicon，不要下成 Intel 版本。M1/M2 安装包只能在 arm64 硬件上原生运行；下错版本会提示镜像损坏或直接无法打开。
拿到离线安装包后，我一般这么做：
# 先保持系统电量充足，双击安装前把其他大型应用关掉 open ~/Downloads/Ollama.dmg # 在访达里按提示把 Ollama 拖入 Applications 目录，这一步等价于手动安装 # 打开一次应用，让它完成初始化 open /Applications/Ollama.app # 确认命令行工具是否连带安装 which ollama && ollama --version为什么要把 standalone 手动安装列成可靠路径？因为它在两个场景下特别有用：一是机器离线，需要离线安装；二是 brew 依赖网络拉取大量依赖，在带宽紧张时很容易中断。.dmg 安装包是完整内置的，装完不需要再补依赖。代价是后续卸载和版本升级要靠你手动下载新包，没有 brew 自动管理那么省心。
这里有一个需要你立刻做的小验证：打开一次应用后，系统可能会弹“已打开”或“无法验证开发者”提示。如果没有弹窗，再检查which ollama。如果命令找不到，常见原因是安装包自带的 CLI 链接没有刷进当前 shell 环境，重启终端通常就好。第 4 章会把这类现象集中排掉。
2.3 安装完成后的第一个检查：为什么 ollama --version 会失败
不管用 brew 还是手动安装，装完后最容易出现的现象是：应用图标能打开，但终端输入 ollama 提示 command not found。我第一次在 M1 上装完也愣了几秒。原因很简单：macOS 只保证 /Applications 里的应用能双击运行，命令行工具的 PATH 设置是另一套机制。Homebrew 装完会写 link，但如果你之前把 shell 配置文件弄得比较乱，新的 bin 路径可能被覆盖。
# 第一步：看命令真不存在，还是 PATH 没包含 which -a ollama # 如果没找到，把 brew 目录加进 zsh 配置 echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zshrc source ~/.zshrc # 再验证 ollama --version这段命令的最后一招，是把 /opt/homebrew/bin 加进 PATH。如果你用的是 zsh，配置文件是 ~/.zshrc；用 bash 的话是 ~/.bash_profile。手动安装用户也可以把 /usr/local/bin 或实际命令所在目录加进去。判断依据很简单：打开访达，找到 Ollama.app，右键显示包内容，找到 Contents/Resources 里带 ollama 名字的二进制，那才是完整安装路径。手动软链到 /opt/homebrew/bin 后，后续使用就和 brew 安装一致。
检查完命令再检查服务：
ollama serve # 会看到监听地址和模型目录，正常时不会秒退看到这类服务日志，说明安装包本身已经工作。剩下的问题是模型路径、端口和环境变量，下一章逐一落地。
3. 安装后的落地配置：模型存储路径、服务监听与私有模型部署
3.1 把模型装到其他盘：OLLAMA_MODELS 环境变量怎么设
M1/M2 的入门款往往只有 256GB 存储，系统、Xcode、Docker 占掉一半，一个 7B 模型至少要 4.3GB，13B 则接近 8GB，多换几个模型系统盘就被吃干。所以第一个要做的参数调整是模型存储路径。Ollama 默认把模型文件放在 ~/.ollama/models，这是隐藏目录；想改到外置 SSD 或第二个分区，需要设置 OLLAMA_MODELS 环境变量。
设置环境变量的方式不只一种，我建议在 ~/.zshrc 里持久化：
# 在 ~/.zshrc 底部添加，目录按自己需求改 export OLLAMA_MODELS="/Volumes/External/models" # 重载配置 source ~/.zshrc # 让运行中的 Ollama 读到新变量 pkill -f "ollama serve" ollama serve > /tmp/ollama.log 2>&1 &这里的 pkill 和重启服务，比直接在旧服务里拉新模型靠谱。原因是 Ollama 服务启动时才读取 OLLAMA_MODELS，运行中途改环境变量不会生效。每次修改完环境变量，都要重复“杀掉服务、重新启动”这个动作。验证是否生效，用 ollama list 看已有模型，再对比目标盘有没有生成 models 目录；如果 list 为空但目录变大，说明模型下载开始写入外置盘了。
参数说明：OLLAMA_MODELS 支持相对路径和绝对路径，但强烈建议用绝对路径，避免不同用户或 launchd 启动时工作目录不同导致目录错乱。另外，如果你还开了系统自动切换用户，路径里别带空格；空格会导致 Ollama 内部路径解析出错，这种翻车表现很诡异，日志里根本没有错误，就是一直拉取失败。
3.2 让局域网内其他设备能用 Ollama：OLLAMA_HOST 参数
Ollama 默认只在 127.0.0.1:11434 上提供 API，这意味着同一局域网的另外一台电脑连不上。在很多“本地部署私有模型”的场景里，你希望笔记本上的模型能供工位旁的机器调用，或者让另一台 M2 负责推理、自己这台只发请求。这时要把监听地址放开。
# 允许所有网卡监听 11434 端口 export OLLAMA_HOST="0.0.0.0:11434" pkill -f "ollama serve" ollama serve > /tmp/ollama.log 2>&1 &和上一个参数一样，OLLAMA_HOST 也是启动时读取。改为 0.0.0.0 后，局域网里任何设备都能访问这台 Mac 的 11434 端口。注意一个边界：这只是把服务暴露在局域网，并不等于安全认证。系统防火墙没开的话，同一 Wi-Fi 下的陌生设备也可以调用你的模型消耗内存。所以我的习惯是：只在可信内网开放，并且配合第 5 章的 Nginx 反向代理加一层 API Key。如果你在公司网络，还应该先问一下网络管理员是否允许开端口，避免引发安全审查。
如果你只想指定某个网卡，例如只想让第二块 USB-C 网卡的设备访问，可以把地址写成那个网卡的 IP，比如 192.168.8.8:11434。默认 127.0.0.1 是保留给本机回环，不用改。这里没有更多需要调的参数，OLLAMA_HOST 是最关键的一个。
3.3 接上 Dify / FastAPI：本地模型服务化不是装完就跑
安装包把 Ollama 变成了一个本地 API 服务，但它默认的协议和 OpenAI 不兼容。如果你想在 Dify、Cherry Studio 这类客户端里把它当作模型供应商，通常需要填写兼容地址。Dify 的自定义模型服务格式一般类似 http://localhost:11434/v1，对应 Ollama 的 OpenAI 兼容端点。Cherry Studio 更简单，直接在模型管理里填本地 API 地址。
这里给出一个最小 FastAPI 调用示例，用于把本机 Ollama 的能力包装成公司业务接口：
# pip install fastapi uvicorn requests import requests from fastapi import FastAPI app = FastAPI() def ask_ollama(prompt: str, model: str = "llama3.2", temperature: float = 0.7): # POST /api/generate 是 Ollama 原生接口 r = requests.post("http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False, "options": {"temperature": temperature, "num_predict": 512} }) r.raise_for_status() # 返回的 response 字段是完整生成文本 return r.json()["response"] @app.get("/ask") def ask(prompt: str): return {"answer": ask_ollama(prompt)}这段代码的关键在于 options 里的两个参数。temperature 控制随机性，0.7 是通用值，但本地私有部署如果做数据抽取或代码补全，建议降到 0.1~0.2，否则结果会“飘”。num_predict 限制最大输出 token，500 左右对大多数业务请求足够；不设这个值时，某些模型可能一直续写，浪费内存。stream 设 False 是为了拿完整 JSON；如果要给前端做打字机效果，stream 设为 True 后要用 SSE 接收，这里不做展开。
调用之前先确认 Ollama 服务还活着：curl -s http://localhost:11434/api/tags。如果返回的 JSON 里有 models 字段，说明端口正常。FastAPI 跑起来后访问http://127.0.0.1:8000/ask?prompt=hello就能看到模型返回。这种“安装包 + 一层业务封装”的架构，就是本地私有模型部署的常见路径：模型在 Ollama 里跑，业务代码不直接碰模型文件，后续换模型只需改 model 参数，不用改业务代码。
4. M1/M2 上 Ollama 安装与运行的避坑指南：5 个高频故障
4.1 下载太慢，卡在 50%：离线包与导入的取舍
现象：安装包能正常下载，但第一次拉模型——例如ollama pull llama3.2——进度条长时间停在 50%。原因：模型文件体积大，默认下载通道带宽不稳定，容易超时。解决：不硬等，改用离线导入。常见做法是先在一台网络状态好的机器上下载好 GGUF 模型文件，拷贝到目标 Mac，再通过 Modelfile 导入。这里给一个最小导入流程：
# 目录切换到模型文件所在位置 mkdir -p ~/ollama-import # 把 llama3.2.gguf 放到该目录 # 写 Modelfile 指定 base 模型文件 cat > Modelfile << 'EOF' FROM /path/to/llama3.2.gguf EOF # 导入成一个本地模型名 ollama create llm -f Modelfile逻辑是绕过官方下载通道，GGUF 是 Ollama 背后 llama.cpp 的原生格式，导入后就是可运行模型。参数说明：Modelfile 里还可以追加 temperature、num_ctx 等默认值，但第一次导入别贪多，先跑通。如果这条命令报找不到量化文件，检查 FROM 路径是否用了绝对路径。这个方案同样适合离线安装包场景：装好 Mac 版 Ollama 后，不需要联网就能用本地的 GGUF 创建模型。
4.2 ollama serve 段错误：内存与电量设置的坑
现象：启动ollama serve后终端直接出现 Segmentation fault，或模型推理到一半进程退出。原因：在 M1/M2 上通常是同时加载了太多模型，或者 macOS 内存交换区不够，也有可能是“低电量模式”下统一内存带宽被限制。解决：先杀掉全部 ollama 进程，然后限制并发加载。
pkill -9 ollama # 限制最多同时加载 1 个模型，避免多个模型抢占内存 export OLLAMA_MAX_LOADED_MODELS=1 # 单请求并发也压一压 export OLLAMA_NUM_PARALLEL=1 ollama serve这两个参数是 Ollama 的运行时参数，OLLAMA_MAX_LOADED_MODELS 控制驻留模型数量，OLLAMA_NUM_PARALLEL 控制单模型并发请求数。在只有统一内存的 M1/M2 上，这两项一旦过高，模型会被反复换入换出，轻则变慢，重则段错误。如果还崩，再看系统日志：打开“控制台”应用搜 ollama，能看到 crash 报告，通常在报告的 “Exception Type” 行能看出是内存还是资源问题。外接电源并关闭低电量模式也是 macOS 笔记本上容易被忽视的修复手段。
4.3 macOS 提示“无法打开，因为 Apple 无法检查其是否包含恶意软件”
现象：手动双击下载的 Ollama.dmg 或解压出的 app，被系统拦截。原因：macOS Gatekeeper 对从网络下载的未公证应用默认拦截。解决：不要直接双击，右键选择“打开”，系统会弹出包含“打开”按钮的二次确认，点它即可。要是人不在机器旁，也可以用命令去除隔离属性：
xattr -dr com.apple.quarantine /Applications/Ollama.app但这条命令改变了系统对应用的隔离标记，建议只在确认下载来源可信时用。注意：不要对整个 Applications 目录执行，范围过大。也可以打开“系统设置-隐私与安全性-仍要打开”，但这个按钮只在最近拦截时出现。顺带一提，如果你下载的是 Intel 版并装到 M1/M2，它可能也需要这样打开，这种情况我更建议重新下载 arm64 版，而不是绕隔离属性。
4.4 命令行找不到 ollama 命令
现象：应用在程序坞里有，但终端输入 ollama 提示 command not found。原因：手动安装包没有把 CLI 路径加进当前 shell，或者 PATH 配置在安装前已经加载。解决：先重启终端，无效时执行：
# 让系统定位可执行文件，如果输出为空说明真的没装 CLI mdfind "kMDItemFSName == 'ollama'" # 找到后手动建软链到 brew bin 目录 sudo ln -s /path/to/ollama /opt/homebrew/bin/ollama如果没有用 brew，也可以放进 /usr/local/bin，但 M1/M2 上可能没这个目录，需要先mkdir -p /usr/local/bin。建软链前确认目标二进制能跑：直接执行它的绝对路径，再ollama --version。如果执行时崩，请回看 4.2。软链是一个后悔药，但不要链到 /usr/bin，macOS 系统分区限制会导致重启后失效。
4.5 如何关闭 Gemma 模型的思考过程，以及它和参数文件的关系
现象：部署 Gemma3 后，每次回答前都输出一段“思考中…”内容，消耗 token。原因：这是指令模型的固有行为，Ollama 版本和模板在解析时没有过滤 thinking 片段。解决：写一个新的 Modelfile，把系统提示强化为“直接输出答案，不输出推理过程”。
cat > Modelfile << 'EOF' FROM gemma3 SYSTEM "You are a helpful assistant. Do NOT include any reasoning steps, only provide the final answer." EOF ollama create gemma3-direct -f Modelfile这个做法是给模型换一层指令包装，本质没有减少计算量，只是把思考阶段的文本从输出里截掉，token 你省不了多少。如果你的目标是节省推理时间，建议直接用量化更低的模型或限制 num_predict。这条踩坑记录的重点是：看到“思考过程”别急着卸载，先确认是模型模板行为还是配置问题；Modelfile 是解决这类定制问题的标准入口。
5. 验证与进阶：从最小 API 到反向代理
5.1 用 curl 检查 Ollama API：最小验证步骤
安装好、环境变量配好的最后一步，是确认 API 真的在服务。你不需要先打开任何客户端，只用 curl 打三个探测。
# 1. 检查服务进程 lsof -iTCP:11434 -sTCP:LISTEN -P # 2. 列出已安装模型 curl -s http://localhost:11434/api/tags | head -c 500 # 3. 最小生成测试 curl -s http://localhost:11434/api/generate \ -d '{"model":"llama3.2","prompt":"say hi","stream":false}' | head -c 500第一条命令的输出里能看见监听进程是 ollama，以及监听的 IP。第二条返回 JSON，里面 models 数组的每一项都带 name、size 和 digest，size 是模型文件大小。第三条则真正让模型跑一次；如果返回里出现 response 字段，说明模型加载和推理链路都通。head -c 500 只截取前 500 字节，避免整段输出占满终端。如果第三条返回 404，常见原因是模型名打错了，先ollama list看一下准确的 name。如果 curl 连接被拒绝，回头检查 OLLAMA_HOST 是否设成 0.0.0.0 或端口被占用。
5.2 原生 /api 与 OpenAI 兼容端点：Dify / Cherry Studio 的地址填法
很多人在这一步会困惑：为什么同一个 Ollama 端口，有人填/api/generate，有人填/v1/chat/completions？其实 Ollama 在 11434 上同时提供两套接口。原生路径是 /api/，用于 FastAPI 直接调用；OpenAI 兼容路径是 /v1/，专门给 Dify、Cherry Studio 这类按 OpenAI 协议做的客户端。
# 验证 OpenAI 兼容端点是否可用 curl -s http://localhost:11434/v1/models | head -c 500如果这个请求返回 404，说明你的 Ollama 版本太老，需要升级。能正常返回后，Dify 里的模型供应商填http://host:11434/v1，密钥随便填一个占位符；Cherry Studio 同样填这个地址，模型名要和ollama list里的完全一致。区别在于，原生 /api 返回更详细的 token 使用统计，适合自己写业务逻辑；OpenAI 兼容端点省去协议适配，适合接开源客户端。对 M1/M2 本地部署来说，两套都开着，不用二选一。
5.3 用 Nginx 反向代理 Ollama：加一道 API Key 权限控制
局域网开放 11434 后，直接暴露原始端口其实不太卫生。常见做法是让 Nginx 监听 11435，转发到本机 11434，由 Nginx 统一校验一个简单的 API Key。这样 Cherry Studio、FastAPI 这类客户端只需要把地址改成 11435，并带上自定义 header 即可。
server { listen 11435; location / { # 如果 header 里没有授权码，直接拒绝 if ($http_x_api_key != "your-secret-key") { return 401; } proxy_set_header Host $host; proxy_pass http://127.0.0.1:11434; } }先把这段配置写进/opt/homebrew/etc/nginx/servers/ollama.conf，然后nginx -t && nginx -s reload。关键参数是 $http_x_api_key，Nginx 会把客户端请求头 X-API-Key 映射成这个变量；客户端传错就 401。实际使用中，Cherry Studio 这类开源客户端通常支持自定义 Header，你在它的设置里为本地模型服务加上 X-API-Key 即可。FastAPI 侧用 requests 也一样，在 headers 里带上。
这个方案没有做 TLS，只适合可信内网。因为 API Key 是以明文在局域网传输，一旦有设备被监听或存在恶意节点，key 会被泄露。对私有模型部署而言，如果要求更高，应该在同一台 Mac 上跑 Caddy 或 Nginx 配本地 CA 证书，给 11435 套上 HTTPS。M1/M2 性能跑加解密完全够，但配置复杂度会上一层，不建议新手第一版就上。
6. 一个 M1 老用户的留存技巧：用 launchd 把 Ollama 挂成后台服务
我每次在 Mac 上重装完 Ollama，最烦的一件事是忘记开ollama serve，等到 FastAPI 报连接拒绝才想起来。后来我把它做成 launchd 服务，开机自动运行，环境变量也由系统统一注入，不再依赖某个终端会话。
在~/Library/LaunchAgents/com.user.ollama.plist写入：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.user.ollama</string> <key>ProgramArguments</key> <array> <string>/opt/homebrew/bin/ollama</string> <string>serve</string> </array> <key>EnvironmentVariables</key> <dict> <key>OLLAMA_MODELS</key> <string>/Volumes/External/models</string> <key>OLLAMA_HOST</key> <string>127.0.0.1:11434</string> </dict> <key>RunAtLoad</key> <true/> </dict> </plist>加载它：
launchctl load ~/Library/LaunchAgents/com.user.ollama.plist注意 ProgramArguments 里写的是可执行文件的绝对路径，因为 launchd 启动时没有完整 PATH，只写ollama会找不到命令。EnvironmentVariables 字段也很关键，它保证 OLLAMA_MODELS 和 OLLAMA_HOST 在开机阶段就设好，不会出现模型目录或端口配置丢失的问题。以前我只会把它们写进 ~/.zshrc，结果 Ollama 被其他服务拉起时读不到变量，模型全部回到系统默认目录。这个坑我踩过两次，后来全挪进 plist 才安心。希望帮到你。
本文还有配套的精品资源，点击获取
