Core ML vs MLX vs Foundation Models：如何选择苹果的端侧 AI 技术栈

苹果如今提供了四种在用户硬件上运行模型的截然不同的方式，选错一种就要付出重写的代价。 在我写下这篇文章的 M2 Max 上，MLX 能稳定跑出 11.2 TFLOPS 的 fp16 矩阵运算，并以实测 351 GB/s 的统一内存带宽搬运数据¹。但对大多数应用来说，这份算力是错误的选择，因为系统自带的 Foundation Models 框架用六行 Swift 就能完成同样的工作，且不会给下载包增加哪怕一兆字节。这四个框架不是竞争关系，而是同一个问题的四种不同答案：模型是谁的，执行由谁维护？

TL;DR

• Foundation Models 是默认选项。如果苹果端侧那个约 30 亿参数的 LLM 能完成任务（摘要、抽取、分类、生成结构化输出、调用您自己的工具），您就无需附带任何模型权重，无需支付推理成本，还能免费继承每一次系统级的模型升级。²
• Core ML 用于把 您自己的 训练好的模型装进应用发布。它是唯一一条同时具备一流 Neural Engine 调度、契合 App Store 的打包方式，以及以灵活性换取续航与可预测性的预编译契约的路径。³
• MLX 适用于模型本身就是产品的场景：研究、微调、运行开放权重 LLM，或任何需要对张量进行即时控制的负载。它是开发机与 Mac 应用的工具，而不是 iOS 的发布载体。⁴
• Core AI（iOS 27）是垫在这一切之下的新地基：一个底层模型执行框架，带 NDArray 张量和显式的计算单元指定，面向那些如今把 Core ML 当张量运行时来滥用的团队。
• 这个决定通常只需一个问题：内置模型就用 Foundation Models；自己的模型跑在 iOS 上就用 Core ML；自己的模型跑在自己的 Mac 上就用 MLX；在 iOS 上需要张量级控制就用 Core AI。 本文余下的篇幅，讲的是这条经验法则失效的那 20% 情形。

问题背后的问题

我见过的每一场”该用哪个框架”的争论，最后都收敛到两条轴上。（这四者我都写过深度剖析：Foundation Models、Core ML、MLX、Core AI。）

第一条轴：权重是谁的？ 是苹果的内置模型，是您训练或转换的模型，还是您从模型库拉下来的开放权重。Foundation Models 永远只运行苹果的模型（外加您的 LoRA 式适配器）⁵。Core ML 和 MLX 永远只运行您提供的权重。仅这一点，就在性能话题登场之前砍掉了一半的选项空间。

第二条轴：谁拥有执行过程？ Foundation Models 把一切都藏了起来：没有张量，没有计算单元，除了一个会话对象之外也没有上下文窗口管理。Core ML 藏起了大部分：您交给它一个编译好的 .mlmodelc 并给出计算单元的提示，调度由框架决定。MLX 什么都不藏：数组运算由您自己写，惰性求值和统一内存就是您的工具。Core AI 介于 Core ML 与 MLX 之间：张量和计算单元指定是显式的，但执行仍由苹果托管。

把任何一个真实功能放到这两条轴上，框架自己就选好了。

Foundation Models：零兆字节的默认解

大多数团队应当最先尝试的框架，恰恰是那个完全不需要模型的框架。Foundation Models 通过 LanguageModelSession 暴露了 Apple Intelligence 背后的端侧 LLM，而它的杀手锏并不是模型本身，而是 引导式生成：给一个 Swift 结构体标注 @Generable，框架就会约束解码过程，让模型的输出 就是 您的类型，而不是一串您需要解析并祈祷格式正确的字符串。²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

整个集成就这么多。没有下载步骤，没有量化决策，也不必费心推敲发热问题；系统负责调度模型，把它共享给设备上的每一个应用，并在每次发布时升级它。工具调用让模型能够执行您定义的函数，这已经足以在完全不依赖服务器的情况下做出真正具备智能体特征的功能。²

约束同样是对称的：这是一个约 30 亿参数的通才模型。它擅长摘要、抽取、分类，也能像模像样地产出结构化输出；但它不做开放域的世界知识、长上下文的文档分析，也做不了前沿模型能做的那些事。当内置模型不够用时，苹果给出的答案是适配器（用苹果的工具包针对基础模型训练的 LoRA 式微调），但适配器意味着一份长期承诺：苹果每升级一次基础模型，您就得重新训练一次⁵。包含会话管理和审核者常踩的失败模式在内的完整拆解，都在Foundation Models 深度剖析里。

何时选它：任务呈语言形态，内置模型能达到您的质量标准，而且”不附带任何权重”这件事很重要。符合条件的功能比多数团队以为的要多得多；在伸手去拿下面任何一项之前，不妨先试试它。

Core ML：您的模型，苹果的执行

Core ML 回答的是另一个问题。您已经有一个模型（视觉分类器、嵌入模型、语音流水线、蒸馏过的 LLM），它需要在 iOS 应用内部运行，靠电池供电，控制在 App Store 的体积限制之内，而且是今年就要上线。

它的契约是预编译。您用 coremltools 转换权重，模型编译成 .mlmodelc，运行时由框架在 Neural Engine、GPU 和 CPU 之间调度；而 ANE 正是这份清单上其他选项在今天的 iOS 上给不了您的东西。真正的工程含量集中在转换这一步：算子覆盖率、量化（调色板化、线性 8/4 位、稀疏化，coremltools 的优化栈是真的深⁶），以及决定您的模型跑在 2 瓦还是 8 瓦的计算单元提示。那些真正能在生产环境中存活下来的做法（调度提示、延迟预算、量化阶梯）是Core ML 支柱文章的主题。

Core ML 不做什么同样关键：它不训练，不微调，也不让您在计算图中途碰到张量。它是一台推理专用设备。那些既要”运行我的图”又要”戳一戳中间结果”的团队，历来只能把 Core ML 硬掰成张量运行时；而 Core AI 的存在，正是为了吸收这种扭曲。

何时选它：权重是您自己的，目标平台是 iOS/iPadOS（或跨苹果平台），并且续航、体积、ANE 都很重要。换句话说，几乎涵盖了这个平台上所有已发布的自定义模型功能。

MLX：装在 Mac 里的研究机器

MLX 是这里的异类：它是苹果机器学习研究团队推出的开源数组框架，而不是系统框架⁴。它长得像 NumPy，采用惰性求值，并把 Apple silicon 的统一内存当作一项实实在在的特性来用：没有主机到设备的拷贝，因为根本不存在独立的设备内存。

这台机器上的数字让论点变得具体。在完全不调优的情况下，M2 Max 在 MLX 下稳定跑出 4096×4096 的 fp16 矩阵乘 11.2 TFLOPS，以及实测 351 GB/s 的流式带宽¹：足以交互式地运行量化后的 300 亿参数开放权重模型，用 LoRA 一夜之间微调 70 亿参数模型，并反复迭代那些原本意味着要去租云 GPU 的训练任务。有了 mlx-lm 生态，多数开放模型不过是一次 pip install 加一次下载的距离。

边界同样具体。没有 Neural Engine：MLX 编程的是 GPU（和 CPU），不是 ANE。没有 iOS 发布路径：技术上您确实可以嵌入它，但权重分发、发热和审核指南都说明这是错误的工具；MLX 属于您的 Mac、您用户的 Mac，以及您的研究循环。而且没有人替您管理执行：内存压力、量化选择、求值调度全归您自己。什么时候”用自己的模型而不是苹果的模型”值得承担这份所有权，MLX 支柱文章有详细讨论。

何时选它：您正在训练或微调，正在本地运行开放权重 LLM，或者正在打造那种”对模型的掌控本身就是产品”的 Mac 原生工具。如果您的主力机是一台内存充裕的 Apple silicon Mac，MLX 能把它变成一台名副其实的机器学习工作站。

Core AI：新的地基

iOS 27 补上了苹果一直缺失的那一层：Core AI，一个底层模型执行框架，带 NDArray 张量、资产与模型分离、显式的计算单元指定，以及可调用的推理函数⁷。当 Core ML”把编译好的模型交给我，你拿走预测结果”的契约过于僵硬时，您就该用它：把张量运算与模型调用交织在一起的流水线，本就该跑在 ANE 上的自定义前后处理，以及共享缓冲区的多模型计算图。

两点澄清能帮多数读者少走一段弯路。Core AI 不是 Foundation Models 的替代品（这一层依然没有内置 LLM，编译好的资产得您自己带）。它也 不是 iOS 版的 MLX：没有训练，没有自动求导，没有即时执行的研究循环。它是打开了舱盖的 Core ML 机舱。如果您从未与 Core ML 的抽象搏斗过，那您并不需要 Core AI；可一旦您发布过 MLMultiArray 的杂技表演，或者为了串联模型而塞进了不必要的转换，您其实已经需要了。张量模型与指定 API 详见Core AI 支柱文章。

真正会被拿来争论的场景

“我们需要一个 LLM，但要用自己的／更大的。” Foundation Models 无法加载外部权重，没有例外。走 Core ML 的蒸馏小型 LLM 是可行的，还能拿到 ANE；走 MLX 的量化开放模型在 Mac 上可行。也请坦诚面对那个端侧圈子里没人愿意说出口的替代方案：如果任务需要前沿级质量，答案就是一次服务器调用，而端侧那几层负责兜底与处理隐私敏感的子集。

“我们想在 iPhone 和 Mac 上用同一套技术栈。” Foundation Models 和 Core ML 在苹果生态内部都是跨平台的；MLX 实际上只属于 Mac。同时发布 Mac 专业应用和 iOS 伴侣应用的团队，往往最终选择 Mac 上用 MLX（大模型、用户自带权重），iOS 上用 Core ML 或 Foundation Models：同一个功能，两套引擎，以及一次对”设备本就不同”的坦诚承认。

“我们已经有一条 Core ML 流水线了，Core AI 是迁移目标吗？” 只在流水线真正让人难受的地方才是。Core AI 吸收的是那些张量形态的边缘；今天能正常工作的编译模型内核，继续照常工作。把一套健康的 Core ML 部署整体迁移过去，什么也换不来。

“SwiftData 或 App Intents 会改变这些结论吗？” 相邻，但不重叠：您的模型层为那些由 App Intents 向系统暴露的功能提供能力，而您持久化的一切都遵循SwiftData 的模式规范。这里讨论的框架决定的是 推理如何运行，而不是围绕它的应用如何构建。

一棵决策树

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

关键要点

对于要交付功能的应用团队： - 先拿 Foundation Models 做原型；六行 Swift 是能想到的最廉价的实验，而”内置模型其实就够了”是最常见的意外收获。 - 把 Core ML 的转换时间与推理时间分开做预算；算子覆盖率和量化才是吞掉数周时间的地方。

对于机器学习工程师： - 一台 64GB 以上的 Apple silicon Mac，在 MLX 之下就是一台真正的微调机器；在去租云 GPU 之前先测一测。上面那组 11.2 TFLOPS / 351 GB/s 的数字，出自一颗落后两代的笔记本芯片。¹ - ANE 依然是 Core ML（如今还有 Core AI）的护城河。如果每次推理的耗电很关键，没有哪条 GPU 路径能与之竞争。

对于架构师： - 把这四个框架当作层次而非对手：语言类功能用 Foundation Models，随应用发布的自定义模型用 Core ML，张量形态的边缘用 Core AI，Mac 和实验室用 MLX。在正经的应用里，混合部署是常态，不是坏味道。 - 模型的 所有权 才是长期的成本中心：Foundation Models 的权重由苹果维护，其余的一切都由您维护。请把这一点计入选择的价格。

常见问题

在设备端运行模型该用苹果的哪个框架？

这个决定通常只需一个问题。内置模型就用 Foundation Models；自己的模型跑在 iOS 上就用 Core ML；自己的模型跑在自己的 Mac 上就用 MLX；在 iOS 上需要张量级控制就用 Core AI。把功能放到两条轴上——它运行的是谁的权重，以及谁拥有执行过程——框架自己就选好了。把这四者当作层次而非对手；在正经的应用里，混合部署是常态。

Foundation Models 能运行我自己的模型权重吗？

不能。Foundation Models 永远只运行苹果内置的端侧模型，也就是那个约 30 亿参数的通才模型，外加您的 LoRA 式适配器。它无法加载外部权重，没有例外。如果您需要自己的 LLM，走 Core ML 的蒸馏小模型是可行的，还能拿到 Neural Engine；走 MLX 的量化开放模型在 Mac 上可行。如果任务需要前沿级质量，答案就是一次服务器调用。⁵

我能把 MLX 打包进 iOS 应用发布吗？

现实中不可行。MLX 是苹果机器学习研究团队推出的开源数组框架，而非系统框架；它只编程 GPU 和 CPU，没有 Neural Engine 访问权限；再加上权重分发、发热和审核指南，它对 iOS 安装包来说是错误的工具。MLX 属于您的 Mac、您用户的 Mac，以及您的研究循环。⁴

Core ML 和 Core AI 有什么区别？

Core ML 是预编译式推理：您交给它一个编译好的 .mlmodelc，给出计算单元的提示，调度由框架决定。iOS 27 中新增的 Core AI，则是那间机舱打开了舱盖：NDArray 张量、资产与模型分离，以及显式的计算单元指定。它依然不做训练，也不附带任何内置 LLM。如果您从未与 Core ML 的抽象搏斗过，那就不需要它。⁷

M2 Max 跑本地机器学习有多快？

在我写下这篇文章的 M2 Max 上，MLX 在完全不调优的情况下稳定跑出 4096×4096 的 fp16 矩阵乘 11.2 TFLOPS，以及实测 351 GB/s 的流式带宽。这足以交互式地运行量化后的 300 亿参数开放权重模型，并用 LoRA 一夜之间微调 70 亿参数模型。在去租云 GPU 之前先测一测；这些数字出自一颗落后两代的笔记本芯片。¹

参考资料