AI寫CUDA算子國產芯片不行？上交方法直線拉升，DeepSeek也適用

GPT-5.2 寫 CUDA 算子，正確率 92%。同樣的模型，給華為 Ascend NPU 寫算子，正確率只有 4%。不是模型變笨了，是它壓根沒見過這類代碼。公開數據幾乎為零，專家寥寥無幾，編譯報錯你還看不懂 —— 這就是 "新硬件冷啟動" 的真實處境。

上海交大團隊的 EvoKernel 不訓新模型、不標新數據，而是讓大模型像老工程師一樣積累經驗：每寫一次算子，記住什么管用、什么不管用，下次優先調用最有價值的歷史經驗。結果：同一個 GPT-5.2，正確率從 4% 拉到 83%，最快的算子比 PyTorch 基線快了 42 倍。不僅如此，團隊還將方法拓展到 DeepSeek 最新 mHC 架構的算子上，同樣取得了顯著效果。

該方案的早期實踐已在昇騰 AI 創新大賽 2025 全國總決賽中斬獲初創賽道金獎 ，項目獲華為計算·夢想起航種子計劃支持。相關團隊成員亦在第十九屆"挑戰杯"全國揭榜掛帥擂臺賽中獲得擂主（特等獎第一名）。

算子（Kernel）是大模型直接運行在加速芯片上的底層計算程序 —— 矩陣乘法、卷積、Softmax 等每一個基礎運算，都需要一段精細適配硬件的算子代碼才能高效執行，它的調優和硬件適配，長期以來一直是需要專家參與的 “手藝活”。在 CUDA 生態里，算子開發有海量開源代碼和成熟工具鏈做支撐，近期以來，大模型也能寫出不錯的 GPU 算子。但昇騰等國產 NPU 有自己的編程語言（如 Ascend C）和硬件架構，公開代碼幾乎為零、開發者社區尚在起步，大模型在這些新生態上近乎 "裸考"。

論文中的實驗把這種落差量化得非常直接。以 GPT-5.2 為例，在 CUDA Level 1 任務上正確率可達 92%，遷移到 Ascend C 后只剩 14%；更難的 Level 2 任務，正確率從 90% 直接跌到 2%。公開數據少、專家經驗稀缺、編譯反饋不透明、性能調優高度依賴真實硬件 —— 這些因素共同構成了一堵典型的 "數據墻"，現有模型并沒有真正學會為新硬件編程，更多是在復用預訓練中見過的 CUDA 模式。

• 論文標題：Towards Cold-Start Drafting and Continual Refining: A Value-Driven Memory Approach with Application to NPU Kernel Synthesis
• 作者單位：上海交通大學、上海人工智能實驗室 等
• 項目主頁：https://evokernel.zhuo.li
• arXiv 論文：https://arxiv.org/abs/2603.10846

EvoKernel 想做的

不是再訓一個模型

圍繞這一冷啟動難題，EvoKernel 給出的答案不是繼續堆標注數據，也不是重新訓練一個專門模型，而是設計了一套從初稿生成到持續優化的自演化智能體框架。系統分成兩個連續階段：

• 冷啟動生成（Cold-Start Drafting）：先找到一個能編譯、能運行、結果正確的初始算子。
• 持續改善（Continual Refining）：在有了第一個可行版本之后，再持續做延遲優化和性能改進。

圖 1：EvoKernel 的整體框架。系統先在冷啟動階段生成可行初稿，再在共享記憶與驗證反饋的幫助下持續做性能精煉。

這套框架最關鍵的設計，是論文提出的價值驅動記憶（Value-Driven Memory）。和常見的相似度檢索不同，EvoKernel 不只是問 "哪些歷史樣本看起來更像當前任務"，而是進一步學習 "哪些歷史經驗在當前階段真正更有用"。為此，團隊引入了階段感知的 Q 值機制：在生成階段，系統優先檢索更可能幫助模型通過編譯和正確性驗證的經驗；在精煉階段，則優先保留更可能帶來性能收益的優化軌跡、候選起點和上下文信息。

換句話說，EvoKernel 不是簡單地 "給模型喂更多例子"，而是在讓模型逐漸學會：面對不同階段的目標，應該參考哪類記憶，忽略哪類噪聲。

為什么它不像傳統智能體一樣 "試一試運氣"？

為了讓這套記憶真正可用，團隊還構建了多層驗證機制。每一次生成的結果，都會經歷 reward hacking 檢查、編譯驗證、正確性校驗和延遲測量四個環節：既要避免模型通過 Python 綁定層繞過算子實現，又要檢查代碼能否在真實 Ascend C 工具鏈中成功編譯，并驗證輸出是否與 PyTorch 參考實現一致；只有通過這些檢查，候選結果才會進入下一輪性能優化。具體而言，團隊針對語義繞過、常量偽造、高層 API 替代等多類 reward hacking 模式，設計了規則篩查與智能體篩查兩級反作弊機制，從源頭降低無效結果進入記憶庫的可能性。

也正因為驗證器足夠嚴格，EvoKernel 的迭代過程并不是提示詞工程式的 "多試幾次"，而是圍繞真實執行反饋不斷調整檢索策略、補充歷史經驗、擴大可用優化起點。

從方法上看，EvoKernel 的關鍵并不只是 "有記憶"，而是它能夠逐步學會哪些記憶在當前階段最值得取用。這也是它和一般基于靜態相似度檢索的方法最主要的區別。

主結果：從 4% 正確率一路拉到 83%

團隊基于 KernelBench 構建了 NPU 版本評測環境，經過 30 輪的迭代后，EvoKernel 在 GPT-5.2 上把整體結果顯著拉升：

• 整體編譯率從 11.0% 提升到 98.5%
• 整體正確率從 4.0% 提升到 83.0%
• 在更難的 Level 2 任務上，實現了 100% 編譯率和 76% 正確率

圖 2：論文中的主實驗結果。表中同時給出了 Level 1、Level 2 和 Overall 三組結果，也展示了首輪到最終輪的變化幅度。對 GPT-5.2 而言，EvoKernel 在整體編譯率和正確率上都顯著優于 Pass@k、Refinement 和 Codex。

作為對比，在相同 30 次預算下，Codex 智能體的整體結果為 83.0% 編譯率和 46.0% 正確率，傳統精煉基線則只有 71.5% 編譯率和 22.0% 正確率。也就是說，即便 Codex 擁有更強的自主工具調用能力，EvoKernel 依然在這個數據稀缺的 NPU 算子開發場景里，表現出了更強的穩定性和成功率。

做對還不夠

EvoKernel 還在繼續把它做快

論文里另一個很值得關注的點，是 EvoKernel 不只停留在 "生成一個能跑的算子"，而是在正確版本出現之后，繼續做持續優化。

圖 3：EvoKernel 的優化結果。左側展示不同類別算子在正確率和加速比上的分布，右側展示同一算子從首個正確版本到最佳版本的持續優化收益。

實驗顯示，在已經找到首個正確版本的前提下，系統進一步通過持續精煉，把算子的中位數速度提升做到 3.60 倍，四分位區間為 1.38 倍到 10.05 倍。更重要的是，這并不是少數偶然樣本帶來的假象。論文統計了 159 個至少出現過 "正確且可繼續優化" 候選的算子，發現其中不少都能隨著迭代持續獲得穩定收益，部分算子相對首個正確版本的加速甚至超過 200 倍。

這意味著 EvoKernel 并不只是一個代碼修復工具，而是開始展現出更接近算子工程師的優化能力。

記憶為什么有用

因為它真的能跨任務遷移

如果說主結果回答的是 "EvoKernel 能不能把一個任務做出來"，那么這部分結果回答的則是 "它能不能把經驗留下來，下次繼續用"。

圖 4：EvoKernel 在跨難度、跨模型設置下的遷移能力。

團隊發現，當系統先在更簡單的 L1 任務上積累經驗，再遷移到更難的 L2 任務時，正確率上升明顯快于從零開始。在第 17 次迭代時，L1 → L2 的遷移設置已經達到 64% 的 L2 正確率，顯著超過混合訓練和從零開始兩種方式。

更進一步，論文還驗證了跨模型遷移。用 GPT-5.2 構建出的記憶庫，能夠把 DeepSeek-V3.2 在保留測試集上的編譯率從 26% 提升到 80%，正確率從 6% 提升到 58%；對 Qwen3-Coder-30B，同樣可以把編譯率從 14% 提升到 84%，正確率從 4% 提升到 32%。這些結果說明，這種記憶更像是一種可復用的 "任務經驗資產"，而不只是一次性上下文拼接。

不止 KernelBench

它還開始走向更真實的工程場景

如果一套方法只在基準測試上好看，意義其實有限 —— 已有研究表明，在 KernelBench 上表現優異的模型，面對新出現的算子或真實硬件需求時，正確率可能直線下降。EvoKernel 的另一個亮點，是團隊把它繼續擴展到了主實驗分布之外的任務。

團隊額外構建了一組包含 70 個 Attention 類算子的測試集（Attention Set）。這些算子從 FlashAttention、xformers 等主流開源社區倉庫中手動篩選而來，覆蓋了當前大模型推理與訓練中需求最迫切、迭代最快的 Attention 算子變體 —— 這恰恰是芯片廠商在實際落地中優先需要解決的算子類別。

在這組更貼近真實工程需求的任務上，EvoKernel 在 CUDA 平臺上達到了 100% 編譯率和 97.1% 正確率；在昇騰平臺上，也取得了 100% 編譯率和 78.6% 正確率。更進一步，在面向 DeepSeek 今年 1 月份發布的流形約束超連接（Manifold-Constrained Hyper-Connections, mHC）新架構的 15 個相關算子上，EvoKernel 成功得到 10 個正確實現，其中 6 個超過 PyTorch 基線，代表性結果包括 SinkhornKnopp 的 41.96 倍加速。

圖 5：在 DeepSeek mHC 算子上的擴展結果。EvoKernel 不只在原始 KernelBench 分布上有效，也開始展現出對新算子族和新架構模式的適配能力。

換句話說，這項工作展示出的并不只是對某個基準測試的適配能力，而是在向更真實的跨任務、跨場景泛化邁出一步。

這項工作的意義

可能不止于 NPU 算子開發

從更大的視角看，EvoKernel 的意義可能不止于 NPU 算子開發。本質上，它回答的是這樣一個問題：當目標領域幾乎沒有現成訓練數據、只有嚴格可驗證反饋時，通用大模型還有沒有辦法通過非參數化、可積累的方式逐漸掌握新技能？

這篇工作給出了一個積極信號。隨著硬件生態越來越分化，真正稀缺的也許不只是算力，而是能夠快速適應新架構、新領域專用語言（DSL）、新工具鏈的工程能力。EvoKernel 試圖把這部分能力，從 "依賴少數專家" 變成 "可以被記憶、檢索和持續放大的系統能力"。

一句話總結

EvoKernel 提出了一種面向數據稀缺 NPU 編程場景的價值驅動記憶框架，不依賴昂貴微調，僅通過可驗證反饋和跨任務經驗積累，就把 GPT-5.2 在 Ascend C 算子開發任務上的整體正確率從 4.0% 提升到 83.0%，并在正確初稿基礎上實現了 3.60 倍的中位數性能優化。

如果你對 NPU 算子開發、跨硬件代碼生成或 LLM agent 在系統軟件領域的應用感興趣，歡迎訪問項目主頁（https://evokernel.zhuo.li）獲取更多細節。本工作由上海交通大學人工智能學院鄭雨杰、李卓主導完成，王翰竟（上海人工智能實驗室）參與合作，溫睦寧（助理研究員，通訊作者）和溫穎（副教授）擔任指導，也歡迎通過論文聯系方式與團隊交流合作。