@elliotarledge：Claude Fable 5 [max] 在 KernelBench-Hard 上的表现。给我印象最深的核心是 B200 fp8 GEMM：它手动编写了原始的 SM10…

Claude Fable 5 [max] 在 KernelBench-Hard 上的表现。

最让我印象深刻的内核是一个B200 fp8 GEMM：它手写了原始的 SM100 tcgen05 PTX，没有使用 CUTLASS 或 cuBLASLt。

它使用 2-CTA 集群 tcgen05 mma 写入 TMEM 累加器，通过 6 级深度的 mbarrier 流水线进行 TMA 3D 加载，并使用一个经过 swizzle 处理的收尾阶段，将输出缩放直接融合到 TMA 存储中。它在 B200 fp8 排行榜上领先：

Fable 5 0.254（手写 tcgen05） GLM-5.2 0.200 Opus 4.8 0.196 GPT-5.5 0.146

这个 0.254 是 6 种形状的平均值，被一个受内存带宽限制的瘦解码形状拖累（约峰值的 3%，张量核心对此无能为力）。计算受限的 GEMM 形状达到了 B200 fp8 峰值的 44-59%。

它实际上将 2 小时 44 分钟会话的后半部分完全用于手工构建 tcgen05 路径，最终结果与其自身调优的 Triton 大致相当（约 0.283 vs 约 0.281）。评分数字就是手写的 PTX（实际部署的内核对每种形状都使用此 PTX，Triton 只是编译失败时的回退方案），它仅仅勉强击败了它正在较劲的回退方案，而不是彻底碾压：多用了约 9 万 token，收益不到 1%。同时，它达到了自己编写用于自查的 CUTLASS 参考实现的约 85-90% 性能。

在 RTX PRO 6000 上，它在两个奖励真实张量核心计算的测试项中排名第一：W4A16 GEMM 达到理论峰值的 0.348，MoE SwiGLU 达到 0.108，均为该榜单最佳，领先于 GLM-5.2 / Opus 4.8 / GPT-5.5。其 RTX fp8 测试项为空白，因速率限制未能在截止前运行。重新扫描即将进行。

每个通过的测试项都经过了奖励破解审计（解决方案 + 追踪）：没有禁止的操作，没有模板编辑，没有存档污染，数值压力测试通过与未修改的评分器一致。

感谢 @NVIDIAAI 提供用于基准测试的计算资源 :)

请参阅下面的链接。

这看起来像一个经过后训练的模型，旨在花费精力提升性能，而不是最小化 token 数。

一个追求节省 token 的优化器会提交调优后的 Triton（约 0.28）并就此收手，这是达到该分数所需代码最少的路径。而 Fable 却花费了约 9 万 token 和一个小时手写原始 tcgen05 PTX，只为不到 1% 的提升。从投资回报率角度看是负面的，但这正是你希望看到的行为——当奖励是“触及硬件的真正原语”（张量核心、TMA、TMEM）而不是满足于任何能免费带来 80% 性能的 DSL 时。

旧模型默认采取相反的策略：最快的内核，最少的代码，通常是 Triton 或 cute-dsl。阅读追踪记录，Fable 的行为就像是针对内核性能天花板进行了优化，而愿意降级到 PTX 只是副作用。如果是这样：很好。这正是你期望从一个写内核的模型中看到的行为，即使它并不总能带来回报。

不幸的是，我没有足够的信用额度来重新运行测试，以观察它是否会采取不同的方法，或者在不花费 9 万 token 换取不到 1% 收益的情况下变得更快。但遗憾的是，我目前没有足够的资金或速率限制重置来这样做。很高兴与任何人合作，或寻找愿意赞助以保持该基准测试尽可能多运行次数并确保所有运行安全的赞助商，乐意找到对大家都有利的方式！

追踪：https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces… 排行榜：http://kernelbench.com/hard B200 fp8 内核：http://kernelbench.com/code?f=/runs/20260702_090059_claude_claude-fable-5_01_fp8_gemm_solution.py.txt…

Claude Fable 5 [max] 编写了提交给 KernelBench-Mega 的第一个真正意义上的（也是最快的）megakernel。

它是在以下环境下测试的：面向 RTX PRO 6000 Blackwell 的 Kimi-Linear W4A16 批量-1 解码。此前所有模型都是通过一个多内核 Triton 流水线“获胜”的，但该流水线无法通过我们的单融合内核真实性验证。

Opus 4.8 14.4x GLM-5.2 11.1x GPT-5.5 4.3x Sonnet 5 4.0x

Fable 实现了 18.7x 的加速比，并且 torch.profiler 显示每个解码 token 恰好只启动一个协作内核。Int4 反量化（半字节在寄存器中解包，从未实体化）、卷积+SiLU、KDA 门控增量状态、MLA 吸收潜在注意力（含在线 Softmax）、MoE 路由器 + 前 8 个专家、RMSNorms，甚至 KV 缓存追加，全部在一次启动内完成，由 14 个网格屏障分阶段执行。我们在审计过程中覆盖了它的输入缓冲区，以证明它是在实时数据上重新计算的。结果确实如此。

这种优势随着上下文长度的增加而扩大。在 2k 上下文时为 17.8x，8k 时为 18.9x，16k 时为 19.5x。更长的上下文意味着更大的 KV 缓存和每个 token 更多的注意力计算量，这通常是解码内核的瓶颈。将所有内容保持在一个启动中会摊薄固定的屏障开销，并且 int4 GEMV 仍然受带宽限制，因此与参考方案的差距只会扩大而不会缩小。

它将会话的 64% 时间用于静默地测量基线、对网格屏障进行微基准测试、推导出约 29x 字节/ token 的理论峰值，然后一次性编写了整个内核，第一次基准测试就达到了 14.4x。最后的一小时则用于删除屏障并使 int4 反量化开销归零（一个 LOP3 + HSUB2/HMUL2）。它尝试了一次回归（更细粒度的 split-K），经过测量后直接回退，而不是试图合理化。

http://kernelbench.com/mega