john-rocky/apple-silicon-llm-bench — 精读笔记

来源：GitHub (★59)

URL: https://github.com/john-rocky/apple-silicon-llm-bench

精读日期：2026-08-18

模型：DeepSeek V4 Flash（AI 生成，人工未审校）

正文获取：全文

一、核心论点/事实

1. 该项目是 Apple Silicon（iPhone/iPad/Mac）上本地 LLM 推理的中立、可复现基准测试，对比 MLX Swift、llama.cpp、CoreML（swift-transformers）、LiteRT-LM、ExecuTorch、ANEMLL、Apple Core AI 及 Apple 自家 Foundation Models。

2. Apple Core AI 是 Core ML 的继任者，于 WWDC 2026（iOS/macOS 27）发布，本项目是首个独立的 on-device LLM 基准测试。

3. 在 iPhone 17 Pro + Qwen3-0.6B 短对话场景下，Core AI GPU "pipelined" 引擎是最快路径：冷启动首代 76.5 tok/s（shader/pipeline 缓存构建），后续冷进程约 194 tok/s；同会话内 Core AI GPU 达 193.3 tok/s，领先 MLX 冷启动 126–133 tok/s。

4. MLX 在同一设备上 6 月中旬测 126–133 tok/s，当前测 159–180 tok/s，差异归因于设备状态变化（疑似 iOS 27 beta 更新），原始数据已公开。

5. 在 Mac M4 Max 上，Core AI 在全部 dense 模型上匹配或超越 MLX；MLX 唯一明显胜出的是 MoE 模型（专家调度优势，非核心引擎）。

6. 噪声控制：7 个模型中 6 个 per-trial σ ≤0.4%（最差 1.3%），dense 模型差异是 trial 噪声的 10–30 倍且方向一致。

7. 0.6B 模型在 macOS 27 beta 升级后出现导出产物回归：官方 recipe 生成的 artifact 慢 2.2×（native quantized-Linear 降级为显式 dequant 操作），内存占用从 0.47 GB 增至 1,519 MB 峰值，约 2 倍差距。

二、方法/架构拆解

基准协议

冷启动（cold）：全新进程首次生成；热启动（warm）：进程内第 2–4 次运行的中位数。
短对话协议：128 token 生成；匹配协议：512-token prompt + 512 生成，greedy，warm。
热启动协议（Gemma 对比）：n≥6 次启动取第 2–3 次中位数，第 1 次丢弃（冷），ctx 强制 2048，每格标注日期和 n。
内存指标取中位数 charged footprint。

关键实现发现

Core AI 的 ANE 路径：通过 stateful INT4 Neural-Engine 转换实现 100% ANE 驻留，bundle 仅 184 MB，比 Core AI ANE 路径精简约 6×。
iOS 无法 JIT 导出 IR：必须预编译；静态 chunk 被检测为 chunked-static 后走 pipelined 引擎。
Core AI 冷/热行为：首次生成 76.5 tok/s（一次性 pipeline 缓存构建成本），后续冷进程约 194 tok/s；MLX 和 LiteRT 冷热持平。
M4 Max 扩展性：Core AI 在 0.6B 小模型上 async-dispatch/overlap 优势明显，但 8B 模型上两者趋近持平（均受内存带宽限制）。
Core AI 官方 recipe 矩阵（M4 Max, macOS 27β）：Core AI 在全部 dense 模型上匹配或超越 MLX；MoE 模型 MLX 胜出。
Core AI 内存优化：unchunked 4096-token prefill 达 1,439 tok/s（+16%），18 GB dirty memory；MoE 提示下 1.7 GB 内存即可达 766 tok/s。
LiteRT-LM harness 修复：r3 版本修复了 task-path prefill 计数器在 capped runs 上被丢弃的 bug，并在设备上验证。

数据与可复现性

所有 bundle 均可下载（除不可复现的 macOS-26 0.6B artifact）。
原始数据目录：results/raw/2026-06-11-m4max-coreai-matrix/、results/raw/2026-07-29-gemma4-e2b-protocol/、results/raw/2026-07-28-gemma4-e2b-protocol-mac/。
跨机器方差是独立复现测试的主要挑战，欢迎外部复现。

三、值得注意的局限/争议

作者承认的局限

1. 0.6B 导出产物不可复现：macOS 27 beta 升级后官方 recipe 生成的 artifact 无法重新组装，Core AI 冷/热行为改用 4B 模型重新验证。

2. CoreML-LLM stateful-chunks bundle 需重新转换才能重新测量。

3. 0.6B 数字依赖导出世代：macOS 27 beta 升级后 native quantized-Linear 降级为显式 dequant 操作，导致 2.2× 性能回退。

4. MLX 112 tok/s 行存在调试污染，作者已修正 "~1.6× once warm" 的表述。

5. 跨机器方差是独立复现的主要障碍，单机结果可能不代表普遍情况。

AI 判断的局限/争议

1. 基准时效性：iOS/macOS 27 仍处 beta 阶段，工具链两代并存，结果可能随正式版发布大幅变化。

2. 模型规模覆盖有限：主要聚焦 0.6B–8B 小模型，未覆盖更大规模（如 30B+）在 Apple Silicon 上的表现。

3. 短对话协议偏向性：128-token 短生成可能有利于某些运行时（如 Core AI 的 pipelined 引擎），长上下文场景结论可能不同。

4. Core AI 的冷启动成本：首次生成 76.5 tok/s 的 pipeline 缓存构建成本在真实使用中可能频繁出现（如 app 重启），基准的 cold/warm 区分可能低估实际体验差异。

5. "Neutral" 主张的挑战：作者自研 Core AI ANE 转换（184 MB stateful INT4）可能引入对特定运行时的优化偏向，中立性需外部验证。

四、与 RRLab 研究的关联

Harness 工程

可复现基准协议设计：cold/warm 区分、n≥6 次启动取中位数、per-cell 日期与 n 标注、内存取 charged footprint——这些协议细节可直接借鉴到 RRLab 的模型评测 harness 中。
Harness bug 修复案例：LiteRT-LM prefill 计数器被丢弃的 bug 及其修复验证流程，提示 RRLab 在评测 harness 中需对每个 runtime 的 instrumentation 路径做独立审计。
设备状态漂移处理：MLX 在同一设备上 126→180 tok/s 的变化（疑似 OS beta 更新），说明评测需记录设备状态快照，RRLab 可建立设备状态追踪机制。

多模型协同

运行时选择依赖优化目标：速度（Core AI GPU pipelined）、内存（Core AI ANE 184 MB）、质量（MoE 用 MLX）——RRLab 的多模型协同框架可根据任务特性动态选择运行时。
MoE 模型的运行时差异：MLX 在 MoE 上胜出（专家调度），提示 RRLab 在 MoE 模型部署时需单独评估运行时选择。

模型评测

噪声控制方法论：per-trial σ ≤0.4% 的统计严谨性、dense 差异与噪声的 10–30× 比值判断——RRLab 评测报告可引入类似信噪比指标。
导出产物回归检测：macOS 27 beta 导致 2.2× 性能回退的案例，说明评测需覆盖工具链版本变化对模型 artifact 的影响。
跨机器方差：单机基准的局限性，RRLab 可建立多设备评测矩阵。

Agent 落地

on-device 推理可行性：iPhone 17 Pro 上 194 tok/s 的 Core AI 表现，说明端侧 Agent 的实时推理已具备条件，RRLab 的 Agent 落地可考虑端侧推理路径。
内存约束下的模型选择：1.7 GB 内存即可达 766 tok/s（MoE 提示），为端侧 Agent 的模型选型提供参考。

AI 原生产品

Core AI 作为 Core ML 继任者：WWDC 2026 发布的新推理栈，RRLab 的 AI 原生产品应关注其 API 演进和性能特性。
冷启动体验优化：Core AI 首次生成 76.5 tok/s 的 pipeline 缓存成本，提示 RRLab 产品需设计预加载/预热机制来规避冷启动惩罚。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/john-rocky/apple-silicon-llm-bench