Core AI：在 Apple Silicon 上运行模型

苹果的端侧 AI 技术栈一直缺了一级台阶。Foundation Models 提供封装好的系统 LLM，免费可用。Core ML 运行一个已转换的固定模型，硬件层面的取舍交由转换器替您决定。MLX 给出的是一套由您自行嵌入的数组框架，以及一个由您自行挑选的模型。iOS 27 补上了位于这三者之下的那一级：Core AI，其一句话概述是“Run AI models in your app on Apple silicon”。¹ 它是模型执行层，是当您希望亲自掌控特化、缓存与推理调度，而不是接受上层默认行为时所要触及的地方。

在第 324 场讲座中，苹果把 Core AI 定位为驱动端侧 Apple Intelligence 的同一套推理框架，如今开放出来，供您自己应用中的智能功能使用。¹⁵

这个定位之所以重要，是因为 Core AI 位于大多数应用理应使用的抽象之下。苹果的描述是：Core AI 在设计上充分考虑了 Apple silicon，让应用能够在 CPU、GPU 与 Neural Engine 上使用最新的模型架构与推理技术；其 Swift API 让常见任务保持简单，同时在需要时把模型特化、缓存与推理性能的更多控制权交到您手中。¹ 本文的论点是：当您有一个模型，并且希望明确控制它在何处、以何种方式执行时，就选择 Core AI；否则请留在 Core ML 或 Foundation Models 这一层。这个框架回报的是具体的需求，而不是默认的偏好。

TL;DR / 要点速览

• Core AI 把未特化的 AIModelAsset（以低成本检查模型的结构与元数据）与已特化的 AIModel（在设备上运行推理）区分开来；AIModelCache 保存设备专属的产物，AssetError 表示资源操作失败。²³⁶⁴
• 推理数据通过 NDArray 流转，它是一个由标量值构成的多维数组，其形状、标量类型与内存布局预期由 NDArrayDescriptor 规定。⁵⁷
• 您通过 SpecializationOptions 使用 ComputeUnitKind（CPU、GPU 或 Neural Engine）来定向硬件，并把异步工作调度到 ComputeStream 上。⁸⁹¹⁰
• InferenceFunction 持有权重与缓冲区并执行推理；InferenceFunctionDescriptor 让您先行查看它的输入、输出与状态签名。该函数是 Sendable 的，因此可以并发运行。¹⁴¹³
• 模型从磁盘上的 .aimodel 包加载。围绕框架的工具链现已完整成文：coreai-torch 这个 Python 包负责转换 PyTorch 模型，coreai-build 命令行工具把 .aimodel 提前编译为按架构区分的 .aimodelc 资源，而 Core AI Debugger 应用、Xcode 调试仪表与 Instruments 模板则覆盖了检查与性能分析。¹⁷ 当您需要明确控制特化与调度时选择 Core AI；否则请留在 Core ML 或 Foundation Models。²¹

贯穿整套设计的两个词：资源与模型

Core AI 要您首先内化的一点是：磁盘上的模型和运行推理的模型是两种不同的对象，而把前者特化成后者代价高昂。框架为二者各自给出了一个类型。

AIModelAsset 是“an unspecialized source model asset”（未特化的源模型资源）。² 您从磁盘上 .aimodel 包的 URL 创建它，用它在不付出特化成本的前提下检查模型。苹果明确说明了这种拆分存在的理由：模型资源让您无需执行特化这一昂贵操作，就能查询模型信息。从资源中，您可以读取函数签名、输入与输出说明、计算类型与存储类型，以及作者提供的元数据。您不能做的是运行推理——资源只用于检查。²

// Call shape is illustrative; confirm the exact initializer against Apple's docs.
let asset = try AIModelAsset(url: bundleURL)   // an .aimodel bundle on disk
// Inspect signatures, input/output descriptions, compute and storage types,
// and author-provided metadata — without specializing.

另一半是 AIModel：“a specialized model for running inference on a device”（用于在设备上运行推理的已特化模型）。³ AIModel 代表一个针对当前设备硬件优化过的已特化 .aimodel 资源，通过从磁盘加载资源来创建。³ 资源回答的是这是什么模型？，模型回答的是就在这里、现在运行它。二者之间的成本不对称，正是 API 强制您指明想要哪一个的原因。若只构建资源，检查上百个候选模型再从中挑一个成本很低；若每次检查都要特化，那将不堪重负。

特化会产出设备专属的产物，而这些产物有自己的归宿：AIModelCache，“a cache that stores the specialized model artifacts for inference”（存储用于推理的特化模型产物的缓存）。⁶ 该缓存保存模型执行其推理函数时所加载的、经过优化的设备专属产物；苹果指出，每个缓存条目都包含一个由特定 .aimodel 或 .aimodelc 与某种特化组合所形成的特化资源。⁶ 实践层面的解读是：特化不是您希望每次启动都重来一遍的事。缓存正是 Core AI 让昂贵的一步只发生一次、此后只发生便宜的一步（加载已缓存产物）的方式。

当资源操作出错时（包缺失、.aimodel 格式损坏、文件不可读），Core AI 会抛出 AssetError，“an error that occurs during model asset operations”（模型资源操作期间发生的错误）。⁴ 请像对待任何 I/O 边界那样对待它：资源位于磁盘上，磁盘操作会失败，而类型系统会准确告诉您 catch 该写在哪里。

张量：NDArray 及其描述符

推理是把数字送进去、再把数字取出来，而 Core AI 承载这些数字的容器是 NDArray，“a multidimensional array of scalar values used for model inference”（用于模型推理的标量值多维数组）。⁵ 如果您用过 NumPy 的 ndarray、MLX 数组或 MLMultiArray，这个概念的轮廓会很熟悉：一块带有明确布局的 n 维标量数据。NDArray 按其形状及其余描述性属性所定义的布局来存储数据。⁵

与之配套的类型是 NDArrayDescriptor，“a description of an array’s shape, scalar type, and memory layout expectations”（对数组形状、标量类型与内存布局预期的描述）。⁷ 描述符就是契约。苹果的说法很直接：描述符包含了对您提供给推理函数的数组值的预期，而且大多数预期都是严格的。如果描述符指定标量类型为 .float32，那么您提供的数组就必须使用 .float32。⁷ 您不必猜测函数想要什么形状和类型；去问函数的描述符，然后照做即可。

// Call shape is illustrative; confirm exact property/method names against Apple's docs.
let inputDescriptor = function.descriptor.inputs.first!   // an NDArrayDescriptor
// The descriptor fixes shape, scalar type, and layout; the array you build
// must satisfy those expectations (e.g. .float32 means .float32).

这里的设计启示与资源／模型的拆分如出一辙。Core AI 始终在昂贵的值对象之前放一个便宜的描述对象。您先读描述符弄清契约，再分配满足它的 NDArray，而不是先分配、到推理时才发现不匹配。针对图像输入，Core AI 还定义了 ImageDescriptor，“a description of an image’s dimensions and pixel format”（对图像尺寸与像素格式的描述），于是视觉模型的像素输入也享有同样的“描述符优先”待遇。¹¹

选择推理在哪里运行

Apple silicon 上有三处可以计算：CPU、GPU 与 Neural Engine。Core AI 之所以存在、而不是只有 Core ML，就是因为 Core AI 让您能够指明框架要面向其中哪一个，而不是由它自行推断。

ComputeUnitKind 是“a type of hardware compute unit available for model inference”（可用于模型推理的一类硬件计算单元）。⁸ 您把计算单元种类与特化选项配合使用，以控制框架在特化模型时面向哪种硬件；默认情况下，特化会使用设备上所有可用的计算单元。⁸ 对绝大多数工作而言，默认值就是正确答案——这正是关键：只有当您有理由时才去覆盖它，比如想把一条对延迟敏感的路径钉在 Neural Engine 上，想把某次调试强制放到 CPU 上，或者有一条需要与其他 GPU 工作协同的重 GPU 流水线。

这一意图通过 SpecializationOptions 传达，它是承载特化时所做选择的结构体。⁹ 特化正是前文那个昂贵的步骤，而计算单元定向以及其他特化决策都集中在 SpecializationOptions 中。由于缓存条目以特定资源与特化组合作为键，改变选项就会改变您取回的缓存产物，从而把定向与缓存闭合成一个环。⁶

“如何运行”的另一个维度是调度，Core AI 把它建模为 ComputeStream，“a stream of work to be run asynchronously”（一条将被异步执行的工作流）。¹⁰ 计算流是您用来把工作编码进去的对象；苹果指出，编码到同一条流上的多次推理，会根据所读写的值按需串行化。¹⁰ 由此可得两点推论。其一，流是您的排序原语：把相互依赖的推理编码到同一条流上，Core AI 就会按数据依赖为它们排序。其二，工作默认是异步的，因此当 Neural Engine 或 GPU 在干活时，流也正是您让调用线程保持空闲的手段。

推理函数：真正执行的那个东西

一个加载好的 .aimodel 并不是单个可调用体。模型会暴露一组具名函数（编码器、解码器、视觉塔，或 prefill 与 decode 两个步骤），而 Core AI 的执行单位是 InferenceFunction：“a function that performs inference on input values and produces output values”（对输入值执行推理并产出输出值的函数）。¹⁴

在调用之前，先检查它。InferenceFunctionDescriptor 是“a description of an inference function’s signature”（对推理函数签名的描述），您用描述符在运行推理前查看该函数输入、输出与状态的名称和类型。¹³ 值得停下来多看一眼的是状态：带状态的函数，正是有状态模型（例如 Transformer 解码循环中的 KV 缓存）在多次调用之间保留信息的方式，而描述符会在您试图驱动它之前，就告诉您这个函数是否带有状态。

InferenceFunction 本身持有推理所需的资源，包括模型权重与中间缓冲区。您从模型中加载函数，并调用 run(inputs:states:outputViews:) 来执行推理。¹⁴ run 的签名在苹果自己的说明中被点名给出，因此一次调用需要的三样东西一目了然：输入值、状态值，以及您希望被写入的输出视图。

// run(inputs:states:outputViews:) is named in Apple's docs; surrounding
// loading/value-construction shapes are illustrative — confirm against Apple's docs.
let function: InferenceFunction = /* load from an AIModel */
let outputs = try function.run(
    inputs: inputValues,        // InferenceValue per input
    states: stateValues,        // any stateful values the function declares
    outputViews: outputViews
)

有两个特性让这个函数在高负载下用起来很舒服。它是 Sendable 的，因此可以从多个任务并发运行；苹果还指出，为支撑这种并发，它会按需自动分配额外的中间缓冲区。¹⁴ 您不必为了保护共享暂存空间而用锁把调用串起来——函数会为每个并发调用方管理各自的缓冲区。相比那些单个推理句柄实际上只能单线程使用的 API，这是一个实打实的差别。

流经 run 的值是 InferenceValue 实例，“a value that an inference function accepts as input or produces as output”（推理函数作为输入接受、或作为输出产生的值）。¹² InferenceValue 包装的要么是 NDArray，要么是像素缓冲区；推理结束后，您通过它的 value 属性取回结果。¹² 正是这层包装，让同一个 run 签名无需拆成多个重载就能同时承载张量输入与图像输入：文本模型传入由 NDArray 支撑的值，视觉模型传入由像素缓冲区支撑的值，而函数则通过读取描述符来知道自己期望的是哪一种。

何时该动用 Core AI

Core AI 最难的部分不是 API，而是判断您究竟该待在这一层，还是待在上面一层。诚实的决策树如下：

• Foundation Models：当苹果的系统模型能完成这项任务时。摘要、分类、抽取、改写、结构化输出——这些属于 Foundation Models 框架，它不占用您的权重、内存预算，也不需要特化步骤。如果您的功能能装进去，就到此为止。为了重新实现系统模型已经做好的事情而下沉到 Core AI，纯属白费力气。
• Core ML：当您有一个固定的、已转换的模型，并希望由转换器替您做硬件与优化决策时。Core ML 面向 Neural Engine，为锁定下来的生产模型提供严格的功耗与延迟表现，而且完全不要求您考虑特化或调度。如果您不想去想计算单元定向或计算流，这就是留在 Core ML 的信号。
• MLX：当您想要一套可自行嵌入并反复迭代的科研级数组框架时——自己的训练循环、量化的开放权重模型、LoRA 微调、快速实验。MLX 是您随权重一起发布的库，而不是系统级的模型执行层。它胜在灵活性与迭代速度。
• Core AI：当您有一个要运行的模型，并且想要框架给出的那些明确把手时：可在投入前检查的 AIModelAsset、能钉住计算单元的 SpecializationOptions、由您管理的 AIModelCache、可供调度的 ComputeStream，以及可以并发调用的 InferenceFunction。当上层的默认行为恰恰成了挡路的东西，而您又能说清自己需要覆盖哪一个默认时，就该来这里了。

贯穿整套技术栈的主线是：每往下一层，就用一个默认换来一个把手。Foundation Models 把一切都给您，什么都不问。Core AI 把操纵杆交给您，并要求您知道该拉哪一根。如果您说不清自己需要哪一项特化、缓存或调度控制，那就说明您还不需要 Core AI。

WWDC 2026 一场实验室问答中的表态，让 Core AI 与 Core ML 在新项目上的分界更清晰。根据对 WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab 的本地转录录音所作的转述，参与问答的一位 Core AI 工程师表示，苹果正在请所有从事神经网络工作的人今后转向 Core AI；Core ML 会继续保留，但聚焦于决策树之类的传统机器学习，而所有新东西都将走向 Core AI。¹⁶ 请把它当作构建该框架的人所释放的方向性信号，而非成文的政策：如果您要在新项目中动用神经网络，实验室的说法是把 Core AI 当作构建的基础。

一个模型如何抵达 Core AI

这个框架只是更大工作流中属于运行时的那一半；自 6 月的测试版以来，苹果已经把工具那一半也完整公布。¹⁷ 整条流水线是这样运转的。

转换。 您从一个 .aimodel 文件开始，它要么由源模型经 coreai-torch 包（苹果的 Core AI PyTorch Extensions for Python）转换而来，要么本来就已准备成该格式。¹⁷ .aimodel 像任何资源一样加入您的 Xcode target，会出现在 Compile Sources 构建阶段中，并在 Xcode 里获得一个模型查看器，用于显示参数、存储体积、元数据与运算图。有一项构建系统依赖需要提前知道：Core AI 的模型集成需要 Metal Toolchain，而 Xcode 默认并不安装它；缺少它时，包含 .aimodel 文件的构建会以“找不到 Metal 编译器”的错误失败。¹⁷

可选的提前编译。 特化会在您创建 AIModel 时自动发生，而对大模型来说，这笔首次加载的开销相当可观。coreai-build 命令行工具把其中最昂贵的部分——模型编译——转移到您的构建机器上：它把 .aimodel 转换为按设备架构区分的 .aimodelc 资源，每种架构一个（编译 MyModel.aimodel 会产出 MyModel.<arch>.aimodelc）；运行时应用挑选与当前设备匹配的资源，于是 Core AI 就跳过了编译步骤。¹⁷ 提前编译面向的是 Apple Intelligence 的硬件门槛：搭载 A17 Pro 或更新芯片的 iPhone 或 iPad、M1 或更新芯片的 Mac，以及搭载 M2 的 Apple Vision Pro。¹⁷

调试与性能分析。 三样工具撑起了可观测性：Core AI Debugger，一款独立的 macOS 应用，用于检查模型的运算图、在设备上运行它，并把输出与一次参考运行做比对；Xcode 中的 Core AI 调试仪表，在调试会话期间实时监控加载、特化与推理活动；以及 Core AI instrument，一个 Instruments 模板，用于分析跨 CPU、GPU 与 Neural Engine 的执行耗时。¹⁷

前文描述的运行时形态可以原封不动地嵌入这套工作流：准备好的模型先作为 AIModelAsset 加载以供检查，再特化为 AIModel，然后通过它的 InferenceFunction 运行；AIModelCache 则保存特化产物，让昂贵的那一步只发生一次。¹²³⁶¹⁴

常见问题

苹果的 Core AI 框架是什么？

Core AI 是 iOS 27 中用于在 Apple silicon 上运行 AI 模型的底层框架，苹果将其概括为“Run AI models in your app on Apple silicon”。¹ 它通过一套 Swift API 在 CPU、GPU 与 Neural Engine 上运行模型推理，让常见任务保持简单，同时在您需要时提供对模型特化、缓存与推理性能的控制。¹ 作为模型执行层，它位于 Foundation Models 与 Core ML 之下。

AIModelAsset 与 AIModel 有什么区别？

AIModelAsset 是您用磁盘上 .aimodel 包的 URL 创建的未特化源资源；因为特化代价高昂，您用它在不特化的情况下检查模型的函数签名、输入与输出说明、计算类型与存储类型以及元数据，而资源本身无法运行推理。² AIModel 则是针对当前设备硬件优化过、确实会运行推理的已特化模型；您通过从磁盘加载资源来创建它。³ 这种拆分让您以低成本检查，只在真正投入时才特化。

Core AI 如何在 CPU、GPU 与 Neural Engine 之间做选择？

您通过 SpecializationOptions 使用 ComputeUnitKind 来控制硬件定向。计算单元种类指的是可用于推理的一类硬件计算单元，您用它控制框架在特化模型时面向哪种硬件；默认情况下，特化会使用设备上所有可用的计算单元。⁸⁹ 只有在有明确理由时才覆盖默认值，比如把一条对延迟敏感的路径钉在某一个计算单元上。

什么是 InferenceFunction，我该如何运行它？

InferenceFunction 对输入值执行推理并产出输出值，同时持有模型权重与中间缓冲区。¹⁴ 您先通过 InferenceFunctionDescriptor 查看它的签名，该描述符会说明函数输入、输出与状态的名称和类型；随后从 AIModel 中加载该函数并调用 run(inputs:states:outputViews:)。¹³¹⁴ 该函数是 Sendable 的，并会自动分配中间缓冲区以支撑并发，因此多个任务可以同时运行它。¹⁴

我该用 Core AI 取代 Core ML 或 Foundation Models 吗？

当系统模型能完成任务时用 Foundation Models；当您有一个固定的已转换模型、并希望由转换器替您做硬件与优化决策时用 Core ML。当您想要明确控制那些原本由上层代劳的特化（SpecializationOptions、ComputeUnitKind）、缓存（AIModelCache）与调度（ComputeStream）时，再动用 Core AI。⁸⁹⁶¹⁰ 如果您说不清自己需要哪一项控制，就留在上面一层。

完整的 Apple Ecosystem 系列如下：MLX on Apple Silicon 讲当您想要自己的模型与训练循环时所嵌入的数组框架；Apple Silicon 的 TBDR 与统一内存 讲让 CPU／GPU／Neural Engine 共享得以成立的硬件底座；Core ML 端侧推理 讲 Core AI 之上那一层固定模型；Foundation Models 讲位于技术栈顶端、苹果封装好的系统 LLM。系列入口在 Apple Ecosystem 系列。若想了解 iOS 与 AI 智能体结合的更广背景，请参阅 iOS Agent Development 指南。

参考资料