你可能不知道，同一塊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代碼的模型學會一些能力，前提是訓練數據要覆蓋均衡、推理講解要由足夠強的老師模型來寫。
