KernelZero详解：大模型自进化生成高性能算子的机制与实践

写算子这个事，圈子里一直有个共识：它比写普通业务代码难上不止一个量级。你得同时懂算法、懂硬件、懂性能工程，写出来的东西还得能跑、跑得快、数值还得对得上。大模型这两年写通用代码已经能糊弄不少人，但一碰到算子就原形毕露——要么直接编译不过，要么跑通了但慢得没法看，要么给了个正确结果却没想明白为什么慢。核心原因其实不复杂：喂给大模型的高质量算子代码数据，太少了。KernelZero这个项目就是冲着这个痛点去的，核心思路一句话：让大模型自己给自己出题，然后自己去解，解完用验证器打分，把打出来的高分样本回灌训练集，形成一个自我进化的飞轮。这篇文章就把这套机制的细节、落地过程和踩坑经验完整拆一遍，适合正在做算子开发、大模型微调，或者对“自进化训练”感兴趣的团队参考。

1. 为什么大模型写不好算子：问题根源不在模型，在数据

1.1 算子开发的门槛到底高在哪

先对齐一下概念。这里说的“算子”，英文叫Kernel，不是数学里的算子，是深度学习框架里跑在GPU/NPU等加速卡上的那一段计算核心。对于大模型来说，从矩阵乘、Softmax、LayerNorm到Attention、FlashAttention，每一个热点算子的性能，直接决定了整个模型的训练和推理成本。

一个合格的算子开发工程师，日常在干什么？把卷积用tiling拆成能装进共享内存的小块，把访存模式重新排列以命中L2缓存，把循环做unroll和vectorize，在寄存器层面减少bank conflict，还要为不同shape做特化……这些活儿不只是功力问题，还极度依赖对目标硬件手册级别的理解。写一个能“跑通”的算子和写一个“能打”的算子，之间的鸿沟比大多数人想象的宽得多。

1.2 大模型在算子方向上的尴尬表现

如果你让现在主流的大模型直接写一个融合LayerNorm的GPU Kernel，大概率会看到两种结果：一是模型给你一段看起来逻辑自洽的CUDA代码，但编译不过；二是模型直接调用框架自带的layer_norm函数，这从“代码生成”的角度说没错，但从“算子开发”的角度说是在作弊——真正的算子开发是要自己实现并超越库函数的，不是调库。

为什么会这样？我个人的观察是，大模型写算子的能力瓶颈主要卡在三个地方：

• 训练数据稀缺：公开语料里通用代码占了绝大多数，真正精心优化过的算子代码（尤其是带有详细性能调优注释的那类）占比极低。
• 验证信号缺失：通用代码有单元测试可以做正确性验证，但算子还要验证性能。一个跑得慢但算得对的kernel，在普通代码评测体系里会被判为“通过”，在算子场景里就是不及格。
• 硬件多样性太强：同一段算子代码，在一张RTX 4090上表现优秀，换到A100上可能因为shared memory大小不同而性能崩塌，更别说还要适配不同厂商的加速卡。

1.3 高质量数据荒，是自进化的最佳理由

前面三个问题里，第一个问题“数据稀缺”是根源。那能不能靠人工标注或者外包众包来解决？可以，但成本大到不现实。一个精通CUDA和GPU体系结构的工程师，写一个高性能算子按天计价，就算只追求“中等优化水平”，一个算子的标注成本也轻松上千块，而且单靠人力无法覆盖算子的长尾空间——不同shape组合、不同dtype组合、不同硬件组合，这个组合空间是爆炸性的。

所以KernelZero的思路顺势就出来了：既然高质量人工标注数据贵且少，那就让大模型自己生成题目、自己试写方案、用自动化的验证器做筛选。通过的方案就是高质量的监督信号，失败的就丢掉。这个过程和AlphaGo下棋有点类似，本质上是自举（Bootstrapping）：用当前模型能力去产出训练数据，再反过来提升模型自己。这恰好绕开了“先有鸡还是先有蛋”的死循环。

2. KernelZero 的整体设计：一个四阶段的自动化飞轮

2.1 系统组成与工作流

KernelZero不能简单理解为一个模型，它不是一次训练出来的，而是一个完整的迭代式数据生产系统。整个系统分成四个核心模块：挑战生成器（Challenge Generator）、求解器（Solver）、验证器（Verifier）和训练回路（Training Loop）。

我按实际运行流程画一条线：第一轮先由一个初始模型（不需要很强，7B左右的通用代码模型就够起步）扮演“出题老师”，生成一批算子开发题目。求解器拿着这些题目去写kernel代码。每个kernel代码都交给验证器，验证器会做编译、数值正确性校验、性能基准测试三件事，输出一个结构化评分和通过/不通过的结论。通过且高质量的那些样本回灌到训练集，对模型做一轮LoRA微调。微调完的新模型继续出题、解题、验证……如此反复。每迭代一轮，模型在算子上的能力就往上抬一点。

2.2 挑战生成器：“自己出题”的技术内涵

很多人第一反应是：自己出题容易啊，写个提示词让模型生成几个矩阵乘的shape不就行了？实际操作远没有那么简单，挑战生成器是整个系统里技术含量最高的一个环节，因为它必须控制题目质量、控制难度梯度、避免题目的无效重复。

在设计时，我参考了课程学习（Curriculum Learning）的思路。挑战生成器输出的每一道题目，都必须包包含四个维度的约束：

这个设计必须避免两个极端：题目太简单，模型轻松通过，训练数据里全是低质量样本，能力提升有限；题目太难，模型长期无法通过，验证器只能输出大量失败样本，训练信号稀疏，飞轮转不起来。理想的难度区间是让当前模型的通过率保持在30%到60%之间——有一部分能通过的数据用于训练，又有足够高的失败率保持挑战性。

那怎么自动控制难度？做法是把难度作为当前模型能力的函数进行动态映射。每经过一轮验证，系统记录的通过率就是一个基准参考。通过率高于60%，说明出题偏简单，就在生成时机微调shape范围和优化目标，让题目更难一些；通过率低于30%，说明题目偏难，就适当放宽。这个机制很像游戏关卡设计里的动态难度调整，但它的调整对象是题目分布本身。

2.3 验证器：让自动出题的“标准答案”可信

这里的核心悖论是：没有标准答案，怎么验证模型写的kernel对不对？总不能让一个比求解器还强的模型去做裁判吧？实际上算子验证没那么玄学，因为基础的计算逻辑是有严格数学定义的，标准答案可以用朴素实现（哪怕是Python循环）算出来，并不需要高性能。这恰好是验证器最大的优势。

一个完整可用的验证器必须做三件事：

编译验证。模型生成的CUDA或Triton代码能通过编译器编译，语法、类型、kernel启动配置等问题在这一步暴露。对于Triton这类Python嵌入的写法，编译验证还能顺带把自动调优的参数跑一遍，看能不能正常产生可执行文件。

数值验证。把kernel跑出来的结果和参考实现对比，计算最大绝对误差、相对误差。这一层要特别小心dtype差异：fp32的kernel如果和fp64的参考实现比，容差可以给得非常紧。但fp16下的算子数值误差上限天然就大，容差太松又会让一些实际上有bug的代码蒙混过关。我实践下来比较稳的做法是参考实现也切到同样的dtype，再用atol（绝对容差）和rtol（相对容差）双阈值判通过，并对减少求和这种容易丢精度的算子单独放大一档容差。

性能验证。这一步是把正确答案和高效答案区分开的关键。验证器要先跑一个朴素的CPU或者GPU参考实现作为基线，再跑若干次模型生成的kernel，取稳定后的平均耗时，计算加速比。性能不达标的代码，即使数值全对，也不能进入到训练集里。但注意性能验证的环境必须在同一张显卡、同一驱动、同一环境变量下进行，否则对比没有意义。

2.4 数据筛选与训练回填：避免“垃圾进，垃圾出”

每次批量解题之后会产生大量结果，但进训练集的只是很小一部分。我的经验是，通过率在30%左右的情况下，宁愿只保留最靠前的5%-10%样本，也不要全部塞进训练集。因为那些“勉强通过”的样本往往代码质量堪忧，只是在某一组shape和容差下碰巧通过，泛化价值很低。

数据筛选还要做去重。让大模型出题，一个典型的失败模式是它反复生成接近相同的shape组合和算子变体。如果不做去重，三轮迭代之后训练集里50%以上都是亲兄弟数据，模型很快就过拟合。我用了一个简单的启发式去重：把算子类型 + 输入shape + dtype + 优化目标拼接成签名，用hash做唯一性判断，只有签名不同的样本才允许进入训练集。再配合一个多样性启发式，保证同一轮训练集里不同shape区间、不同算子类型的分布相对均匀。

最后是训练回填的比例控制。每次微调时，新筛选出的样本只占训练集的30%左右，剩下的数据从历史样本池里采样补充。这样做的目的是防止灾难性遗忘——模型刚学会的新能力不能以牺牲旧能力为代价。这个比例我调过几次，20%太少，模型学不到东西；50%以上则经常导致上一轮学到的性能优化能力明显退化。30%是一个比较稳妥的起始值。

3. 实操过程：从零搭建一套 KernelZero 流程

3.1 环境选型与工具链

在买卡之前，先把软件栈定下来，这个顺序不要反。

首先确定求解器模型怎么部署。我建议先别上头用超大模型，直接用一个可以本地部署的开源模型作为起点。我用的是Llama-3.1-8B-Instruct，部署用vLLM，因为vLLM的批量推理吞吐量比原生transformers的generate快很多，而且支持连续批处理，跑几百道题的时间从一个小时缩短到十分钟以内。如果团队没有GPU机器的条件，也可以临时用API，但注意出题和解题在自进化过程中会产生大量请求，API费用会是一笔不小的开销。本地部署是成本更可控的长期方案。

然后是算子验证环境。我自己对两套硬件的理解都有涉及，这里只说通用的做法。CUDA环境下，强烈建议用Triton而不是直接上CUDA C来起步。Triton有几个决定性优势：Python直接写，编译粒度更小，错误提示对模型更友好，而且有自动tiling，模型不需要手动管理共享内存和线程同步这些细节。这意味着验证器的编译通过率会显著高于CUDA C，飞轮转起来更顺畅。等到数据积累了足够多、模型学会了常规套路，再引入CUDA C的题目来拔高上限。

3.2 挑战生成器的关键实现

我采用的实现方式是给挑战生成器一个可解析的“出题模板”和一套约束规则文本，让模型在规则范围内自由发挥，输出必须是结构化的JSON，而不是自由文本。结构化的好处是下游验证器可以直接解析，不需要再做一层语义理解，减少出错环节。

一个出题模板的例子大致是这样：

请生成一个LayerNorm类算子开发任务，满足以下约束： - 算子类型：LayerNorm Normalization - 允许的输入shape范围：(batch, seq, hidden) hidden介于2048到16384之间，batch介于2到16之间 - dtype：fp16 - 优化目标：在A100上达到cuDNN对应func性能的60% - 限制条件：禁止调用框架的layer_norm函数 输出格式为JSON： { "op": "layernorm", "input_shape": [batch, seq, hidden], "dtype": "fp16", "target_ratio": 0.6, "constraints": ["no_optimized_library_call"] }

注意出题模板里的“禁止调用框架函数”这个限制，在提示词里重复强调还不够，因为模型很容易“钻空子”，生成一个kernel代码时直接内部调用torch.nn.functional.layer_norm。这种作弊行为在验证器那里是能发现的，但发现后是直接丢样本还是记录为负样本，我后面在问题排查里再展开讲。

此外，挑战生成器还需要维护一个“已出题列表”，把最近几轮的题目签名传进去，提示模型“不要生成与历史题目重复的任务”。这个列表可以放在上下文里，也可以用检索的方式做筛选，规模大了之后我用的是向量检索加去重过滤。实践经验：直接把历史题目签名列表放进prompt是最便宜的方案，先把效果做出来再考虑工程优化。

3.3 求解器：批量采样解题的正确姿势

求解器部署好之后，批量解题的关键在于温度和采样的控制。如果你用greedy decoding，模型每次产出的kernel代码几乎一样的，那数据多样性就没法保证。我建议把temperature设置到0.7到0.9之间，同时每个题目采样top_p 0.95，产生3到5个独立样本。这些同题异解的样本非常宝贵：一道题的多份解法放在一起，验证器可以对比谁更快、谁数值更稳，而最优秀的那个样本就可以作为“标准答案”式的训练数据。

这里有一个容易忽略的工程细节：采样输出要做字段分隔。模型经常会在代码块里插入额外的注释、解释性文字，甚至把中间过程也写进代码块，导致提交给编译器的文件不干净。解决方式是在验证器前加一个严格的提取器（Extractor），它负责从模型输出中截取第一个python到最后一个之间的内容，然后做语法检查，如果不能通过AST解析就立刻丢弃。用AST解析而不是正则匹配，是因为正则容易在花括号嵌套和多行注释情况下误判，AST虽然也有漏网的但整体靠谱得多。

3.4 验证器的实现细节与门槛

验证器这一层是保证整个飞轮数据质量的最终防线。我会给每个kernel提交分配一组测试用例，这里有三个关键参数需要明确：

• 核对几次：至少调三个不同shape的profile进行正确性和性能验证，只测一个shape容易过拟合。因为一个kernel可能在shape A上性能不错，在shape B上因为块大小选取不当而大幅退化。
• 性能基准：每个算子的性能基线，我建议同时跑两个基线：朴素参考实现（纯PyTorch算子组合）和手动写的高性能实现。前者用来衡量基本正确性，后者用来卡优化目标。对于LayerNorm，朴素参考就是两遍扫描计算均值和方差再归一化，高性能基线则直接用cuDNN作为参照。
• 容差设置：fp16场景下，atol=1e-2, rtol=1e-2；fp32场景下，atol=1e-4, rtol=1e-4。这个容差在很多通用评测里看来宽松得离谱，但在fp16的规约求和场景这是必要的。

性能验证里我踩过一个特别典型的坑：第一次跑kernel的时候会有CUDA上下文初始化和JIT编译开销，导致第一轮耗时偏长。如果直接拿这个数据做判定，很多优秀kernel会被误判为“不达标”。处理方式很简单——先warmup两轮，再正式计时取中位数，同时把计时区间放在torch.cuda.Event之间，用事件测时而不是用Python的time.time，后者会包含大量CPU-GPU同步开销。

3.5 微调与进化循环：LoRA是性价比之选

数据筛选好之后，进入训练环节。这里我不推荐一上来就全参数微调，原因很现实：每轮迭代产生的数据就那么两三千条，全量微调会严重过拟合且耗时极长，尤其是那种几千条数据训一两个epoch的操作，几乎必然跑飞。LoRA才是自进化循环的正确选择。

我的LoRA配置参考如下：

peft_config: r: 16 lora_alpha: 32 lora_dropout: 0.05 target_modules: - q_proj - k_proj - v_proj - o_proj - gate_proj - up_proj - down_proj

训练超参数方面，learning rate我习惯用2e-4配合cosine调度，epoch数量控制在一到两个——LoRA本身就带着正则化效果，训太多反而遗忘旧能力。数据格式用最简单的instruction + solution输入输出对，不需要额外做RLHF。这里和数据配比配合着看：如果一批样本本身质量足够高、测试通过率也在线，SFT就能让模型学到可观的优化技巧。只有当模型收敛速度明显变慢、需要更高上限时，才考虑引入GRPO这类偏好优化机制，把验证器的分数转为偏好信号做强化学习。

每次训练完，都要做一次冻结点评估：把历史所有题型的通过率重新跑一遍，和上一轮微调后的通过率对比，确认没有出现严重指标滑坡。这步不能省，因为“新题型掌握但旧题型明显退化”在我测试中不止一次出现过。

4. 常见问题与排查实录

这套系统理论上听起来顺滑，实际跑起来问题比想象的多。我把我踩过、排查过的问题按频率排序，整理成一个速查表：

4.1 出题重复率高：一个容易被低估的效率杀手

这是早期迭代时长教训最惨的一个问题。第一轮跑完，人工检查训练集的时候发现，超过四成的样本都是LayerNorm配shape (1024, 4096)——因为出题的时候模型看到的历史列表太短，或者历史签名列表压根没传进去，它就会在上文里反复试探那些熟悉的组合。后来我把签名列表通过压缩摘要的方式放进了出题prompt，并明确要求生成的shape必须避开列表里的组合。去重逻辑也从简单的哈希升级成了“shape范围碰撞检测”，例如(1024, 4096)和(1024, 4095)这种近乎重复的数据，虽然在严格意义上是不同shape，但对模型学习来说没有区别——这种局部敏感哈希（LSH）对范围的量化处理，可以把相似shape归到同一个hash桶，减少近似重复。

4.2 数值容差和性能基准的“双重标准”

验证器这块容易出的偏差不只是warmup。我测过一段模型生成的Fused Softmax Kernel，数值对比结果完全正常，但是把它和PyTorch的softmax做对比时，发现它处理的是重新加了mask的变体，而PyTorch的实现是标准softmax。这属于“语义不一致导致数值恰好对上”的情况，虽然少见，但只要出现一次，进到训练集里就会对模型产生毒害。

后来我在验证器里增加了“参考实现的输入先生成一次，同时传给模型kernel和宿主环境”的双向校验：不只对比输出，还要检查输入在运算前后是否发生了非预期篡改。只有输出和参考一致、输入没有被改动过的样本才允许通过。这一类“形式验证”工作虽然啰嗦，但它是自进化系统稳定性的地基。

4.3 奖励信号太弱时的应对

如果遇到模型长期过不了验证器、通过率低于10%的时候，整个飞轮节奏就会被打断。这时不要急着加训练数据或加大模型参数，我的经验是先回到“出题”这一侧调整难度梯度：先把性能目标放宽到朴素的1.5倍而不是cuDNN的60%，让模型先学会把kernel写对，再逐步收紧性能目标。这个“先求对，再求快”的阶梯式策略，比指望模型直接从低质量代码一步跳到高性能实现靠谱得多。

4.4 训练集污染与数据清洗的警惕

最后提一下数据污染。因为自进化的数据本身就是模型产物，它会在不知不觉中强化模型的错误倾向。有一次我发现模型开始频繁地给kernel写if x == 0: return 0这样的分支，看起来严谨，实际上只是因为它在前几代数据里见过类似的代码，而这类代码在对应场景里根本没有必要。这就是模型学到的“噪音特征”。我的处理方式是在验证器里搞附加规则集：对某些投机性pattern（比如无意义的常量判断、多余的向量化循环分支）做特征检测，命中即剔除。

5. 延伸思考：自进化式训练的可行边界与应用迁移

5.1 KernelZero 与现有基准的分工

现在做LLM算子生成评测的基准已经有一些了，KernelBench这类任务集就是通过让大模型直接按题目生成kernel再测试性能来打分的。这类基准是静态的：题目固定，答案一次性打分，没有反馈和迭代。KernelZero的思路差异在于把静态评测变成了动态训练回路。如果拿竞赛做类比：KernelBench是高考，题目固定，考完出分；KernelZero更像训练营+月考，出题、解题、评分、再出题，一轮轮滚下去。它不是评估模型当前能力的工具，而是制造新能力的引擎。

5.2 自进化经验的迁移：不只适用于算子

这套“挑战生成器+求解器+验证器”的架构，实质上可以迁移到不少其他领域。凡是有低成本自动化验证器的方向，都可以试一下自进化的循环。比如单元测试生成、数据库查询优化、协议实现、编译器pass优化。核心判断标准只有一个：你能否快速、自动化地判断答案的质量？如果能，这个方向就适合用类似方法做数据自生产。如果验证成本很高，比如必须人工审核，那这套机制的收益就会大打折扣。

5.3 还需要解决的问题与未来改进方向

我目前卡得比较狠的还有三个问题，供同样在做这类项目的团队参考。

一是跨硬件泛化能力还很弱。当前训练数据绑定在一块特定GPU上，换一张算力规格完全不同的卡，模型的性能调优经验就用不上。理论上需要在多机多卡环境下采集数据，做多标签训练，让模型学会“为硬件特征生成对应配置”，但这会明显增加数据生产复杂度。

二是**“只做题，不总结”**。当前整个系统的学习信号全部来自“代码跑得对不对、快不快”，但模型不理解为什么某个tiling策略在这个shape下更好。下一阶段我想在验证器里引入“后处理分析器”，对通过案例的kernel代码做静态分析，提取优化模式，变成自然语言描述，再喂回给挑战生成器和训练数据。本质上就是把隐式的优化知识显式化。

三是推理成本控制，毕竟每轮迭代都要批量跑几百道题目的采样推理和若干个kernel的编译验证，GPU时间开销不小。我现在能做到的是把编译结果做缓存，完全相同的shape签名第二次不用重新编译，同时在采样阶段用vLLM的批处理能力一次性投喂多个提示词，尽量把GPU的空闲吃干净。

我个人做下来最大的体会是：让大模型“自举出题”这套方案，真正价值不在于生成的数据量，而在于它把“能力成长”从一种依赖外部标注的静态过程，变成了一个边界可以不断扩大的闭环。你不再需要等着有经验的人写教材、写答案，模型自己会去探索能力边界的下一个挑战点。现阶段做算子方向刚好合适，因为这个领域的验证器已经很成熟、性能指标也足够明确。如果你想入局自进化式训练，别急着做花哨的强化学习框架，先认真把一个验证器做到滴水不漏，飞轮自然就转起来了。