1. 首頁 > 生活百科 > >

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

算法vivo x300s相機

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

文章圖片

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

文章圖片

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

文章圖片

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.10846EvoKernel 想做的
不是再訓一個模型
圍繞這一冷啟動難題 ， 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 。
【AI寫CUDA算子國產芯片不行？上交方法直線拉升，DeepSeek也適用】作為對比 ， 在相同 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）獲取更多細節 。 本工作由上海交通大學人工智能學院鄭雨杰、李卓主導完成 ， 王翰竟（上海人工智能實驗室）參與合作 ， 溫睦寧（助理研究員 ， 通訊作者）和溫穎（副教授）擔任指導 ， 也歡迎通過論文聯系方式與團隊交流合作 。

    推薦閱讀