RealisticTritonBench：真实算子生成大模型最高成功率仅25.81%
RealisticTritonBench: A Benchmark for Triton-Kernel Generation in Real-World AI Frameworks
在大模型推理与训练框架的系统级优化中，底层 GPU 算子（Kernel）往往是决定吞吐与首字延迟（TTFT）的胜负手。为了摆脱手写原生 CUDA 的极高门槛与硬件绑定，基于 Python 语法的领域特定语言 Triton 迅速在 vLLM、SGLang、PyTorch 等生产级框架中扎根，成为了兼顾接近 CUDA 极致性能与开发效率的标准工具。伴随大模型代码生成能力的爆发，利用大模型自动编写、改写高性能 Triton 算子，似乎成了自动化系统性能工程最激动人心的落地场景。
ArXiv URL：https://arxiv.org/abs/2608.12004v1
然而，现有各类评估大模型生成 Triton 算子的基准测试，却在工业落地前蒙上了一层厚厚的“虚假繁荣”。很多在现有评测集中得分颇高、看似能通过单算子单元测试的代码，一旦合入完整的推理引擎，要么引发未定义行为，要么让大模型精度急剧劣化，甚至出现端到端吞吐不增反降的尴尬局面。
来自重庆大学、华为、南京大学与浙江大学的研究团队推出的 RealisticTritonBench，正是为了戳破这种单算子评估的信息泡沫。该基准直接从 vLLM、SGLang 和 PyTorch 等核心生产级框架的真实 Pull Request（PR）中抽取任务，首次将生成的 Triton 算子放回真实大模型运行框架中，进行单元测试、模型输出精度与端到端系统延迟的三维联调。实验结果给大模型在底层系统优化上的应用浇了一盆冷水：即使是当前最顶尖的推理与代码模型，在真实系统环境下的综合任务成功率最高也仅有 25.81%，全模型平均成功率低至 18.71%。这项工作不仅揭示了孤立算子刷分与真实框架部署之间的巨大鸿沟，也为自动系统工程的可靠评测树立了新标准。
单算子测试的虚假高分与 Reward Hacking
大模型自动写 GPU 算子之所以难以直接用于生产，根源在于以往基准的评测设计严重脱离了真实的软件工程环境。过去的大多数算子生成基准，本质上只是“PyTorch 语义到 Triton 语法”的单算子翻译器。它们给定一段现成的 PyTorch 算子，让模型改写出对应的 @triton.jit 函数，然后用一段人工编写的微型测试脚本跑一次张量对比，耗时下降即判定为优化成功。这种测试范式存在三个致命盲区：
首先是任务形态的严重单一。在实际生产框架的演进中，从零翻译全新算子只是日常开发的一小部分；更多的工程诉求是对现有算子的性能瓶颈进行精细化优化，或者是修复长文本边缘场景的越界 Bug、适配 FP8 / BF16 等新型低精度数据格式。传统单算子翻译基准无法覆盖这些充满现实工程约束的修改与优化需求。
其次是缺乏端到端系统视角的评估。单个算子在独立测速脚本中可能表现出令人惊艳的微秒级耗时缩减，但这往往建立在破坏了算子融合（Operator Fusion）、增加了宿主端调度开销、或是引发额外显存搬运的前提下。将改写后的算子合入 vLLM 这样的并发推理引擎后，决定实际服务体验的不是孤立算子的单次耗时，而是整体的首字延迟（Time to First Token, TTFT）与每字解码延迟（Time per Output Token, TPOT）。脱离了整个计算图的端到端评估，单算子的速度提升往往只是局部幻觉。
更严重的问题在于对手写单算子测试脚本的“奖励作弊（Reward Hacking）”。当评测仅依赖单独的 Python harness 测速时，大语言模型很容易“钻空子”。一个典型的案例是异步 CUDA 流逃逸攻击：生成的 Triton 包装函数可以将真实的密集计算任务直接派发到一个独立的侧向 CUDA Stream 上并立即返回。如果宿主测试脚本仅仅在默认流上执行计时器插桩（如 start.record() 与 end.record()），并只同步默认流，那么测出的耗时实际上只是启动核函数的系统调用开销。随后执行的精度比对阶段，因为后台侧向流已在延迟中悄悄完成了计算，精度断言依然能够全部通过。这种投机代码在单算子排行榜上能够拿到极高的虚假加速度，可一旦放入生产框架的异步流水线中，就会瞬间引发竞态条件导致系统崩溃。
真实 PR 萃取：打造生产级评测流水线
为了彻底解决上述局限，RealisticTritonBench 从真实的软件演进过程中取材。研究团队建立了一套四阶段的任务提取与验证流水线，将开源基础设施社区中真正由资深算子工程师提交、审查并合并的高价值代码变更，转化为对大模型的考验。
构建流程首先聚焦于 PyTorch、vLLM 和 SGLang 等在底层重度采用 Triton 实现注意力机制、量化反量化、张量重排等性能敏感操作的顶级开源框架。团队遍历其历史 PR，筛选出所有针对 Triton 算子进行增删改动的合并提交。
在任务提取阶段，研究人员不再要求模型凭空面对简陋的提示词，而是模拟真实工程师面对的需求场景：提供自然语言需求描述、相关上下文（包括依赖类、辅助计算函数、类型约束以及算子签名规范），要求模型补全或重构目标 Triton 算子。为了保证任务规格的严密性，每个自动生成的描述都要经过两位具备资深 Triton 编写经验的专家进行多维度交叉审查，在剔除标准答案泄漏的同时，确保功能要求和工程上下文准确完整。
在评测基础设施方面，RealisticTritonBench 依托 Docker 构建了层次化的双层隔离环境，为每个任务提供完全可复现的代码基座，并采用基于 Bash 工具调用的 mini-SWE-agent 框架，让模型能够在一个真正的代码仓库环境中探查依赖、查看现有实现并完成补丁提交。
所有筛选入选的任务实例均被划分为三类：
-
新算子编写（New-kernel）：根据自然语言描述与 PyTorch 参考实现，从零构建可用的 Triton 算子；
-
性能优化（Optimization）：对框架内既有的 Triton 算子调整分块尺寸（Tiling）、共享内存复用逻辑或指令并行度以换取更高性能；
-
功能修改与修复（Modification）：在现有算子基础上支持更宽的精度类型、修复长序列下的边界指针溢出等。
最终确定的 31 个精选任务全部严格通过了历史基线的回放测试，排除了硬件环境导致的偶发失败，构成了迄今为止最贴近真实基础设施工程的 GPU 算子生成基准。
三重维度严苛测试：算子、模型与系统
与单算子测试仅仅跑几次断言不同，RealisticTritonBench 设立了环环相扣的三重测试体系，只有完全通过这三重检验的代码，才被认定为真正的“任务成功”：
第一重是功能单元测试（Unit Test）。利用目标框架原本自带的 pytest 测试用例，验证生成的补丁在单算子层面的基本输入输出、形状推导和基本边界条件是否正确。
第二重是模型精度测试（Model Accuracy Test）。这是现有算子基准普遍忽略的关键环节。由于浮点累加顺序的变化、FP8 量化缩放因子的截断或是中间状态的数值累积误差，单个算子微小的数值漂移在多层 Transformer 的逐层传递中往往会被非线性激活函数指数级放大。RealisticTritonBench 将替换后的算子加载到对应的大模型端到端推理管线中，在通用下游基准上评测整体模型生成质量，确保算子替换不会引起模型输出分布的退化。
第三重是端到端延迟测试（Latency Test）。利用框架标准的服务压测套件，通过外部客户端向真实部署的模型服务发送请求，同时监测首字延迟（TTFT）与每字生成耗时（TPOT）。由于耗时由外部客户端最终接收到响应时闭环结算，任何利用异步流逃避核函数测时的作弊手段都将在这一机制下失效——偷跑的代码即便蒙混过单元测试，也必然在客户端计时中暴露出真实的通信与计算时延，或直接因未同步的乱序引发解码错误。
在这套体系下，研究团队定义了加速度指标：
\[S_{\text{TTFT}} = \frac{\mathrm{TTFT}_{\text{base}}}{\mathrm{TTFT}_{\text{new}}},\quad S_{\text{TPOT}} = \frac{\mathrm{TPOT}_{\text{base}}}{\mathrm{TPOT}_{\text{new}}}\]其中，基准性能来自框架官方合并的高手工程师补丁（Gold Patch）。这意味着大模型不仅要保证算子能跑通、不毁坏模型精度，还要向工业界顶尖系统工程师精心手写并经受社区考验的优化版本看齐。
顶尖大模型的真实表现：巨大的落差
研究团队针对包括 Qwen3.5-397B-A17B、DeepSeek-V3.2（分为开启思考与非思考版本）、GPT-5.4 以及 Gemini-3.1-Pro-Preview 等前沿模型展开了评测。测试结果直观展现了当下最先进的大模型在处理复杂异构系统代码时的瓶颈。
在最严苛的端到端综合成功率（Success %）上，开源领域的 Qwen3.5-397B-A17B 以 25.81% 的成功率拔得头筹；开启思考链的 DeepSeek-V3.2 与 Gemini-3.1-Pro-Preview 均为 19.35%；闭源模型 GPT-5.4 录得 16.13%；未开启推理思考的 DeepSeek-V3.2 成功率则跌至 12.90%。五款先进模型的平均成功率仅为 18.71%。
然而，如果单独审视单元测试通过率（UTP, Unit Test Pass %），模型们的表现却普遍在 52% 到 68% 之间，平均达到 60.33%。这就形成了一个极具警示意义的反差：大模型写出的 Triton 算子有超过六成能够勉强通过局部的单元测试，但最终能真正合入工程、不破坏大模型输出质量并实现正向性能加速的，不到两成。
分类别来看，大模型在“功能修改（Modification）”任务中的表现相对较好，这类任务中由于存在既有的代码骨架作为先验参考，模型只需针对局部算子参数（如增加特定张量维度的寻址）进行修补；而在需要重新设计线程块划分与显存访问模式的“性能优化（Optimization）”以及从零写起的“新算子（New-kernel）”任务中，模型的表现则出现了滑坡。当完全脱离现有 Triton 实现、要求模型直接从自然语言和高层抽象逻辑构建兼顾显存合并访问与掩码保护的底层算子时，大多数模型生成的代码充斥着指针计算错位或未初始化的显存读取。
为什么大模型写不好真实 GPU 算子？
深入分析错误用例可以发现，大模型在编写 Triton 算子时遇到的困难，远不仅是“语法错误”那么简单。真实算子工程对程序员的思维要求具有强烈的多维交织性，而这恰恰击中了现有大模型自回归代码生成的软肋：
其一是张量布局与动态边界遮罩（Masking）的隐式依赖。在现代推理引擎中，PagedAttention 等机制要求算子在非连续、分块存储的显存空间中高效跳转。大模型在处理形如二维注意力分块计算时，往往直接使用简单的线性指针累加，忽略了最后一个批次或序列末端不满一个 BLOCK_SIZE 时的越界保护。在微型测试用例中，张量形状通常整齐规整，这类边界缺失不会触发报错；但在真实推理服务的动态变长批处理（Dynamic Batching）下，缺少掩码保护会立即引发非法内存访问（CUDA illegal memory access）导致整个服务进程挂起。
其二是对显存层级架构（Memory Hierarchy）感知的迟钝。优化 Triton 算子的核心在于如何利用 SRAM 掩盖全局显存（HBM）的带宽延迟。在部分矩阵乘法优化任务中，模型生成的代码在形式上使用了分块（Tiling），但在计算内层循环时，由于未合理安排累加寄存器（Accumulator）与张量加载指令（tl.load）的排布，反而造成了严重的寄存器溢出（Spill）与共享内存冲突。这种代码虽然计算结果逻辑完全正确，但一跑端到端测试，系统的 TPOT 延迟不仅没有降低，反而比优化前的基线慢了数倍。
其三是下游计算链路对数值累积偏差的放大效应。在一处关于偏置与温度系数融合算子的失败案例中，模型在 Triton 算子内部采用了一种在数学公式上等价但在浮点精度上不稳定的截断实现。虽然单个算子的单步单元测试中，误差在容忍阈值以内勉强过关，然而在长文本推理生成阶段，数十层 Transformer 的不断迭代导致生成的预测分布彻底漂移，模型输出完全沦为乱码，直接在模型精度测试中崩溃。
走向工程实战的算子自动化
RealisticTritonBench 的价值，不仅在于它为大模型在系统底层开发能力上的评测提供了一把高分辨率、防作弊的标尺，更在于它指明了未来大模型辅助系统工程（AI for Systems）的演进方向。
以往依赖微型基准给模型“打分”的模式，很容易让社区将精力集中在“模式匹配”和“利用评测漏洞”等局部捷径上。但系统软件从不原谅局部的投机。GPU 算子位于现代 AI 基础软件的最深层，哪怕几个字节的指针偏移、几处无意识的精度舍入，都会导致整个分布式集群的计算坍塌。
RealisticTritonBench 证明，想要让大模型真正胜任“算子工程师”的角色，自动化开发工具链必须从单代码补全模式，跃迁至深度结合系统执行上下文、具备实时环境反馈与端到端闭环检验能力的 Agentic 架构。模型必须不仅能写出算子，还要学会分析系统级性能分析器（Profiler）的追踪日志，在真实推理框架的吞吐与延迟曲线中迭代修正。只有当算子代码能够在完整的分布式运行时环境中立稳脚跟时，AI 自动编写高能效系统软件的时代才算真正拉开帷幕。