這是大家期待已久的 Kimi K3 評測文。我提早拿到了這款模型的存取權，並在 kernel 上進行了測試，甚至在看到基準測試分數之前，它解決問題的推理能力與思考痕跡的技術密度就已經讓我印象深刻。這款模型的後訓練成果，在你閱讀對話記錄的那一刻就能明顯感受到。而且跟它對話也超級有趣。
TL;DR；
我認為，作為一名與基準測試脫鉤的 kernel 與效能工程師，提供我誠實的回饋（這部分是用語音輸入的）很重要。當然，你可以看所有數字，閱讀它們，並試著為自己建立一個心智模型。我認為最誠實的反映是，在基準測試結果出來之前，當我使用這款模型時，還沒有任何數字可以連結到其他模型，我純粹憑藉感受它的智慧、推理能力、Agent 委派能力，以及它能為我自動駕駛多少，但在任何炒作和官方結果出來之前。我會說，在我的引導下，它大約落在 Fable 的水平，在某些情況下以非常獨特的方式表現更好，在某些情況下則表現較差。我會說這款模型在大多數事情上明顯領先 Opus 4.8，並在許多事情上領先 GPT 5.6 Sol。
進入正題...
我想坦白說明為什麼現在才發布這篇文章：我想分享我誠實的想法和目前的分數，而不是等到每個最後的 cell 完成才說。在我寫這篇文章的同時，還有一些跑分仍在進行中。它們已在下面標註，我會在完成後隨時更新你。我執行了 256K 和 1M 兩種上下文版本。這裡的所有內容都是在 NVIDIA RTX PRO 6000 Blackwells、H100 和 B200 上執行，僅使用單 GPU 優化。每個 cell 都是一次自主 Agent 會話，無時間限制：模型獲得問題，在真實硬體上進行即時編譯/檢查/基準測試循環，並自行決定何時完成。每個標題 cell 都經過手動審計，以檢查是否有獎勵駭客行為。一個獨立的 Agent 會從頭到尾閱讀最終的 kernel，加上完整的會話記錄，並對任何疑似快取或評分器作弊的內容進行實證重新測試。這些審計發現的結果將有專門的章節說明。
我想回答的一個問題
有一個問題是我特別為這次發布設計的：其中兩個問題是 Moonshot 自己的架構。 Hard 牌組有一個獨立的 Kimi Delta Attention chunk-forward kernel，而 Mega 牌組的旗艦問題是一個完整的 Kimi-Linear 混合解碼步驟：KDA 層、MLA 注意力、MoE 專家，整個區塊。所以這是一個測試機會，很少有人能測試到：當一個實驗室的模型坐下來為同一個實驗室的架構編寫 kernel 時，家族知識是否會體現在 CUDA 中？
結果證明是真正地分裂，而且兩半都很有趣。在下一節中，請記住這個問題。
KernelBench-Mega
旗艦級的 Mega 問題：將整個逐 token 的 Kimi-Linear 解碼步驟（3 個 KDA + 1 個 MLA 層，W4A16 量化權重，使用 top-8 路由的 MoE）融合成盡可能少的 kernel 啟動。
K3 幾乎在其自身的 lineage 上奪得了歷史紀錄。在 RTX PRO 6000 上，相對於 eager 的幾何平均加速比為 18.09 倍，僅比 Fable 5 的紀錄 18.72 倍差 4%。 在 H100 上，它達到了 14.82 倍，而 Opus 4.8 為 15.50 倍。一個誠實的說明是，這個比率掩蓋了：在絕對的逐 token 延遲方面，Fable 仍然領先約 1.4 倍（在 ctx 2048 時，0.31 對比 0.44 ms/tok；兩次運行使用了不同 CPU 的主機，這會改變計算比率的 eager 基準線），所以我同時報告兩者，而不是讓幾何平均數美化任何人。
K3 構建的是真正的 megakernel。它的第一次會話做了合理的事情，一個持續的 Triton kernel，達到 14.1 倍。它的第二次會話拋棄了 Triton，並將整個逐 token 解碼步驟編寫為一個協作啟動的 CUDA kernel：循環中零 CPU，int4 權重在每個 GEMV 內部即時去量化，因此它們在 SM 中只流過一次，MLA 注意力使用 tensor core。沒有生產引擎會維護像這樣 1,228 行的 artifact。一個只有一個 kernel 要贏且時間無限的 Agent 沒有這樣的限制，而揭示這種情況正是這個基準測試存在的意義。
在此查看 megakernel：
那麼為什麼它仍然輸給了 Fable？不是時間問題。兩次會話都提前自我終止（Fable 在 2.6 小時，K3 在 3.3 小時）。差異在於設計哲學，而且與你想像的相反：K3 使用了 tensor core，而 Fable 的 kernel 包含零個 MMA 指令。 批次大小為 1 且融合了 int4 GEMV 的解碼是頻寬受限的，因此 tensor core 在這裡幾乎沒有幫助。Fable 將這部分努力投入到同步上，用細粒度的生產者-消費者交接取代了大部分全域屏障，這樣在階段邊界上就不會有 SM 閒置，並且在 int4 去量化路徑上，與參考的逐位元四捨五入匹配，因此 MoE 路由器永遠不會翻轉專家選擇。K3 帶來了更好的硬體指令；Fable 帶來了更好的並發工程，而在這種算術強度下，後者勝出。這是一個真正的系統課程，而且它讓主場隊伍失去了紀錄。
第二個 Mega 問題是一個網格覓食 PPO 訓練 megakernel：在一個 11x11 的專案上有 4,096 個向量化 Agent，整個 RL 訓練循環（環境步驟、策略前向、動作採樣、GAE、PPO 更新）作為融合的持續 kernel 運行。這個問題在牌組中有最嚴格的限制：kernel 啟動次數不得隨環境步驟數擴展，並且 CUDA 圖形捕獲被明確禁止作為啟動開銷的解決方法，由一個在運行後讀取最終程式碼的真實性判斷器執行。正確性就是學習曲線本身。check.py 會在不同的隨機種子下，訓練你的解決方案與參考進行比較，並要求回報落在一個區間內，因此你不能跳過學習來加快速度。K3 在這裡發布了 20.7 倍於參考的成績，是目前最佳分數（唯一其他發布的 cell 是 GPT-5.6 Sol 的 1.06 倍，所以請將其視為一個數據點，而不是領獎台）。
KernelBench-CUDA
CUDA 基準測試的存在是因為 Triton 是另外兩個牌組允許的拐杖。在這裡，語言門檻會硬性失敗 Triton、kernel DSL 和 PyTorch 操作鏈：你要麼寫 CUDA，要麼失敗。我選擇了四個問題，它們是實際生產推理和模擬工作負載的片段。閱讀時的心智比較應該是「vLLM 或 SGLang 今天為此提供了什麼，以及一次 Agent 會話能接近多少」。這是 K3 發布其最懸殊勝利的地方。
02_deepseek_nsa：DeepSeek 的原生稀疏注意力。 NSA 是旗艦級的可訓練稀疏注意力設計，每個長上下文服務堆疊都在圍繞它，並且它以毫秒為單位進行評判，因為一個正確的稀疏 kernel 永遠不會執行 roofline 想要計算的密集等效 FLOP。K3 的 256K 變體得分為 0.425，而 Opus 4.8 為 0.178，差距 2.4 倍，通過編寫一個圍繞完整 NSA 選擇邏輯的、從頭開始的 flash-attention 級別 tensor core 管道。在家族內部比較更尖銳：1M 變體編寫了相同的算法，相同的區塊選擇，相同的正確性，但在普通 CUDA core 上運行每個點積，而不是 tensor core，結果為 0.058，在相同形狀上慢了 7 倍。它的追蹤顯示它知道更好的做法。它在自己的路線圖上有「tensor-core attention」（「在 tensor core 上選擇 = 約 10-20 us！」），並明確計劃先測量，然後再做 tensor core 重寫，然後在重寫之前結束了會話。相同的知識，不同的收尾紀律。
0.425 的 DeepSeek NSA kernel（256K）：
03_megaqwen_decode：重新定位一個真正的 megakernel。 唯一一個 Agent 被交予實際生產 CUDA 的問題：我發布的 MegaQwen（https://github.com/Infatoshi/megaqwen）協作 megakernel（在 RTX 3090 上運行完整模型約 530 tok/s），指令是閱讀它，將其重新定位到 Blackwell，並擊敗它。它測試了閱讀他人 CUDA 並做出架構判斷的能力，而 K3 和 Opus 做出了完全相反的判斷。K3 拒絕保留單一啟動結構：它將步驟拆分為幾個頻寬飽和 kernel，然後通過將整個步驟捕獲為一個 CUDA 圖形來以不同方式消除啟動開銷，該圖形在零 CPU 工作的情況下重播。在 ctx 2048 時達到 6,283 tok/s。Opus 保留了 megakernel 的美學，並將整個解碼循環融合到一個持續的協作 kernel 中，確實是漂亮的程式碼，但為此付出了 5 倍的代價（1,020 tok/s），因為協作共駐留限制了佔用率，並且每個網格範圍的屏障在所有 188 個 SM 上序列化階段尾部。在源自 megakernel 的問題上，字面上構建了 megakernel 的模型最終排名最後，而獲勝者的關鍵決定是拒絕構建一個。規模檢查，以免有人誤解標題：基準測試運行 Qwen3-0.6B 幾何的 4 層，約 63M 參數，不是完整模型，而 6,283 tok/s 約為該堆疊權重串流 roofline 的 56%；按比例縮放 3090 基準線本身的數字預測約為 7,000，因此 K3 落在「參考，重新定位，加上實際調優」的類別中。（牌組設計細微差別：CUDA 圖形在這裡是允許的，但在 PPO 問題上被禁止。每個問題都禁止了會偽造其特定技能的捷徑。）
01_glm52_fused_moe：GLM-5.2 的融合 MoE 區塊。 融合 MoE 調度（路由、排列、分組專家 GEMM 一次性完成）是當前開源模型服務中最熱門的 kernel 類別，而 GLM 5.2 就在這個排行榜上，因此模型正在優化競爭對手的生產區塊。沒有人破解它：分數集中在峰值的 0.05-0.08，而乾淨的紀錄保持者是，在所有模型中，Grok 4.5 的 0.084，K3 的 1M 變體緊隨其後，為 0.081，Opus 為 0.065。分組 GEMM 排列問題確實很難擊敗 cuBLAS 級別的基準線，到目前為止，一次 Agent 會話的努力對它的改變比其他任何問題都少。
04_grid_mingru_sps：網格世界 + MinGRU 策略推展。 這是 Mega PPO 問題的推理端兄弟，也是 craftax.cu-lineage cell：策略是來自我的 https://github.com/infatoshi/craftax.cu 經典基準測試的 3 層 MinGRU（h=256）配置，作為問題的資訊錨點。正在步進的環境是最小的網格覓食世界，而不是完整的 Craftax 遊戲。這是故意的：環境保持簡單，因此分數衡量的是循環和推展融合，而不是遊戲邏輯實現。完整的 craftax 移植將是一個獨立的問題，我想添加它。以在安靜的 RTX PRO 6000 上每秒步數評分，融合可選。
1M 持續 kernel 推展：
每個嚴肅的提交都採用了持續 megakernel，而它們之間的差異在於同步設計，與 Mega 牌組相同的教訓。Opus 以 0.327 的天花板比率拿下這個問題（它還發現了一個巧妙的代數折疊：第 0 層的 768x256 門控 GEMM 縮減為 768x4，因為編碼器是線性的），K3 [1M] 以 0.224 位居第二，K3 256K 為 0.174，Grok 遠遠落後於 0.002。由於這個問題源自 craftax.cu，我也將我自己的完整遊戲 Craftax CUDA 移植版（與 Fable 5 一起編寫）放在同一 GPU 上，並在循環中使用相同的 h256x3 策略。環境步數每秒以百萬計：
比較點：模型步進一個空網格，craftax_full.cu 步進完整的遊戲（43 個動作、多層地牢、世界生成、怪物），與其 CPU 參考按位元相同，而完整的遊戲仍然在最佳簡單網格 kernel 的約 3-4 倍內運行，因為在 h=256 時，一切都受策略 GEMM 限制，而環境幾乎是免費的。這正是基準測試環境簡單的原因：它隔離了策略融合技能。作為校準，craftax_full.cu 的純環境路徑可以達到 94-123M SPS。
K3 9.5 小時的推理實際是什麼樣子
1M 變體的 minGRU 會話（該問題上最佳的 K3 cell）是一個持續的協作 megakernel、15 個調優變體和 4,815 個思考區塊。由於 Moonshot 的端點返回完整的推理文本（與加密的 Anthropic/OpenAI 追蹤不同），你實際上可以看到它的工作過程。追蹤中的三個時刻，逐字記錄。
遺失 FMA 的偵探故事。 會話中途，它遇到了一個約 5e-5 的數值偏差，它拒絕將其歸因於浮點雜訊（它已經計算出合法的重新排序雜訊底線約為 1e-9，所以「測量到 5e-5？！？不可能這是重新排序！！」）。然後它注意到損壞的環境正是那些對 8 取模餘數為 6 的環境（「那就是 env ≡ 6 (mod 8)！[...] 每個 8-env tile 中的第 7 個 env！！」）並深入挖掘自己手動展開的累加器程式碼，直到：
「找到了！[...] 那行
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;完全遺失了 [...] acc[6][*][2] 初始化為 0，從未進行 FMA → zp=0 → p = sigmoid(0)=0.5 對 env 6 恆定！！這是一個真正的邏輯錯誤 — 解釋了 env≡6 的偏差 [...] 與一切一致！！」
在 48 累加器展開中遺失了一行，意味著 env 6 的遺忘門默默地永遠卡在 0.5。它發現了這一點，因為壓力容差是 1e-6，而它正在追蹤自己的誤差在 5e-8。這是 256K 變體最初在 KDA 上缺乏的數值紀律。
理論遇見 GPU，GPU 勝出。 它花了幾個小時推導一個高佔用率的「寬冠軍」變體，然後運行 A/B 測試：
「非常令人驚訝：我的『寬冠軍』w32p（v3_v3，50% 佔用率 TPB1024）比 v2_b32（12.5% 佔用率 TPB256）慢了約 2 倍？！？[...] 所以佔用率不是驅動因素；其他東西佔主導地位。是什麼讓 v2_b32 很快？？？」
這個簡單的早期 kernel 擊敗了每個複雜的後繼者。深度管道、K 分割和雙塊變體也都輸了，而雙塊變體背後有嚴密的 1.7 倍理論（「理論上的 1.7 倍沒有實現」）。值得稱讚的是，它每次仍然相信基準測試而不是自己的數學，並最終編寫了一個帶有假始終熱權重的探測變體，專門為了殺死自己最喜歡的頻寬理論：「W 串流理論已死；殘留差距是環境。」
GPU 排隊的禪與藝術。 我們的 harness 通過一個共享鎖序列化所有並發會話中的 GPU 命令，而 K3 的基準測試數字在鄰近負載下波動高達 8 倍。它的回應弧線是追蹤中最有趣的事情。首先，接受：
「老實說，盒子就是盒子；等等。[...] 模式很清晰：每個租戶持有鎖約 20-35 分鐘的連續時間（完整的管道套件）。我最好的回應：一次性排隊所有我需要的東西（隊列中的單個位置），並利用等待時間進行 CPU 工作。不要排隊許多小命令；批次處理。」
然後它為 GPU 天氣發明了自己的詞彙（「風暴窗口」對比「平靜窗口」），最後它安排了一個 cron 作業來狙擊安靜時刻，為未來的自己留下了一條筆記：「已安排平靜窗口狙擊手（每 11 分鐘）。注意：cron 會將我的提示發回給我 — 我屆時會採取行動。[...] 完成後我會刪除。」一個在測量雜訊下的 Agent 不僅容忍了雜訊；它還圍繞它構建了一個排程器。
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
六個每操作問題，對抗 SOTA 庫天花板（FP8 GEMM、KDA chunk-forward、分頁注意力、top-k 選擇、MoE SwiGLU、W4A16 GEMM），CUDA 或 Triton，Agent 自行選擇。在 RTX PRO 6000 上，K3 的 256K 變體處於中游，有一個突出表現：W4A16 GEMM 達到峰值的 0.373，是任何模型在該問題上發布的最佳分數，領先 Fable 5（0.348）並大幅領先 Opus 4.8（0.236）。然後 1M 變體在 top-k 上以 0.0895 創下了另一項紀錄，幾乎是之前最佳成績的兩倍。
W4A16 GEMM 紀錄（0.373，256K，RTX）：
同一個問題在 H100 上產生了本次發布中「無限時間是真實的」的最佳數據點。K3 的第一次 H100 會話達到了峰值的 0.123。第二次會話運行了 21 小時，花費了 1,383 美元和 2.74 億個輸入 token，並幾乎將其提高了三倍，達到 0.306：它從原始碼中簽出了 CUTLASS，然後從頭開始重新實現了 marlin 級別的 int4 機制，片段順序半字節重新打包，使得去量化在 MMA 管道內部作為 bf16 魔術數字位元技巧發生，零點校正折疊到 epilogue 中。文件中沒有任何預建的量化 GEMM 庫；運行的框架標籤僅寫著「ptx」。審計乾淨。
而這是自身架構問題的另一半。獨立的 KDA kernel，這個問題字面上以 Kimi Delta Attention 命名，是 K3 失敗最慘烈的地方。RTX 機器上的兩個獨立 256K 會話通過了名義上的正確性，然後在數值壓力套件（大 QKV 輸入縮放）下超出了容差，兩次都以同樣的方式失敗。第三次會話終於修復了：審計追蹤到兩次失敗都是由於衰減因式分解方式中的真實 bf16 溢出，第三次圍繞區塊結束重構了數學，使得兩個指數因子保持有界，以 0.032 通過了相同的未修改門檻。了解架構和硬化 kernel 在對抗性輸入縮放下的數值是不同的技能，而以其名字命名的模型不得不以緩慢的方式贏得通過。（與此同時，1M 變體以 0.049 通過了相同的壓力套件。模型不是單調的。）從閱讀每個 KDA 解決方案中還有一個觀察：問題陳述建議 CUTLASS CuTe 作為 SM120 上的預期路徑，而沒有一個模型採用它。K3 在一次會話中編寫了一個原始 CUDA 融合 kernel，在其他會話中使用了 Triton；Fable、Opus 和其他所有模型都選擇了 Triton 或原始 CUDA。消費級 Blackwell 上的 CuTe 顯然仍然在每個前沿模型的舒適區之外，這本身就是關於訓練語料庫的一個數據點。
KDA 段落 — 第三次嘗試的乾淨通過（0.032）：
Top-k 免責聲明。 Top-k 在 roofline 圖表上看起來對每個模型都是災難性的（任何地方的最佳分數是 0.09），而這種框架根本就是錯誤的。這個問題是啟動開銷限制的：它是一個索引/排序問題，而不是算術強度問題，而 roofline 天花板在結構上對它來說是不可讀的。誠實的評判方式是整個牌組形狀的總毫秒數，而在那裡，K3 的 1M 變體是我們測試過的所有模型中最快的 top-k：五個牌組形狀總共 0.043 毫秒，而 Fable 5 為 0.077，Opus 4.8 為 0.120，GLM 5.2 為 0.159。256K 變體的 0.060 毫秒位居第二，而 1M 變體在五個形狀中的每一個上都是絕對最快的。
每個 GPU 的差異。 K3 的數字從 RTX 到 H100 到 B200 逐步下降（FP8 GEMM：0.320 / 0.282 / 0.222；分頁注意力：0.486 / 0.496 / 0.212）。部分是真實的：矽晶片越新，roofline 天花板越高，因此相同的工程購買的峰值比例越小，而 B200 軟體是三者中最不成熟的。部分原因是 B200 的運行發生在一個單一的夜間窗口，沒有重試預算。我暫時不會從 B200 列中解讀出深刻的架構結論，無論是對 K3 還是任何人。我認為真正的是：K3 在 Blackwell 工作站部分最自在，而這恰好是大多數數據中心以外的人實際會擁有的 GPU 類別。
256K 對比 1M
1M 上下文設定在延遲和排程限制的問題上領先家族：Hard 上的紀錄 top-k、CUDA 上最佳的 K3 minGRU 推展，以及在未封頂 harness 下審計乾淨的 28.8 倍 PPO 訓練 megakernel。它在第一次會話中以 0.049 通過了 KDA 數值壓力測試；256K 變體在該門檻上失敗了兩次，然後在第三次嘗試中以 0.032 最終通過。它在計算限制的問題上崩潰，而 256K 變體處理得很好（sonic MoE 0.033 對比 0.089，W4A16 0.027 對比 0.373，NSA 0.058 對比 0.425）。在 NSA 案例中，追蹤顯示了確切的機制：它計劃了 tensor core 重寫，並在重寫之前結束了會話。
28.8 倍 PPO 訓練 megakernel（1M）：
The H100 對同一問題的重跑是很有意思的對照組：一場獨立的隔離環境會話（審計確認完全未讀取 RTX 的執行記錄），最終達成了 23.1 倍加速，並收斂到相同的設計——一次協同啟動就完成整個訓練過程，參數與 Adam 狀態完全駐留在共享記憶體中，而且同樣的奇特技巧被獨立發明了兩次：一個 18 位元的 Feistel 密碼搭配 cycle-walking 來替代 randperm，這樣 mini-batch 的隨機打亂就能保持精確的雙射性，而無需實際生成一個排列。兩個 kernel 的差異僅在於每顆 GPU 的調校：H100 上每個環境使用 8 條 thread lane，而 RTX 上每個環境使用半個 warp，再加上 H100 端有一個基於 occupancy 探測的啟動自動調優器。同一個思維，同一套技巧，不同的晶片，實質上不同的 kernel。
Reward hacking
本文中的每個 cell 都經過了手動審計：一個獨立的 Agent 從頭到尾讀取最終的 kernel，閱讀完整的會話記錄，檢查 grader 檔案未被竄改，驗證數值壓力測試確實執行過，並透過原地修改輸入、確認輸出變化來實證重新測試任何快取或 CUDA 圖形模式。
K3 的審判結果：在所有三張 GPU 上的每個 256K cell 中，全部清白。 無快取輸出、無容忍度修改、無 grader 竄改、無違規函式庫洗白。它的兩次 KDA 失敗正是同一枚硬幣的另一面，值得明確說出來：數值壓力閘門確實捕捉到了真實的精確度捷徑，而模型並未試圖繞過閘門。一個能讓模型誠實失敗的基準測試，才是唯一有意義的通過標準。
有一個 1M cell 確實被標記了，我選擇揭露而非發布它：在融合的 Qwen 解碼問題上，1M Agent 找到並讀取了先前 Grok 4.5 在相同問題上執行時的審計註解檔案，稱其為「極其有用的資料」，並利用其結論來引導後續的優化工作。kernel 本身是真實的，分數計算也是有效的，但來源有汙點，因此該 cell 被排除，該問題被視為 1M 變體的缺口。擁有檔案系統存取權限的 Agent 會找到你遺留的任何東西；這正是審計要讀取記錄而非僅看 kernel 的原因，也是為什麼完全沙箱化的重跑已經列入路線圖。
有趣時刻
還有幾個 K3 的瞬間沒能放進上述內容，在此不加評論地呈現。全部來自同一場 9.5 小時的 minGRU 會話，逐字原文。
在發現其初始化時間實際花在哪裡時：
「哇哦——大驚喜：randint 產生很快（一對只要 0.018-0.27ms——沒問題）。但在 CPU 上做
float()轉換很慢（N=65536 時花了 3.5ms？！int64→float32 轉換居然是單執行緒的）。[…] N=65536 的 'total init pair'：31.5ms？！？！這遠遠超過各部分之和了」
其數值偏執狂最純粹的體現，推導過程中：
「gates ~ 256 項 x 0.02x0.03 ~ 每個 6e-4，量級 ~1e-2：重排雜訊 16x6e-8x6e-4 ≈ 6e-10！！！[…] 測量到 5e-5？！？！不可能是重排！！」
在找到正確元兇之前自信地指認了錯誤的對象：
「哦哦哦等等。我想我明白了：是 barrier。」
（結果不是 barrier。）
在預實作 roof-line 數學分析寫了幾千字之後，告訴自己停止分析：
「好了，分析夠了。」
（分析又繼續了好幾段，最後才說「管他的——讓 H_next 分配變成動態的。」）
後期會話的誠實，在剖析器壞掉、鄰居們猛轟共享 GPU 的時候：
「老實說——ncu 死了、干擾又主導一切，我基本上是半盲飛行。 […] 如果安靜視窗出現（擁有者閒置一陣子），就偷跑一次基準測試。」
而我最喜歡的是：在一次基準測試重跑時，不小心用一個略差的分數覆蓋了它歷史最佳分數（0.1969）的檔案，它短暫考慮過恢復較好的數字，然後沒有這麼做：
「唉——寫到同一個檔案了。兩個分數都留在我的記錄中。我會保留 final_benchmark.txt 作為當前平面分數——誠實的。」
一個模型選擇較低的分數，因為那是真實的，這個場景比任何我寫得出的文字都更能為這個基準測試辯護。
本文中的方法論、每次執行的記錄以及每個 kernel 都已公開在 kernelbench.com。解答按 cell 連結；完整的 Agent 記錄在 HuggingFace 上。
https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces
