Apple Core AI 集成#

Core AI 是 Apple 推出的新框架，可直接在 Apple silicon 上运行神经网络。它引入了 .aimodel 模型格式、现代 Swift 推理 API、基于 PyTorch 的转换工具、提前编译、模型专门化，以及专用的调试和性能分析工具。

Apple 将 Core AI 描述为端侧 AI 执行的下一代方案，也是 Apple Intelligence 端侧运行所依托的推理框架。它专为当前的神经网络架构设计，适用于从紧凑型视觉模型到大型生成式模型的各种模型，并可在 CPU、GPU 和 Apple 神经引擎 (ANE) 之间调度任务。

Core AI 是一条新的部署路径，并非 Core ML 的新名称。这些框架使用不同的模型格式、转换工具、运行时 API 和应用集成模式。

Core AI 与 Core ML 对比#

如果应用需要广泛的设备覆盖、Vision 框架集成，或决策树和表格型流水线等模型类型，Core ML 仍是合适的选择。Apple 继续支持 Core ML，并建议使用非神经网络模型类型的开发者选择 Core ML。

Core AI 格式的工作原理#

Core AI 的模型创作工作流程以 PyTorch 模型为起点：

PyTorch model
    ↓ torch.export
ExportedProgram
    ↓ coreai-torch
Core AI program
    ↓ optimize and save
.aimodel
    ↓ specialize or compile ahead of time
Apple silicon executable

Apple 的 coreai-torch 软件包会将 PyTorch ATen 操作降级为 Core AI 操作，从而转换 torch.export.ExportedProgram。对于不受支持的操作，可以通过自定义降级实现或自定义 Metal 内核来实现。

生成的 .aimodel 是一个尚未专门化的模型资源。应用准备模型时，Core AI 会针对目标设备对其进行专门化。应用可以让这一过程在首次使用时发生，也可以提前请求专门化，或提供提前编译的模型以缩短初始加载时间。

在 Swift 中，应用使用 Core AI 框架加载资源，选择推理函数，提供类型化的 NDArray 输入，并接收带名称的输出。这不同于将 Core ML 模型包装在 Vision 请求中，因此采用 Core AI 需要应用运行时能够处理 .aimodel 资源。

实现详情请参阅 Apple 关于 AIModel、模型专门化与缓存以及提前编译的文档。

将 YOLO26 模型导出到 Core AI#

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.export(format="coreai")  # 创建 'yolo26n.aimodel'
model.export(format="coreai", quantize=16)  # FP16 asset

# 运行导出的模型
coreai_model = YOLO("yolo26n.aimodel")
results = coreai_model("https://ultralytics.com/images/bus.jpg")

完整参数列表请参阅导出模式。计算图是静态的：它会按照传递给 export 的 imgsz 进行追踪，因此预测时请使用相同尺寸。Ultralytics 元数据存储在资源自带的 metadata.json 中，因此类别名称、步幅和任务信息在往返过程中都会保留。

选择检测头#

使用 nms=False 时，YOLO26 会导出端到端检测头，在计算图内筛选检测结果。Core AI 没有 top-k 原语，因此该筛选操作会降级为完整排序，并在 Apple 神经引擎分区边界产生固定开销——约 1.7 ms，与 max_det 无关。使用 nms=None 导出则会输出原始 (1, 84, 8400) 预测结果，并将非极大值抑制留给预测器处理：

yolo export model=yolo26n.pt format=coreai nms=None quantize=16

在运行 iOS 27.0 的 iPhone 17 Pro 上，YOLO26n 输入尺寸为 640 时，检测头位于计算图内的耗时为 3.01 ms，不包含检测头时为 1.28 ms（FP16、提前编译、三个交错的 50 次迭代区块）。这两种方式在推理时都通过 YOLO(...) 完成往返转换。如果单次计算图调用必须返回最终检测结果，请使用 nms=False；如果要使用外部 NMS，则保留默认的 nms=None。

在 iOS 27 或 macOS 27 上，应用随后会通过 Apple 的 Core AI Swift API 加载并运行导出的资源。导出的资源使用入口 main，接收形状为 [batch, 3, imgsz, imgsz] 的单个 images 输入，并返回 output0（实例分割模型还会返回 output1）：

import CoreAI

let modelURL = Bundle.main.url(forResource: "yolo26n", withExtension: "aimodel")!
let model = try await AIModel(contentsOf: modelURL)
guard let function = try model.loadFunction(named: "main") else {
    throw AppError.missingInferenceFunction
}

let outputs = try await function.run(inputs: ["images": imageTensor])

与当前的 Core ML 和 Vision 工作流程不同，Ultralytics iOS SDK 中的 Core AI 路径会自行执行 letterbox 预处理并构造 NDArray，从资源的 metadata.json 读取相同的 Ultralytics 元数据，并重用 Core ML 输出解码器。应用传入 .aimodel 路径或 .aimodel.zip URL 时，SDK 会加载资源。Apple 在 Core AI 框架文档中提供了最新 API 详情，并在 Core AI 模型仓库中提供了可运行的模型示例。

实测性能#

在配备 Apple M4 的 Mac mini 上，使用默认原始检测头（nms=None）运行 YOLO26n FP16（quantize=16）Core ML 和 Core AI 导出模型的端到端单图推理测试结果如下。设备配置为 4 个性能 CPU 核心、6 个能效 CPU 核心、10 核 GPU、16 核神经引擎、16 GB 内存，运行 macOS 27.0；测试使用 ultralytics 8.4.168、Core ML 推理用的 coremltools 9.0，以及 Python 3.13 上用于 Core AI 推理的 coreai-torch 0.4.3 和 coreai-core 1.0.0b3。每个单元格显示总耗时（预处理 + 推理 + 后处理），下方为各阶段耗时明细。

• 速度值是单图突发延迟：通过 Ultralytics Python API，在 bus.jpg 上预热 3 次后，连续调用 predict 15 次所测得的平均值；每个模型和计算单元都在独立的新进程中运行。各任务在一次顺序测试中交替测试 CPU/加速器。Core ML 行通过 coremltools.ComputeUnit.CPU_ONLY 或 CPU_AND_NE 加载；Core AI 行通过 SpecializationOptions.cpu_only() 或 SpecializationOptions.from_preferred_compute_unit_kind(ComputeUnitKind.neural_engine()) 进行专门化，最终的操作放置由各框架控制。
• 在每个计算单元上，检测、分割、分类、姿态和 OBB 在两种格式下都返回相同的预测结果。在这台 Mac 上，优先使用 Neural Engine 的 Core ML FP16 语义分割模型比仅使用 CPU 运行得更慢；Core AI 语义后处理耗时为 6.4 到 7.4 毫秒，而 Core ML 为 0.4 毫秒。
• 对比设备端 iPhone 17 Pro 的结果，请参阅 CoreML 集成。

Core AI 的优势#

Core AI 为未来在 Ultralytics 上的部署带来了一些值得期待的优势：

• 现代 PyTorch 导出路径：转换从 torch.export 开始，相比许多现有导出器使用的跟踪流程，能保留表达能力更强的 PyTorch 计算图。
• 精细的运行时控制：应用可以管理专门化、编译模型缓存、推理函数、内存和计算资源分配。
• 先进的模型支持：有状态执行、动态形状、单个制品中的多个函数以及自定义 Metal 内核，旨在支持现代视觉和生成式架构。
• 专用开发者工具：Core AI Debugger 可检查计算图和张量值，并追溯到对应的 Python 代码。Xcode 和 Instruments 可用于运行时分析。
• 零拷贝机会：Core AI 提供存储和缓冲区控制，旨在减少相机、图形处理和推理工作负载之间的数据拷贝。
• 针对 Apple 芯片优化：设备专门化让 Apple 能针对特定设备上的 CPU、GPU 和 Neural Engine 优化模型。
• 灵活的压缩方式：Apple 的 Core AI Optimization 工具支持量化、调色板化和剪枝，包括低比特权重格式。

这些功能可能尤其适用于未来的 YOLO 模型，例如采用动态执行、包含较大多模态组件，或使用无法很好映射到现有 Core ML 操作的自定义操作的模型。

当前的劣势和限制#

Core AI 目前还不能取代用于生产环境的 Core ML 路径：

• 需要较新的操作系统：公开版框架面向 iOS 27 和 macOS 27 系列，而 Core ML 支持的已安装设备范围要广得多。
• 测试版软件：Apple 的 Core AI 框架及其部分 Python 工具链仍处于早期阶段，正式发布前可能会发生变化。
• 导出环境较受限：coreai-torch 目前要求使用 Python 3.11 到 3.14 以及较新的 PyTorch 版本，支持范围远窄于 Ultralytics 所支持的 Python 和 PyTorch 版本范围。
• 支持的导出平台有限：coreai-core 目前仅发布 macosx_26_0_arm64 和 manylinux_2_34_x86_64 wheel，因此 format=coreai 需要运行 macOS 26 或更高版本的 Apple silicon Mac，或运行 glibc 2.34 或更高版本的 x86_64 Linux（例如 Ubuntu 22.04+）。运行 .aimodel 仍需要 Apple 硬件。
• 在 Ultralytics SDK 中作为可选项，而非默认项：在 iPhone 17 Pro 上，设备端对比显示，Core AI 的完整流水线表现与 Core ML 持平，而非更胜一筹；语义分割、深度任务和仅使用 CPU 的推理速度更慢，FP16 资源的下载大小约为两倍，因此 iOS SDK 和 Flutter 插件仍默认使用 Core ML。
• SDK 使用 raw head：使用 nms=False 时，YOLO26n 在 Core AI 上的耗时约为 Core ML 的两倍（一次对比测试中分别为 3.06 毫秒和 1.53 毫秒），而在 iOS 27.0 上，FP16 端到端姿态模型在 Core AI 的默认资源放置方式下不会返回任何检测结果（apple/coreai-torch#115）。默认的 raw head（nms=None）可避免这两个问题，SDK 会在 Swift 中运行 NMS。请参阅选择 head。
• 没有 iOS Simulator 运行时：iOS Simulator SDK 不包含 Core AI。
• 需要迁移应用：.aimodel 不能替代 .mlpackage；模型加载、预处理、推理调用、元数据处理和输出解码都需要在 Ultralytics SDK 之外实现 Core AI 版本，而 Ultralytics SDK 提供了该实现。
• 生产环境证据有限：性能、功耗、首次运行时的专门化耗时、精度和压缩效果，都需要针对支持的 YOLO 任务和设备矩阵进行验证。
• 没有 NMS 流水线：Core ML 可以为较旧的 YOLO 检测模型打包 NMS 阶段。Core AI 默认导出原始的一对多预测；对于 YOLO26 无 NMS 的 head，请使用 nms=False。目前不支持嵌入式 NMS（nms=True）和 dynamic=True。coreai-torch 尚未实现针对 torchvision::nms 的降级转换，因此 NMS 会留在主机端运行。
• 输入尺寸固定：导出的计算图是在一个 imgsz 下跟踪生成的，不支持动态形状，因此预测时必须使用导出时采用的尺寸。
• FP16 资源可能在加载时导致进程中止：某些 FP16 .aimodel 资源无法加载 Apple Neural Engine 程序，导致 MPSGraph 触发断言失败，进程随之结束，而不会回退到其他选项。这发生在 Apple 运行时内部，早于任何 Ultralytics 代码运行；同一资源使用仅 CPU 的专门化方式可以成功加载。如果资源出现此问题，请回退到 FP32；在 iPhone 17 Pro 上检查过的 FP16 SDK 资源（所有 nano 模型、各尺寸的检测模型，以及每个任务中最大的模型）均可成功加载，不会导致进程中止。

应该使用哪种 Apple 格式？#

在以下情况下，现在就使用 Core ML：

• 需要部署到当前和较旧版本的 Apple 操作系统
• 需要使用 Ultralytics iOS 或 Flutter SDK 的默认路径
• 需要通过 Vision 框架处理图像
• 需要经过测试的 FP16 和 INT8 YOLO 部署方案
• 需要为兼容的旧版检测模型嵌入 NMS

如果可以要求使用 iOS 27 或 macOS 27，且需要以下功能，请评估 Core AI：

• 最新的 Apple 设备端神经网络运行时
• 明确控制专门化和缓存管理
• 先进的动态或有状态模型执行
• 自定义 Core AI 操作或 Metal 内核
• 详细调试 Core AI 计算图并分析运行时

在应用迁移期间，Core ML 和 Core AI 预计会共存。由于两者的部署目标和应用契约不同，支持 Core AI 并不意味着可以立即弃用 Core ML。

Ultralytics 路线图#

专用的 coreai 导出目标已实现：导出和数值验证覆盖了受支持的 YOLO26 任务模型，并在 macOS 26 上的 Ultralytics CI 中持续运行；FP16 延迟则在设备上测量。Core AI 达到与 Core ML 路径相同的支持水平之前，剩余的路线图工作包括：

1. 缩小 Apple Neural Engine 上端到端 head 的延迟差距（apple/coreai-torch#66），并解决 Neural Engine 的正确性问题（apple/coreai-torch#115、#116。
2. INT8 和调色板化 Core AI 资源；SDK 资源为 FP16，下载大小约为 INT8 Core ML 资源的两倍。
3. 发布稳定版 Apple 框架和转换工具（iOS 27 和 macOS 27 系列目前仍处于测试阶段）。
4. 针对支持的设备矩阵，对内存、功耗和专门化进行基准测试。

Ultralytics iOS SDK 和 Flutter 插件在 iOS 27 及更高版本中将 Core AI 作为可选项加载；Core ML 仍是它们的默认方案，也是覆盖 iOS 27 以下系统的推荐目标。请关注Ultralytics 路线图和发行说明，了解其余事项。

更多资源#

• Apple Core AI 概览
• Core AI 框架文档
• Core AI PyTorch 扩展
• Core AI Optimization
• Apple Core AI 模型仓库
• Ultralytics Core ML 集成

常见问题#