【免费下载链接】laya-coremlLocal Laya typed decisions on Apple Core ML and Neural Engine. Validated ports, ~5 ms short decisions on M3 Max, reproducible speed and energy benchmarks.项目地址https://gitcode.com/gh_mirrors/la/laya-coreml点击查看免费下载本文是 Laya-CoreML 项目在 Apple M3 Max 上针对 Neural EngineANEFP16 与 W8 K-means 压缩候选的完整基准报告解读。它回答了三个关键问题将 Laya 多语言决策模型重写到 Core ML 神经引擎后短决策到底快了多少、省了多少能量以及这些数字如何被可信地测量与验证。读完本文你将掌握该项目的测量边界PSTR 功率采样、配对交替实验设计、空闲扣除与 bootstrap 区间、保真度质量门59/59 拟合问题、0.02 概率漂移门限以及从仓库内命令一键复现的完整流程。最终结论先行FP16 ANE 重写将完整预测速度提升 1.39×、每决策整机系统能量估算改善 2.78×对比编译后的 MLX FP16 基线另经单独验证的 W8 K-means 候选分别达到 1.42× 与 3.19×。两者均未达到最初要求的 10× 目标本文的数据全部是 M3 Max 本地结果并附带精度与功率测量边界的详细说明。该测量与转换实验的工程细节见 docs/ANE_ENGINEERING.md数学界与保真度契约见 docs/ANE_MATH.md。一、最终持续短决策对比三臂同会话实验官方发布的三臂对比在单次会话内完成机器条件为M3 Max、40 GPU 核心、128 GiB 统一内存、macOS 27.2。三个模型共享同一个多语言源 checkpoint、相同的 8 个发票状态变体、每个请求一个四选项问题、91 个真实 token 补齐到 96。不使用输出缓存也不生成 token。三个模型全部常驻内存加载、编译与预热均排除在测量区间之外。基线启用mx.compile、prompt-prefix 缓存与 32-token 形状分桶比历史 eager MLX 基线更快。FP16 ANE 候选保留原始权重采用完整的 Core ML transformer 主体、宿主host端 embedding 查找与 FP32 CPU 动作action尾部。W8 使用分组 K-means 的weight-only 调色板压缩而非 W8A8 算术——其激活仍为 FP16宿主动作尾部仍为 FP32。指标MLX GPU FP16编译ANE FP16ANE W8 K-means完成决策数17,18423,96124,453实测活动时长120.02 s120.02 s120.02 s端到端 P506.937 ms4.976 ms4.879 ms端到端 P957.393 ms5.307 ms5.227 ms每决策平均耗时6.984 ms5.009 ms4.908 ms整机平均功率估算61.39 W30.75 W27.39 W每决策整机能量0.4288 J0.1540 J0.1344 J空闲扣除后每决策能量0.3393 J0.0888 J0.0715 J相对编译 MLX 的速度增益1×1.394×1.423×相对编译 MLX 的整机能量增益1×2.784×3.189×相对编译 MLX 的空闲扣除能量增益1×3.823×4.749×所有比值均使用区间均值包含全部已完成工作。官方给出的推导式是FP16: speed 1.394 × average system-power ratio 1.997 energy gain 2.784 W8: speed 1.423 × average system-power ratio 2.241 energy gain 3.189这里有一个容易踩坑的点能量比值再乘一次速度会重复计算耗时。能量增益 速度增益 × 平均功率比绝不能再把能量乘速度。空闲扣除行的测量边界不同它不意味着整机功耗真的下降 3.8–4.7×。这些都是饱和吞吐区间若要声称固定 FPS 下的功耗优势需要另行做等请求率equal-request-rate实验。W8 在此次会话中相对 FP16 的平均速度仅提升约2.1%但主体包从 251.91 十进制 MB 缩小到 129.29 十进制 MB。注意包体积不含原始 checkpoint/宿主 embedding 表也不代表总运行时内存。在 experiments/ane_engineering/validation96.json 与 experiments/ane_engineering/validation96-w8km.json 中可以对照各变体的包体积、概率漂移与筛选延迟。二、实验设计平衡周期、空闲采样与样本纪律每个实现运行 6 个 20 秒块排列成 3 个平衡周期MLX, ANE FP16, ANE W8, ANE W8, ANE FP16, MLX。块之间插入 10 秒空闲采样其中前 3 秒被丢弃让前一个加速器活动与慢速 SMC 更新先稳定然后对相邻的稳定空闲功率取平均。各后端块的功率范围MLX 为 60.32–62.38 WFP16 ANE 为 29.28–35.14 WW8 ANE 为 26.68–27.95 W。桌面其他应用保持打开交替顺序与相邻空闲采样能降低但无法消除后台负载与传感器不确定性。以上块顺序与块数校验由 benchmarks/energy_summary.py 中的audit_structure强制完成任何不完整的平衡周期或乱序块都会让审计直接报错而不是悄悄修正。全部65,598 次预测都与其后端对应状态的舍入预热输出一致三个后端在这 8 个状态上选出相同答案。在 benchmarks/energy.py 中这种一致性在测量开始前就先被强制answer_agreement检查三个后端在 32 次预热调用上的选择答案是否一致任何差异都会raise ValueError(Selected answers differ on the energy workload)测量过程中expected参数还会逐次比对舍入结果出现不稳定立即累计并最终拒绝报告unstable_rounded_results。更广的保真度套件FP16 L96 通过 59/59 拟合问题最大概率漂移 0.002925W8 在同一条 0.02 门限下通过同样 59 题漂移 0.014393。完整的 63/63 结果属于另行导出的 FP16 L1024 模型。官方明确指出这些是回归夹具regression fixtures不是对任意输入下通用任务准确率或校准保持的声明。本次运行保留了1,101个功率样本最大采样间隔0.510 秒记录到的最大系统功率74.47 W没有任何样本被丢弃。每个块都记录共享进程所有模型与录制缓冲常驻的 RSS但这些值无法归属到单个后端的模型内存。当前运行时与包指纹随报告一起存储。原始调用与 PSTR 样本见 benchmarks/results/ane-energy-finalists.json审计摘要与会话内 bootstrap 区间见 benchmarks/results/ane-energy-summary.json。更早的 FP16 单臂试点 测得 1.410× 速度与 2.939× 整机系统能量增益但它早于最后的输入检查与逐调用稳定性插桩上面的新三臂运行才是最终运行时对外发布的比较。最终原始报告中一处元数据说明起初无条件下描述了历史 macmon 组件求和下限一条附加的metadata_corrections条目澄清该次运行仅使用 PSTR原字段与全部测量值均被保留。三、测量边界与遥测局限为什么必须自建 PSTR-only 采样器3.1 计时边界完整预测而非孤立内核每一次计时的调用都包含提示构建、tokenization、数组构建、宿主 embedding 查找如适用、同步模型执行、动作特征、校准与输出格式化。MLX 会求值其惰性输出Core ML 返回完整的 NumPy 数组。因此这里比较的是未缓存的完整预测不是孤立的模型内核。官方措辞明确“This compares uncached predictions, not isolated model kernels.”3.2 macmon 的组件求和缺陷与整个能量运行被拒绝最终对比使用小型、无特权的 PSTR-only 采样器仓库路径 benchmarks/pstr_sampler/README.md。它固定使用 macmon 0.8.2 的低层 SMC API打开一条只读连接每 500 ms 采样原始PSTR值不读取 IOReport 组件计数器。这是一个整机传感器估算不是外部墙上功耗或电池测量。可执行文件哈希与源码来源随原始结果一起记录。为什么必须自建采样器官方 macmon CLI 计算sys_power max(PSTR, component_sum)见其 0.8.2 源码。本次 OS 上 CPU 与 ANE 计数器通常返回零然后某一次采样突然跳到约 38,021 W CPU 与 2,068 W ANE组件下限把该故障传播成 40,089 W 的系统读数。IOReport 异常的精确原因未解原始 PSTR 值也无法从该样本恢复。整个受影响的能量运行被拒绝既不删除也不裁剪坏样本其 原始记录 仍保留但其存储的能量聚合值不得作为结果使用。在 benchmarks/pstr_sampler/src/main.rs 中validate_watts的实现印证了这一纪律非有限或非正值直接退出失败有限正值原样保留、绝不裁剪或替换。单元测试还专门验证了 40,089.36 W 这种「不合理」值在采样器层面会被原样通过因为「物理合理」与否属于能量 harness 的独立判断——即 benchmarks/energy.py 中integrate的 500 W 上限。更早的 FP16-only 运行使用官方 macmon v0.8.2 发布版其归档 SHA256 已验证为588d5bde79885ba36f693e5150911c10c3ad208a2e418a3f2aa827ac84a2d973它通过了后续健全性检查作为历史证据保留。最终 PSTR-only 运行用同一个采样器重新测量每个后端。3.3 积分与健全性门限benchmarks/energy.py 的integrate函数是核心使用单调接收时间戳做梯形积分区间边界插值不外推任何缺失、非正、非有限或高于 500 W 的系统读数都会raise ValueError拒绝整个运行不是删除或裁剪500 W 上限是对该 M3 Max 刻意设置的宽松健全性检查不是校准过的精度界采样间隔超过max(2 秒, 3 × 采样间隔)也拒绝运行max_sample_gap_seconds在 Sampler 中按max(2, 3 * interval_ms / 1000)计算start()会等待首批样本到达covered()保证采样器覆盖整个基准区间。审计摘要benchmarks/energy_summary.py会对原始样本重新积分验证完整平衡周期、逐调用稳定性、调用计数、活动能量、两个相邻空闲区间与由此得到的空闲扣除能量任何「存储值与重算值不一致」都直接拒绝。增量能量保留符号绝不夹紧来制造大比值。直读采样器不输出 CPU/GPU/ANE 功率字段因为它不测量它们历史上缺失或为零的组件计数器不能证明零能量或 ANE 未执行。bootstrap 对完整平衡周期重采样一次桌面会话的 3 个周期不能代表所有后台负载、未来运行或传感器精度。所有测得的比值都远未达到 10×。四、如何正确阅读「能量增益」比值恒等式与空闲扣除这里值得展开说明一个测量语义避免误读官方数字总能量grosssystem_joules_per_decision 活动区间积分能量 / 完成决策数。它包含整台机器的基础功耗所以 ANE 每决策 0.1540 J 意味着「整个 M3 Max 在这段时间里平均只花了这么多能量跑一次决策」。空闲扣除idle-subtracted每个块前后各取 10 秒空闲丢弃前 3 秒把前后稳定空闲功率取平均再用该平均功率乘以块时长从总能量中减去incremental_system_joules 块积分能量 − idle_watts × 块时长。这在 benchmarks/energy.py 的main()中逐块计算并写入block[incremental_system_joules]。比值恒等式speed gain × average system-power ratio energy gain。从源码看benchmarks/energy.py 的comparison()正是这样计算 ratios 的speed mlx_mean_ms / candidate_mean_mssystem_power mlx_mean_watts / candidate_mean_watts然后system_energy_per_decision mlx_joules_per_decision / candidate_joules_per_decision。官方在 measurement 字段中记录了ratio_identity: speed * average power reduction energy per decision improvement (do not multiply speed again)。不确定性区间当周期数 ≥ 3 时benchmarks/energy_summary.py 用固定种子np.random.default_rng(20260920)对完整平衡周期做 5,000 次簇重采样保持内部顺序输出cycle_bootstrap_95_percent的 2.5% 与 97.5% 分位数。注意 bootstrap 对象是整周期而非单块以保留平衡顺序与后台负载相关性。从审计结果 benchmarks/results/ane-energy-summary.json 可以看到摘要把各后端的latency、block_ranges每块系统平均功率与空闲平均功率的最小/最大范围都结构化输出方便读者独立核验。五、Snake 兼容性是一个独立工作负载同一个已发布的 Snake 规划器、紧凑提示与安全策略分别在 FP16 ANE 适配器与编译 MLX 上运行在完全相同的实时状态上交替评估顺序。种子 101 与 102 各完成 300 步600/600 提议并执行的动作一致零死亡、零护盾干预。最终得分分别为 9 与 10蛇长 15 与 16最大移动概率差 0.0036。这验证的是这条 FP16 轨迹对比不是压缩模型在 Snake 上的行为或无限生存能力。种子ANE 完整决策 P50 / P95编译 MLX 完整决策 P50 / P9510123.45 / 27.10 ms17.14 / 23.58 ms10217.68 / 27.30 ms19.18 / 33.27 msANE 适配器在 B1/L96 上串行跑三个问题MLX 在最多 L64 上批量跑这三个问题。这些计时包含规划器特征与完整预测排除另一后端的做功、游戏步与终端渲染且波动明显。它们不构成一致的 Snake 加速或最大稳定渲染速率。单问题 4.98 ms 的结果绝不能宣传为完整 Snake 帧时间专用 B3/L64 ANE 导出是独立的优化与验证任务。原始 Snake 状态、输出与计时在 benchmarks/results/ane-snake.json。对应的复现命令完整起见先按 ANE 工程文档导出包python -m benchmarks.snake artifacts/ane-repro/body96/model.mlpackage \ /path/to/original/laya-multilingual --ane --mlx-compiled \ --steps 300 --seeds 101 102 --output artifacts/ane-snake.json六、Neural Engine 是否真的在执行工作「compute plan 说会放到 ANE」不等于「硬件确实在跑」。该项目用两层证据回答这个问题。第一层Core ML 计算计划anticipated placement。重写的 B1/L96 图中全部6,390 个非常量操作被安排在MLNeuralEngineComputeDevice上其余 3,809 个未知条目是常量。同一系统上普通 SDPA 导出的图没有任何 NE 偏好操作。在 benchmarks/common.py 的compute_plan中可以看到如何用MLComputePlan统计每个操作符的preferred_compute_device、supported_compute_devices与estimated_cost。需要强调这是预期放置本身不足以作为硬件证据。第二层运行时硬件追踪。候选以CPU_AND_NE运行期间单独的一次 15.97 秒 InstrumentsCore ML追踪捕获了3,124 个活动的 “Neural Engine Prediction” 区间以及一次无关的缓存系统模型加载。因此导出的硬件表在计算计划之外提供了正向的运行时 ANE 活动证据。该表是全局的不给每次预测附加 PID 或模型身份本次录制中 Core ML model-signpost 表为空。项目不把每个硬件区间都归因于 Laya也不声称宿主工作运行在 ANE 上。允许列表硬件事件 只包含时间戳、时长、设备、标签与状态完整 Instruments 归档与进程环境元数据留在被忽略的artifacts/目录。追踪与能量测试是分开的插桩后的硬件区间不用作端到端延迟结果。追踪摘要在 benchmarks/trace_summary.py运行时代码见 laya_coreml/ane.py——ANEAgent.model_inputs构建embeddings/full_mask/local_mask/type_vectors/marker_map五个固定形状输入forward把-1e4掩码应用于 logits、以未校准原始-logit softmax 派生动作特征并在宿主端用精确 erf GELU 完成 FP32 动作头。七、保真度质量门从 Fixture 到逐调用稳定性阅读任何性能数字之前先确认「换了实现的模型还是不是同一个模型」。该项目把保真度做成硬门限而不是事后描述选择一致验证器要求所有被评估问题的 argmax 决策与存储的 FP32 golden 完全一致experiments/ane_engineering/validate.py 的 gate 定义argmax: all evaluated questions agree概率门限校准与动作概率误差均 ≤ 0.02--max-probability-error默认 0.02输出必须有限、token 用量不变重复稳定性100 次重复公开调用返回相同舍入结果能量测量中进一步要求整场 65,598 次调用保持稳定黄金参照校验golden reference 的source_weights_sha256必须与包清单中model.safetensors的哈希一致防止用不同权重自证布局回归tests/test_ane_layout.py 在纯 CPU 上把微型ConvBody与原始DecisionModel对比覆盖显式/SDPA 注意力预言机、三种题型、不同填充值、非零 norm bias、多种 RoPE base 与非默认 norm epsilon——布局与掩码语义在完全无硬件、无 checkpoint 的条件下独立验证。失败候选写入passed: false并以非零退出码结束被跳过的用例即使固定形状子集通过也保持未验证状态。这就是为什么 W8 uniform组 32 误差 0.023612、组 4 误差 0.033858与 W6 K-means误差 0.052243、W4 K-means误差 0.200221全部被拒——尽管它们的 argmax 决策全部保持 59/59饱和决策掩盖了动作 logit 差异W4 的最大动作 logit 误差达 605.30也正因如此官方强调「该 fixture 的饱和决策单独不足以作为验收测试」。相关详细表格见 docs/ANE_ENGINEERING.md 的「Compression screening」小节。八、复现从导出到能量审计的完整命令链完整复现分四步导出包、构建采样器、跑能量对比、跑审计。前提是先按 docs/ANE_ENGINEERING.md 的命令创建并验证固定的 L96 FP16 与 W8 K-means 包——那些命令写入artifacts/ane-repro/下的全新目录。采样器在本地构建不安装任何系统守护进程或特权服务。pip install -e .[convert,dev,compare,research] cargo build --release --locked --manifest-path benchmarks/pstr_sampler/Cargo.toml python -m benchmarks.energy \ --source /path/to/original/laya-multilingual \ --candidate artifacts/ane-repro/body96-w8km/model.mlpackage \ --fp16-candidate artifacts/ane-repro/body96/model.mlpackage \ --candidate-factory experiments.ane_engineering.runtime:ANEAgent \ --sampler benchmarks/pstr_sampler/target/release/pstr-sampler --pstr-only \ --cycles 3 --seconds 20 --idle-seconds 10 \ --output artifacts/energy.json python -m benchmarks.energy_summary artifacts/energy.json \ --output artifacts/energy-summary.json命令行参数的完整语义可以从 benchmarks/energy.py 的 argparse 定义逐条对应--source原始本地 checkpoint 或固定 Hugging Face 模型laya-multilingual默认解析到仓库固定的 checkpoint--candidate/--fp16-candidateW8 与 FP16 包路径提供第二个参数时块序变成三臂MLX, ANE FP16, ANE W8, ANE W8, ANE FP16, MLX--candidate-factorymodule:function(source, package)工厂仓库内兼容导入为experiments.ane_engineering.runtime:ANEAgentexperiments/ane_engineering/runtime.py 直接转出 laya_coreml/ane.py 的ANEAgent--sampler与--pstr-only直读 PSTR 采样器规避 macmon 的组件求和下限--seconds默认 30最小 10、--idle-seconds默认 10最小 6、--cycles默认 31 个周期 每后端 2 个块、--sample-ms默认 500、--max-system-watts默认 500、--rate0 饱和吞吐否则为每秒决策数、--mlx-eager禁用编译、--output。任何违反seconds10, idle6, cycles1, rate0的参数都会被parser.error拒绝。报告会在每个块结束后增量保存包含environment芯片、内存、OS、Python、各包版本、源码哈希见 benchmarks/common.py 的environment()、settings、measurement语义声明、macmon_version、采样器可执行文件 SHA256、候选 manifest、候选源码 SHA256、基线选项、工作负载、预热记录、答案一致性、block_order与全部块。审计侧 benchmarks/energy_summary.py 的summarize()会重新计算每个块的系统能量与空闲扣除能量校验失败即抛错。若需独立运行时诊断先启动benchmarks.trace_ane等待其就绪 PID 文件再在没有其他模型负载运行时挂接 Instrumentspython -m benchmarks.trace_ane \ --source /path/to/original/laya-multilingual \ --package artifacts/ane-repro/body96/model.mlpackage \ --seconds 90 --ready artifacts/trace.pid # 在另一个终端使用写入该文件的 PID。 xcrun xctrace record --template Core ML --attach PID \ --time-limit 15s --output artifacts/ane.trace xcrun xctrace export --input artifacts/ane.trace --toc \ --output artifacts/toc.xml xcrun xctrace export --input artifacts/ane.trace \ --xpath /trace-toc/run[number1]/data/table[schemaane-hw-intervals] \ --output artifacts/hardware.xml python -m benchmarks.trace_summary --hardware-xml artifacts/hardware.xml \ --toc-xml artifacts/toc.xml --output artifacts/hardware-summary.json采样器自身的构建与只读冒烟检查benchmarks/pstr_sampler/README.mdcargo build --release --locked --manifest-path benchmarks/pstr_sampler/Cargo.toml benchmarks/pstr_sampler/target/release/pstr-sampler --version benchmarks/pstr_sampler/target/release/pstr-sampler pipe -i 500 -s 3 cargo test --locked --manifest-path benchmarks/pstr_sampler/Cargo.toml cargo fmt --check --manifest-path benchmarks/pstr_sampler/Cargo.tomlpstr-sampler pipe每行输出一个 JSONsys_power瓦、power_source: SMC:PSTR、source_library: macmon0.8.2、sampler: laya-pstr-sampler0.1.0、sample_elapsed_seconds-s 0表示无限采样。Cargo 依赖将 macmon 固定为0.8.2且默认特性关闭见 benchmarks/pstr_sampler/Cargo.toml。九、适用前提与已知限制原始 checkpoint 与较短导出有独立的上下文限制L96 运行时拒绝放不下的输入。短负载速度结果不能外推为 512/1024 token 的表现也不能覆盖全部三个 Laya checkpoint。从 docs/ANE_ENGINEERING.md 的表格看L1024 固定图完整短问题 p50 为 88.433 ms一次真实 1024-token 请求约 91.7 ms——大固定图对短请求也做填充工作若把所有请求路由到 L1024 会丢掉短输入优势精度声明边界Core ML FP16 执行不声称与原始 FP32 逐位一致掩码用有限-1e4偏置而非对任意极端输入替换-infinity能量是估算PSTR 是私有 SMC 估算值不是外部校准的墙上功耗或电池测量整机传感器会包含桌面其他应用与后台负载10× 目标未达成官方在 docs/ANE_MATH.md 中做了独立的数学审查本文所有速度/能量比值均为同会话配对数据任何比值都不接近 10×压缩 ≠ 加速包体积减半不直接等于推理更快或更省电每个压缩变体都需要同等的精度门、新的计算计划与配对端到端速度/能量对比。综上这份基准的核心价值在于方法论严谨平衡周期消除顺序偏置、PSTR-only 采样器剔除遥测污染路径、审计器对原始样本重算能量、fixture 门限约束精度再加上配对会话与明确的测量边界使得「1.39× / 2.78×FP16」与「1.42× / 3.19×W8 K-means」这两个结论既具体又可复现。对于想在 Apple Silicon 上优化本地推理的开发者它同时提供了三条可直接照搬的经验测量整机能量时警惕组件计数器陷阱、用平衡交替块对抗后台负载漂移、永远把速度与能量增益建立在同会话配对数据之上。赞分享【免费下载链接】laya-coremlLocal Laya typed decisions on Apple Core ML and Neural Engine. Validated ports, ~5 ms short decisions on M3 Max, reproducible speed and energy benchmarks.项目地址https://gitcode.com/gh_mirrors/la/laya-coreml点击查看免费下载相关推荐laya-coreml Snake 发布基准测试指南Core ML ANE 完整游戏循环的吞吐量、节拍稳定性与复现方法laya coreml Snake 发布基准测试指南Core ML ANE 完整游戏循环的吞吐量、节拍稳定性与复现方法 导读本文以 docs/SNAKE_BLaya-CoreML 本地基准测试指南普通 SDPA 导出在 M3 Max 上的延迟、计算单元选择与保真度验证Laya CoreML 本地基准测试指南普通 SDPA 导出在 M3 Max 上的延迟、计算单元选择与保真度验证 本文基于 BENCHMARKS.md httHeadroom 基准测试指南压缩性能、准确率验证与可复现的评测方法Headroom 基准测试指南压缩性能、准确率验证与可复现的评测方法 Headroom 的核心承诺是压缩上下文但不损失准确率。本篇技术文章以仓库中 wik人工智能LLM 网关AI 应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Laya-CoreML 神经引擎（ANE）基准测试全解析：FP16 短决策的速度与能耗测量方法论、保真度验证与复现指南
【免费下载链接】laya-coremlLocal Laya typed decisions on Apple Core ML and Neural Engine. Validated ports, ~5 ms short decisions on M3 Max, reproducible speed and energy benchmarks.项目地址https://gitcode.com/gh_mirrors/la/laya-coreml点击查看免费下载本文是 Laya-CoreML 项目在 Apple M3 Max 上针对 Neural EngineANEFP16 与 W8 K-means 压缩候选的完整基准报告解读。它回答了三个关键问题将 Laya 多语言决策模型重写到 Core ML 神经引擎后短决策到底快了多少、省了多少能量以及这些数字如何被可信地测量与验证。读完本文你将掌握该项目的测量边界PSTR 功率采样、配对交替实验设计、空闲扣除与 bootstrap 区间、保真度质量门59/59 拟合问题、0.02 概率漂移门限以及从仓库内命令一键复现的完整流程。最终结论先行FP16 ANE 重写将完整预测速度提升 1.39×、每决策整机系统能量估算改善 2.78×对比编译后的 MLX FP16 基线另经单独验证的 W8 K-means 候选分别达到 1.42× 与 3.19×。两者均未达到最初要求的 10× 目标本文的数据全部是 M3 Max 本地结果并附带精度与功率测量边界的详细说明。该测量与转换实验的工程细节见 docs/ANE_ENGINEERING.md数学界与保真度契约见 docs/ANE_MATH.md。一、最终持续短决策对比三臂同会话实验官方发布的三臂对比在单次会话内完成机器条件为M3 Max、40 GPU 核心、128 GiB 统一内存、macOS 27.2。三个模型共享同一个多语言源 checkpoint、相同的 8 个发票状态变体、每个请求一个四选项问题、91 个真实 token 补齐到 96。不使用输出缓存也不生成 token。三个模型全部常驻内存加载、编译与预热均排除在测量区间之外。基线启用mx.compile、prompt-prefix 缓存与 32-token 形状分桶比历史 eager MLX 基线更快。FP16 ANE 候选保留原始权重采用完整的 Core ML transformer 主体、宿主host端 embedding 查找与 FP32 CPU 动作action尾部。W8 使用分组 K-means 的weight-only 调色板压缩而非 W8A8 算术——其激活仍为 FP16宿主动作尾部仍为 FP32。指标MLX GPU FP16编译ANE FP16ANE W8 K-means完成决策数17,18423,96124,453实测活动时长120.02 s120.02 s120.02 s端到端 P506.937 ms4.976 ms4.879 ms端到端 P957.393 ms5.307 ms5.227 ms每决策平均耗时6.984 ms5.009 ms4.908 ms整机平均功率估算61.39 W30.75 W27.39 W每决策整机能量0.4288 J0.1540 J0.1344 J空闲扣除后每决策能量0.3393 J0.0888 J0.0715 J相对编译 MLX 的速度增益1×1.394×1.423×相对编译 MLX 的整机能量增益1×2.784×3.189×相对编译 MLX 的空闲扣除能量增益1×3.823×4.749×所有比值均使用区间均值包含全部已完成工作。官方给出的推导式是FP16: speed 1.394 × average system-power ratio 1.997 energy gain 2.784 W8: speed 1.423 × average system-power ratio 2.241 energy gain 3.189这里有一个容易踩坑的点能量比值再乘一次速度会重复计算耗时。能量增益 速度增益 × 平均功率比绝不能再把能量乘速度。空闲扣除行的测量边界不同它不意味着整机功耗真的下降 3.8–4.7×。这些都是饱和吞吐区间若要声称固定 FPS 下的功耗优势需要另行做等请求率equal-request-rate实验。W8 在此次会话中相对 FP16 的平均速度仅提升约2.1%但主体包从 251.91 十进制 MB 缩小到 129.29 十进制 MB。注意包体积不含原始 checkpoint/宿主 embedding 表也不代表总运行时内存。在 experiments/ane_engineering/validation96.json 与 experiments/ane_engineering/validation96-w8km.json 中可以对照各变体的包体积、概率漂移与筛选延迟。二、实验设计平衡周期、空闲采样与样本纪律每个实现运行 6 个 20 秒块排列成 3 个平衡周期MLX, ANE FP16, ANE W8, ANE W8, ANE FP16, MLX。块之间插入 10 秒空闲采样其中前 3 秒被丢弃让前一个加速器活动与慢速 SMC 更新先稳定然后对相邻的稳定空闲功率取平均。各后端块的功率范围MLX 为 60.32–62.38 WFP16 ANE 为 29.28–35.14 WW8 ANE 为 26.68–27.95 W。桌面其他应用保持打开交替顺序与相邻空闲采样能降低但无法消除后台负载与传感器不确定性。以上块顺序与块数校验由 benchmarks/energy_summary.py 中的audit_structure强制完成任何不完整的平衡周期或乱序块都会让审计直接报错而不是悄悄修正。全部65,598 次预测都与其后端对应状态的舍入预热输出一致三个后端在这 8 个状态上选出相同答案。在 benchmarks/energy.py 中这种一致性在测量开始前就先被强制answer_agreement检查三个后端在 32 次预热调用上的选择答案是否一致任何差异都会raise ValueError(Selected answers differ on the energy workload)测量过程中expected参数还会逐次比对舍入结果出现不稳定立即累计并最终拒绝报告unstable_rounded_results。更广的保真度套件FP16 L96 通过 59/59 拟合问题最大概率漂移 0.002925W8 在同一条 0.02 门限下通过同样 59 题漂移 0.014393。完整的 63/63 结果属于另行导出的 FP16 L1024 模型。官方明确指出这些是回归夹具regression fixtures不是对任意输入下通用任务准确率或校准保持的声明。本次运行保留了1,101个功率样本最大采样间隔0.510 秒记录到的最大系统功率74.47 W没有任何样本被丢弃。每个块都记录共享进程所有模型与录制缓冲常驻的 RSS但这些值无法归属到单个后端的模型内存。当前运行时与包指纹随报告一起存储。原始调用与 PSTR 样本见 benchmarks/results/ane-energy-finalists.json审计摘要与会话内 bootstrap 区间见 benchmarks/results/ane-energy-summary.json。更早的 FP16 单臂试点 测得 1.410× 速度与 2.939× 整机系统能量增益但它早于最后的输入检查与逐调用稳定性插桩上面的新三臂运行才是最终运行时对外发布的比较。最终原始报告中一处元数据说明起初无条件下描述了历史 macmon 组件求和下限一条附加的metadata_corrections条目澄清该次运行仅使用 PSTR原字段与全部测量值均被保留。三、测量边界与遥测局限为什么必须自建 PSTR-only 采样器3.1 计时边界完整预测而非孤立内核每一次计时的调用都包含提示构建、tokenization、数组构建、宿主 embedding 查找如适用、同步模型执行、动作特征、校准与输出格式化。MLX 会求值其惰性输出Core ML 返回完整的 NumPy 数组。因此这里比较的是未缓存的完整预测不是孤立的模型内核。官方措辞明确“This compares uncached predictions, not isolated model kernels.”3.2 macmon 的组件求和缺陷与整个能量运行被拒绝最终对比使用小型、无特权的 PSTR-only 采样器仓库路径 benchmarks/pstr_sampler/README.md。它固定使用 macmon 0.8.2 的低层 SMC API打开一条只读连接每 500 ms 采样原始PSTR值不读取 IOReport 组件计数器。这是一个整机传感器估算不是外部墙上功耗或电池测量。可执行文件哈希与源码来源随原始结果一起记录。为什么必须自建采样器官方 macmon CLI 计算sys_power max(PSTR, component_sum)见其 0.8.2 源码。本次 OS 上 CPU 与 ANE 计数器通常返回零然后某一次采样突然跳到约 38,021 W CPU 与 2,068 W ANE组件下限把该故障传播成 40,089 W 的系统读数。IOReport 异常的精确原因未解原始 PSTR 值也无法从该样本恢复。整个受影响的能量运行被拒绝既不删除也不裁剪坏样本其 原始记录 仍保留但其存储的能量聚合值不得作为结果使用。在 benchmarks/pstr_sampler/src/main.rs 中validate_watts的实现印证了这一纪律非有限或非正值直接退出失败有限正值原样保留、绝不裁剪或替换。单元测试还专门验证了 40,089.36 W 这种「不合理」值在采样器层面会被原样通过因为「物理合理」与否属于能量 harness 的独立判断——即 benchmarks/energy.py 中integrate的 500 W 上限。更早的 FP16-only 运行使用官方 macmon v0.8.2 发布版其归档 SHA256 已验证为588d5bde79885ba36f693e5150911c10c3ad208a2e418a3f2aa827ac84a2d973它通过了后续健全性检查作为历史证据保留。最终 PSTR-only 运行用同一个采样器重新测量每个后端。3.3 积分与健全性门限benchmarks/energy.py 的integrate函数是核心使用单调接收时间戳做梯形积分区间边界插值不外推任何缺失、非正、非有限或高于 500 W 的系统读数都会raise ValueError拒绝整个运行不是删除或裁剪500 W 上限是对该 M3 Max 刻意设置的宽松健全性检查不是校准过的精度界采样间隔超过max(2 秒, 3 × 采样间隔)也拒绝运行max_sample_gap_seconds在 Sampler 中按max(2, 3 * interval_ms / 1000)计算start()会等待首批样本到达covered()保证采样器覆盖整个基准区间。审计摘要benchmarks/energy_summary.py会对原始样本重新积分验证完整平衡周期、逐调用稳定性、调用计数、活动能量、两个相邻空闲区间与由此得到的空闲扣除能量任何「存储值与重算值不一致」都直接拒绝。增量能量保留符号绝不夹紧来制造大比值。直读采样器不输出 CPU/GPU/ANE 功率字段因为它不测量它们历史上缺失或为零的组件计数器不能证明零能量或 ANE 未执行。bootstrap 对完整平衡周期重采样一次桌面会话的 3 个周期不能代表所有后台负载、未来运行或传感器精度。所有测得的比值都远未达到 10×。四、如何正确阅读「能量增益」比值恒等式与空闲扣除这里值得展开说明一个测量语义避免误读官方数字总能量grosssystem_joules_per_decision 活动区间积分能量 / 完成决策数。它包含整台机器的基础功耗所以 ANE 每决策 0.1540 J 意味着「整个 M3 Max 在这段时间里平均只花了这么多能量跑一次决策」。空闲扣除idle-subtracted每个块前后各取 10 秒空闲丢弃前 3 秒把前后稳定空闲功率取平均再用该平均功率乘以块时长从总能量中减去incremental_system_joules 块积分能量 − idle_watts × 块时长。这在 benchmarks/energy.py 的main()中逐块计算并写入block[incremental_system_joules]。比值恒等式speed gain × average system-power ratio energy gain。从源码看benchmarks/energy.py 的comparison()正是这样计算 ratios 的speed mlx_mean_ms / candidate_mean_mssystem_power mlx_mean_watts / candidate_mean_watts然后system_energy_per_decision mlx_joules_per_decision / candidate_joules_per_decision。官方在 measurement 字段中记录了ratio_identity: speed * average power reduction energy per decision improvement (do not multiply speed again)。不确定性区间当周期数 ≥ 3 时benchmarks/energy_summary.py 用固定种子np.random.default_rng(20260920)对完整平衡周期做 5,000 次簇重采样保持内部顺序输出cycle_bootstrap_95_percent的 2.5% 与 97.5% 分位数。注意 bootstrap 对象是整周期而非单块以保留平衡顺序与后台负载相关性。从审计结果 benchmarks/results/ane-energy-summary.json 可以看到摘要把各后端的latency、block_ranges每块系统平均功率与空闲平均功率的最小/最大范围都结构化输出方便读者独立核验。五、Snake 兼容性是一个独立工作负载同一个已发布的 Snake 规划器、紧凑提示与安全策略分别在 FP16 ANE 适配器与编译 MLX 上运行在完全相同的实时状态上交替评估顺序。种子 101 与 102 各完成 300 步600/600 提议并执行的动作一致零死亡、零护盾干预。最终得分分别为 9 与 10蛇长 15 与 16最大移动概率差 0.0036。这验证的是这条 FP16 轨迹对比不是压缩模型在 Snake 上的行为或无限生存能力。种子ANE 完整决策 P50 / P95编译 MLX 完整决策 P50 / P9510123.45 / 27.10 ms17.14 / 23.58 ms10217.68 / 27.30 ms19.18 / 33.27 msANE 适配器在 B1/L96 上串行跑三个问题MLX 在最多 L64 上批量跑这三个问题。这些计时包含规划器特征与完整预测排除另一后端的做功、游戏步与终端渲染且波动明显。它们不构成一致的 Snake 加速或最大稳定渲染速率。单问题 4.98 ms 的结果绝不能宣传为完整 Snake 帧时间专用 B3/L64 ANE 导出是独立的优化与验证任务。原始 Snake 状态、输出与计时在 benchmarks/results/ane-snake.json。对应的复现命令完整起见先按 ANE 工程文档导出包python -m benchmarks.snake artifacts/ane-repro/body96/model.mlpackage \ /path/to/original/laya-multilingual --ane --mlx-compiled \ --steps 300 --seeds 101 102 --output artifacts/ane-snake.json六、Neural Engine 是否真的在执行工作「compute plan 说会放到 ANE」不等于「硬件确实在跑」。该项目用两层证据回答这个问题。第一层Core ML 计算计划anticipated placement。重写的 B1/L96 图中全部6,390 个非常量操作被安排在MLNeuralEngineComputeDevice上其余 3,809 个未知条目是常量。同一系统上普通 SDPA 导出的图没有任何 NE 偏好操作。在 benchmarks/common.py 的compute_plan中可以看到如何用MLComputePlan统计每个操作符的preferred_compute_device、supported_compute_devices与estimated_cost。需要强调这是预期放置本身不足以作为硬件证据。第二层运行时硬件追踪。候选以CPU_AND_NE运行期间单独的一次 15.97 秒 InstrumentsCore ML追踪捕获了3,124 个活动的 “Neural Engine Prediction” 区间以及一次无关的缓存系统模型加载。因此导出的硬件表在计算计划之外提供了正向的运行时 ANE 活动证据。该表是全局的不给每次预测附加 PID 或模型身份本次录制中 Core ML model-signpost 表为空。项目不把每个硬件区间都归因于 Laya也不声称宿主工作运行在 ANE 上。允许列表硬件事件 只包含时间戳、时长、设备、标签与状态完整 Instruments 归档与进程环境元数据留在被忽略的artifacts/目录。追踪与能量测试是分开的插桩后的硬件区间不用作端到端延迟结果。追踪摘要在 benchmarks/trace_summary.py运行时代码见 laya_coreml/ane.py——ANEAgent.model_inputs构建embeddings/full_mask/local_mask/type_vectors/marker_map五个固定形状输入forward把-1e4掩码应用于 logits、以未校准原始-logit softmax 派生动作特征并在宿主端用精确 erf GELU 完成 FP32 动作头。七、保真度质量门从 Fixture 到逐调用稳定性阅读任何性能数字之前先确认「换了实现的模型还是不是同一个模型」。该项目把保真度做成硬门限而不是事后描述选择一致验证器要求所有被评估问题的 argmax 决策与存储的 FP32 golden 完全一致experiments/ane_engineering/validate.py 的 gate 定义argmax: all evaluated questions agree概率门限校准与动作概率误差均 ≤ 0.02--max-probability-error默认 0.02输出必须有限、token 用量不变重复稳定性100 次重复公开调用返回相同舍入结果能量测量中进一步要求整场 65,598 次调用保持稳定黄金参照校验golden reference 的source_weights_sha256必须与包清单中model.safetensors的哈希一致防止用不同权重自证布局回归tests/test_ane_layout.py 在纯 CPU 上把微型ConvBody与原始DecisionModel对比覆盖显式/SDPA 注意力预言机、三种题型、不同填充值、非零 norm bias、多种 RoPE base 与非默认 norm epsilon——布局与掩码语义在完全无硬件、无 checkpoint 的条件下独立验证。失败候选写入passed: false并以非零退出码结束被跳过的用例即使固定形状子集通过也保持未验证状态。这就是为什么 W8 uniform组 32 误差 0.023612、组 4 误差 0.033858与 W6 K-means误差 0.052243、W4 K-means误差 0.200221全部被拒——尽管它们的 argmax 决策全部保持 59/59饱和决策掩盖了动作 logit 差异W4 的最大动作 logit 误差达 605.30也正因如此官方强调「该 fixture 的饱和决策单独不足以作为验收测试」。相关详细表格见 docs/ANE_ENGINEERING.md 的「Compression screening」小节。八、复现从导出到能量审计的完整命令链完整复现分四步导出包、构建采样器、跑能量对比、跑审计。前提是先按 docs/ANE_ENGINEERING.md 的命令创建并验证固定的 L96 FP16 与 W8 K-means 包——那些命令写入artifacts/ane-repro/下的全新目录。采样器在本地构建不安装任何系统守护进程或特权服务。pip install -e .[convert,dev,compare,research] cargo build --release --locked --manifest-path benchmarks/pstr_sampler/Cargo.toml python -m benchmarks.energy \ --source /path/to/original/laya-multilingual \ --candidate artifacts/ane-repro/body96-w8km/model.mlpackage \ --fp16-candidate artifacts/ane-repro/body96/model.mlpackage \ --candidate-factory experiments.ane_engineering.runtime:ANEAgent \ --sampler benchmarks/pstr_sampler/target/release/pstr-sampler --pstr-only \ --cycles 3 --seconds 20 --idle-seconds 10 \ --output artifacts/energy.json python -m benchmarks.energy_summary artifacts/energy.json \ --output artifacts/energy-summary.json命令行参数的完整语义可以从 benchmarks/energy.py 的 argparse 定义逐条对应--source原始本地 checkpoint 或固定 Hugging Face 模型laya-multilingual默认解析到仓库固定的 checkpoint--candidate/--fp16-candidateW8 与 FP16 包路径提供第二个参数时块序变成三臂MLX, ANE FP16, ANE W8, ANE W8, ANE FP16, MLX--candidate-factorymodule:function(source, package)工厂仓库内兼容导入为experiments.ane_engineering.runtime:ANEAgentexperiments/ane_engineering/runtime.py 直接转出 laya_coreml/ane.py 的ANEAgent--sampler与--pstr-only直读 PSTR 采样器规避 macmon 的组件求和下限--seconds默认 30最小 10、--idle-seconds默认 10最小 6、--cycles默认 31 个周期 每后端 2 个块、--sample-ms默认 500、--max-system-watts默认 500、--rate0 饱和吞吐否则为每秒决策数、--mlx-eager禁用编译、--output。任何违反seconds10, idle6, cycles1, rate0的参数都会被parser.error拒绝。报告会在每个块结束后增量保存包含environment芯片、内存、OS、Python、各包版本、源码哈希见 benchmarks/common.py 的environment()、settings、measurement语义声明、macmon_version、采样器可执行文件 SHA256、候选 manifest、候选源码 SHA256、基线选项、工作负载、预热记录、答案一致性、block_order与全部块。审计侧 benchmarks/energy_summary.py 的summarize()会重新计算每个块的系统能量与空闲扣除能量校验失败即抛错。若需独立运行时诊断先启动benchmarks.trace_ane等待其就绪 PID 文件再在没有其他模型负载运行时挂接 Instrumentspython -m benchmarks.trace_ane \ --source /path/to/original/laya-multilingual \ --package artifacts/ane-repro/body96/model.mlpackage \ --seconds 90 --ready artifacts/trace.pid # 在另一个终端使用写入该文件的 PID。 xcrun xctrace record --template Core ML --attach PID \ --time-limit 15s --output artifacts/ane.trace xcrun xctrace export --input artifacts/ane.trace --toc \ --output artifacts/toc.xml xcrun xctrace export --input artifacts/ane.trace \ --xpath /trace-toc/run[number1]/data/table[schemaane-hw-intervals] \ --output artifacts/hardware.xml python -m benchmarks.trace_summary --hardware-xml artifacts/hardware.xml \ --toc-xml artifacts/toc.xml --output artifacts/hardware-summary.json采样器自身的构建与只读冒烟检查benchmarks/pstr_sampler/README.mdcargo build --release --locked --manifest-path benchmarks/pstr_sampler/Cargo.toml benchmarks/pstr_sampler/target/release/pstr-sampler --version benchmarks/pstr_sampler/target/release/pstr-sampler pipe -i 500 -s 3 cargo test --locked --manifest-path benchmarks/pstr_sampler/Cargo.toml cargo fmt --check --manifest-path benchmarks/pstr_sampler/Cargo.tomlpstr-sampler pipe每行输出一个 JSONsys_power瓦、power_source: SMC:PSTR、source_library: macmon0.8.2、sampler: laya-pstr-sampler0.1.0、sample_elapsed_seconds-s 0表示无限采样。Cargo 依赖将 macmon 固定为0.8.2且默认特性关闭见 benchmarks/pstr_sampler/Cargo.toml。九、适用前提与已知限制原始 checkpoint 与较短导出有独立的上下文限制L96 运行时拒绝放不下的输入。短负载速度结果不能外推为 512/1024 token 的表现也不能覆盖全部三个 Laya checkpoint。从 docs/ANE_ENGINEERING.md 的表格看L1024 固定图完整短问题 p50 为 88.433 ms一次真实 1024-token 请求约 91.7 ms——大固定图对短请求也做填充工作若把所有请求路由到 L1024 会丢掉短输入优势精度声明边界Core ML FP16 执行不声称与原始 FP32 逐位一致掩码用有限-1e4偏置而非对任意极端输入替换-infinity能量是估算PSTR 是私有 SMC 估算值不是外部校准的墙上功耗或电池测量整机传感器会包含桌面其他应用与后台负载10× 目标未达成官方在 docs/ANE_MATH.md 中做了独立的数学审查本文所有速度/能量比值均为同会话配对数据任何比值都不接近 10×压缩 ≠ 加速包体积减半不直接等于推理更快或更省电每个压缩变体都需要同等的精度门、新的计算计划与配对端到端速度/能量对比。综上这份基准的核心价值在于方法论严谨平衡周期消除顺序偏置、PSTR-only 采样器剔除遥测污染路径、审计器对原始样本重算能量、fixture 门限约束精度再加上配对会话与明确的测量边界使得「1.39× / 2.78×FP16」与「1.42× / 3.19×W8 K-means」这两个结论既具体又可复现。对于想在 Apple Silicon 上优化本地推理的开发者它同时提供了三条可直接照搬的经验测量整机能量时警惕组件计数器陷阱、用平衡交替块对抗后台负载漂移、永远把速度与能量增益建立在同会话配对数据之上。赞分享【免费下载链接】laya-coremlLocal Laya typed decisions on Apple Core ML and Neural Engine. Validated ports, ~5 ms short decisions on M3 Max, reproducible speed and energy benchmarks.项目地址https://gitcode.com/gh_mirrors/la/laya-coreml点击查看免费下载相关推荐laya-coreml Snake 发布基准测试指南Core ML ANE 完整游戏循环的吞吐量、节拍稳定性与复现方法laya coreml Snake 发布基准测试指南Core ML ANE 完整游戏循环的吞吐量、节拍稳定性与复现方法 导读本文以 docs/SNAKE_BLaya-CoreML 本地基准测试指南普通 SDPA 导出在 M3 Max 上的延迟、计算单元选择与保真度验证Laya CoreML 本地基准测试指南普通 SDPA 导出在 M3 Max 上的延迟、计算单元选择与保真度验证 本文基于 BENCHMARKS.md httHeadroom 基准测试指南压缩性能、准确率验证与可复现的评测方法Headroom 基准测试指南压缩性能、准确率验证与可复现的评测方法 Headroom 的核心承诺是压缩上下文但不损失准确率。本篇技术文章以仓库中 wik人工智能LLM 网关AI 应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考