待验证｜lithos-metal补Apple推理内核

10月11日20:30Z前后，lithos-metal在不到一分钟内连续合并5个围绕Apple silicon LLM推理内核的PR。这个时间线本身就是本期增量：kernel choices、Apple9 tile、exact prefill attention、FP8 decode和prefill scratch复用被连续推进到main分支。

这不是大厂发布或已复验性能榜单，而是一条低置信开源工程观察。项目仓库把自己描述为“high-performance LLM inference kernels and serving for Apple silicon”，10月11日最后一次push停在20:31:14Z，抓取时显示183星、12个fork和17个open issues。PR #35、#36、#37、#39的GitHub API元数据可读，PR #38这次只拿到merge commit标题，因此本文对#38只写“FP8 E4M3 decode每个half2处理两个code”，不展开文件级判断。

信源边界需要收紧。PR正文里的M3 Ultra、M4 Pro和Qwen3.8-27B-NVFP4数据是项目作者自报，官方发布渠道未确认这些10月11日改动已经进入正式版本，早报没有运行本地基准，也没有找到独立第三方benchmark复验。v0.1.2发布于10月5日，它能说明项目迁移、安装方式和当时的支持环境，但不能当成本期新增发布。

因此，本篇只把它放在开源生态观察位。可核验的是合并时间、PR主题和作者给出的测量口径；仍待验证的是这些改动在用户可安装版本、其他Apple芯片和不同模型配置下是否成立。

对开发者的实际意义在于，这组PR把Apple本地推理的讨论从“能不能在Mac上跑”推进到更底层的问题：同一模型在不同Apple GPU代际上是否选择了正确tile，serve路径是否能复用调参结果，prefill精确模式是否真的逐token一致，以及内存scratch是否会把长上下文推到GPU page fault。

一分钟内合并了什么

这5个PR的共同点是都围绕lithos-metal的推理执行路径，增量集中在运行时和内核细节。#37先合并，处理prefill scratch复用；#38随后合并，merge commit标题指向FP8 E4M3 decode；#36处理exact prefill attention；#35补Apple9 matrix tile和M3 Ultra、M4 Pro测量配置；#39最后合并，把测量过的kernel choices接到serve路径。

时间	PR或commit	可核验增量	早报写法边界
20:30:33Z	PR #37	prefill scratch复用不再重复attention partials	可写内存占用自报下降，不写独立证实
20:30:41Z	PR #38	FP8 E4M3 decode每个half2处理两个code	只按merge commit标题记录
20:30:48Z	PR #36	N-exact prompt passes在各芯片上保持精确	可写修复正确性路径
20:30:56Z	PR #35	Apple9 tile和M3 Ultra、M4 Pro measured profiles	可写项目自测结果
20:31:15Z	PR #39	serve启用测量过的kernel choices	可写serve路径配置变化

PR #35的信息量最大。正文称原来的matrix tile假设Apple10 cooperative-tensor layout，因此在Apple9 GPU，也就是M3和M4路径上结果错误，accelerator保持关闭，所有T大于1的projection都走shader GEMV。PR作者给出自测数字：M3 Ultra上一个43-token的Qwen3.8-27B-NVFP4 prompt首token从11.8秒降到0.65秒，DSpark decode从约5 tok/s到36.0 tok/s；M4 Pro的DSpark decode自报为25.7 tok/s。这些数字说明作者在修“错误路径”和“测量配置”，但仍是项目内测口径。

PR #36把问题从速度转向正确性。它的正文称--prefill-chunk-size N-exact承诺复现128-row passes的结果，但在没有自己prefill optimizer的芯片上并未做到。具体例子是M3 Ultra上一个2846-token prompt的greedy output在token 179发生分歧。修复后，exact pass的行使用其所属128-row pass的chunking；正文还说256-row pass等于四个64-row passes，M3 Ultra上的816和2846-token prompts用512-row exact passes能逐token等于128-row输出。

PR #37处理的是长上下文时的scratch复用。正文称旧的prompt program scratch reuse会把小值放进任意空slot，导致后续attention partials重复开新slot。作者给出的例子是Qwen3.8-27B prompt program在32K context下，M4 Pro上128-row passes持有18.7 GB scratch，256-row达到34.9 GB，超过working set并触发GPU page fault。修复后，值最多占用两倍大小的free slot，M4 Pro口径降到5.8 GB和9.1 GB，M3 Ultra 512-row pass从35.0 GB到9.3 GB。这里同样只能写项目自报，因为没有第三方复现。

PR #39把前面的测量选择接入serve。正文说，serve此前不会autotune，因此没有recipes的芯片会用默认几何编译GEMV、tile和GDN dispatch。改动后，配置可以携带来自设备autotuner的kernel_choices，serve session以measured_choices=True查表，未列出的shape继续使用默认值，--no-autotune保留默认几何。PR #39还明确写明其“after”列包含#38，并且是在#28之前测得。

自报数字能说明什么

这组数据先提供了一个观察窗口：Apple GPU推理路径里仍有很多“选错kernel就差很多”的细节。对本地推理工具来说，用户看到的是首token时间、decode速度、长上下文是否崩溃；工程实现里对应的却可能是tile layout、chunk顺序、scratch arena复用和tuning cache identity。

指标	PR自报before	PR自报after	来源和限制
M3 Ultra DSpark decode	66.0 tok/s	73.6 tok/s	PR #39，包含#38，未独立复验
M4 Pro DSpark decode	25.7 tok/s	35.1 tok/s	PR #39，serve options口径
M3 Ultra 2846-token首token	12.0秒	8.6秒	PR #39，Qwen3.8-27B-NVFP4
M4 Pro 2846-token首token	25.9秒	21.5秒	PR #39，Qwen3.8-27B-NVFP4
M4 Pro 256-row scratch	34.9 GB	9.1 GB	PR #37，作者自测

这些数字之间也不能简单相加。#35的M3 Ultra首token从11.8秒到0.65秒，是在Apple9 tile修复上下文里描述的短prompt数据；#39的首token表格则是serve options，且包含#38并说明是在#28之前测得。#37讲scratch占用和GPU page fault，主要关心长上下文prompt program是否跑得下。把这些数字混成一个“整体性能提升多少倍”的结论，会丢掉每个PR自己的基准、硬件、模型和测量条件。

还有一个容易误读的点是“measured choices”。PR #39描述的是配置可以携带设备上测得的kernel choices，serve按表查用；没有列在表里的shape仍然保留默认值。serve每次启动不会因此重新跑完整autotune。这会让线上serve路径更接近调参结果，也会让配置和硬件绑定得更紧。换句话说，它提高的是“把测量结果带到服务路径”的确定性，不能扩展成跨全部Apple芯片、全部模型和全部上下文长度都成立的通用加速结论。

更准确的表达是：10月11日的合并把多个此前分散的内核问题推进到main分支，项目作者自报在M3 Ultra和M4 Pro上有可观变化，但早报还不能判断这些变化在其他模型、其他上下文长度、正式release安装包和普通用户机器上是否稳定复现。

为什么是Apple本地推理信号

Apple silicon上的LLM推理一直有一个特殊约束：硬件在用户身边，内存带宽、统一内存和Metal栈都很有吸引力，但真正能不能跑得快，取决于项目是否把不同芯片代际的执行路径调清楚。M3、M4、M5并不只是市场名，它们对应不同GPU能力、tile布局和kernel选择。一个项目如果只在某一代芯片上调通，换到另一代就可能掉回默认路径。

lithos-metal的10月11日改动正好暴露了这层问题。PR #35说Apple9路径原本假设Apple10布局，结果是accelerator关闭；PR #39说serve原来不用autotune结果，只能走默认几何；PR #36说明“exact”这种用户可见承诺背后，还有chunking顺序和bit-for-bit一致性；PR #37说明长上下文不仅是模型窗口大小，也受临时workspace复用策略约束。这些都是本地推理项目从可演示走向可用时必须补的工程账。

但它仍是早期项目。10月5日的v0.1.2 release写到项目刚迁移到lithos-ai/lithos-metal，发布包包含compiled runtime、kernels、chip recipes和serving dependency wheels，要求Apple silicon、macOS 26或更新版本，并由Homebrew提供Python 3.12。release正文还写了991 local contract checks passed。这些能说明项目在做发布工程，不能说明10月11日的新kernel选择已经进入正式包。

开源生态里的验证链条通常更长：PR合并、release包含这些提交、用户通过包管理器安装到相同代码、外部用户在公开硬件和参数下复现指标。lithos-metal目前处在早期环节，因此适合标为low confidence。

早报观点

早报判断是，lithos-metal这组PR的主要价值落在Apple本地推理的“硬件代际差异工程化”。只要模型仍要在端侧运行，kernel选择、tile布局、prefill正确性和scratch内存都会直接变成用户感受到的延迟、吞吐和崩溃概率。

这也解释了为什么它不能被写成大新闻。项目作者给出的数字很具体，反而更需要保持边界：具体不等于独立，详细不等于复现。尤其是PR #39同时引用多个前置改动，#35和#37又各自有不同prompt长度、row size和硬件配置。如果读者只记住“性能提升了”，就会误解这条消息；如果读者记住“项目正在把serve路径接到测量过的kernel choices”，才接近事实。

对开发者来说，这条的价值是提示本地LLM工具链的竞争变量正在下沉。模型名、量化格式和GUI体验仍重要，但端侧体验的上限常常由更底层的Metal kernel决定。对企业买方来说，当前还不能据此做采购判断；更合理的动作是把它放进观察列表，等release、复现脚本和第三方测试出现。

接下来怎么验证

发布路径是第一层验证。如果lithos-metal发布包含10月11日5个PR的新版本，并在release note中列明commit范围、安装方式和已知限制，今天的工程信号就会从“main分支合并”升级为“用户可安装版本”。在那之前，v0.1.2只能作为背景，不能替新改动背书。

外部benchmark是第二层验证。理想材料应至少写明Apple芯片型号、macOS版本、模型与量化格式、prompt长度、decode设置、是否启用DSpark、是否使用--no-autotune以及测量脚本。尤其PR #39里的before/after表格很容易传播，但只有公开脚本和第三方机器复验，才能判断它是普遍收益、特定配置收益，还是只修复了某条路径。

正确性测试要变得可读。#36的“exact prompt passes”不是普通用户会主动搜索的概念，但它影响长prompt或分块prefill时输出是否一致。若后续文档能把N-exact、128-row边界和可能的near-tie输出差异解释清楚，lithos-metal才更容易被非内核开发者采用。

芯片代际差异还要持续维护。PR #35说Apple10 code unchanged，M5 Max kernel tier unchanged；#39又写到M3 Ultra和20-core M4 Pro measured choices。对读者来说，真正有用的不是“支持Apple silicon”这个大词，而是自己的芯片代际是否落在已测路径里，未覆盖shape会回退到什么默认行为。

因此，今天这条应保留在开源生态深度观察，避免上升为行业结论。它给出的信号足够具体：本地推理的瓶颈正在被一层层拆到kernel、attention、FP8 decode和serve配置。它缺的证据也足够明确：正式版本、独立benchmark、复现实验和用户侧稳定性报告。