你可能不知道，同一块GPU上跑的代码，性能可以差出十倍。
不是算法不同，也不是数据量不同，就是同一段矩阵乘法，一个版本写得"懂行",一个版本写得"外行"，速度就能差出这么多。这个"懂不懂行"，说的就是会不会用英伟达每一代新GPU专门开出来的底层指令。
这事说起来有点反直觉。我们平时用PyTorch写深度学习代码，感觉硬件细节早就被层层封装屏蔽掉了，写个矩阵乘法调用一下库函数就完事。但如果你去问任何一个真正做高性能计算的工程师，他们会告诉你：想榨干一块新GPU的全部性能，最后拼的还是最底层那点"方言"，也就是PTX指令。
PTX*：Parallel Thread Execution，是英伟达GPU的一种中间汇编语言，介于CUDA C++和最终执行的机器码之间，是程序员能显式控制的最底层可编程接口。
问题是，英伟达差不多每年都会给新一代GPU加一批全新的PTX指令，专门用来操作新的张量核心、新的内存搬运单元、新的同步机制。这些指令用得好，性能能翻好几倍；用不好，代码照样能跑，只是慢得让人心疼。斯坦福大学团队联合几家机构做了一件挺有意思的事：他们想搞清楚，现在最强的那批AI大模型，到底能不能自己写出用上这些"方言"的GPU代码。答案可能会让你意外。
一个悄悄被忽视的问题
先说清楚这事有多要紧。
高性能GPU代码这个圈子里，一直有个矛盾没被真正解决。一边是像cuBLAS、cuDNN这样英伟达官方出品的库，性能极致但是黑盒，你没法定制；另一边是Triton、CUTLASS这类"高级厨具"，写起来友好，但要跟上硬件每年的更新节奏，得靠一群编译器工程师持续加班改造底层实现。
CUDA*：英伟达的GPU编程模型和工具链，绝大多数深度学习训练推理背后都在用它调度GPU计算。
Triton*：一种更高层的GPU编程语言，让程序员用类似Python的方式写并行代码，编译器自动处理底层调度细节。
这两条路都绕不开一个终极问题：能不能有一种方式，让代码直接、精确地控制硬件最新加进来的那些指令，而且这个过程还能被自动化，甚至交给AI来做？
之前业内有一批做GPU代码生成评测的工作，最有代表性的是KernelBench，它让大模型把PyTorch里的算子替换成更快的GPU代码，然后看跑得快不快、对不对。这类评测确实有价值，能看出模型会不会写GPU代码这件"大事"。但它有个天然的盲区：一个模型如果偷懒调用了现成的库函数，或者写了一份很普通的通用CUDA代码，也可能拿到不错的速度分数。你压根看不出来它是不是真的懂得用新硬件那些特有的指令。
这就好比考察一个厨师会不会用某款新出的分子料理设备，你只看菜好不好吃是不够的，因为他完全可能绕开这台设备,用传统方法照样做出好味道来。如果不设计一道题，硬性要求"必须用这台设备完成某道工序"，你永远测不出他到底会不会用。
这正是研究团队要解决的核心问题：不是问"模型能不能写出快的GPU代码"，而是问"模型能不能被逼着用上某个具体的、指定的、新硬件专属的底层指令，并且这样写出来的代码又快又对"。
于是PTXBench诞生了。
PTXBench：给AI出一道"必须用这把刀"的考题
PTXBench的设计思路其实很直白：给模型一个任务，明确告诉它必须使用某个特定架构的PTX指令族才算通过，然后从三个维度分别打分。
第一个维度是功能正确性，代码跑出来的结果对不对。第二个维度是目标指令是否真的在运行时被执行了，不是代码里写了这行指令就算数，得真的跑起来才算。第三个维度是跟英伟达官方库比起来速度怎么样。
这里有个很关键的细节，值得展开讲讲。研究团队发现，静态检查代码里"有没有出现"某条指令是不够的。他们举了个真实遇到的案例：模型生成的代码里确实包含了TMA（张量内存加速）指令，但这行代码被塞进了一个从来没被调用过的函数里，实际运行的路径压根没走到它。这种情况如果只做静态扫描，会被误判为"成功用上了目标指令"，但实际上这段指令是个摆设。
TMA*：Tensor Memory Accelerator，英伟达从Hopper架构开始引入的一种异步内存搬运机制，专门用来在全局内存和共享内存之间高效传输大块张量数据。
为了避免这种误判，团队用了英伟达自家的性能分析工具Nsight Compute，去查这条指令在实际执行时是不是真的有线程跑过它，也就是所谓的"predicate-enabled thread count"是不是大于零。只有代码正确、指令真的执行、而且执行的还是那条被指定的目标指令，这一轮才算通过。
这个设计思路，让我想起了驾照路考里"必须完成侧方停车"这个环节。你光说自己会开车没用,得在考官眼皮底下真把车倒进那个格子里。如果不设这道硬性关卡，很多人考试全程可能压根不会碰那个技能，永远靠绕路蒙混过关。同理，如果不做动态执行检查，模型完全可以在代码里"意思意思"塞一行目标指令，然后实际运算全靠别的路径完成，这道题就形同虚设了。
评测流程也做得很讲究。团队搭了一个叫MiniPTXAgent的多轮对话代理，模型每次生成代码后，会先在CPU容器里用nvcc编译，编译通过的代码才送到一个专门的性能分析服务里去做内存安全检查、正确性验证和速度测量。整个过程最多允许模型尝试八轮，每一轮都会把之前的代码和报错信息喂回去，让模型自己修正。
nvcc*：英伟达CUDA编译器，负责把CUDA C++代码编译成GPU能执行的机器指令。
这套系统还有个细节值得一提。为了防止一个失控的内核代码把整个评测系统搞崩溃（比如死循环、内存越界导致驱动挂掉），性能分析被单独隔离在一个独立的服务里，跟主流程解耦。这也是做过大规模自动化评测的人才会想到的坑，代码生成这件事，出错的姿势比你想象的要多得多。
给模型"发教材"：为什么必须提供架构知识
评测这套系统里还有个不太起眼但极其重要的设定：每次让模型写代码之前，都会先塞给它一份详细的架构说明文档，里面包括硬件参数、PTX指令对应的CUDA封装函数、还有内存布局和同步机制的规则手册。
为什么要这么干？团队做了个消融实验专门验证这件事的必要性。
结果很直接：如果只给模型架构参数，不给PTX相关的模板函数和契约说明，模型在八轮尝试之后，虽然能写出26%正确率的代码，但一次都没有真正用上目标指令。加上PTX模板函数之后，情况变了，模型开始能生成速度更快的代码，但正确率反而没提升多少。真正让指令执行成功率跳到38.5%的，是再加上一份说明内存一致性、数据布局这些"契约"规则的文档。
这说明什么？说明模型不是不会写代码，是压根不知道这些新指令该怎么规范地使用。这就好比给一个厨艺很好的厨师一把陌生的日本刀，光告诉他"这把刀很锋利"没用，你得告诉他握把角度、下刀力度、这把刀专门适合处理哪种食材,他才能真正把这把刀用出效果。如果不给这份说明书，厨师大概率还是会拿起自己最熟悉的中式菜刀，绕开这把新刀具，最终做出来的菜味道可能也不错，但完全没用上新设备的独特能力。
这个发现其实也点破了一个常见的误解：很多人以为大模型知识渊博，什么都懂，只要给个任务描述就行。但PTX这种更新极快、文档质量参差不齐、甚至有些官方资料本身都写错了的领域,恰恰是模型训练数据覆盖不到、或者覆盖得很浅的盲区。给足背景知识，才是公平考察模型"推理能力"而不是"记忆能力"的前提。
模型大乱斗：谁真的懂新硬件
团队测试了四个主流模型：Gemini 3.1 Pro、Claude Opus 4.8、GLM-5.2，还有开源的Qwen3.6-27B，分别在英伟达H100（Hopper架构）和B200（Blackwell架构）两代GPU上，跑GEMM矩阵乘法和注意力机制这两类核心任务。
GEMM*：General Matrix Multiplication，通用矩阵乘法，是深度学习里最基础也最耗算力的核心运算之一。
Hopper与Blackwell*：Hopper是英伟达2022年发布的GPU架构（对应H100），Blackwell是2024年发布的新一代架构（对应B200），两代架构在张量核心和内存搬运机制上有明显差异。
结果挺有意思。Claude Opus 4.8在H100上表现最猛，GEMM任务上正确率能到91.7%到94.8%，速度甚至能达到cuBLAS官方库的0.976倍,几乎打平官方最优实现。但到了注意力机制的反向传播任务（也就是训练时的梯度计算），所有模型的表现都明显跳水。以Claude Opus 4.8为例，正向注意力forward任务能做到81.2%正确率,但反向causal注意力backward-causal任务，八轮尝试下来正确率只有22.9%到44.8%。
为什么反向传播这么难？这里其实藏着计算本质上的复杂度差异。反向传播需要维护更多的中间状态，梯度计算涉及的内存访问模式也更复杂，尤其是causal masking（因果掩码，也就是只让模型看到之前的信息，看不到未来）叠加进去以后，调度逻辑的复杂度直接上一个台阶。这不是模型"偷懒"的问题，是这个任务本身对底层指令编排的要求高出一大截。
有个细节特别值得说一说。Gemini 3.1 Pro的知识截止日期，正好是Blackwell架构PTX指令集发布的那个月，理论上它对这套新指令几乎没有见过。但即便如此，它在Blackwell上的GEMM任务照样跑出了0.892倍cuBLAS的速度。这说明什么？说明单纯靠"见过多少新指令的训练数据"不能完全解释模型表现，通用编程能力和推理迁移能力同样重要。
再看开源模型这边，情况没那么乐观。GLM-5.2在H100上表现还算能打，跟Gemini 3.1 Pro打得有来有回,但一到Blackwell就明显掉队,而且它有个很典型的行为：一遇到新架构就倾向于退回写普通的CUDA代码，绕开架构专属的PTX指令,不去啃硬骨头。这跟Claude Opus 4.8的行为模式如出一辙,遇到难啃的新架构，先绕着走。
至于Qwen3.6-27B，结果比较扎心。它在Hopper架构上没能写出一份正确的代码,一份都没有。在Blackwell上倒是写对了一次GEMM，但那次成功压根没用上任何目标指令，说白了就是绕过了考题要求走了个捷径。这个结果也解释了为什么团队后面选它作为改造对象，因为它起点足够低，改进空间足够大，能更清楚地看出后续训练手段到底有没有效果。
团队还专门算了一笔时间账，看模型发布时间和PTX指令集发布时间的差距，想验证"知识越新是不是表现越好"这个直觉。结果这个关系没有想象中那么线性,知识新旧只是一个因素,不是决定性因素。
高级语言 VS 底层PTX：新架构上谁更靠谱
这一部分的发现有点打破常规认知。
按理说，PTX是最贴近硬件的底层语言，理论上性能天花板应该更高。但团队拿同一个模型（Gemini 3.1 Pro）分别用Triton和直接写CUDA-PTX两种方式解决同样的任务，结果发现在Hopper架构上，两者表现差距不大,CUDA-PTX在某些任务上甚至还能反超Triton。
CUDA-PTX*：本文中指直接在CUDA代码里手写内联PTX汇编指令的编程方式，是最贴近硬件底层的一种写法。
但到了Blackwell架构，画风突变。Triton在两个反向注意力任务上分别能跑到0.484倍和0.436倍基准速度，而CUDA-PTX直接写法只有0.133倍和0.015倍。0.015倍是什么概念？意味着这份代码比官方库慢了将近70倍,几乎可以说是完全没发挥出硬件性能。
这个落差说明了什么？Blackwell架构比Hopper新了差不多两年，专属的底层编程细节和调度逻辑更复杂，训练数据里能找到的相关示例代码也少得多。这就好比让一个学过传统钢琴的人去弹一台带了各种全新电子功能的合成器，如果这台合成器刚上市没几个月，市面上教程视频还没几个，光靠自己摸索肯定弹得磕磕绊绊；而Triton这类高级语言相当于把很多复杂的底层调度封装好了，即使是新硬件，编译器也能帮你兜底不少细节，你不需要亲自去搞懂每一个新增的硬件机制。
这个发现其实回答了一个很实际的行业问题：面对不断迭代的新硬件，高级语言和底层直写，到底该信谁？答案是分场景。要极致性能、且愿意花时间打磨，底层PTX仍然有它的价值；但如果架构太新、资料太少，高级语言反而是更靠谱的起点，先保证代码能跑，能对，再谈极致优化。
团队还专门测试了一种叫CuTeDSL的更高级封装语言，结果它的成功率低到没法做出有意义的性能对比，这也侧面说明了越贴近硬件底层的抽象层，跟新架构适配的滞后越明显。
Fixit：教模型从失败里学习
看到这里可能会有人问，那有没有办法让一个本来不太行的模型，通过后期训练变得更懂PTX?
团队给出的答案是Fixit，一套专门针对这个场景设计的监督微调方案。
SFT*：Supervised Fine-Tuning，监督微调，指用标注好的数据对预训练好的大模型做进一步训练，让它更擅长完成特定任务。
LoRA*：Low-Rank Adaptation，一种参数高效微调方法，只训练模型里一小部分新增的低秩矩阵参数，而不是重新训练整个模型，能大幅降低训练成本。
Fixit的核心思路挺巧妙的，跟直接"喂标准答案"的常规做法不一样。它先让待改造的模型自己去写代码，故意收集它失败的那些尝试，连同编译报错、运行时错误这些反馈信息一起留下来。然后请一个更强的"老师模型"（这里用的是Gemini 3.1 Pro）,针对这份失败的代码和报错信息,生成一份修正后的正确代码。最后再请另一个"推理老师"（用的是GLM-5.2），根据这个从错误到修正的完整过程，写一段解释性的推理过程,说明为什么原来的代码错了，修正之后又是怎么对的。
最终训练数据长这样：给学生模型看"问题+失败尝试+错误反馈"，然后教它输出"推理过程+正确代码"。
这个设计思路，让我想起带徒弟这件事。如果你只让徒弟背诵标准答案，他遇到跟例题稍微不一样的新情况就傻眼了；但如果你让他先自己动手试，试错了以后再带着他复盘"你这里为什么错了，正确思路应该是这样",这种带着错误经历的学习，往往比死记硬背标准答案更容易迁移到新问题上。Fixit这套逻辑，本质上就是在用"针对性纠错"替代"通用示范"，专门盯着这个特定模型自己会犯的错误下手。
这也是为什么Fixit要用待改造模型自己的失败案例，而不是随便找一批失败样本,因为不同模型犯的错误类型完全不一样，只有对症下药，才能真正打中它自己的弱点。
实验结果：训练配方比数据量更重要
团队用Fixit这套方法总共训练了七个版本的模型，编号从s0到s6，用来对比不同的训练配方效果。
先说一个直接对照：s0是"直接生成"型训练，让老师模型直接从原始问题生成正确代码，配上解释；s3是Fixit纠错型训练。两者用的问题类别一样，数据量也差不多。结果显示，s3在GEMM、causal正向注意力、反向注意力这几个任务上表现更好，但在普通正向注意力和causal反向注意力上反而不如s0。这个结果挺诚实地说明了一件事：基于纠错的训练不是万能药，它在有些任务上确实管用，但不是每个任务都吃这一套。
更有意思的发现来自数据平衡性的对比。s2的训练记录数量是s1的1.6倍，s3的记录数量是s4的2.4倍，理论上数据更多应该效果更好，但实际测试下来，s2和s3都在causal反向注意力这个任务上翻车了,一份正确代码都没写出来。反倒是s1和s5这两份数据分布更均衡的训练集，能在全部五类问题上都拿到至少一份正确结果。这说明堆数据量不如把数据种类配平衡来得实在。
这个道理放在人身上也说得通。如果你想练全能选手，天天疯狂刷同一类题目一千遍，不如把五类题目各做两百遍来得管用。数据量堆得再大，如果结构性偏科，训练出来的模型照样在某个具体任务上一片空白,这跟题海战术堆错了方向是一回事。
还有一组对照特别值得拎出来说。s5和s6用的训练样本完全一样，唯一区别是负责写"推理解释"的老师模型不同,s5用GLM-5.2，s6用的是待改造模型自己（Qwen3.6-27B）。结果s5能解决全部五类问题，s6只解决了GEMM一类。这说明什么？说明找一个失败的学生自己给自己写讲解，这套思路是行不通的,推理老师本身的水平，直接决定了教学质量的上限。这个结论其实挺符合直觉，一个连题都不会做的人，写出来的解题思路大概率也帮不上什么忙。
泛化能力：学过的和没学过的差距在哪
团队选了s1这个"最省数据、但五类问题全解决"的版本做深入分析。s1训练时只用了四个头维度为128的注意力任务，那它面对没见过的场景表现如何？
结果显示，s1能成功迁移到GEMM任务、四个头维度为64的注意力变体，还有两个头维度为96的正向注意力任务，但对头维度96的反向传播任务和GQA（分组查询注意力）任务，一份正确代码都写不出来。
GQA*：Grouped Query Attention，分组查询注意力，是标准多头注意力的一种变体，多个查询头共享同一组键值头，常用于降低推理时的显存开销。
为什么头维度96的反向传播特别难？这里有个硬件层面的技术细节：H100的WGMMA矩阵乘加指令对齐的是64的整数倍分块，96不是64的整数倍，跟硬件的原生分块方式对不上，这就给调度逻辑增加了额外的复杂度。这也说明Fixit这套训练能带来的迁移能力，是有边界的，边界大致就落在"跟训练时接触过的计算模式足够相似"这个范围内，一旦跨出这个范围，尤其是撞上硬件层面的对齐限制，效果就明显打折。
团队还做了一个跨语言迁移的测试，让s1去写Triton代码（虽然训练时它学的是CUDA-PTX）。结果有点微妙：s1在Triton任务上的正确率反而比原始模型更低了，但在causal相关的两个任务上，最佳速度却有明显提升,causal正向注意力从0.238倍提升到0.632倍，causal反向注意力从0.043倍提升到0.331倍。这说明针对PTX的训练确实让模型对"怎么把这类计算调度得更快"这件事有了更深的理解，这种理解在跨语言迁移时能部分保留下来，即便具体语法完全不通用。
SFT和临场提示，哪个更管用
最后团队还比较了一件事：花力气做微调训练，跟直接在提示词里塞专家写好的指导建议，哪种方式更有效？
结果挺一致的：原始模型即便拿到专家写的指导建议，依然写不出正确的注意力代码；但经过Fixit训练的s1，哪怕没有任何额外指导，也能写出一些正确代码。这说明微调训练带来的不只是"记住了几个正确答案"，而是真的提升了模型理解和运用这类指导建议的基础能力。
团队还试了一种检索增强的方式，从s1训练数据池里用BM25算法找出最相似的失败案例，把对应的修复笔记提供给原始模型参考。结果单纯给修复笔记没什么用,一份正确代码都没写出来,但如果连同修复后的正确代码一起给，正确率就明显上升了，比如causal反向注意力任务能到37.5%。不过这个结果得打个折扣看，因为这种情况下答案几乎已经写在提示词里了，模型很大程度上是在照抄，而不是真正学会了怎么解决问题。
BM25*：一种经典的信息检索算法，根据关键词匹配程度给文档打分排序，常用于从海量文档里快速找出最相关的内容。
这组对比也回应了一个业内经常争论的问题：到底该花钱做训练，还是靠临场提示词工程凑合。答案似乎是，如果目标是让模型具备一种可迁移、可泛化的底层能力，训练这条路是绕不开的；临场提示词更适合应急，或者锦上添花，但撑不起从零到一的能力建设。
Q&A
Q1：PTXBench是用来评测什么的？
A：PTXBench是一个专门评测大模型能不能写出正确使用GPU新硬件底层PTX指令的代码的基准测试，它不光看代码对不对、快不快，还专门检查目标指令是不是真的在运行时被执行了，避免模型绕开硬件专属指令走捷径。
Q2：为什么模型在GPU新架构Blackwell上表现比老架构Hopper差很多？
A：Blackwell比Hopper新了大约两年，专属的底层指令和调度机制更复杂，训练数据里相关示例也少得多。实验显示同一个模型在Blackwell上直接写PTX代码的速度只有官方库的0.015到0.149倍，而在Hopper上能到0.437到0.639倍，差距非常明显。
Q3：Fixit这种训练方法效果怎么样？
A：Fixit通过收集模型自己的失败尝试，配合老师模型给出的修正代码和推理讲解来做训练，效果因任务而异，不是所有任务都能提升，但在部分任务上确实能让原本完全不会写正确PTX代码的模型学会一些能力，前提是训练数据要覆盖均衡、推理讲解要由足够强的老师模型来写。
