Core ML 端侧推理：真正能落地上线的模式

Core ML 是随每一台现代 Apple 设备一起交付的端侧推理引擎。这套框架会在可用时把运算调度到 Neural Engine，不可用时交给 GPU，最后才退回 CPU，并根据模型与硬件自动选择最快的路径¹。结果是：在较新的 iPhone 上，绝大多数生产级模型规模的推理延迟处于亚毫秒到数十毫秒之间，每次调用不产生费用，没有网络往返，也不会把数据暴露给第三方。

把这套框架当成“不起眼的管道”的印象早已过时。近十年来，从“照片”应用的语义搜索到大多数内置本地 ML 的第三方应用，端侧功能一直由 Core ML 支撑；在一直回溯到 iOS 11 的所有系统上，它依然是运行固定的、已转换模型的生产层。不过它在技术栈中的位置确实在 WWDC 2026 上发生了变化：Apple 推出了 Core AI，将其定位为驱动端侧 Apple Intelligence 的底层框架，并指明它是新的神经网络工作的方向¹¹¹²。而让一次 Core ML 部署真正上线、而不是停留在“在我的 Mac 上能跑”的那些模式并没有变，数量依旧不多：模型转换、调度提示、延迟预算与量化。本文会对照 Apple 的文档逐一梳理，最后再把 Core ML 放回 WWDC26 之后的技术栈中定位。

TL;DR

• Core ML 在 Apple Silicon 的 Neural Engine、GPU 和 CPU 上运行 .mlpackage 与 .mlmodel 文件。调度是自动的，但可以通过 MLModelConfiguration.computeUnits 给出提示²。
• 模型转换通过 coremltools 完成（PyTorch、TensorFlow、ONNX → Core ML）。转换属于工具链的工作，而非运行时的工作；模型一旦转换并打包，应用只需加载并运行它。
• Apple Silicon 的统一内存架构意味着模型权重不会在 CPU、GPU 与 NE 之间来回拷贝，三者由同一块内存支撑³。正是这个架构细节让亚毫秒级推理成为可能。
• 量化（近期 Core ML 版本中的 INT8、INT4）能缩小模型体积并加快 Neural Engine 上的推理，代价是可测量的精度损失，具体幅度取决于模型。coremltools 9.0（2025年11月）新增了 iOS 26 部署目标、模型状态读写以及 int8 模型输入输出¹³。
• 技术栈在 WWDC 2026 上变了：Apple 把 Core AI 定位为端侧 Apple Intelligence 背后的推理框架，也是新的神经网络工作的落点；Core ML 则继续作为固定的已转换模型与传统 ML 的生产层¹¹¹²。

心智模型：三条计算路径，一块内存

Apple Silicon（M 系列 Mac 以及 A12 Bionic 之后的 A 系列 iPhone）提供三种推理目标。

Neural Engine。 面向低精度矩阵乘法的专用加速器。对现代 ML 模型所依赖的运算（卷积、注意力、嵌入）最快，功耗也最低。但它只支持特定的运算类型与张量形状，不受支持的算子会按层回退到 GPU 或 CPU。

GPU。 通过 Metal 提供的通用并行计算。处理 ML 形态的任务比 Neural Engine 慢，但快过 CPU，负责承接 Neural Engine 不支持的运算。

CPU。 兜底路径。做 ML 推理很慢，但始终可用、支持全部运算，而且行为可预期。

统一内存架构意味着三者由同一块物理 RAM 支撑³。模型权重只加载一次，调度目标切换时并不会被拷贝。正是这个架构事实，把多目标调度从“逐层的拷贝开销”变成了“逐层的调度决策”。

调度由 MLModelConfiguration.computeUnits 控制。

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all 是默认值，对几乎所有应用来说也是正确选择。框架会为每个运算挑选最快的路径，而这种逐运算的判断比开发者手写的任何启发式都要快。需要覆盖它的场景很少：一种是为了测试结果一致而强制 .cpuOnly（模型在不同路径上的表现存在差异，而测试需要确定性的路径），另一种是强制 .cpuAndGPU，把 Neural Engine 让给另一个并发任务。

模型转换：属于工具链的工作

多数 ML 模型是在 PyTorch、TensorFlow 中训练的，或者直接用 Apple 的 Create ML 训练。Core ML 接受 .mlpackage 文件，这是 Xcode 13 引入、取代旧有 .mlmodel 的现代格式⁴。转换通过 Apple 的开源 Python 包 coremltools 完成⁵。

一次典型的 PyTorch 到 Core ML 转换分三步。

1. 加载训练好的 PyTorch 模型，并切换到推理模式。
2. 用与生产输入形状一致的示例输入张量对模型做 trace。
3. 针对目标 iOS 部署版本，用 coremltools 转换 trace 后的模型。

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

转换只在开发环境中针对目标 iOS 部署版本（minimum_deployment_target）执行一次。输出的 .mlpackage 才是放进 Xcode 工程的产物，运行时的应用并不会执行 coremltools。当前版本 coremltools 9.0 新增了直到 iOS 26 的部署目标、读写模型状态的能力（面向带 KV 缓存的 Transformer 解码器这类有状态模型）、int8 模型输入输出，以及对 Python 3.13 和 PyTorch 2.7 的支持¹³。

转换中有两个实际的坑。其一，动态形状的输入需要用 ct.RangeDim 显式处理，因为 Core ML 默认静态形状，一旦生产环境的应用送入尺寸不一的输入，报错信息往往毫无帮助。其二，PyTorch 中没有 Core ML 对应实现的自定义算子，要么写一个 Core ML 自定义层（用 Swift 代码实现缺失的算子），要么在转换前修改模型结构去掉该算子。两条路的文档都很完善⁵。

真正用得上的延迟预算

对要上线的应用来说，有三档延迟预算值得关注。

16 ms（60 fps 的实时 UI）。 实时相机滤镜、逐帧更新的 AR 场景、实时音频分析。这个预算包含全部环节：图像预处理、模型推理、后处理、UI 更新。能塞进来的模型通常都很小（MobileNetV3 一级，参数量在 1 亿以下），并跑在 Neural Engine 上。

100 ms（交互式 UI）。 用户执行某个操作并等待结果：点一下识别、画一笔认字、说一句转写。这个预算更宽松，可以支撑更大的模型。10 亿参数以下的语言模型、小型视觉 Transformer，以及多数生产级分类器都能从容装下。

1 秒以上（后台或批处理）。 照片库索引、文档分析、应用启动时的模型预热。更大的模型也能用，但必须用进度指示器来管理用户预期。Foundation Models 的端侧 LLM 在上下文窗口较大的操作中就落在这一档。

这些预算是参考线，而非硬性上限。正确的做法不是相信另一台机器上得出的理论数字，而是用 os_signpost 或 Instruments 的 Core ML 模板在目标设备上实测⁶。

量化：更小何时也更快

Core ML 支持多个量化级别⁷:

• Float32（全精度）。 训练时的默认值。体积最大、精度最高、速度最慢。
• Float16。 半精度。在 GPU 与 NE 上更小也更快；对条件良好的模型，精度损失通常可以忽略。
• INT8。 带校准的 8 位整数量化。体积大致是 Float32 的四分之一，在 NE 上常有 2 到 4 倍的提速。精度损失因模型而异；对视觉模型来说，配合量化感知训练可以把 top-1 精度损失控制在 1% 以内。
• INT4 及以下。 近期 Core ML 版本针对特定模型架构（LLM、大型视觉模型）支持的激进量化。代价是明显的精度损失；这项技术与针对模型特点的量化感知训练搭配时效果最好。

通过 coremltools.optimize.coreml.linear_quantize_weights 做线性量化时，会接受一份全局 op 配置，用来选择量化模式（linear_symmetric 或 linear），并设定一个权重体积阈值，低于该阈值的权重保持全精度。转换在既有的 .mlpackage 上运行，产出一个新的量化包；两者可以同时放进 bundle，由应用根据设备档次决定加载哪一个。

是否量化要逐个模型判断：小分类器可能得不到多少好处，因为它的计算本来就很便宜；大语言模型受益极大，因为它的计算主要由量化权重上的矩阵乘法主导。正确的做法是先量化，在留出的测试集上测精度，如果精度损失对该用途可以接受就发布。

可以直接拿来用的 Apple 内置模型

Apple 通过 Core ML Models 页面提供了若干预训练的 Core ML 模型⁸。值得了解的几类如下。

• 图像分类： MobileNetV2、ResNet50、SqueezeNet 各变体，均已打包好，可直接放入 Vision 框架的 VNCoreMLRequest。
• 目标检测： YOLOv3、MNIST、CenterNet 各变体。
• 姿态估计： 用于人体姿态的 PoseNet（可作为 Vision 中 VNDetectHumanBodyPoseRequest 的基线替代）。
• 语义分割： 用于图像分割的 DeepLabV3。
• 文本识别： 基于 ML 的 OCR，作为 Vision 内置能力之外的选择。

对多数应用而言，Apple 的预训练模型已经覆盖了感知类基本能力（分类、检测、分割），无需自行训练。至于语言任务，系统的端侧 LLM 完全位于这一层之上：Foundation Models 框架以高层 Swift API 的形式把它暴露出来，离线且免费，不需要您自行打包或转换任何模型文件。

模型加密与 App Store 相关考量

应用 bundle 里的 .mlpackage，任何人解包 IPA 都能读取。对于确实构成知识产权的模型，Apple 通过 Encrypt your Core ML model 工作流支持模型加密⁹: 通过 Xcode 生成加密密钥并交由 CloudKit 管理，bundle 中的模型以加密形式存放，Core ML 在加载时解密。

对大多数应用来说，加密属于过度设计。用通用 ImageNet 数据训练出来的模型并不构成竞争壁垒，加密它只会增加运维复杂度，却没有保护到任何有价值的东西。请把加密留给那些真正体现训练数据投入或竞争优势的模型。

端侧隐私：架构层面的胜利

隐私这件事很直接。Core ML 的推理完全在设备上完成。输入数据（图像、音频、文本）不会离开设备。模型文件在本地，推理在本地，结果也在本地。

对受监管行业（医疗、金融、教育）的应用来说，这个架构事实直接消除了一整类合规工作。没有需要写进隐私政策的第三方数据处理方，没有需要做安全审查的模型 API 端点，也不存在数据驻留问题，因为数据根本没有移动过。

隐私清单（Privacy Manifest）格式¹⁰把这套隐私叙述固化到 App Store 提审流程中：一个仅用 Core ML 做端侧推理、别无其他的应用，可以就推理路径声明零第三方数据共享。提审流程更快，隐私审核更短，面向用户的隐私“营养标签”也更干净。

与智能体工作流的连接

Core ML 与本系列已经覆盖过的三种模式相互配合。

Vision 框架的 VNCoreMLRequest。 自定义 Core ML 模型可以经由 Vision 流水线运行，并自动完成预处理。这一模式（在 Vision Framework 中有详述）是在 iOS 应用中交付自定义图像分类器或检测器的正道。

Foundation Models 的端侧 LLM。 Apple Intelligence 的系统级 LLM 位于 Foundation Models 框架之后，而截至 WWDC 2026，Apple 明确指出驱动它的推理框架是 Core AI¹¹。本文中的概念依然可以直接迁移：计算单元调度、量化权重与延迟预算，对系统级 LLM 的约束方式，与对您自己转换的模型完全一样。那篇讲框架的文章覆盖 LLM 的 API，本文覆盖其下的推理模式。

使用本地 ML 的 App Intents 工具。 一个运行本地图像分类器或文本分类器的 AppIntent，可以在没有网络往返的情况下把结构化结果返回给 Apple Intelligence。正是这种组合让“智能体化的 Apple”真正保有隐私；智能体的工具之所以能跑在本地，是因为框架支持这么做。

何时该选择云端推理

Core ML 的上限就是设备的算力。有三种情形云端才是正确答案。

大到无法随 bundle 分发的模型。 700 亿参数的 LLM 装不进应用 bundle。这种量级的负载，云端推理（或者流式加载权重再在端侧运行，那是另一种模式）才是合适的工具。

推理过程中需要跨设备共享状态。 推理时必须读写共享数据库的模型（例如面向数十亿条记录做协同过滤的推荐系统）。Core ML 纯本地的模式并不契合。

模型迭代非常快。 每天都要发布模型更新的团队会更受益于服务端推理，因为发布不必等待 App Store 审核周期。Core ML 把模型打进应用的做法给模型迭代节奏带来了摩擦，这个权衡是真实存在的。

规律很清楚：云端胜在规模与迭代速度，Core ML 胜在延迟、成本与隐私。

WWDC 2026 之后 Core ML 的位置

WWDC 2026 重画了本文脚下的地图，但并没有让它失效。Apple 推出了 Core AI，这是一个 iOS 27 的框架，其摘要写着“Run AI models in your app on Apple silicon”；并在第 324 场 session 中表示，Core AI 就是驱动端侧 Apple Intelligence 的推理框架，如今已向第三方应用开放¹¹。如果说 Core ML 的转换器替您做出了硬件与优化上的决定，那么 Core AI 把这些操纵杆交到了您手里：显式的模型特化、受管理的产物缓存、计算单元定向，以及异步计算流。完整拆解见 Core AI：在 Apple silicon 上运行模型。

关于走向的信号，比文档本身透露的还要强烈。在 WWDC 2026 的机器学习 group lab 上，一位 Core AI 工程师表示，Apple 正在请所有做神经网络的人今后转向 Core AI，Core ML 会保留，但重心转向决策树这类传统机器学习¹²。这句话是实验室问答的转述而非公开政策，但它与这次发布的整体形态吻合：新的工具链、新的格式以及 Apple Intelligence 的负载，都归了 Core AI。

对今天就要发布的应用，务实的读法如下。

• 既有的 Core ML 部署会继续工作。 iOS 27 中没有任何内容废弃 .mlpackage 这条路径，而 coremltools 9.0 在 2025年11月这样不久之前才交付了新能力（iOS 26 目标、有状态模型、int8 输入输出）¹³。
• 在 iOS 27 以下，Core ML 仍是唯一选择；对于一个固定的、已转换的模型，如果转换器的默认行为正合您意，它也是务实的选择。
• 面向 iOS 27 及以上的新神经网络工作，应当优先评估 Core AI，尤其是当您能明确说出所需的特化、缓存或调度控制时。
• 其他各层没有移动。 系统级 LLM 仍在 Foundation Models之后，MLX 仍是面向自有开放权重模型与微调模型的可嵌入数组框架。Core ML 与 Core AI 之争，讨论的是您模型的执行层，而不是这些。

这套模式对 iOS 26 及以上应用意味着什么

三点结论。

1. 只要模型能装进 bundle，并且每次调用都能返回用户可据此行动的结果，就默认选择 Core ML。 图像分类、目标检测、音频分类、手势识别、嵌入生成，以及中小规模的语言任务都属于此列。框架的自动调度加上 Apple Silicon 的 NPU，免费带来亚毫秒到数十毫秒的推理。

2. 只要精度损失可以接受，就大胆量化。 INT8 通常是安全的；INT4 适合那些体积节省确实重要的大模型。请在留出集上测量精度，而不要想当然地认为量化在任何场景下都安全。

3. 与 Vision、Foundation Models 搭配，构成完整的本地流水线。 Core ML 是引擎，Vision 是其上的感知 API，Foundation Models 是其上的 LLM。本系列的 Vision 一文与 Foundation Models 一文覆盖了更高层的接口。

完整的 Apple Ecosystem 系列包括：带类型的 App Intents；MCP 服务器；路由之问；Foundation Models；运行时与工具链 LLM 之别；三种接口；单一事实来源模式；两个 MCP 服务器；面向 Apple 开发的 hooks；Live Activities；watchOS 运行时；SwiftUI 的内部构造；RealityKit 的空间心智模型；SwiftData 的 schema 纪律；Liquid Glass 模式；多平台交付；平台矩阵；Vision 框架；Symbol Effects；我拒绝写的那些主题。系列主页在 Apple Ecosystem 系列。若想了解 iOS 与 AI 智能体结合的更广背景，请参阅 iOS Agent Development 指南。

常见问题

Core ML 如何在 Neural Engine、GPU 和 CPU 之间做选择？

Core ML 会逐个检查模型图中的运算，并把它派发给支持该运算的最快目标。Neural Engine 以最低的延迟和功耗处理它支持的运算（大多数矩阵乘法、卷积、注意力）。NE 不支持的算子交给 GPU，其余的由 CPU 处理。这个决策是逐运算的、自动的，而且比手写启发式更快。

是不是应该始终使用 .computeUnits = .all？

几乎总是如此。框架的自动调度调校得很好。需要覆盖它的场景有两种：测试输出一致性时改用 .cpuOnly（由于浮点舍入，同一模型在 NE 与 CPU 上的结果会略有差异），或者为并发任务腾出 Neural Engine 时改用 .cpuAndGPU。

.mlpackage 与 .mlmodel 的实际区别是什么？

.mlpackage 是 Xcode 13 引入的现代格式，支持存储元数据、为 ML Program（mlprogram）编译准备的多个模型变体，以及 iOS 13 之后的工具链。.mlmodel 是遗留格式。两者都能通过 MLModel 加载，但新项目应当使用 .mlpackage。

应用 bundle 中的 Core ML 模型可以有多大？

没有固定上限，但 App Store 对下载包大小的限制是 4 GB，空中下载安装也有现实约束。系统的端侧 LLM 完全绕开了这个问题：由系统负责分发，应用通过 Foundation Models访问，无需自行打包任何东西。对随应用打包的模型来说，100 MB 以内很宽裕；100 到 500 MB 配合启动时的加载策略也可行；超过 500 MB 最好通过 BGProcessingTask 后台下载或按需资源来处理。

新模型应该用 Core ML 还是 Core AI？

在 iOS 27 以下，Core ML 是唯一选择。在 iOS 27 及以上，Apple 表明的方向是神经网络用 Core AI，传统机器学习与既有部署继续用 Core ML¹¹¹²。如果您有一个固定的、已转换的模型，而转换器的默认行为足够用，Core ML 依然可以顺利上线；如果需要对特化、缓存或调度做显式控制，Core AI 存在的意义正是提供这种控制。

怎么知道量化是否损伤了模型精度？

留出一份测试集，分别在原始 Float32 模型和量化模型上跑推理，比较各项指标（分类器看 top-1 精度，检测器看 F1，语言模型看 perplexity，翻译看 BLEU 等），再依据应用对精度的要求做判断。量化感知训练（在损失函数中模拟量化来训练模型）通常能挽回大部分精度损失。

参考资料