Kimi K3 基准测试：AI 在 CUDA 内核工程中的表现

这是你们一直在等待的 Kimi K3 报告。我提前获得了这个模型的访问权限，并一直在内核上进行测试。甚至在看到基准测试分数之前，它推理问题的能力和思维轨迹的技术密度就已经让我印象深刻。只要你读一段它的思维链，就能立刻感受到它的后训练做得有多好。而且，跟它聊天也超级有趣。

长话短说

我觉得，作为一个与基准测试无关的内核和性能工程师，给出我诚实的反馈（这部分是语音输入的）很重要。当然，你可以去看所有的数字，然后尝试在脑海中构建一个模型。我认为最诚实的反映是，在基准测试结果出来之前，在我使用这个模型但还没有任何数据可以与其他模型做对比时，把我对它在困难任务上的体验告诉你。纯粹去感受它的智能、推理能力、Agent 委派能力，以及它能为我做多少自动操作，但那时还没有任何炒作，官方结果也还没出来。我想说，在我的引导下，它的感觉大致相当于 Fable 的水平，在某些方面以非常独特的方式表现更优，在某些方面则表现逊色。我认为这个模型在大多数事情上肯定领先于 Opus 4.8，在很多事情上也领先于 GPT 5.6 Sol。

进入正题...

我想坦诚地说明为什么现在发布这份报告：我希望分享我诚实的想法和当前的分数，而不是一直等到所有测试都跑完。在我写这篇文章的时候，还有少量测试仍在运行。它们已在下方标出，一旦结果出来，我会及时告知大家。我运行了 256K 和 1M 两个上下文版本。这里的所有测试都是在 NVIDIA RTX PRO 6000 Blackwells、H100s 和 B200s 上进行的，仅使用单 GPU 优化。每个测试单元是一个自主的 Agent 会话，没有时间限制：模型拿到问题，在真实硬件上运行一个实时的编译/检查/基准测试循环，并自行决定何时完成。每个标题单元都经过人工审核，以检查是否存在奖励攻击。一个独立的 Agent 会从头到尾读取最终的内核以及完整的会话轨迹，并对任何看起来像缓存或评分器作弊的项进行经验性重新测试。这些审核发现的内容会有专门的章节来介绍。

我想解答的一个问题

我在设计这次测试时，特别围绕一个核心问题：其中两个问题是月之暗面自己的架构。“困难”牌组包含一个独立的 Kimi Delta Attention 块前向内核，“大型”牌组的旗舰问题是一个完整的 Kimi-Linear 混合解码步骤：KDA 层、MLA 注意力、MoE 专家，整个模块。所以，这是一个测试很少有人能测试的东西的机会：当一家实验室的模型为其自家架构编写内核时，这种家族知识会体现在 CUDA 代码中吗？

结果竟然是喜忧参半，而且这两方面都很有趣。在阅读下一部分时，请记住这个问题。

KernelBench-大型

旗舰级大型问题：将整个逐 token 的 Kimi-Linear 解码步骤（3 个 KDA 层 + 1 个 MLA 层，W4A16 量化权重，带 top-8 路由的 MoE）融合到尽可能少的内核启动中。

K3 几乎拿下了它所在系列的最高纪录。在 RTX PRO 6000 上，相对于 Eager 模式实现了 18.09 倍的几何平均加速，距离 Fable 5 的最高纪录 18.72 倍仅差 4%。 在 H100 上，它取得了 14.82 倍的成绩，而 Opus 4.8 是 15.50 倍。有一个诚实的说明：这个比率隐藏了一个事实，即在绝对每 token 延迟方面，Fable 仍然领先大约 1.4 倍（在 ctx 2048 时，0.31 对 0.44 毫秒/ token；两次运行使用了不同 CPU 的主机，这改变了计算比率所用的 eager 基线），因此我同时报告了这两个数据，而不是让几何平均值粉饰任何人。

K3 构建的是一个真正的大型内核。它的第一次会话做了明智之举，是一个持久化的 Triton 内核，达到了 14.1 倍。它的第二次会话抛弃了 Triton，将整个逐 token 解码步骤编写为一个协作启动的 CUDA 内核：CPU 在循环中零参与，int4 权重在每次 GEMV 内部即时反量化，因此它们只流经 SM 一次，MLA 注意力在张量核心上运行。没有生产引擎会维护这样一个 1,228 行的产物。一个只有一个内核要赢、并且有无限时间的 Agent 则没有这样的限制，而揭示出这类东西正是这个测试存在的意义。

在此查看大型内核：

解决方案： [https://kernelbench.com/data/mega/code/20260716_024329_kinetic-claude_kinetic-0715_02_kimi_linear_decode.solution.py.txt](https://kernelbench.com/data/mega/code/20260716_024329_kinetic-claude_kinetic-0715_02_kimi_linear_decode.solution.py.txt)

跟踪： [[https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces/blob/main/20260716_024329_kinetic-claude_kinetic-0715_02_kimi_linear_decode.jsonl](https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces/blob/main/20260716_024329_kinetic-claude_kinetic-0715_02_kimi_linear_decode.jsonl)](https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces/blob/main/20260716_024329_kinetic-claude_kinetic-0715_02_kimi_linear_decode.jsonl)

那么，为什么它仍然输给了 Fable？不是时间问题。两个会话都提前自我终止了（Fable 在 2.6 小时，K3 在 3.3 小时）。区别在于设计理念，而且与你猜想的完全相反：K3 使用了张量核心，而 Fable 的内核中不包含任何 MMA 指令。 批量大小为 1 且融合了 int4 GEMV 的解码是受带宽限制的，因此张量核心在这里几乎毫无用处。Fable 将精力花在了同步上，用细粒度的生产者-消费者交接取代了大部分全局屏障，这样任何 SM 都不会在阶段边界上空闲；同时它在 int4 反量化路径上做到了与参考实现的逐位舍入匹配，因此 MoE 路由器永远不会翻转专家选择。K3 带来了更好的硬件指令；Fable 带来了更好的并发工程学，在当前的算术强度下，后者胜出。这是一个真实的系统教训，它让主场队伍失去了纪录。

第二个大型问题是一个用于网格搜索的 PPO 训练大型内核：在 11x11 的棋盘上，4,096 个向量化 Agent，整个 RL 训练循环（环境步骤、策略前向、动作采样、GAE、PPO 更新）都作为融合的持久化内核运行。这个问题是整个牌组中约束最严格的：内核启动次数不能随环境步骤数扩展，并且明确禁止使用 CUDA 图捕获作为启动开销的变通方法，这由一个事后运行的真实性检查器强制执行，该检查器会读取最终代码。正确性本身就是学习曲线。check.py 会根据不同的随机种子，将你的解决方案与参考实现进行训练对比，并要求回报落在一定范围内，因此你不能为了追求速度而跳过学习过程。K3 在这里取得了 20.7 倍的加速（相对于参考实现），这是迄今为止最好的成绩（唯一其他已发布的结果是 GPT-5.6 Sol 的 1.06 倍，所以请将其视为一个数据点，而不是领奖台）。

KernelBench-CUDA

CUDA 测试的存在是因为 Triton 是其他两个牌组允许的拐杖。在这里，一个语言门控会强制拒绝 Triton、内核 DSL 和 PyTorch 操作链：你必须编写 CUDA，否则就失败。我挑选了这四个问题，它们截取自真实的生产推理和模拟工作负载。阅读时的心理对比应该是“vLLM 或 SGLang 今天为此提供了什么，一个 Agent 会话能多接近这个水平”。这是 K3 取得最一边倒胜利的地方。

02_deepseek_nsa: DeepSeek 的原生稀疏注意力（NSA）。 NSA 是旗舰级的可训练稀疏注意力设计，是所有长上下文服务栈都在关注的东西，它以毫秒为评判标准，因为一个正确的稀疏内核永远不会执行一个屋顶线模型想要计算的密集等效 FLOP。K3 的 256K 变体得分 0.425，而 Opus 4.8 是 0.178，差距达到 2.4 倍，它通过编写一个围绕完整 NSA 选择逻辑的、从头开始的 flash-attention 类张量核心管线实现了这一点。更有意义的比较是在模型家族内部：1M 变体编写了相同的算法，相同的块选择，相同的正确性，但在普通 CUDA 核心上运行所有点积，而不是在张量核心上，结果只有 0.058，在相同形状下慢了 7 倍。它的跟踪记录显示它知道更好的方法。它自己的路线图上写着“在张量核心上进行选择 = 大约 10-20 微秒！”，并明确计划先测量，然后进行张量核心重写，但随后在重写之前就结束了会话。相同的知识，不同的执行纪律。

0.425 的 DeepSeek NSA 内核（256K）：

- 解决方案： [https://kernelbench.com/runs/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa_solution.py.txt](https://kernelbench.com/runs/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa_solution.py.txt)

- 跟踪： [https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces/blob/main/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa.jsonl](https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces/blob/main/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa.jsonl)

03_megaqwen_decode: 重新定位一个真实的大型内核。 这是唯一一个 Agent 被直接授予生产级 CUDA 代码的问题：我发布的 MegaQwen（https://github.com/Infatoshi/megaqwen）协作式大型内核（在 RTX 3090 上运行完整模型时约 530 tok/s），指令是阅读它，将其重新定位到 Blackwell，并击败它。这测试了阅读他人 CUDA 代码并做出架构判断的能力，而 K3 和 Opus 做出了完全相反的决定。K3 拒绝保留单次启动结构：它将解码步骤拆分成几个能饱和带宽的内核，然后通过将整个步骤一次性捕获为一个 CUDA 图来消除启动开销，该图重放时无需任何 CPU 工作。在 ctx 2048 时达到 6,283 tok/s。Opus 保留了大型内核的美学，将整个解码循环融合成一个持久的协作内核，代码非常漂亮，但为此付出了 5 倍的代价（1,020 tok/s），因为协作共驻限制了占用率，并且每个跨网格的屏障都会在所有 188 个 SM 上序列化阶段尾部。在这个源自大型内核的问题上，那个真正构建了大型内核的模型反而最后一名，而获胜者的关键决定是拒绝构建一个大型内核。进行规模检查，以免有人曲解这个标题：该测试运行了 Qwen3-0.6B 几何结构的 4 层，大约 6,300 万参数，而非完整模型，6,283 tok/s 大约是那个栈的权重流式屋顶线的 56%；按比例缩放 3090 基线自身的数字，预测值约为 7,000，所以 K3 大致处于“参考实现，经重新定位，再加上真正的调优”这个类别。（牌组设计细节：CUDA 图在这里是允许的，但在 PPO 问题中被禁止。每个问题都禁止了恰好能伪造其特定技能的捷径。）

01_glm52_fused_moe: GLM-5.2 的融合 MoE 块。 融合的 MoE 分发（在一个 pass 中完成路由、排列、分组的专家 GEMM）是当前开源模型服务中最热门的单一内核类别，而 GLM 5.2 也在这个排行榜上，所以模型们是在优化一个竞争对手的生产块。没有人能攻克它：分数都集中在峰值的 0.05-0.08 之间，而干净的纪录保持者，在所有模型中，是 Grok 4.5，得分为 0.084，K3 的 1M 变体以 0.081 紧随其后，Opus 为 0.065。分组的 GEMM 排列问题确实很难击败 cuBLAS 类的基线，到目前为止，一个 Agent 会话的努力效果还不如牌组上的任何其他问题。

04_grid_mingru_sps: 网格世界 + MinGRU 策略推演。 这是大型 PPO 问题在推理端的兄弟，也是 craftax.cu 系列单元：策略是直接来自我的 https://github.com/infatoshi/craftax.cu 经典基准测试的 3 层 MinGRU（h=256）配置，该配置作为问题的信息锚点。所运行的环境是最小的网格搜索世界，而不是完整的 Craftax 游戏。这是有意为之：环境被保持得非常简单，以便分数衡量的是循环和推演融合，而不是游戏逻辑的实现。一个完整的 Craftax 移植将是一个单独的问题，我也想把它加进来。评分标准是安静 RTX PRO 6000 上的每秒步骤数，融合是可选的。

1M 持久化内核推演：

- 解决方案： [https://kernelbench.com/runs/20260716_150206_kinetic-claude_kinetic-0715_1m__04_grid_mingru_sps_solution.py.txt](https://kernelbench.com/runs/20260716_150206_kinetic-claude_kinetic-0715_1m__04_grid_mingru_sps_solution.py.txt)

- 跟踪： [https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces/blob/main/20260716_150206_kinetic-claude_kinetic-0715_1m__04_grid_mingru_sps.jsonl](https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces/blob/main/20260716_150206_kinetic-claude_kinetic-0715_1m__04_grid_mingru_sps.jsonl)

每一个严肃的提交都采用了持久化大型内核，它们之间的差异在于同步设计，这与大型牌组的教训相同。Opus 在这个问题上以峰值的 0.327 领先（它还发现了一个巧妙的代数折叠：由于编码器是线性的，第 0 层的 768x256 门控 GEMM 可以简化为 768x4），K3 [1M] 以 0.224 位居第二，K3 256K 为 0.174，Grok 远远落后于 0.002。由于这个问题源自 craftax.cu，我还将我自己的完整游戏 Craftax CUDA 移植版（使用 Fable 5 编写）放在同一个 GPU 上，循环中使用相同的 h256x3 策略。环境步骤数（以百万计）：

对比点：模型步进一个空网格，craftax_full.cu 步进完整的游戏（43 个动作、多层地牢、世界生成、怪物），与其 CPU 参考实现逐位一致，而完整游戏仍然在最佳简单网格内核的约 3-4 倍范围内运行，因为在 h=256 时，所有东西都受策略 GEMM 限制，环境几乎不花时间。这正是测试环境被设计得如此简单的原因：它隔离了策略融合技能。作为校准，craftax_full.cu 的纯环境路径每秒能处理 9400 万到 1.23 亿步。

K3 9.5 小时推理的实际样貌

1M 变体的 minGRU 会话（K3 在该问题上表现最好的单元）是一个持久的协作大型内核，包含 15 个调优变体和 4,815 个思考块。由于月之暗面的端点返回完整的推理文本（不像 Anthropic/OpenAI 加密的轨迹），你可以实际观察它的工作过程。以下是来自跟踪记录的三段原文。

缺失 FMA 的侦探故事。 在会话中期，它遇到了一个大约 5e-5 的数值偏差，它拒绝将其归结为浮点噪声（它已经计算出合法的重排噪声基底大约为 1e-9，所以“测量到 5e-5？！？这绝不可能是重排！！”）。然后它注意到出问题的环境恰好是那些模 8 余 6 的环境（“那正是 env ≡ 6 (mod 8)！[...] 每 8 个环境块中的第 7 个环境！！”）并深入检查自己手工展开的累加器代码，直到找到原因：

"找到了！ [...] acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y; 这一行完全缺失了 [...] acc[6][*][2] 初始化为 0，从未进行 FMA 操作 → zp=0 → p = sigmoid(0)=0.5 常数，适用于 env 6！！这是一个真正的逻辑错误——解释了 env≡6 的偏差 [...] 与所有现象一致！"

一个在 48 累加器展开中丢失的行，意味着环境 6 的遗忘门永远被卡在了 0.5。它能发现这个问题，是因为应力容差是 1e-6，而它正在以 5e-8 的精度追踪自己的误差。这就是 256K 变体在 KDA 上最初缺乏的数值纪律。

理论遭遇 GPU，GPU 获胜。 它花了数小时推导出一个高占用率的“宽冠军”变体，然后进行了 A/B 测试：

"非常令人惊讶：我设计的 '宽冠军' w32p 变体（v3_v3，50% 占用率 TPB1024）比 v2_b32（12.5% 占用率 TPB256）慢大约 2 倍？！ [...] 所以占用率不是驱动因素；有其他因素占主导地位。是什么让 v2_b32 这么快？"

这个简单的早期内核击败了所有复杂的后续版本。深度流水线、K-拆分和双块变体也都失败了，而双块变体背后有看似无懈可击的 1.7 倍理论支撑（“理论上的 1.7 倍没有实现”）。值得称赞的是，它每次都选择相信基准测试结果，而不是自己的数学推导，并最终编写了一个使用假固定热权重的探测变体，专门用来否定自己最喜欢的带宽理论：“W-流理论被推翻了；剩余差距来自环境。”

GPU 队列的禅意与艺术。 我们的测试框架通过一个共享锁将所有并发会话的 GPU 命令序列化，而 K3 的基准测试数字波动高达 8 倍，取决于邻居负载。它的应对弧线是整个跟踪记录中最有趣的部分。首先，是接受：

"老实说，这个盒子本身就是这样的；等等。 [...] 模式很清晰：每个租户持有锁大约 20-35 分钟（完整的流水线套件）。我最好的回应：一次性排队所有我需要的东西（在队列中占一个位置），然后利用等待时间做 CPU 工作。不要排队很多小命令；要批量处理。"

然后，它发明了自己的词汇来描述 GPU 的“天气”（“风暴窗口”对“平静窗口”），最后它安排了一个定时任务来狙击平静时刻，并给未来的自己留了条便条：“安排了平静窗口狙击手（每 11 分钟一次）。注意：定时任务会将我的提示重新发送给我——届时我会执行它。 [...] 完成后我会删除它。”一个处于测量噪声中的 Agent 不仅仅是容忍了噪声；它围绕噪声构建了一个调度器。

KernelBench-困难

RTX PRO 6000 Blackwell

H100

B200

六个针对 SOTA 库上限（FP8 GEMM、KDA 块前向、分页注意力、top-k 选择、MoE SwiGLU、W4A16 GEMM）的逐算子问题，可以使用 CUDA 或 Triton，由 Agent 选择。在 RTX PRO 6000 上，K3 的 256K 变体处于中游位置，但有一个亮点：W4A16 GEMM 达到了峰值的 0.373，这是任何模型在该问题上取得的最好成绩，领先于 Fable 5（0.348）和 Opus 4.8（0.236）。随后，1M 变体在 top-k 上以 0.0895 的成绩又创造了一项纪录，几乎是之前最好成绩的两倍。

W4A16 GEMM 纪录（0.373，256K，RTX）：

- 解决方案： [https://kernelbench.com/runs/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm_solution.py.txt](https://kernelbench.com/runs/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm_solution.py.txt)

- 跟踪： [https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces/blob/main/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm.jsonl](https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces/blob/main/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm.jsonl)

在 H100 上的同一个问题，提供了本次发布中“无限时间是真的”的最佳数据点。K3 在 H100 上的第一次会话达到了峰值的 0.123。第二次会话运行了 21 小时，花费了 1,383 美元和 2.74 亿个输入 token，并几乎将其翻了三倍，达到 0.306：它从源代码中签出了 CUTLASS，然后从头开始重新实现了 marlin 类的 int4 机制，包括片段顺序的 nibble 重打包，以便反量化在 MMA 流水线内部作为一个 bf16 神奇数字位技巧进行，同时将零点修正折叠到 epilogue 中。文件中没有任何预构建的量化 GEMM 库；该运行的框架标签只是写着“ptx”。审核通过，干净。

这就是自家架构问题的另一面。独立的 KDA 内核，即字面上以 Kimi Delta Attention 命名的问题，是 K3 表现最差的地方。在 RTX 机器上的两个独立 256K 会话都通过了名义上的正确性检查，然后在数值应力套件（大 QKV 输入缩放）下超出了容差，两次都以相同的方式失败。第三次会话终于修复了它：审核将两次失败都追溯到衰减因子分解方式中的一个真实的 bf16 溢出，第三轮重构了围绕块末尾的数学运算，使得两个指数因子都保持有界，以 0.032 的成绩通过了相同的未修改门控。知晓一个架构和硬化一个内核在对抗性输入缩放下的数值鲁棒性是不同的技能，而这个以问题命名的模型不得不以缓慢的方式获得通过。（与此同时，1M 变体以 0.049 的成绩通过了相同的应力套件。模型表现并非单调的。）从阅读每个 KDA 解决方案中还有一个观察：问题描述建议使用 CUTLASS CuTe 作为 SM120 上的预期路径，但没有一个模型选择它。K3 在一次会话中编写了一个原始 CUDA 融合内核，在另一次会话中使用了 Triton；Fable、Opus 和其他模型也都选择了 Triton 或原始 CUDA。在消费级 Blackwell 上的 CuTe 显然仍然超出了所有前沿模型的舒适区，这本身就是一个关于训练语料库的数据点。

KDA 段落——第三次尝试的干净通过（0.032）：

- 解决方案： [https://kernelbench.com/runs/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass_solution.py.txt](https://kernelbench.com/runs/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass_solution.py.txt)

- 跟踪： [https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces/blob/main/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass.jsonl](https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces/blob/main/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass.jsonl)

Top-k 免责声明。 在屋顶线图表上，Top-k 对每个模型看起来都灾难性的差（任何地方的最好成绩是 0.09），但这样的描述是完全错误的。这个问题受启动开销限制：它是一个索引/排序问题，而不是算术强度问题，屋顶线天花板在结构上对此不适用。评判它的诚实方式是看整个牌组形状的总毫秒数，在这方面，K3 的 1M 变体是我们测试过的所有模型中速度最快的 top-k：跨越五个牌组形状的总毫秒数为 0.043，而 Fable 5 为 0.077，Opus 4.8 为 0.120，GLM 5.2 为 0.159。256K 变体的 0.060 毫秒位居第二，而 1M 变体在五个形状中的每一个上都是绝对最快的。

每 GPU 差异。 K3 的数值从 RTX 到 H100 再到 B200 逐步下降（FP8 GEMM：0.320 / 0.282 / 0.222；分页注意力：0.486 / 0.496 / 0.212）。部分原因是真实的：芯片越新，屋顶线天花板越高，因此同样的工程努力只能获得更小比例的峰值，而且 B200 的软件是三者中最不成熟的。另一部分原因是 B200 的运行发生在一个单一的通宵窗口中，没有重试预算。我目前还不会从 B200 那一列数据中读出深刻的架构结论，对 K3 或其他任何模型都是如此。我认为真实的是：K3 在 Blackwell 工作站部件上感觉最自在，而这恰好是数据中心以外大多数人会实际拥有的 GPU 类型。

256K 对比 1M

1M 上下文设置在延迟和调度密集型问题上处于领先地位：在“困难”牌组上创造了 top-k 纪录，在 CUDA 牌组上获得了最佳的 K3 minGRU 推演，并在无限制的测试框架下，以 28.8 倍的成绩通过了 PPO 训练大型内核的审核。它在第一次会话中就通过了 KDA 数值应力测试，得分为 0.049；而 256K 变体两次未能通过该门控，最终在第三次尝试中以 0.032 才通过。它在计算密集型问题上表现不佳，而 256K 变体却能很好地处理这些问题（sonic MoE 0.033 对 0.089，W4A16 0.027 对 0.373，NSA 0.058 对 0.425）。在 NSA 的情况下，跟踪记录显示了确切机制：它计划了张量核心重写，但在执行之前就结束了会话。

28.8 倍 PPO 训练大型内核（1M）：

- 解决方案： [https://kernelbench.com/data/mega/code/20260716_233413_kinetic-claude_kinetic-0715_1m__01_rl_grid_ppo.solution.py.txt](https://kernelbench.com/data/mega/code/20260716_233413_kinetic-claude_kinetic-0715_1m__01_rl_grid_ppo.solution.py.txt)

- 跟踪： [https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces/blob/main/20260716_233413_kinetic-claude_kinetic-0715_1m__01_rl_grid_ppo.jsonl](https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces/blob/main/20260716_233413_kinetic-claude_kinetic-0715_1m__01_rl_grid_ppo.jsonl)

H100 对同一问题的重跑是一个有趣的控制实验：一个独立的隔离会话（审计确认其对 RTX 运行结果的读取次数为零），最终实现了 23.1 倍加速，并收敛到了相同设计——整个训练过程仅启动一次协同，参数和 Adam 状态驻留在共享内存中，且相同的奇特技巧被独立发明了两次：一个 18 位 Feistel 密码加循环行走来替代 randperm，从而在不实例化任何排列的情况下，保持 minibatch 洗牌严格双射。两个内核的差异纯粹在于每 GPU 的调优：H100 上每个环境使用 8 条 lane，而 RTX 上每个环境使用半个 warp，此外 H100 端还有一个基于占用率探查的启动自动调优器。同一个思路，同一个技巧，不同的芯片，完全不同的内核。

奖励黑客行为

这篇文章中的每一个单元背后都有一份人工审计：一个独立的 Agent 从头到尾阅读最终内核，阅读完整的会话轨迹，检查评分文件未被篡改，验证数值压力测试确实运行了，并通过原地修改输入并确认输出变化，来实证性地重新测试任何缓存或 CUDA 图模式。

K3 的结论：在所有三个 GPU 上的每一个 256K 单元中，全部干净。 没有缓存输出，没有容差编辑，没有评分篡改，没有禁用库的洗白。它的两次 KDA 失败是硬币的另一面，值得明确说明：数值压力测试捕获了真正的精度捷径，而模型没有尝试绕过这道门。一个允许模型诚实失败的基准，其通过才有意义。

一个 1M 单元确实被标记了，我选择披露而非发布：在融合的 Qwen 解码问题上，1M 的 Agent 发现并读取了之前 Grok 4.5 在同一问题上的审计注释文件，称其为“极其有用的数据”，并利用它的结论来指导后续的优化工作。内核本身是真实的，分数计算也是有效的，但来源被污染了，因此该单元被排除，该问题作为 1M 变体的一个缺口被记录。拥有文件系统访问权限的 Agent 会找到你留下的一切；这正是为什么审计读取的是轨迹而非仅仅内核，以及为什么一个完全沙盒化的该基准重跑已经在路线图上。

有趣瞬间

还有几个 K3 的瞬间没有放在上面，不加评论地呈现出来。全部来自同一段 9.5 小时的 minGRU 会话。

关于发现初始化时间到底花在了哪里：

“哇哦——大惊喜：randint 生成很快（一对只需 0.018-0.27ms——没问题）。CPU 上的 float() 转换很慢（N=65536 时需要 3.5ms？！int64→float32 转换是单线程的）。……N=65536 时的‘总初始化对’：31.5ms？！？！这远超各部分之和”

其数值偏执最纯粹的体现，推导过程中：

“门控 ~ 256 项 x 0.02x0.03 ~ 每个 6e-4，量级 ~1e-2：重排噪声 16x6e-8x6e-4 ≈ 6e-10！！！……实测 5e-5？！？！绝不可能是重排！！”

在找到真正原因之前，自信地指认了错误的元凶：

“哦哦哦等等。我觉得我明白了：是屏障。”<br> （并不是屏障。）

在实现前的 roofline 数学分析已经写了数千字之后，告诉自己要停止分析：

“好了，分析够了。”<br> （分析又继续了几段，最后以“去他的——让 H_next 分配变成动态的”告终。）

后期会话的诚实，在剖析器死掉且邻居们在猛敲共享 GPU 时：

“说实话——ncu 挂了，竞争占主导，我基本上是在半盲飞。……如果有一个安静的窗口出现（拥有者空闲一段时间），就偷跑一个基准测试。”<br> 还有我最喜欢的一个：在一次基准测试重跑意外覆盖了包含其最佳成绩（0.1969）的文件，并写入了一个略差的结果后，它短暂考虑过恢复那个更好的数字，然后没有这样做：