夜雨聆风一觉醒来，代码已经换了模样
2026年7月16日深夜，Moonshot AI的服务器集群里，Kimi K3正在做一件前所未有的事，它坐在一个沙箱环境中，读着自己训练管线里那段跑得最慢的GPU内核代码，皱了皱眉，然后开始动手改。
全程没有人类工程师在旁边指点或帮它敲nvidia-smi。它自己跑profiler、查看瓶颈、提出方案、编译、测延迟、检查数值精度；发现不对，推翻，再来
这个循环，它跑了整整15个小时
等工程师们第二天早上端着咖啡打开监控面板，屏幕上的数字让人倒吸一口凉气：AttnRes算子的前向加反向耗时，从283.6毫秒，被砍到了114.4毫秒。
快了将近60%而且，数值完全没漂
▲ 官方发布的加速曲线图：横轴是有效运行小时，纵轴是相对基线的加速百分比。红线Kimi K3（+59.7%）与蓝线Claude Fable-5（+57.1%）终点接近，但K3的阶梯式抬升明显更陡，每一轮迭代的提升更快。
一个内核里能"抠"出169毫秒，分量有多重？
先给不做GPU编程的朋友翻译一下这件事的分量。
你用ChatGPT、用Kimi、用任何大模型聊天，后台由Python调度，吃满GPU算力的是一小段一小段叫"kernel"的程序。它们为矩阵乘法、注意力计算、归一化等计算提供高度特化的实现，直接跑在GPU的数千个计算核心上。
同样一道数学题，写得烂的kernel可能让显存带宽浪费一大半，寄存器和共享内存用不满；写得好的kernel，能把同一块芯片的性能"榨"到接近物理极限。业内最著名的例子就是FlashAttention，通过分块计算和重计算的巧妙设计，在不改变数学含义的前提下，显著降低注意力算子的显存开销并提高速度。缺少这类优化，聊天模型的训练成本会高得多。
过去，这种活只有极少数"内核英雄"能干，手写CUDA C++或Triton代码，一行一行抠内存访问模式，一遍一遍跑profiler，一个通宵一个通宵地熬。整个行业围绕这群人形成了一种几乎是手工作坊式的英雄文化。
而现在，K3用15小时，在一个生产规模的算子上，做完了一位资深内核工程师可能需要数天甚至数周才能完成的优化循环。
评论区里，有人用一条短评概括了这种分量：
"169.2ms is a lot to find in one kernel over 15 hours."（在一个内核里用15小时找到169.2毫秒的优化空间，这个量级相当可观。）
▲ 社区开发者对优化幅度的直觉反应，行家才知道，在一个已经被Triton实现过的成熟算子里再抠出这么多时间，有多不容易。
"两阶段算法"与"内核融合"：K3到底改了什么？
官方给出的技术描述很简短，但信息量很大。
K3面对的起点是一个生产规模的FLA Triton AttnRes实现，96层网络、模型维度8192、序列长度8192，对应K3训练时实际运行的算子规格。
任务要求只有一条：在不改变数值结果的前提下，尽可能提高训练侧速度。
这个"不改变数值结果"的约束，是整件事最硬核的地方。内核优化领域有句老话：想变快太容易了，偷偷降个精度就行。但精度漂了，训练可能"静默出错"，loss继续下降也掩盖不了模型已经学歪。守住numerics，是区分"花活"和"真功夫"的分水岭。
K3的解法是设计了一套全新的两阶段内核算法（two-phase kernel algorithm），并且在此基础上做了内核融合（kernel fusion）。用人话说就是：它重新规划了数据在GPU内存层级之间的流动路径，把原本需要"算完→写回显存→再读出来→接着算"的多个步骤，合并成一次连贯操作，大幅减少了中间数据的搬运开销。
而这一切，是在一个闭环agent循环中完成的：读代码→提出改写→编译→真机测延迟→检查数值误差→不满意就回退→再迭代。15小时，不间断
从一个算子到编译器和芯片的"全栈自举"
如果故事到这里就结束，它只是一个"AI写了个快kernel"的新闻。但K3的发布还给出了更深入的系统工程案例。
第二层：从零搭了一个GPU编译器
官方称K3构建了一套叫MiniTriton的紧凑GPU编译器，自带tile级中间表示（基于MLIR）、优化pass、以及PTX代码生成管线。在支持的roofline基准上，性能与OpenAI的Triton和PyTorch的torch.compile持平甚至更好；nanoGPT端到端训练的loss曲线也与参考实现接近，用来验证从DSL前端到运行时的完整管线。
▲ @rohanpaul_ai评论：K3从零搭了GPU编译器，从DSL和编译器pass到PTX代码生成，其Tensor Core路径已可与Triton竞争。
第三层：48小时设计了一颗芯片
在一次约48小时的自主运行中，K3使用开源EDA工具与Nangate 45nm工艺库，为一个基于自身架构的nano模型设计并验证了一颗推理芯片，仿真中100MHz时序收敛，解码吞吐超过8700 tokens/s，面积约4平方毫米，集成百万级标准单元与INT4乘加阵列。
内核→编译器→芯片 Google DeepMind的Paige Bailey看完后发了一条被广泛转发的帖子：
▲ "一个能从DSL前端一路优化到RTL和CUDA运行时的LLM……这简直是疯了。"
更让行业内部人士坐不住的，是官方博客里的一项披露："在K3开发后期，早期版本的K3已经承担了团队大部分的内核优化工作。"
按照官方说法，K3在发布前就已参与改写训练管线的代码，模型由此开始优化支撑自身训练的基础设施。这个递归结构构成了"self-evolving"一词在该案例里的具体含义。
第三方基准：14.82倍，快但不能错
厂商自己的沙箱演示，读者有理由持保留态度。那么换一个独立擂台呢？
斯坦福大学Scaling Intelligence Lab搭建的KernelBench，正是为此而生。规则很简单：给模型一段PyTorch实现，要求它生成CUDA/DSL内核，在真机H100上跑。编译不过？不算数值错了？不算对了但比PyTorch更慢？也不算只有正确且更快，才得分
K3在KernelBench上的表现：生成的CUDA内核相对优化后的PyTorch，达到约14.82倍加速，处于当时榜单前列。
▲ KernelBench排行界面：Kimi K3与Claude Opus 5、Fable 5等模型的对比。
这里的283.6→114.4毫秒与14.82倍来自两套不同的测试：前者是官方AttnRes生产算子的绝对延迟优化，后者是KernelBench公开任务上的相对加速倍数。任务、硬件和基线均有差异；两项结果共同显示，这个模型能写出在真机上通过正确性检查并获得加速的GPU代码。
不要急着欢呼：脚注里的魔鬼
在为AI欢呼之前，有几条清醒的边界值得划出来。
第一， 官方博客自己标注：Fable 5的评测由第三方完成，可能包含fallback机制；多数模型轨迹中可能存在"仍在数值容差内的精度捷径"。演示曲线的每一个刻度，都有脚注
第二， 15小时循环的完整失败轨迹、全部attempt日志、精确的硬件配置，并未完全对外公开到"人人可逐比特复现"的程度。这仍然是厂商主导的演示，而非peer-reviewed的独立复现。
第三， K3本身是一个约2.8万亿参数的稀疏MoE模型（每次激活约104B参数），开放权重虽然承诺在7月27日放出，但Unsloth文档已经给出了冷酷的现实：完整权重需要TB级存储，量化后仍需数百GB。"开放权重"不等于"你的笔记本能跑"
第四， 官方自己也坦承：K3总体体验仍落后于最强闭源模型（点名Claude Fable 5与GPT 5.6 Sol）。它仍是追赶者，只在特定维度展示出惊人的突破。
15小时循环带来的问题
一位社区评论者说得好：比起终点的毫秒数，15小时循环本身才是更值得关注的基准。
▲ 这条评论认为：价值在于模型能在噪声反馈中保持连贯假设、守住数值约束、产出可复现的优化轨迹。
传统的代码生成基准，HumanEval、SWE-bench，衡量的是分钟级的能力：写个函数，修个bug。但内核优化的真实工作流近似科研实验：一次失败的融合可能只在特定batch size下变慢，一次数值漂移可能要跑完整个训练曲线才暴露。 把agent放进长达十几小时的沙箱，要求它自己读profiler、自己回退方案，测试的是一种全新的能力维度，在充满噪声的反馈信号中，维持对目标函数的追踪。
这也引出了一个问题：当AI开始改写训练自己的基础设施，"工具"和"使用工具的人"之间的边界，正在变得前所未有地模糊。
K3没有颠覆世界它的模型整体水平仍在追赶它的芯片只是仿真POC它的编译器还需要更多验证
但在2026年7月的那个夜晚，一个AI在没有人类帮助的情况下，花了15个小时，重新发明了一种让自己跑得更快的方法。
这件事的余震，恐怕才刚刚开始