![]()
本文作者包括明尼蘇達大學的張子健(共同第一作者),王嶸(共同第一作者),李世陽,羅越波,洪明毅,丁才文。
CUDA 代碼的性能對于當今的模型訓練與推理至關重要,然而手動編寫優化 CUDA Kernel 需要很高的知識門檻和時間成本。與此同時,近年來 LLM 在 Code 領域獲得了諸多成功。這推動人們去探索如何利用 LLM 來編寫優化 CUDA kernel。然而,現有的方法面臨諸多問題,例如高昂的訓練與推理成本,不良的 kernel 性能,以及缺乏硬件反饋導致的盲目探索。
那么對于使用 LLM 進行 CUDA 代碼生成,我們能不能設計一個簡單而有效的方法,使其能夠低成本地生成可靠高效的 CUDA kernel?
明尼蘇達大學的團隊提出了一種新的方法——CudaForge。這是一種簡單、高效且低成本的多智能體 CUDA Kernel 生成與優化工作流。該工作流受人類專家的實際開發流程啟發,包含初始 Kernel 的編寫、正確性測試、硬件反饋分析以及迭代改進等關鍵階段。
- 論文標題:CudaForge: An Agent Framework with Hardware Feedback for CUDA Kernel Optimization
- 論文鏈接:https://arxiv.org/pdf/2511.01884
- 代碼地址: https://github.com/OptimAI-Lab/CudaForge
實驗結果表明,CudaForge 在 KernelBench Levels 1-3 上取得了 SOTA 的結果,超越了現有的所有方法。值得注意的是,通過 CudaForge 生成一個經過優化的 Kernel 在單張 RTX6000上僅需約26.5 分鐘,同時僅產生約0.3 美元的 API 調用成本!
CudaForge Workflow 介紹
正如人類專家所采用的開發方法,包括初始 Kernel 的編寫、正確性測試、硬件反饋分析以及迭代改進,我們將 CudaForge 設計為如上所示的迭代式優化框架。
該框架包含兩個相互獨立的智能體:CoderJudge
Coder 根據任務描述以及來自 Judge 的反饋生成候選 CUDA kernel;而 Judge 則利用 kernel 本身、硬件反饋以及運行時信息對每個候選進行評估。
具體而言,給定一個 CUDA kernel 生成任務,Coder 首先接收任務要求以及對應的 PyTorch 參考實現,然后生成一個初始的候選 kernel。該 kernel 將被編譯并在測試用例上執行以驗證其正確性。
如果測試失敗,Judge 會檢查運行時信息(例如編譯錯誤、與 PyTorch 參考結果不一致的輸出),并分析該錯誤 kernel 的問題所在。隨后,Judge 會返回相應的糾錯反饋(如缺少頭文件等),以指導下一輪生成。當某個候選 kernel 通過了正確性測試后,Judge 會使用NCU工具對其進行性能剖析,獲取NCU 性能指標(如內存帶寬、占用率、warp 效率等)。
結合 GPU 硬件規格,這些指標構成了用于識別主要性能瓶頸(如算力受限或帶寬受限)的硬件反饋,Judge 會進一步基于此返回一個明確的優化建議(如使用 shared memory)給 Coder。
在下一輪中,Coder 會同時接收上一輪的 kernel、Judge 的反饋以及原始任務需求,并生成新的、經過修正或優化的 kernel。該過程最多重復N輪,最終我們會從所有正確的候選結果中選擇效率最高的 kernel作為最終輸出。
在此,我們給出一個使用 CudaForge 進行 Kernel 優化的案例,并將其與Kevin-32B方法進行對比:
這一對比進一步凸顯出使用硬件反饋對于 Cuda 代碼優化的重要意義。
具體來說,CudaForge通過以下三項關鍵設計顯著提升了 CUDA kernel 的生成與優化能力:
雙智能體分工協作:CudaForge 采用Coder–Judge雙智能體架構,其中 Coder 專注于代碼生成,Judge 負責評估代碼并提供反饋,從而實現“認知負載”的有效分離。
迭代式優化流程:CudaForge 通過多輪迭代逐步糾錯與提速,使得 Kernel 能在每一輪中持續被改進,特別是在復雜任務中能夠獲得更加穩定的優化效果。
顯式引入硬件反饋:CudaForge 將GPU 規格NCU 性能指標(如帶寬、占用率、Warp 效率)納入反饋,使 Judge 能精確定位瓶頸并提供可執行的優化指導
實驗評估
我們在 KernelBench Levels 1-3 上評估了我們的模型,并與 Kevin-32B,OpenAI-o3 等模型進行了比較。
在 RTX 6000 上的 KernelBench Levels 1–3 主要結果:
在我們的主要實驗中,我們默認將OpenAI-o3同時用作 Coder 與 Judge,并將最大迭代輪數設為N = 10,以在性能提升與推理成本之間取得平衡。
在 KernelBench 上,CudaForge 達到了 97.6% 的正確率,平均加速比為 1.677×,Fast1 比例為 70.8%,并且實現了1.107× 的中位數加速比1.592× 的 75 分位加速比。這些結果顯著優于基礎模型 OpenAI-o3 與一系列消融變體(包括o3-self-refine、o3-correction、o3-optimization)。
與 Kevin-32B 在 H200 上的對比:
考慮到 Kevin-32B 是基于 H200 訓練的 RL 模型,我們在 H200 上對比了 Kevin-32B 和 CudaForge。下圖展示了 CudaForge 與 Kevin-32B 在 KernelBench 上的正確性與性能表現對比。虛線表示 CudaForge 在 Level 1 和 Level 2 上的平均水平。
盡管CudaForge 不需要訓練(training-free),它在KernelBench Level 1–2上的表現依然優于Kevin-32B,并且在Level 3上也取得了極為出色的性能。
CudaForge 的 API 與計算時間成本分析
我們進一步分析了 CudaForge 的性能與其 API 調用成本和計算時間之間的關系,如圖所示。隨著 API 成本與計算時間的增加,CudaForge 的性能呈單調提升趨勢。值得注意的是,即使在每個任務耗費不超過 0.15 美元和 10 分鐘的情況下,CudaForge 也已經能夠超越 Agentic 基線方法,這充分展示了其出色的性能-成本平衡能力。
![]()
基于 KernelBench,我們測評了 CudaForge 所需的時間和 API 成本,結果表明在 KernelBench Levels 1-3 所有任務上,CudaForge 每個任務僅需平均 0.3 美元的 API 成本,以及在單卡 RTX6000 上 26.5 分鐘的運行時間!
消融實驗
在不同 LLM 上實例化 CudaForge:
為了驗證 CudaForge 是否依賴某個特定基礎模型,我們在實驗中固定一方(Coder 或 Judge)為 OpenAI-o3(記作 O3),并將另一方替換為多種先進的大模型,包括 QwQ-32B、GPT-5、Claude-Sonnet-4、GPT-OSS-120B 等。
如表所示,所有組合都能夠取得較高的正確率和良好的性能表現,并且在某些情況下甚至超過原始的 O3/O3 配置。
這一結果表明,CudaForge 并不依賴于某個特定的基礎模型:其有效性主要來源于 Coder–Judge 的工作流機制,并且隨著更強模型的出現,它可以直接受益并進一步提升性能。
在不同 GPU 架構上使用 CudaForge:
我們進一步在多種 GPU 架構上評估 CudaForge,包括 RTX 6000、RTX 4090、RTX 3090 和 A100,以考察其在不同硬件條件下的適用性。
實驗結果(如表所示)顯示,CudaForge 在所有測試 GPU 上均保持了高正確率和強性能表現,證明其具有良好的硬件通用性和穩定性。
總結
我們提出了 CudaForge,一個無需訓練的多智能體 CUDA kernel 生成與優化框架。該框架模擬人類專家的迭代式工作流程,并顯式地引入硬件反饋,以實現有針對性的 Kernel 優化,而非盲目搜索。 在 KernelBench 基準上,CudaForge 相較于現有方法取得了最高的正確率和顯著的性能提升,同時在不同 GPU 架構和多種基礎大模型上均表現出強魯棒性與泛化性。
此外,CudaForge 的性能隨著迭代輪數的增加能夠進一步提升。 最后,得益于其低 API 開銷與低時間成本,CudaForge 為自動化 CUDA Kernel 開發提供了一種高效、實用且可投入實際使用的解決方案。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.