苹果开发者文档上线了 Core AI Beta，这是一个用于在 Apple silicon 设备上运行 AI 模型的新框架。文档显示，它支持 iOS 27.0+、iPadOS 27.0+、Mac Catalyst 27.0+、macOS 27.0+、tvOS 27.0+、visionOS 27.0+ 和 watchOS 27.0+，目前均标注为 Beta。

这不是一次面向普通用户的 Apple Intelligence 新功能发布，也不是 Core ML 被改名。更稳妥的理解是：苹果正在把神经网络模型的端侧推理链路单独拎出来，给开发者更多控制权，尤其是模型专门化、缓存、异步计算和性能分析。

Core AI 把重点放在端侧神经网络推理

Core AI 的官方描述是“Run AI models in your app on Apple silicon”。它面向 Apple silicon 设计，可在 CPU、GPU 和 Neural Engine 之间使用计算资源。对开发者来说，关键不只是“能跑模型”，而是能更细地管理模型在设备上的表现。

文档列出的核心 API 包括 AIModel、AIModelAsset、InferenceFunction、InferenceValue、ComputeStream 和 NDArray。这里能看出它的取向：围绕模型资产、推理函数、多维张量和异步计算组织，而不是围绕传统机器学习任务做一层通用封装。

项目Core AI 当前信息对开发者的影响
状态Beta不适合贸然押注生产环境主链路
设备基础Apple silicon老设备与非苹果芯片不在叙事中心
计算单元CPU、GPU、Neural Engine需要重新做性能测试和调度策略
核心能力模型专门化、缓存、推理性能控制部署成本下降，但调优责任更重
数据结构NDArray、多维数组描述更贴近深度学习推理工作流

Core AI 还提供 ComputeStream，用于异步运行计算任务。这对实时交互类 AI 功能更重要，例如图像处理、语音相关能力或设备端小模型推理。用户未必会感知到框架名称，但开发者会在延迟、功耗和模型加载时间上和它打交道。

它补的是工具链，不是一个孤立 API

Core AI 的分量不只在 Swift API。苹果同时把模型准备、转换、调试和性能分析工具放进了同一条链路：Core AI Optimization 用于面向 Apple silicon 优化模型，Core AI PyTorch Extensions 可将模型转换为 .aimodel 格式，Core AI Debugger 支持可视化和数值调试，还能把张量值追溯到 Python 源码。

进入 Xcode 后，Core AI debug gauge 和 Core AI instrument 可用于监控、剖析推理性能；coreai-build 命令行工具则支持提前编译模型。这些工具说明苹果关心的不只是“模型能不能进 App”，而是模型进 App 后是否可调、可测、可部署。

横向看，Google 在 Android 侧有 LiteRT、NNAPI 等端侧推理路线，NVIDIA 和高通也在围绕本地推理做开发工具。苹果的特殊之处在于硬件、系统、开发工具和 App 分发都在自己生态内。好处是协同空间大，代价是开发者更容易被系统版本和硬件边界锁住。

Core ML 仍在，边界比名字更重要

最容易误读的一点，是把 Core AI 看成 Core ML 的替代品。苹果文档给出的边界很直接：如果应用使用的模型类型不是神经网络，例如决策树或表格特征工程，仍应参考 Core ML。

这句话很关键。Core ML 过去承担的是更广义的机器学习模型部署入口，覆盖范围不只神经网络。Core AI 则更像是为现代深度学习推理准备的新通道，尤其贴近 PyTorch 模型转换、张量调试和 Neural Engine 调度。

受影响最大的是苹果平台 AI/ML 开发者。团队如果正在把视觉、语音、生成式或其他神经网络能力放到端侧，需要评估 .aimodel 格式、工具链迁移、Xcode 调试流程和 27.0+ 系统门槛。企业客户和独立开发者也要现实一点：Beta 意味着接口、工具和最佳实践都可能变化，现在更适合验证，不适合把路线写死。

接下来最该看的不是苹果会不会给它取一个更响的营销名，而是三个变量：Core AI 何时转正，Core ML 与 Core AI 的分工是否进一步清晰，以及开发者能否在真实 App 中跑出稳定的功耗和延迟表现。端侧 AI 讲到最后，拼的不是口号，是每一次推理能不能在用户手里安静完成。