colibri Metal 后端 M5 Max 性能报告OMP 自旋陷阱与 PIPE 管线的联合调优实践【免费下载链接】colibriRun frontier MoE models on hardware you already own — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 项目地址: https://gitcode.com/GitHub_Trending/colibri3/colibri本文是 colibri 项目在 Apple M5 Max 上 Metal GPU 后端的实测性能报告对应仓库文档 docs/METAL-M5MAX-PERF-REPORT.md。它完整记录了一次 rebase 之后 Metal 后端发生的性能回归——默认配置下解码吞吐从 2.06 tok/s 跌至 1.25 tok/s−39%——并逐步定位到根因OMP 热线程自旋在 Apple Silicon 上偷走了与 GPU 共享的 SoC 功耗预算。读完本文你将掌握三个可直接落地的实战能力① 用COLI_NO_OMP_TUNE1恢复 GPU 时钟② 用PIPE1 PIPE_WORKERS8掩盖 CPU→GPU 专家分派延迟③ 在 128 GB 统一内存机型上安全设定--ram预算避免触发内存压缩造成双重惩罚。报告结论速览TL;DRRebase 之后Metal 后端在调优后比 rebase 前更快——2.24 vs 2.06 tok/s8.5%。但默认配置下 rebase 后的分支严重回退1.25 tok/s−39%原因在于新基线引入了 OMP 热团队 active-spin仓库内问题 #77在 Apple Silicon 上CPU 与 GPU 共享同一功耗/散热预算自旋会把 GPU 的时钟余量偷走导致 Metal 内核被降频。关闭自旋即可恢复 GPU再叠加旧基线不存在的新特性PIPE异步专家 I/O 管线吞吐即可超过rebase 前的成绩。报告的最终建议是Metal 构建应将 OMP 默认设为被动等待passive wait。这一结论并非孤例。同一方法论在 docs/METAL-M1ULTRA-FMT2-REPORT.md 中做了交叉验证M1 Ultra 上该自旋陷阱不重现Mac Studio 桌面级功耗余量下 GPU 未被节流COLI_NO_OMP_TUNE单独使用是中性的0.8%PIPE成为唯一有效杠杆6.9%——这进一步印证了自旋伤 GPU 时钟的机制判断与硬件环境强相关需按机型实测。测试环境与方法每轮固定不变报告的可信度建立在严格的固定条件下硬件Apple M5 Max —— 18 个 CPU 核心12 P 6 E40 核 GPU128 GB 统一内存模型GLM-5.2 int4744B MoE专家权重从 SSD 流式加载工作负载./coli run Compare the myths of Lucifer and Prometheus生成 1024 个 token恒定标志COLI_METAL1 DIRECT1 MTP0 --ram 110每轮工作集一致约 607 个专家/token命中率约 74–75%RSS 约 97.9 GBfallback CPU 0所有合格 block 都在 GPU 上其中COLI_METAL1启用 Apple Silicon Metal 后端需要make METAL1构建参见 docs/ENVIRONMENT.md 第 64 行DIRECT1走O_DIRECT无缓冲读取MTP0关闭多 token 预测具体语义见下文注意事项--ram 110给专家工作集分配 110 GB 内存预算--ram默认值 0 表示自动约取可用内存的 88%见 docs/SETTINGS.md 第 37 行。基准结果A–E 五组配置逐项对比下表是本报告的核心数据tok/s 为解码吞吐wall 为总耗时时间单位均为秒配置tok/swall (s)expert-diskexpert-matmulattentionattention GPU kernelexpert GPU overhead*A— 旧基线rebase 前分支2.064962661091007651B— rebase 后默认配置1.25819285215290223106C— rebase 后默认 PIPE11.3078829719027221289D— rebase 后 COLI_NO_OMP_TUNE11.905392661431098584E— rebase 后 NO_OMPPIPE1最优2.2445724197997944*expert GPU overhead 专家 GPU 墙钟时间 − 专家内核时间即 GPU 空闲等待被喂数据的耗时。专家内核时间本身在每一轮未节流的运行中都恒定在约 34–35 s。最优配置E的完整命令COLI_METAL1 DIRECT1 MTP0 COLI_NO_OMP_TUNE1 PIPE1 PIPE_WORKERS8 \ ./coli run --model /path/to/glm52_i4 \ Compare the myths of Lucifer and Prometheus --ram 110注意 E 配置下 expert-disk241 s、expert-matmul97 s、attention99 s三项全面低于旧基线 A266 / 109 / 100 s——这正是PIPE在新基线上带来的净收益。逐阶段拆解回归从何而来又如何被修复A→B默认回归的根因是 GPU 降频不是内核工作量变大五组运行中 GPU 分派数量完全相同约 140k 个 block、79,794 次 attention 层启动、618k 个专家跑在 GPU 上但attention GPU 内核时间翻了近三倍76 s → 223 s。相同的工作量下内核执行时间不可能凭空翻三倍唯一的解释是GPU 在降频。罪魁祸首是 OMP 热团队自旋#77启用 active spin 时CPU 大约以 97% 的占用率在忙等 GPU而 M 系列 CPU 与 GPU 共享同一个功耗/散热包络这种自旋直接把 GPU 的时钟余量抢走了。源码印证了这一机制。在 c/colibri.c 的 OMP 热线程调优块中引擎在 Linux/FreeBSD 上会setenv(OMP_WAIT_POLICY,active,0)保持团队热状态以消除每段极小的专家 matmul 之间团队重新唤醒的延迟注释中记录了 Zen5 构建上 matmul 时间从 66.9 s 降到 20.9 s 的测量结果但注释同样明确记录#707 问题报告指出在 Apple Silicon LLVM libomp 上OMP_WAIT_POLICYactive单独就会让解码慢 122%KMP_BLOCKTIME200单独慢 115%M1 Max 32 GB 实测因此在__APPLE__分支下这些 spin-wait 变量被显式跳过并打印提示[OMP] hot-thread tuning skipped on macOS (#707): spin-wait knobs measured slower on Apple Silicon (COLI_NO_OMP_TUNE1 to skip)配套的 c/omp_tune.h 进一步解释了为什么只做物理核心数调优、不做 spin-wait注释中记录了 #116 在 Metal 上 −39%、#159 在 x86CUDA 上约 3× 的同类自旋伤害机制是当 token 由磁盘上的字节拼成时空转的团队会从真正干活的 I/O 池手里抢走核心。这也解释了为什么报告要求Metal 构建默认被动等待——在 Metal 卸载期间 CPU 大部分时间在等待 GPU主动自旋就是纯粹的负收益。B→C自旋仍在时加 PIPE 收效甚微在自旋尚未关闭时叠加PIPE1吞吐仅从 1.25 微升到 1.30。原因很直观CPU 已经被自旋占满没有多余的计算周期去运行 PIPE 的 I/O worker 线程。这为先关自旋、再开 PIPE的正确顺序提供了直接证据。修复一A→DCOLI_NO_OMP_TUNE1把 GPU 时钟还回去COLI_NO_OMP_TUNE1使 OMP 团队转为被动等待passive waitGPU 的功耗预算得以恢复attention 内核时间从 223 s 回落到 85 s接近旧基线的 76 s吞吐跃升至 1.90 tok/s。该变量在引擎中的实现是存在即生效的 kill-switch在 c/colibri.c 中只要检测到COLI_NO_OMP_TUNE环境变量整个 OMP 调优 重新 exec 路径都会被跳过COLI_NO_OMP_TUNE1的官方文档描述见 docs/ENVIRONMENT.md 第 86 行——OpenMP 热线程调优OMP_WAIT_POLICYactive自旋 proc-bind的 kill-switch当 CPU 主要是在等待 GPU如 Metal时应设为 1避免自旋偷走共享功耗预算。仓库测试 c/tests/test_omp_tune.c 也对这一 kill-switch 的行为做了单元验证。但 A→D 之后仍留有残余差距且全部集中在expert-matmul比 A 多 33 s——具体是GPU overhead从 51 s 涨到 84 s而专家内核时间仍恒定在约 34 s。机制是被动等待虽然不再偷电但 CPU 把下一批专家交给 GPU 的节奏变慢了GPU 在两次分派之间陷入空闲。修复二D→EPIPE1 PIPE_WORKERS8掩盖分派延迟PIPE1配合PIPE_WORKERS8让专家权重保持预取和流式供给GPU 不再空等expert overhead 从 84 s 降到 44 s甚至低于旧基线的 51 s同时PIPE的 I/O 重叠把磁盘墙钟时间从 266 s 压到 241 s。净结果2.24 tok/s——超过 rebase 前的 2.06因为旧基线上根本没有PIPE这个特性。从源码看PIPE 是引擎内一个带锁存语义的异步专家加载池c/colibri.c主线程把当前 batch 的专家 id 以 release 语义发布到cur原子槽并唤醒池中 workerworker 用 CAS 抢占槽位执行expert_load()后置位ready[]matmul 循环则对每个槽位等待完成——整个机制保证与阻塞加载路径字节一致byte-identical仅重排 I/O 顺序。环境变量解析在 c/colibri.cPIPE默认在 Windows 上开、其他平台关PIPE_WORKERS默认 8且存在一个实用隐式规则——显式设置正的PIPE_WORKERS会自动隐含PIPE1该表在 c/tests/test_pipe_block.c 中有逐行验证包括PIPE_WORKERS0不触发、显式PIPE0永远优先。相关文档见 docs/tuning.md 第 119–123 行与 docs/ENVIRONMENT.md 第 71–72 行。两个杠杆是互补的不是凑巧叠加报告的定性总结非常关键NO_OMP恢复 GPU 时钟PIPE掩盖NO_OMP引入的 CPU→GPU 分派延迟。两个都要。单独关自旋D只能到 1.90单独开 PIPEC只能到 1.30二者叠加E才是 2.24。推荐配置与运行方式报告给出了三条明确建议Apple Silicon Metal 构建应将 OMP 默认设为被动等待——例如在COLI_METAL启用时自动设置OMP_WAIT_POLICYpassive或等效于COLI_NO_OMP_TUNE的行为。#77 的 active-spin 默认值在本机型是 −39% 的陷阱Metal 卸载期间 CPU 绝大多数时间在等 GPU主动自旋等于主动节流。这是影响力最大的单一改动。将PIPE1 PIPE_WORKERS8文档化为 Metal 的推荐配置——它回收了被动等待带来的分派延迟成本并重叠了专家 I/O。注意PIPE_WORKERS并非越大越好姊妹报告 docs/METAL-M1ULTRA-FMT2-REPORT.md 实测 8 是甜点值12 → 1.41 属于噪声16 → 1.37 下降SSD 饱和后多余 worker 只会增加争用。128 GB M5 Max 的内存上限边界--ram 110安全RSS 约 97 GB压缩器安静--ram 120会越界进入内存压缩双重惩罚——压缩器的 CPU 开销和从 GPU 抢走的 SoC 功耗--ram 115未测/临界。由于 Metal 的注册缓冲共享统一内存这个拐点比纯 CPU 构建更低。完整命令E 配置可直接复制运行COLI_METAL1 DIRECT1 MTP0 COLI_NO_OMP_TUNE1 PIPE1 PIPE_WORKERS8 \ ./coli run --model /path/to/glm52_i4 \ Compare the myths of Lucifer and Prometheus --ram 110注意事项与尚未探索的杠杆这些数字仅代表解码decode报告给出的是稳态解码数据。冷 prefill 的耗时不受影响fused attention 覆盖 S≤4 序列长度因此 prefill 墙钟不在本报告吞吐统计范围内。DIRECT1是必需项不是可选项DIRECT0被单独 A/B 验证过在运行的同一时点吞吐约慢 2×2.16 → 1.15 tok/s同时 RSS 从 98 GB 降到 84 GB——原因是读取回退到操作系统页缓存虽然降低了进程 RSS却破坏了DIRECT1所启用的zero-copy GPU slab 注册为喂给 GPU 增加了一次拷贝。docs/ENVIRONMENT.md 第 85 行对DIRECT的定位也说明它是依赖驱动的在带 DRAM 缓存且有头部的真实 NVMe 上通常是大胜实测 Blackwell/Windows 盒子上配合PIPE1解码 34%但在 QLC/无 DRAM 或慢速/虚拟化磁盘上可能中性甚至为负——务必在目标硬件上实测。MTP0贯穿始终MTP 开启是一个尚待探索的杠杆rebase 后的内核新增了fused attention 处理 S≤4覆盖 MTP verify 前向的提交意味着 MTP verify 现在由 GPU 加速。而 MTP 在旧基线上是净亏损128 GB 内存拐点参见 docs/METAL-M1ULTRA-FMT2-REPORT.md 的建议 3MTP 在 128 GB 上是严格损失接受率 63–74% 但 12–15 GB RSS 会越过内存拐点进入 swap 抖动。在新基线上重测 MTP 开启是报告明确列出的后续工作。确定性声明token-exact的边界报告确认了引擎在并行配置下不具备运行间可复现性两次完全相同的DIRECT1运行同配置、同提示、贪心 / MTP 关闭在约 7 个 token 内开始分叉。原因是预期的且无害的并行专家求和归约中的浮点非结合性PIPE worker 完成顺序和/或 GPU threadgroup 归约偶尔会在 token 边界翻转一次 argmax。输出质量不受影响两次补全都是合法文本且各轮间吞吐完全一致同一时点均为 1.28 tok/s因此基准数字是稳定的。对 PR 的 token-exact 声明的正确解读是GPU 路径在确定性/串行验证配置下与 CPU 参考一致而不是开启PIPE/线程后跨运行比特级可复现——报告明确建议如此表述以免有人 diff 两次运行结果后误报 bug。测量局限数字为每种配置在热缓存上的单次运行运行间与热/环境波动未被量化同一会话内对旧/新 commit 做 A/B 会进一步收紧节流结论。总结这份 M5 Max 性能报告是一个教科书级的回归定位 → 根因分析 → 双杠杆修复案例默认配置 −39% 的暴跌既不在内核工作量、也不在 I/O 路径而在 OMP 热团队自旋偷走共享 SoC 功耗预算COLI_NO_OMP_TUNE1c/colibri.c 中的存在即生效 kill-switch恢复 GPU 时钟PIPE1 PIPE_WORKERS8异步专家加载池c/colibri.c掩盖分派延迟二者叠加将吞吐推到2.24 tok/s。对 colibri 在 Apple Silicon 上的使用者这份报告给出了可直接复制的推荐命令与内存边界对引擎开发者它同时是一份在共享功耗包络的 SoC 上CPU 忙等会伤害 GPU的实测警示并已沉淀进 docs/ENVIRONMENT.md、docs/tuning.md 与 docs/METAL-M1ULTRA-FMT2-REPORT.md 等配套文档形成了一套跨机型可复现的 Metal 调优方法论。【免费下载链接】colibriRun frontier MoE models on hardware you already own — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 项目地址: https://gitcode.com/GitHub_Trending/colibri3/colibri创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 colibri Metal 后端 M5 Max 性能报告：OMP 自旋陷阱与 PIPE 管线的联合调优实践
colibri Metal 后端 M5 Max 性能报告OMP 自旋陷阱与 PIPE 管线的联合调优实践【免费下载链接】colibriRun frontier MoE models on hardware you already own — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 项目地址: https://gitcode.com/GitHub_Trending/colibri3/colibri本文是 colibri 项目在 Apple M5 Max 上 Metal GPU 后端的实测性能报告对应仓库文档 docs/METAL-M5MAX-PERF-REPORT.md。它完整记录了一次 rebase 之后 Metal 后端发生的性能回归——默认配置下解码吞吐从 2.06 tok/s 跌至 1.25 tok/s−39%——并逐步定位到根因OMP 热线程自旋在 Apple Silicon 上偷走了与 GPU 共享的 SoC 功耗预算。读完本文你将掌握三个可直接落地的实战能力① 用COLI_NO_OMP_TUNE1恢复 GPU 时钟② 用PIPE1 PIPE_WORKERS8掩盖 CPU→GPU 专家分派延迟③ 在 128 GB 统一内存机型上安全设定--ram预算避免触发内存压缩造成双重惩罚。报告结论速览TL;DRRebase 之后Metal 后端在调优后比 rebase 前更快——2.24 vs 2.06 tok/s8.5%。但默认配置下 rebase 后的分支严重回退1.25 tok/s−39%原因在于新基线引入了 OMP 热团队 active-spin仓库内问题 #77在 Apple Silicon 上CPU 与 GPU 共享同一功耗/散热预算自旋会把 GPU 的时钟余量偷走导致 Metal 内核被降频。关闭自旋即可恢复 GPU再叠加旧基线不存在的新特性PIPE异步专家 I/O 管线吞吐即可超过rebase 前的成绩。报告的最终建议是Metal 构建应将 OMP 默认设为被动等待passive wait。这一结论并非孤例。同一方法论在 docs/METAL-M1ULTRA-FMT2-REPORT.md 中做了交叉验证M1 Ultra 上该自旋陷阱不重现Mac Studio 桌面级功耗余量下 GPU 未被节流COLI_NO_OMP_TUNE单独使用是中性的0.8%PIPE成为唯一有效杠杆6.9%——这进一步印证了自旋伤 GPU 时钟的机制判断与硬件环境强相关需按机型实测。测试环境与方法每轮固定不变报告的可信度建立在严格的固定条件下硬件Apple M5 Max —— 18 个 CPU 核心12 P 6 E40 核 GPU128 GB 统一内存模型GLM-5.2 int4744B MoE专家权重从 SSD 流式加载工作负载./coli run Compare the myths of Lucifer and Prometheus生成 1024 个 token恒定标志COLI_METAL1 DIRECT1 MTP0 --ram 110每轮工作集一致约 607 个专家/token命中率约 74–75%RSS 约 97.9 GBfallback CPU 0所有合格 block 都在 GPU 上其中COLI_METAL1启用 Apple Silicon Metal 后端需要make METAL1构建参见 docs/ENVIRONMENT.md 第 64 行DIRECT1走O_DIRECT无缓冲读取MTP0关闭多 token 预测具体语义见下文注意事项--ram 110给专家工作集分配 110 GB 内存预算--ram默认值 0 表示自动约取可用内存的 88%见 docs/SETTINGS.md 第 37 行。基准结果A–E 五组配置逐项对比下表是本报告的核心数据tok/s 为解码吞吐wall 为总耗时时间单位均为秒配置tok/swall (s)expert-diskexpert-matmulattentionattention GPU kernelexpert GPU overhead*A— 旧基线rebase 前分支2.064962661091007651B— rebase 后默认配置1.25819285215290223106C— rebase 后默认 PIPE11.3078829719027221289D— rebase 后 COLI_NO_OMP_TUNE11.905392661431098584E— rebase 后 NO_OMPPIPE1最优2.2445724197997944*expert GPU overhead 专家 GPU 墙钟时间 − 专家内核时间即 GPU 空闲等待被喂数据的耗时。专家内核时间本身在每一轮未节流的运行中都恒定在约 34–35 s。最优配置E的完整命令COLI_METAL1 DIRECT1 MTP0 COLI_NO_OMP_TUNE1 PIPE1 PIPE_WORKERS8 \ ./coli run --model /path/to/glm52_i4 \ Compare the myths of Lucifer and Prometheus --ram 110注意 E 配置下 expert-disk241 s、expert-matmul97 s、attention99 s三项全面低于旧基线 A266 / 109 / 100 s——这正是PIPE在新基线上带来的净收益。逐阶段拆解回归从何而来又如何被修复A→B默认回归的根因是 GPU 降频不是内核工作量变大五组运行中 GPU 分派数量完全相同约 140k 个 block、79,794 次 attention 层启动、618k 个专家跑在 GPU 上但attention GPU 内核时间翻了近三倍76 s → 223 s。相同的工作量下内核执行时间不可能凭空翻三倍唯一的解释是GPU 在降频。罪魁祸首是 OMP 热团队自旋#77启用 active spin 时CPU 大约以 97% 的占用率在忙等 GPU而 M 系列 CPU 与 GPU 共享同一个功耗/散热包络这种自旋直接把 GPU 的时钟余量抢走了。源码印证了这一机制。在 c/colibri.c 的 OMP 热线程调优块中引擎在 Linux/FreeBSD 上会setenv(OMP_WAIT_POLICY,active,0)保持团队热状态以消除每段极小的专家 matmul 之间团队重新唤醒的延迟注释中记录了 Zen5 构建上 matmul 时间从 66.9 s 降到 20.9 s 的测量结果但注释同样明确记录#707 问题报告指出在 Apple Silicon LLVM libomp 上OMP_WAIT_POLICYactive单独就会让解码慢 122%KMP_BLOCKTIME200单独慢 115%M1 Max 32 GB 实测因此在__APPLE__分支下这些 spin-wait 变量被显式跳过并打印提示[OMP] hot-thread tuning skipped on macOS (#707): spin-wait knobs measured slower on Apple Silicon (COLI_NO_OMP_TUNE1 to skip)配套的 c/omp_tune.h 进一步解释了为什么只做物理核心数调优、不做 spin-wait注释中记录了 #116 在 Metal 上 −39%、#159 在 x86CUDA 上约 3× 的同类自旋伤害机制是当 token 由磁盘上的字节拼成时空转的团队会从真正干活的 I/O 池手里抢走核心。这也解释了为什么报告要求Metal 构建默认被动等待——在 Metal 卸载期间 CPU 大部分时间在等待 GPU主动自旋就是纯粹的负收益。B→C自旋仍在时加 PIPE 收效甚微在自旋尚未关闭时叠加PIPE1吞吐仅从 1.25 微升到 1.30。原因很直观CPU 已经被自旋占满没有多余的计算周期去运行 PIPE 的 I/O worker 线程。这为先关自旋、再开 PIPE的正确顺序提供了直接证据。修复一A→DCOLI_NO_OMP_TUNE1把 GPU 时钟还回去COLI_NO_OMP_TUNE1使 OMP 团队转为被动等待passive waitGPU 的功耗预算得以恢复attention 内核时间从 223 s 回落到 85 s接近旧基线的 76 s吞吐跃升至 1.90 tok/s。该变量在引擎中的实现是存在即生效的 kill-switch在 c/colibri.c 中只要检测到COLI_NO_OMP_TUNE环境变量整个 OMP 调优 重新 exec 路径都会被跳过COLI_NO_OMP_TUNE1的官方文档描述见 docs/ENVIRONMENT.md 第 86 行——OpenMP 热线程调优OMP_WAIT_POLICYactive自旋 proc-bind的 kill-switch当 CPU 主要是在等待 GPU如 Metal时应设为 1避免自旋偷走共享功耗预算。仓库测试 c/tests/test_omp_tune.c 也对这一 kill-switch 的行为做了单元验证。但 A→D 之后仍留有残余差距且全部集中在expert-matmul比 A 多 33 s——具体是GPU overhead从 51 s 涨到 84 s而专家内核时间仍恒定在约 34 s。机制是被动等待虽然不再偷电但 CPU 把下一批专家交给 GPU 的节奏变慢了GPU 在两次分派之间陷入空闲。修复二D→EPIPE1 PIPE_WORKERS8掩盖分派延迟PIPE1配合PIPE_WORKERS8让专家权重保持预取和流式供给GPU 不再空等expert overhead 从 84 s 降到 44 s甚至低于旧基线的 51 s同时PIPE的 I/O 重叠把磁盘墙钟时间从 266 s 压到 241 s。净结果2.24 tok/s——超过 rebase 前的 2.06因为旧基线上根本没有PIPE这个特性。从源码看PIPE 是引擎内一个带锁存语义的异步专家加载池c/colibri.c主线程把当前 batch 的专家 id 以 release 语义发布到cur原子槽并唤醒池中 workerworker 用 CAS 抢占槽位执行expert_load()后置位ready[]matmul 循环则对每个槽位等待完成——整个机制保证与阻塞加载路径字节一致byte-identical仅重排 I/O 顺序。环境变量解析在 c/colibri.cPIPE默认在 Windows 上开、其他平台关PIPE_WORKERS默认 8且存在一个实用隐式规则——显式设置正的PIPE_WORKERS会自动隐含PIPE1该表在 c/tests/test_pipe_block.c 中有逐行验证包括PIPE_WORKERS0不触发、显式PIPE0永远优先。相关文档见 docs/tuning.md 第 119–123 行与 docs/ENVIRONMENT.md 第 71–72 行。两个杠杆是互补的不是凑巧叠加报告的定性总结非常关键NO_OMP恢复 GPU 时钟PIPE掩盖NO_OMP引入的 CPU→GPU 分派延迟。两个都要。单独关自旋D只能到 1.90单独开 PIPEC只能到 1.30二者叠加E才是 2.24。推荐配置与运行方式报告给出了三条明确建议Apple Silicon Metal 构建应将 OMP 默认设为被动等待——例如在COLI_METAL启用时自动设置OMP_WAIT_POLICYpassive或等效于COLI_NO_OMP_TUNE的行为。#77 的 active-spin 默认值在本机型是 −39% 的陷阱Metal 卸载期间 CPU 绝大多数时间在等 GPU主动自旋等于主动节流。这是影响力最大的单一改动。将PIPE1 PIPE_WORKERS8文档化为 Metal 的推荐配置——它回收了被动等待带来的分派延迟成本并重叠了专家 I/O。注意PIPE_WORKERS并非越大越好姊妹报告 docs/METAL-M1ULTRA-FMT2-REPORT.md 实测 8 是甜点值12 → 1.41 属于噪声16 → 1.37 下降SSD 饱和后多余 worker 只会增加争用。128 GB M5 Max 的内存上限边界--ram 110安全RSS 约 97 GB压缩器安静--ram 120会越界进入内存压缩双重惩罚——压缩器的 CPU 开销和从 GPU 抢走的 SoC 功耗--ram 115未测/临界。由于 Metal 的注册缓冲共享统一内存这个拐点比纯 CPU 构建更低。完整命令E 配置可直接复制运行COLI_METAL1 DIRECT1 MTP0 COLI_NO_OMP_TUNE1 PIPE1 PIPE_WORKERS8 \ ./coli run --model /path/to/glm52_i4 \ Compare the myths of Lucifer and Prometheus --ram 110注意事项与尚未探索的杠杆这些数字仅代表解码decode报告给出的是稳态解码数据。冷 prefill 的耗时不受影响fused attention 覆盖 S≤4 序列长度因此 prefill 墙钟不在本报告吞吐统计范围内。DIRECT1是必需项不是可选项DIRECT0被单独 A/B 验证过在运行的同一时点吞吐约慢 2×2.16 → 1.15 tok/s同时 RSS 从 98 GB 降到 84 GB——原因是读取回退到操作系统页缓存虽然降低了进程 RSS却破坏了DIRECT1所启用的zero-copy GPU slab 注册为喂给 GPU 增加了一次拷贝。docs/ENVIRONMENT.md 第 85 行对DIRECT的定位也说明它是依赖驱动的在带 DRAM 缓存且有头部的真实 NVMe 上通常是大胜实测 Blackwell/Windows 盒子上配合PIPE1解码 34%但在 QLC/无 DRAM 或慢速/虚拟化磁盘上可能中性甚至为负——务必在目标硬件上实测。MTP0贯穿始终MTP 开启是一个尚待探索的杠杆rebase 后的内核新增了fused attention 处理 S≤4覆盖 MTP verify 前向的提交意味着 MTP verify 现在由 GPU 加速。而 MTP 在旧基线上是净亏损128 GB 内存拐点参见 docs/METAL-M1ULTRA-FMT2-REPORT.md 的建议 3MTP 在 128 GB 上是严格损失接受率 63–74% 但 12–15 GB RSS 会越过内存拐点进入 swap 抖动。在新基线上重测 MTP 开启是报告明确列出的后续工作。确定性声明token-exact的边界报告确认了引擎在并行配置下不具备运行间可复现性两次完全相同的DIRECT1运行同配置、同提示、贪心 / MTP 关闭在约 7 个 token 内开始分叉。原因是预期的且无害的并行专家求和归约中的浮点非结合性PIPE worker 完成顺序和/或 GPU threadgroup 归约偶尔会在 token 边界翻转一次 argmax。输出质量不受影响两次补全都是合法文本且各轮间吞吐完全一致同一时点均为 1.28 tok/s因此基准数字是稳定的。对 PR 的 token-exact 声明的正确解读是GPU 路径在确定性/串行验证配置下与 CPU 参考一致而不是开启PIPE/线程后跨运行比特级可复现——报告明确建议如此表述以免有人 diff 两次运行结果后误报 bug。测量局限数字为每种配置在热缓存上的单次运行运行间与热/环境波动未被量化同一会话内对旧/新 commit 做 A/B 会进一步收紧节流结论。总结这份 M5 Max 性能报告是一个教科书级的回归定位 → 根因分析 → 双杠杆修复案例默认配置 −39% 的暴跌既不在内核工作量、也不在 I/O 路径而在 OMP 热团队自旋偷走共享 SoC 功耗预算COLI_NO_OMP_TUNE1c/colibri.c 中的存在即生效 kill-switch恢复 GPU 时钟PIPE1 PIPE_WORKERS8异步专家加载池c/colibri.c掩盖分派延迟二者叠加将吞吐推到2.24 tok/s。对 colibri 在 Apple Silicon 上的使用者这份报告给出了可直接复制的推荐命令与内存边界对引擎开发者它同时是一份在共享功耗包络的 SoC 上CPU 忙等会伤害 GPU的实测警示并已沉淀进 docs/ENVIRONMENT.md、docs/tuning.md 与 docs/METAL-M1ULTRA-FMT2-REPORT.md 等配套文档形成了一套跨机型可复现的 Metal 调优方法论。【免费下载链接】colibriRun frontier MoE models on hardware you already own — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 项目地址: https://gitcode.com/GitHub_Trending/colibri3/colibri创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考