24 小時、1,000 次工具呼叫：GPU kernel 最佳化案例研究證明了什麼

實驗設定

Meta 測試了 Muse Spark 1.2 迭代最佳化 GPU kernel 的能力：單次執行超過 1,000 次工具呼叫、最長持續 24 小時。在 Muse Code 的 agent 環境裡，模型寫出一個 kernel、編譯、對照提供的 baseline 進行效能分析（profiling），再拿分析資料回頭改進——一個緊湊的「寫、編譯、量測、改進」迴圈，整整維持一天。測試目標是 NVIDIA Hopper GPU 上的 KDA 與 MLA attention kernel。

有一條規則讓這場測試不摻水：模型被禁止匯入 FLA 之類的第三方 kernel 函式庫。不能包一層現成的高速實作就領功——agent 必須動用真正的 kernel 最佳化知識，自己用 Triton 把演算法實作出來。

Agent 實際做出了什麼

這些解法並不泛用取巧。KDA 這題——對照組是 FLA 的 Triton 實作——Muse Spark 1.2 把一個 chunk 平行的前置 kernel 和一個逐 chunk 的循序掃描配成一組，除了標準的 fusion 與 tiling，還用上 KDA 特有的手法，例如把帶閘控的累積衰減（gated cumulative decay）重新對齊到 chunk 中點。MLA 這題——對照 PyTorch 參考實作，batch size 1、64 個 head、序列長度 8192、latent 維度 512——它設計出一條雙 kernel 的 Triton 管線，讓共享的 KV latent 同時充當 K 和 V 重複使用。

這是專家在真正吃透演算法結構之後才寫得出來的那種最佳化，不是表層的迴圈微調。而且隨著執行時間拉長，agent 仍持續找到相對 baseline 的可觀改進——進展在數百次迭代中不斷累積，而不是第一波爆發後就進入高原期。

為什麼「24 小時」才是真正的頭條

能把一個 kernel 改進二十分鐘的模型很多。要讓有方向的進展維持一整天，需要的是大多數 agent 沒有的基礎設施。三個部件撐起這一切。目標制約（goal conditioning）讓第 700 次迭代仍然瞄準和第 1 次相同的目標——模型正是為此而訓練。脈絡壓縮（context compaction）留住真正重要的知識（哪些策略失敗了、profiler 說了什麼），而不是被一整天的歷史淹沒。而事件日誌讓執行環境能安全重啟——跑 24 小時，一定會有東西出狀況，如果一次當機就抹掉第 23 個小時的成果，整個實驗就毫無意義。

這對日常工作意味著什麼

會去最佳化 Hopper kernel 的團隊不多。但這個任務的形狀——對著可量測的目標反覆迭代、從每次嘗試中學習、不能失去主線——和很多不起眼的工程活兒是同一個模子：追殺不穩定的測試套件、一點一點磨掉 bundle 大小、把一支 API 在上百個呼叫點逐一遷移。這份案例研究就是 Meta 的證據：「開下去跑、明天再來看」已經是真實可行的工作流程了。評測方法論發表在 Meta 的研究網站上；長時程工作的產品端入口，從文件開始。