在 Mac 上本地运行大语言模型已从极客玩具演变为切实可行的工程实践。Apple Silicon 的统一内存架构、Neural Engine（ANE）的高能效矩阵运算能力以及 Metal Performance Shaders（MPS）的 GPU 加速，构成了一个独特的推理栈。与通用的 Ollama 部署不同，聚焦 Core ML 与 Metal 的原生优化能够充分释放 Apple 硬件的 ML 潜力。本文将从框架选型、混合调度策略、量化配置三个维度给出可落地的工程参数。
Core ML 与 MLX 的定位差异
Apple 官方提供了两条部署路径：Core ML 与 MLX。Core ML 是 Apple 的端侧机器学习框架，能够将模型编译为针对 ANE 优化的部署格式；MLX 则是 Apple 于 2024 年推出的类 PyTorch 框架，专为 Apple Silicon 设计但仅支持 CPU 与 GPU 计算，不支持 ANE 加速。两者的性能特征存在显著差异：ANE 在预填充阶段（Prefill）具有明显的时延优势，能够大幅降低首 token 产生时间（Time To First Token，TTFT）；而 GPU 在解码阶段（Decode）的吞吐量更高，每输出 token 耗时（Time Per Output Token，TPOT）更具竞争力。
这一差异催生了「解耦推理」（Disaggregated Inference）的设计思路：将预填充阶段分配给 Core ML+ANE，将解码阶段分配给 MLX+GPU。SqueezeBits 团队的开源项目 Yetter Inference Engine 实现了这一架构，在 Qwen3-0.6B 和 Llama-3.2-1B-Instruct 等模型上取得了优于单一框架的端到端延迟。实测数据显示，在 448 输入 tokens 加 64 输出 tokens 的预填充密集场景下，Core ML+ANE 的 TTFT 仅为 MLX+GPU 的约 40%；而在 64 输入 tokens 加 448 输出 tokens 的解码密集场景下，MLX+GPU 的 TPOT 优于 Core ML+ANE 约 15% 至 20%。
状态管理与有状态模型
在 Core ML 中部署 LLM 需要特别处理 KV 缓存。Apple 在 iOS 18 和 macOS 15 引入了有状态模型（Stateful Models）特性，允许模型在多次推理调用之间保持持久的键值缓存缓冲区，避免每次调用都重新传递完整的上下文状态。这一特性对于 ANE 推理至关重要，因为 ANE 对内存布局和操作数有严格的编译时要求。
然而，直接使用 HuggingFace Transformers 的默认缓存接口会导致 Core ML 模型包含过多状态。以 Qwen3-0.6B 为例，若按层分别传递缓存，模型将包含 56 个状态，导致 ANE 编译失败。解决方案是实现自定义的 Cache 和 CacheLayerMixin 接口，将所有层的键值缓存合并为两个张量：key_cache 和 value_cache，形状为 (num_hidden_layers, num_key_value_heads, max_cache_len, head_dim)（batch_size=1 时）。这样即可将状态数量从 56 降至 2，显著降低 ANE 编译失败的概率。
此外，状态张量的维度大小必须遵守 2 的幂次规则。如果某个维度的尺寸不是 2 的幂次（例如 80），运行时将报错「Unable to compute the prediction」。建议在缓存接口内部将非首维 Padding 至最近的 2 的幂次（如 80→128），仅使用未 Padding 的实际区域进行计算。
量化配置与精度控制
Core ML 支持多种量化策略，推荐采用 INT4 权重量化配合 FP16 激活精度。量化参数的关键配置如下：
- 量化粒度：per-channel（逐通道）量化，权重按输出通道进行分组量化，能够在相同比特数下获得比 per-tensor 量化更高的精度。
- 量化精度：权重量化为 INT4，激活保持 FP16。注意 Core ML 的图优化会将 FP16 数值截断，因此激活无需额外量化。
- 组大小：若使用 MLX 进行 GPU 解码，组大小（group size）建议设为 64，即每 64 个参数共享一个量化缩放因子。
在模型转换阶段，应通过 coremltools 指定 compute_units 为 ALL，以允许 Core ML 运行时在 CPU、GPU 和 ANE 之间自动选择最优计算单元。在实际部署中，通过 Xcode 生成的性能报告可以验证每一操作是否真正分配到了 ANE。报告样例显示，除 token embedding（gather 操作）、LM head（linear 操作）和少量逐元素操作外，几乎所有运算都运行在 ANE 上。
数值稳定性与图优化
将 PyTorch 模型转换至 Core ML 时，存在若干数值稳定性陷阱。最常见的问题源于 RMSNorm 或 LayerNorm 中的 pow(x, 2) 操作。该操作在 ANE 上会产生数值不稳定，导致模型仅输出换行符而无法生成有效文本。解决方案是在 Core ML 转换器中实现自定义的 MIL（Model Intermediate Language）图通道，将 pow(x, 2) 替换为 mul(x, x)。此外，可额外实现一个图通道将 RMSNorm 子图中的 add 操作融合到后续 rsqrt 操作的 epsilon 参数中，进一步减少冗余计算。
对于长序列场景（如 max_seq_len=1024 或 2048），scaled_dot_product_attention（SDPA）操作的内存需求会导致 ANE 编译失败。Core ML Tools 提供了一个未公开的图通道 scaled_dot_product_attention_sliced_q，可将 SDPA 拆分为多个 Q 切片处理，从而降低峰值内存占用。使用方式为在转换时指定 min_seq_length 和 seq_length_divider 参数，例如 min_seq_length=512, seq_length_divider=4。
混合调度的工程实现
实现 Core ML+ANE 预填充与 MLX+GPU 解码的混合调度，需要解决两框架之间的状态传递问题。Core ML 的预填充模型应输出无状态（stateless）的 KV 缓存张量，而非使用有状态模型；MLX 侧则接收这些缓存张量作为初始状态启动解码循环。转换工具（如 Yetter Inference Engine）负责将任意 HuggingFace 模型打包为单一的多功能 Core ML 包，预填充和解码分别对应不同的函数入口，共享同一份权重以控制模型文件体积。
混合调度的推理流程如下：首先将用户输入通过 tokenizer 编码为 token IDs；随后调用 Core ML 的预填充函数，在 ANE 上完成输入序列的向量化并输出 KV 缓存；将缓存传递至 MLX 的解码循环，在 GPU 上逐 token 生成；每个解码步骤结束后，GPU 可选择将更新后的缓存回传至 ANE 供下一次预填充使用（当存在新的用户输入时）。这一架构在预填充密集场景下能够实现约 30% 的端到端延迟削减，同时在解码密集场景下保持与纯 MLX 相当的吞吐量。
监控指标与调优阈值
生产环境中建议监控以下核心指标：TTFT（首 token 延迟）、TPOT（每 token 延迟）、显存占用以及 ANE 利用率。ANE 的峰值利用率应达到 80% 以上，若低于此值需检查是否存在未能 ANE 化的操作（如 gather 和 linear 层）。对于 7B 级模型，INT4 量化后的模型体积约为 3.5GB，配合 512 最大序列长度的 KV 缓存，单次推理的显存占用应控制在 6GB 以内，M1 Pro/M2 Pro/M3 系列的统一内存足以支撑。
若在 Xcode 性能报告中观察到大量 CPU 回退操作（fallback），需检查模型的算子是否被 Core ML 完整支持。常见的不兼容算子包括自定义激活函数、动态形状控制流以及部分高级注意力变体。对于此类情况，可在转换前使用 PyTorch JIT 追踪将模型固化为静态计算图。
小结
Apple Silicon 的本地 LLM 推理并非简单的框架调用，而是需要对 Core ML 的编译约束、ANE 的内存布局要求以及 GPU 的解码特性有深入理解。通过混合调度架构充分发挥 ANE 的预填充优势与 GPU 的解码效率，结合 INT4 量化与有状态模型的状态管理，Mac 完全可以作为隐私敏感场景下的本地推理终端。关键参数可归结为：compute_units 设为 ALL、缓存合并为 2 个状态张量、状态维度 Padding 至 2 的幂次、量化采用 INT4 per-channel、SDPA 启用切片处理。遵循上述工程实践，可在消费级 Mac 上实现每秒 15 至 25 tokens 的推理吞吐量，满足交互式对话与轻量级辅助任务的需求。
资料来源：SqueezeBits 博客《Disaggregated Inference on Apple Silicon: NPU prefill and GPU decode》（2025 年 8 月），Apple 官方 Core ML 文档与 MLX 框架说明。