利用 Core AI 将设备端 AI 模型整合到你的 App 中

一句话判断

✅ 这场 Session 最值得关注的一件事是：Core AI 把第三方开源模型塞进 Apple 芯片的门槛，从“手搓 Core ML 算子和 Tensor 转换”直接降到了“调 Foundation Models API”的级别。

这场 Session 讲了什么

Apple 终于把第三方开源模型（如 Qwen、SAM3）的调用体验，和苹果自家的 Apple Foundation Models (AFM) 拉平了。以前搞端侧大模型，你要自己用 Core ML 转模型、写一堆恶心的前后处理代码、还要处理首次加载的卡顿。现在 Apple 推出了 Core AI 框架，直接提供 coreai-models GitHub 仓库，里面不仅有转好的 .aimodel 文件，连 Swift 前后处理包都给你写好了。

对开发者来说，最爽的变化是语言模型直接复用了 FoundationModels 框架的 LanguageModelSession API。你只需要把 CoreAILanguageModel 传进去，就能用熟悉的 session.respond(to:) 和 @Generable 宏来跑 Qwen 这种第三方模型。这对想做端侧 AI 功能、又不想按 token 给云端大模型交过路费的独立开发者和中型团队来说，绝对是杀手级更新。

值得深挖的点

复用 Foundation Models API 的神来之笔

Apple 让第三方模型复用自家 AFM 的 API，这步棋走得非常聪明。以前我们用 Core ML 跑 NLP 模型，最痛苦的不是模型转换，而是 Tokenizer（分词器）的 Swift 实现和结构化输出的解析。现在 Core AI 直接桥接了 LanguageModelSession，这意味着你跑 Qwen 0.6B 时，可以直接用 @Generable 宏定义一个 VocabCard 结构体，框架会自动帮你搞定 JSON 解析和类型映射。

这种设计的 trade-off 很明显。好处是开发者零学习成本，代码复用率极高，iOS 和 macOS 甚至可以无缝切换底层模型（比如在 Mac 上换成 Qwen3 8B）。坑在于，你的业务逻辑被绑定在了 Apple 的 FoundationModels 抽象层上。如果未来开源社区出了更适合端侧的新一代架构（比如非 Transformer 架构），而 Apple 的 API 还没跟上，你就会很被动。另外，第三方模型的 Tokenizer 和 AFM 原生模型的差异，在极端 edge case 下可能会引发隐藏的截断或乱码问题，这块 Apple 在 Session 里轻描淡写带过了，实战中得自己踩坑。

AOT 编译与首屏延迟的博弈

端侧模型最大的体验杀手是首次运行时的 Model Specialization（模型特化/编译）。Session 里展示了一个很真实的场景：用户拍完照，UI 卡住转圈，因为 Core AI 正在把通用的 .aimodel 编译成当前设备 Neural Engine（神经网络引擎）专用的格式。

Apple 给出的解法是 coreai-build 命令行工具，让你在开发机上提前做 Ahead-of-time (AOT) 编译，生成特定架构的编译产物。这里有个很有意思的部署策略博弈：Apple 强烈建议不要把模型塞进 App Bundle。一个 SAM3 加上 Qwen 动辄大几百 MB，会让所有用户（包括不用 AI 功能的人）承担下载成本。最佳实践是把 AOT 编译后的模型放在 CDN 上，用 Background Assets（后台资源）在用户首次开启功能时按需下载。这要求你的后端必须针对 A17、M2、M3 等不同芯片架构维护多份编译产物，运维复杂度直线上升，但换来的是首屏秒开的极致体验。

代码片段

1. 极简加载并运行 SAM3 图像分割

场景：用文本提示词从图片中抠出特定物体，直接拿到 Mask，不用自己写 Vision 和 Tensor 转换。

import CoreAIImageSegmenter

// 从磁盘加载 SAM3 模型
let segmenter = try await ImageSegmenter(resourcesAt: sam3ModelURL)

// 传入图片和提示词，直接拿到分割结果
let response = try await segmenter.segment(image: inputImage, prompt: "flower")

// 提取最优的分割 Mask
let mask = response.segments.first?.mask

坑：segment 方法是异步的，如果在主线程连续高频调用（比如相机实时预览），没有做节流的话会直接把 Neural Engine 跑满导致掉帧。

2. 用 @Generable 跑第三方 LLM

场景：加载 Qwen 模型，并用熟悉的 Foundation Models API 生成强类型的词汇卡片。

import FoundationModels
import CoreAILanguageModels

// 定义强类型的输出结构
@Generable
struct VocabCard {
    let chineseWord: String
    let englishMeaning: String
    let exampleSentence: String
}

// 加载 Qwen 模型并创建 Session
let model = try await CoreAILanguageModel(resourcesAt: qwen3ModelURL)
let session = LanguageModelSession(model: model)

// 自动生成并解析 JSON，拿到强类型对象
let response = try await session.respond(
    to: "Create a vocab card for flower",
    generating: VocabCard.self
)
let card: VocabCard = response.content

坑：@Generable 依赖模型严格输出合法的 JSON。0.6B 这种小参数模型在复杂 Prompt 下很容易“幻觉”出多余的 Markdown 标记（比如 ```json），导致解析失败，Prompt 里必须加严厉的约束。

3. 本地 AOT 编译模型

场景：在打包前，把通用的 .aimodel 编译成 iOS 设备专用的格式，消除用户首次打开时的编译卡顿。

# 使用 coreai-build 工具针对 iOS 平台进行预编译
xcrun coreai-build compile MyModel.aimodel --platform iOS

坑：编译产物是跟芯片架构（如 ARM64e）强绑定的。如果你只编译了 iOS，拿去 Mac Catalyst 或 macOS 原生跑，依然会触发运行时的 Specialization 延迟。

最佳实践

已有项目如果正在用 Core ML 跑开源 NLP 或视觉模型，建议立刻评估迁移到 Core AI。最大的收益是省掉手写 Tokenizer 和前后处理的几千行代码。新项目采用时，务必坚持“模型不入包”原则。在 App 内设计一个优雅的 First-run experience（首次运行体验），比如用一个漂亮的动画介绍 AI 功能，同时后台触发 Background Assets 下载模型。

实战中最容易踩的坑是内存峰值。Session 里提到 iOS 端用 Qwen 0.6B，macOS 端换 Qwen3 8B。在 iOS 上，如果你同时把 SAM3 和 Qwen 加载到内存，很容易触发系统的 Jetsam（内存警戒）机制导致 App 被杀。一定要做好模型的生命周期管理，用完一个释放一个，或者严格限制并发推理的数量。

还有什么值得关注

Core AI Instruments 模板：Xcode 新增了专门的 Instruments 模板，能精准抓取 Model Specialization 的耗时，帮你定位到底是哪个算子在首次加载时拖慢了速度。
macOS 无缝扩容：同一套 Swift 代码在 Mac 上跑，可以直接把模型 URL 换成 8B 甚至更大的版本，利用 Mac 的统一内存（Unified Memory）做更复杂的长文本推理（比如生成完整的课程计划）。
自带 Swift 前后处理包：coreai-models 仓库里的 CoreAISegmentation 等包，把以前需要懂 Core Image 和 vImage 才能写的张量转换，封装成了纯粹的 Swift API。