【免费下载链接】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点击查看免费下载导读本文以 docs/SNAKE_BENCHMARKS.md 为核心系统讲解 laya-coreml 在 Apple Silicon 上用 Core ML Neural EngineANE实时驱动贪吃蛇游戏时的发布级基准测试。你将掌握“单问题 ~5 ms 微基准”与“完整游戏循环基准”的区别、无上限uncapped与节拍paced两种测量模式的结果与通过标准、如何在本机复现 49.66 decisions/s 与 20 decisions/s 两组关键数据以及如何从源码层面理解测量边界避免在二次引用时误读性能结论。基准测试定位测的是完整游戏循环不是单问题推理docs/SNAKE_BENCHMARKS.md明确说明本次发布的 ANE FP16 演示在三个未限速uncapped的 600 步局中持续跑出了49.1–50.0 次新鲜决策/秒且零死亡三局合并的吞吐量为49.66/s。关键前提是——每一步移动都包含三个顺序执行的模型提问、规划器planner计算和 truecolor 终端序列化。也就是说这是完整激活的游戏循环active game loop而不是仓库中单独报告的“单问题 ~5 ms”微基准。这个区分非常重要单独的 ~5 ms 基准只测量一个短问题在持续负载下的推理延迟详见 docs/ANE_BENCHMARKS.md 与 docs/LAUNCH.md 中的说明而本基准把每一步的完整工作都计入时间三个顺序 typed question 的模型predict每一步都要回答“移动方向”“是否存在安全路线”“食物是否可达”三个问题基于哈密顿环的规划器/安全层计算Rich 组件合成与 truecolor ANSI 序列化游戏状态更新。因此不能把 4.98 ms 的单问题延迟当作“每一帧游戏的时间”这是阅读本基准时首先要建立的认知。环境与方法可复现的测量前提文档给出了完整的环境与方法说明任何复现都应遵循同一套前提项目取值硬件Apple M3 Max40 核 GPU128 GiBmacOS 27.2Python3.12.13安装方式全新环境中安装laya-coreml0.1.0wheel依赖Core ML Tools 9.0、NumPy 2.1.3、Rich 15.0.0未安装 Torch、MLX、Transformers模型公开 ANE FP16 bundlerevision39d6a9b3d0f67f06da74fbade6121ea134cbdb21执行前下载模型规格B1/L96/K32batch 1、长度 96每个决策三个顺序提问compact prompt棋盘24×16初始蛇长 6预热20 个 warmup 决策不计入统计安全层默认开启可见的 cycle safety layerraw top-1 单独测量计时边界严格遵循计入同步predict、游戏特征planner features、Rich 合成、truecolor ANSI 序列化、游戏更新节拍模式还计入真实的sleep调用。排除模型加载、预热、终端模拟器的绘制painting。从源码看这一测量边界在 laya_coreml/snake/benchmark.py 中有明确实现每个 tick 用time.perf_counter()记录tick_start依次执行policy.decide(game)、compose(...)渲染到内存io.StringIO、game.step(decision.executed)最后用active_ms (time.perf_counter() - tick_start) * 1000得到完整的活跃 tick 延迟节拍模式下再通过time.sleep(remaining)补齐剩余时间benchmark.py。通过标准pass criteria每个局episode必须同时满足输出有限finite outputs模型概率非法时直接抛错不执行移动零死亡保持 cycle order 不变、食物进度持续推进受保护模式下这两条不满足会触发AssertionError见 benchmark.py节拍模式下每个节拍局中超过请求时间预算的活跃 tick 占比 ≤ 1%result[passes] game.alive and result[miss_fraction] 0.01见 benchmark.py。无上限模式没有固定 deadline每一步都等待一次新鲜的预测结果后再移动。此外整个基准期间没有其他模型基准并行运行。运行时、检查点、包哈希、提示词哈希以及逐 tick 测量结果都记录在 benchmarks/results/coreml-snake.json对应 JSON 结构中的created_utc、model、settings、method、raw_top1、sweep、uncapped_soak、soak_attempts、fastest_tested_stable_fps等字段。无上限稳定性49.66/s 是有边界证明不是无限生存声明文档给出了三个种子各 600 步的无上限长局结果SeedMovesObserved decisions/sScore / final lengthDeathsSafety interventions10160049.1020 / 260110260049.8924 / 300010360049.9923 / 2901跨这 1,800 个决策三问题 API 延迟16.32 ms P50 / 21.33 ms P95完整活跃 tick 延迟19.07 ms P50 / 25.96 ms P95。文档特别强调这是在显式辅助safety layer下的有边界生存证据不能据此声称模型在没有安全层的情况下可以无限期游玩。这一表述与 laya_coreml/snake/policy.py 的实现一致LayaPolicy.decide先由规划器计算合法/安全移动与食物可达性再把规划器特征交给模型最后在受保护模式下把实际执行方向限制在安全方向集合内executed max(allowed, keyprobabilities.__getitem__) if self.guarded and proposed not in allowed else proposed见 policy.py。无上限模式的本质等待新鲜预测无上限模式对应 demo 的--max-speed不做节拍每一步都等一次完整推理。在 benchmark.py 中表现为fpsNone时跳过time.sleep在 laya_coreml/snake/cli.py 的play中则是if not args.max_speed: remaining 1 / args.fps - ...; time.sleep(remaining)。它不会跳过模型调用——每一步都是真实推理只是不受 1/FPS 的时间预算约束。节拍扫描与确认20 decisions/s 是唯一通过的测试档节拍模式用于回答“以固定的决策频率运行时完整游戏循环能否稳定跟上”。文档给出了 seed 7、每档 120 步的扫描结果失败档位的失败率也被保留Requested decisions/sObserved decisions/sActive deadline missesResult2018.550.83%Pass; confirmed below3028.6710.83%Fail4037.2237.50%Fail5044.2153.33%Fail6050.68100.00%Fail观察值低于请求值例如 20/s 档实际只有 18.55/s是因为节拍测量包含真实的睡眠与调度开销——这不是纯推理时间。20/s 档的完整活跃 tick 统计在 benchmarks/results/coreml-snake.json 的sweep字段中active_tick P50 ≈ 31.6 ms、P95 ≈ 40.9 ms120 步中仅 1 个 tick 超时0.83%。在 20/s 档上追加的三个种子各 600 步的长确认SeedMovesObserved decisions/sActive deadline missesScoreResult10160018.394 / 600, 0.67%20Pass10260018.424 / 600, 0.67%24Pass10360018.423 / 600, 0.50%23Pass节拍导致的延迟差异观察到了但没有定位原因文档记录了节拍模式下三问题 API 的延迟约为26.3 ms P50而无上限时约为16.3 ms P50——存在“随节拍而不同”的差异但没有隔离其成因。可能的解释调度、设备电源状态切换只是推测未被本报告证明。因此文档明确警告持续吞吐结果不能宣传为固定帧 deadline 保证。从源码看这一差异体现在 benchmark.py 的测量口径上inference_ms只统计policy.decide内agent.predict的耗时见 policy.py而active_tick_ms统计整个 tick。节拍模式下推理段在时间轴上的位置不同推理后可能立刻 sleep测量样本的调度上下文也随之变化但报告不对此下结论。原始 top-1 与可分享录制数据汇总在关闭安全覆写unassisted / raw top-1后seeds 101/102/103 各完成 200 步得分 7/6/7零死亡。文档特别指出这些局中模型接收的仍是完全相同的规划器特征因此不能用来检验“从未处理过的原始棋盘上推理”的能力也不能据此建立长局无辅助生存的结论。这与 policy.py 中guarded开关的语义一致--unassistedcli.py只是让执行方向直接取模型 top-1输入特征构造不变。全部基准模式合计4,920 个决策、零死亡、4 次安全干预。另有一个真实终端录制演示855 个决策、75.034 秒、最终得分 26、蛇长 32、零死亡、零干预其原始时间戳、状态与动作由精确的确定性回放测试验证test_published_real_showcase_replays_every_board_and_action_exactly见 tests/test_snake.py。该录制的 GIF、MP4 与溯源信息见 docs/LAUNCH.md。上图为录制演示的预览帧1920×1080。基准与演示运行的是同一套模型、游戏与渲染管线区别仅在于基准的渲染写入内存流不依赖终端模拟器绘制而演示是真实终端输出。复现命令与结果解读文档给出的官方复现命令完整继承可直接复制执行pip install laya-coreml[demo]0.1.0 hf download aac6fef/laya-multilingual-coreml-ane \ --revision 39d6a9b3d0f67f06da74fbade6121ea134cbdb21 \ --local-dir models/ane laya-coreml-snake benchmark --model ./models/ane \ --rates 20,30,40,50,60 --sweep-steps 120 --soak-steps 600 \ --seeds 101,102,103 --raw-steps 200 --output snake-benchmark.json参数语义与默认值可以从 benchmark.py 的命令行解析中确认--rates节拍扫描档位默认10,20,30,40,50,60本报告使用20,30,40,50,60--sweep-steps每档扫描步数默认 120--soak-steps长确认步数默认 600--seeds种子列表默认101,102,103,104--raw-stepsraw top-1 步数默认 200--output报告输出路径默认benchmarks/results/snake.json另有--promptcompact/detailed默认compact、--compute-unitscpu_ne/cpu_gpu/cpu/all、--width/--height默认 24×16、--resume用已保存报告的配置续跑。基准的完整执行顺序源码中可见先测 raw top-1前三个种子、关闭安全层再测 uncappedseed 7然后扫描各节拍档位seed 7再对通过档位做多种子长确认最后把fastest_tested_stable_fps写入报告并作为退出码依据benchmark.py。整个过程每完成一个阶段就原子化保存报告先写.tmp再replace中断后可用--resume续跑。若只想以无约束速率试玩laya-coreml-snake --model ./models/ane --max-speed注意真实终端的实际绘制可能使速率低于序列化基准值。此外本报告只测量 ANE FP16 bundle独立的 Snake GPU bundleB3/L64/K4会把三个问题**批量batch**在一起性能特性不同。历史配对模型对比见 docs/ANE_BENCHMARKS.md 与 BENCHMARKS.md。源码视角基准如何保证测量可信确定性棋盘采用确定性哈密顿环hamiltonian_cycle要求宽高 ≥4 且至少一维为偶数见 laya_coreml/snake/game.py种子固定食物生成random.Random(seed)录制回放测试验证真实演示逐板逐动作精确一致tests/test_snake.py。不变量检查受保护模式下若 cycle order 被破坏或食物停滞超过棋盘容量基准直接抛AssertionError而不是默默通过benchmark.py。非法概率防线模型输出任何非有限值或越界概率时policy.decide抛ValueError且不执行移动policy.py——这正是“finite outputs”通过标准的实现。离线保证local_checkpoint设置HF_HUB_OFFLINE1本地模型目录优先未缓存的 Hub ID 会给出下载指引而不是在演示中偷偷联网policy.py。可审计性报告记录模型 revision、权重 SHA256、包 SHA256、源码 SHA256、提示词与全部设置policy.py--resume时会校验这些元数据一致才允许续跑benchmark.py。结论如何正确引用这组数字“49.66/s三局合并”是无上限、含三顺序提问 规划器 内存渲染序列化的完整游戏循环吞吐是带安全层的 600 步局生存证据“20 decisions/s”是这台机器、这些种子上通过节拍测试的最高档观察值 18.39–18.42/s是“最高通过测试档”不是普适上限也不等于完美的 20 FPS 显示单问题 ~5 ms 微基准与游戏帧时间不是一回事详见 docs/ANE_BENCHMARKS.md 与 docs/SNAKE_DEMO.md节拍与无上限之间约 16.3→26.3 ms 的 API 延迟差异已被观察到但未被归因引用时应保留这一限定所有原始数据均可从 benchmarks/results/coreml-snake.json 的raw_top1、sweep、uncapped_soak、soak_attempts、fastest_tested_stable_fps字段逐 tick 复核。赞分享【免费下载链接】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点击查看免费下载相关推荐M3 Max 上的 Laya MLX Snake 基准测试全解析持续吞吐、节拍稳定性与可复现测量M3 Max 上的 Laya MLX Snake 基准测试全解析持续吞吐、节拍稳定性与可复现测量 本文深入解析 laya mlx 仓库中 docs/SNAKE人工智能大模型本地部署推理引擎戴森球计划工厂蓝图终极指南从新手到工业巨头的星际工厂建造秘籍戴森球计划工厂蓝图终极指南从新手到工业巨头的星际工厂建造秘籍 你是否曾为戴森球计划中复杂的工厂布局而头疼是否在寻找能够快速提升生产效率的实用方案戴森球计划游戏开发Baron未来路线图自定义滚动条技术的发展趋势分析Baron未来路线图自定义滚动条技术的发展趋势分析 在当今Web开发领域自定义滚动条技术已经成为提升用户体验的重要一环。Baron作为一款轻量级、高性能的自UI库/组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
用 DBMS_XPLAN 快速收集与解读 SQL 执行计划)
