Mac本地AI，已经强的离谱

一个重要变化：Ollama 0.19（2026年3月30日发布）将其推理引擎切换为 Apple Silicon 上的 MLX。在 M5 Max 上运行 Qwen3.5–35B-A3B 的 Ollama 基准测试显示，prefill 从 1,154 tokens/秒提升到 1,810 tokens/秒（+57%），decode 从 58 tokens/秒提升到 112 tokens/秒（+93%）。这不是一个小优化。这是最常用的本地 LLM 运行时实现的两倍性能提升。

第二个变化：Apple 的 Foundation Models 框架于 2025 年随 macOS 26 / iOS 26 发布，经过 2026 年 Q1 和 Q2 的成熟，已经成为 Swift 应用可以真正依赖的东西。通过 @Generable 宏实现的引导生成，可以生成类型安全的结构化输出。工具调用是内置的。多轮对话是有状态的。该模型为 3B 参数，但针对大多数应用实际执行的任务类型（摘要、分类、结构化提取）进行了重度优化。而且调用它完全免费。

第三个变化：macMLX 于 4 月 18 日发布，是一个 SwiftUI 原生的 LLM 运行时，提供 OpenAI 兼容的 API。最后这个细节并不炫酷，但正是它让采用变得可行。任何已经使用 OpenAI API 的应用只需更改配置即可切换到 macMLX。

第四个变化：WhisperKit（Argmax）和 FluidAudio（Parakeet）现在通过 CoreML 在神经网络引擎上运行，与基于 MLX 的转录相比，速度提升显著。FluidAudio 在真实音频上对大型模型的平均推理时间为 0.19 秒。mlx-whisper 在相同工作负载下平均为 1.02 秒。通过 WhisperKit 使用 Whisper-large-v3 turbo 转录一小时的音频大约需要 90 秒。

综合结果：六个月前你需要使用 Deepgram + Anthropic + 向量数据库构建的栈，现在可以完全在用户的机器上运行，速度更快、完全免费，并且具有无与伦比的隐私性。

1、硬件规格：实际推荐

大多数人高估了他们需要的性能，而低估了现有硬件的能力。按芯片和内存的实际推荐：

M1 / M1 Pro, 8–16GB：对于所有合理任务使用 Apple Foundation Models。你已经拥有一个针对你的硬件优化的 3B 参数设备端模型。使用它。对于更大的工作负载，4-bit 量化 7–8B 模型可以运行但会比较慢。使用 WhisperKit 的 Whisper-base 或 small 进行转录。

M2 / M2 Pro, 16–32GB：添加 Qwen 3 8B Q4 量化（约 5GB 驻留内存）进行更重的推理任务。保留 Foundation Models 用于快速结构化输出。WhisperKit large-v3 turbo 用于转录。这是混合栈变得实用的起点。

M3 Pro / M3 Max, 18–128GB：独立开发者的最佳选择。使用 Qwen 3 8B 处理一般工作，Phi-4 14B（Q4，约 9GB）进行需要更强推理能力的任务，Apple Foundation Models 用于结构化输出。多个模型可以同时驻留内存。

M4 Pro / M4 Max, 24–128GB：30B 级别模型变得舒适。Llama 4 Scout（较小变体）以 Q4 量化可以运行。DeepSeek V3-Distill-32B 适合代码密集工作。30B 模型的解码速度现在达到 60–90 tok/s 范围。

M5 / M5 Max, 32–128GB：70B 级别模型变得实用。Qwen3.5–35B-A3B 是当前 MLX 的展示模型，在 Ollama 0.19 更新后达到 112 tok/s 的解码速度。M5 的 GPU 神经加速器专门针对 LLM 推理。如果你有 128GB 的 M5 Max，你可以在本地运行 70B 模型，达到与云服务相当的质量。

整个系列的规律：从 M1 开始的每一款芯片都可以运行一些有用的东西。问题在于你的硬件能舒适支持多大的模型，同时为操作系统其他部分的响应留出余量。

2、四种运行时选择，排名

有四种运行时值得了解。每种都有明确的用例。

Apple Foundation Models（Swift 框架，系统集成）

适用场景：你在构建原生 macOS 或 iOS 应用，且工作负载适合 3B 模型的优势（摘要、分类、结构化提取、对话任务）。@Generable 宏让结构化输出变得简单。工具调用是内置的。零安装成本，因为模型已经在每台支持 Apple Intelligence 的设备上。

跳过场景：你需要比 3B 模型更强的推理能力，或者你需要一个能在 Python 或其他非 Swift 环境中运行的运行时。

Ollama 0.19+（MLX 后端）（HTTP API，命令行）

适用场景：你想通过熟悉的 REST API 简单地在 Ollama 库中加载 1000+ 模型中的任意一个。MLX 后端现在匹配或超越了大多数其他 Apple Silicon 选项。广泛支持各种模型（Llama、Qwen、Mistral、Phi、Gemma、DeepSeek、Mixtral 等）。使用 ollama pull 轻松切换模型。

跳过场景：你需要绝对最低的 TTFT（首 token 延迟），或者你想在 Swift 应用内嵌入推理而不运行守护进程。

MLX 直接使用（Python 和 Swift 绑定）

适用场景：你想要最高速度和最紧密的集成。MLX 在 Apple Silicon 上比 llama.cpp 快 20–30%。MLX-LM Python 包提供直接访问。Swift 绑定可以在你的应用中原生使用。macMLX 用 UI 和 OpenAI 兼容的 API 进行了封装。

跳过场景：易用性比最后 20% 的性能提升更重要。

LM Studio（GUI 应用，支持 MLX）

适用场景：你想要一个桌面应用来管理模型、运行对话和提供 API，而无需使用命令行。适合向非开发者介绍本地 AI 的团队。支持选择 MLX 运行时。

跳过场景：你在其他应用中部署或想要可编程的工作流。

值得关注：Rapid-MLX，一个开源 MLX 运行时，声称比 Ollama 快 4.2 倍，缓存 TTFT 为 0.08 秒，支持完整的工具调用和 17 个工具解析器。新项目（2026 年 4 月），但值得关注。可作为 OpenAI 的即插即用替代品。

3、按用例的模型推荐

模型领域变化很快，但截至 2026 年 5 月，以下是每个用例的推荐选择：

避免：Llama 3.x 基础模型（已被取代）、旧版 Mistral 7B（同尺寸下 Qwen 3 8B 更好）、没有持续维护的模型。

4、语音转文字：人们常搞错的子栈

如果你需要转录，正确答案不再是"通过 Python 运行 Whisper"。

WhisperKit（Argmax）是生产环境的选择。Whisper 变体编译为 CoreML，在神经网络引擎上运行，支持实时转录的流式处理。通过 WhisperKit 使用 Whisper-large-v3 turbo 转录一小时音频大约需要 90 秒，并且可以在前台工作的同时继续使用你的机器。

FluidAudio 是一匹黑马。NVIDIA 的 Parakeet 模型编译为 CoreML。大型模型每次推理平均 0.19 秒，在大多数工作负载上比 WhisperKit 更快。开源，提供 Swift SDK。如果 Parakeet 在你的领域中的准确性表现良好（在英语上很强，其他语言覆盖较轻），值得使用。

mlx-whisper 是三者中最慢的，但在 Python 流水线中运行良好。如果你已经在使用 Python 工作流，可以用于批量转录。

whisper.cpp 仍然可用，但不再是 Apple Silicon 上的默认推荐。通过 WhisperKit / FluidAudio 的神经网络引擎路径始终更快。

跳过：对于任何延迟敏感的工作负载，跳过云端转录 API。即使是 Deepgram 的往返延迟，在最近的 Mac 上，对于短音频也比 WhisperKit 慢。

5、大多数团队应该采用的混合模式

如果你正在构建一个 AI 占相当比例工作负载的产品，2026 年 5 月的正确架构是三层混合模式：

┌────────────────────────────────────────────────────┐
│ 第1层：始终在线、低延迟                            │
│ → Apple Foundation Models（3B，原生，免费）         │
│ 用于：持续分类、路由、                              │
│ 结构化字段提取、简单摘要                           │
├────────────────────────────────────────────────────┤
│ 第2层：按需重负载                                  │
│ → 通过 Ollama-MLX 或 MLX 直接使用的 Qwen 3 8B      │
│ 用于：详细分析、多步推理、                          │
│ 长文本生成                                         │
├────────────────────────────────────────────────────┤
│ 第3层：云端爆发（可选）                            │
│ → 通过 API 使用 Claude Opus 4.7 或 GPT-5.5          │
│ 用于：最高风险推理，仅在用户                       │
│ 明确选择时使用                                     │
└────────────────────────────────────────────────────┘
音频部分：
WhisperKit（实时）或 FluidAudio（更快批量）

这种模式有三个重要的特性：

它可以离线工作。 第1层和第2层不需要网络。你的应用在飞机上、医院里、法庭上或 AI 供应商宕机时都不会中断。

它默认尊重隐私。 第3层是选择加入且明确的。默认的用户体验永远不会将用户数据发送到任何地方。

它的成本是稳定的。 第1层和第2层在运行时免费。第3层是唯一的成本项，并且受用户选择限制。

这是今天我会为任何 Apple Silicon 上的新 AI 产品构建的架构。这也是将现有云端优先产品改造为混合模式的正确形态。

6、应该停止的做法

2026 年 5 月人们仍在做的三件应该停止的事：

通过 Python 使用 mlx-lm 运行所有内容。 Python 适合原型设计。对于生产环境，Swift 或原生运行时能提供更好的集成、更低的内存开销以及对神经网络引擎路径的访问。

过度量化以适应更小的硬件。 Q2 或 Q3 量化节省内存，但会不均匀地降低各任务的质量。如果你的模型在 Q4 下放不下，选择更小的模型而不是更激进的量化。在大多数工作负载上，Q4 的 8B 模型优于 Q2 的 14B 模型。

将本地模型视为云服务级别。 3B Foundation Models、8B Qwen、甚至 35B Qwen3.5 都不是 Claude Opus 4.7。它们在适合的工作负载上是合适的。构建混合架构并根据任务复杂度进行路由，而不是基于原则。

7、我今天会搭建的精确栈

如果你正在一台 M3 Pro 或更新的 Mac 上从头开始，这是我建议安装的栈：

Ollama 0.19+（brew install ollama）。拉取 Qwen 3 8B（ollama pull qwen3:8b）和 Gemma 4 E2B（ollama pull gemma4:e2b）。
Apple Foundation Models。如果你运行的是 macOS 26，这些已经在你的系统上。无需安装，直接使用 Swift 框架即可。
WhisperKit（brew install whisperkit-cli 或通过 Swift Package Manager）。拉取 large-v3 turbo 模型。
macMLX，用于通过 UI 进行临时模型探索。
可选：Rapid-MLX，如果你想要实验性的最快运行时并支持完整工具调用。

在开发时，将你的 IDE 配置为指向本地 Ollama 端点（http://localhost:11434/v1），用于任何调用"OpenAI"的代码。大多数代理框架（Codex、Cursor、Aider）只需一个环境变量即可接受此切换。

总磁盘空间：约 15GB 用于模型文件。空闲时总内存：加载一个模型约 6GB 驻留。总成本：每次调用零成本，永远如此。

8、为什么这具有战略意义

Apple Silicon 上的本地 AI 不再仅仅关乎隐私或成本。这关乎部署。带有本地推理层的产品具有纯云产品在结构上无法匹配的特性：离线操作、可预测的延迟、零每次调用成本、真正的数据驻留以及对供应商宕机的弹性。

对于消费产品，这种差异化正变得有意义。对于受监管行业（医疗、法律、金融），它正在成为必需。对于开发者工具，它正在成为预期。

工具在过去 5 周内已经跟上。硬件已经准备好一年了。问题不再是要不要在本地运行。问题是你是否为你的产品和受众设计了正确的混合架构。

搭建好你的栈。发布混合模式。停止向不需要的 API 发送数据。

原文链接: The Local AI Stack for Apple Silicon, Now With Superpowers

汇智网翻译整理，转载请标明出处