GPU代码里藏着的“方言“：AI能听懂英伟达最新硬件说的话吗？

你可能不知道同一块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分别在英伟达H100Hopper架构和B200Blackwell架构两代GPU上跑GEMM矩阵乘法和注意力机制这两类核心任务。GEMM*General Matrix Multiplication通用矩阵乘法是深度学习里最基础也最耗算力的核心运算之一。Hopper与Blackwell*Hopper是英伟达2022年发布的GPU架构对应H100Blackwell是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.2s6用的是待改造模型自己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*一种经典的信息检索算法根据关键词匹配程度给文档打分排序常用于从海量文档里快速找出最相关的内容。这组对比也回应了一个业内经常争论的问题到底该花钱做训练还是靠临场提示词工程凑合。答案似乎是如果目标是让模型具备一种可迁移、可泛化的底层能力训练这条路是绕不开的临场提示词更适合应急或者锦上添花但撑不起从零到一的能力建设。QAQ1PTXBench是用来评测什么的APTXBench是一个专门评测大模型能不能写出正确使用GPU新硬件底层PTX指令的代码的基准测试它不光看代码对不对、快不快还专门检查目标指令是不是真的在运行时被执行了避免模型绕开硬件专属指令走捷径。Q2为什么模型在GPU新架构Blackwell上表现比老架构Hopper差很多ABlackwell比Hopper新了大约两年专属的底层指令和调度机制更复杂训练数据里相关示例也少得多。实验显示同一个模型在Blackwell上直接写PTX代码的速度只有官方库的0.015到0.149倍而在Hopper上能到0.437到0.639倍差距非常明显。Q3Fixit这种训练方法效果怎么样AFixit通过收集模型自己的失败尝试配合老师模型给出的修正代码和推理讲解来做训练效果因任务而异不是所有任务都能提升但在部分任务上确实能让原本完全不会写正确PTX代码的模型学会一些能力前提是训练数据要覆盖均衡、推理讲解要由足够强的老师模型来写。