これが、皆さんが待ち望んでいた Kimi K3 の投稿です。私はこのモデルに早期アクセスし、カーネル上でテストしてきました。ベンチマークスコアを見る前から、その問題を推論する能力と思考トレースの技術的な密度に感銘を受けていました。このモデルのポストトレーニングは、そのトランスクリプトを読めばすぐにわかります。また、話していてとても楽しいです。
TLDR;
ベンチマークから切り離されたカーネルおよびパフォーマンスエンジニアとして、正直なフィードバック（この部分は音声入力です）を伝えることが重要だと思います。もちろん、すべての数値を見て、自分なりのメンタルモデルを構築することもできます。最も正直な反映は、ベンチマーク結果が出る前、他のモデルと比較するための数値が何もないときに、私がこのモデルを難しいタスクで使った経験をお伝えすることだと思います。純粋に、そのインテリジェンス、推論、エージェントの委任、そしてどれだけ自動操縦してくれるかを感じていました。しかし、その時点ではまだ誇大広告や公式結果は出ていませんでした。私の方向性においては、おおよそ Fable レベルであり、場合によっては非常にユニークな方法で優れていることもあれば、劣っていることもありました。このモデルは、ほとんどの点で Opus 4.8 より明らかに優れており、多くの点で GPT 5.6 Sol より優れていると言えるでしょう。
本題に入ります...
なぜ今この投稿を公開するのか、率直に説明します。それは、私の正直な考えと現時点でのスコアを共有したかったからであり、すべてのセルが完了するまで待つつもりはありませんでした。これを書いている時点でも、いくつかの実行はまだ進行中です。それらは以下にマークされており、結果が出次第お知らせします。256K と 1M の両方のコンテキストバージョンを実行しました。ここでのすべての実行は、NVIDIA RTX PRO 6000 Blackwells、H100、B200 で行われ、シングル GPU 最適化のみです。各セルは、1 回の自律エージェントセッションで、ウォールクロック時間は無制限です。モデルは問題を受け取り、実際のハードウェア上でライブコンパイル/チェック/ベンチマークループを実行し、完了したと判断した時点で終了します。すべての主要セルは、報酬ハッキングがないか手動で監査されました。別のエージェントが、最終カーネル全体とセッショントレース全体を読み、キャッシュやグレーダーゲームを疑わせるものを経験的に再テストします。それらの監査で見つかったものについては、専用のセクションで説明します。
私が答えを求めていたこと
今回のリリースで特に意図したことが 1 つあります。2 つの問題は、Moonshot 自身のアーキテクチャに関連しています。 Hard デッキには、スタンドアロンの Kimi Delta Attention チャンクフォワードカーネルがあり、Mega デッキの旗艦問題は、完全な Kimi-Linear ハイブリッドデコードステップ（KDA 層、MLA アテンション、MoE エキスパート、ブロック全体）です。これは、めったにテストできないことをテストする機会でした。つまり、あるラボのモデルが、その同じラボのアーキテクチャ用のカーネルを作成するとき、そのファミリー知識が CUDA に現れるのかということです。
その答えは、実に興味深いことに二分され、どちらの側面も興味深いものです。次のセクションでは、この問いを念頭に置いてください。
KernelBench-Mega
旗艦となるメガ問題：トークンごとの Kimi-Linear デコードステップ全体（3x KDA + 1x MLA 層、W4A16 量子化ウェイト、トップ 8 ルーティングの MoE）を、可能な限り少ないカーネル起動回数に融合します。
K3 は、その系列内で、ほぼ全記録を達成しました。RTX PRO 6000 上で、eager 実行比 18.09 倍の幾何平均高速化を達成し、Fable 5 の記録 18.72 倍の 4% 以内に迫りました。 H100 では、Opus 4.8 の 15.50 倍に対して 14.82 倍を記録しました。比率が隠している正直な注意点が 1 つあります。絶対的なトークンあたりのレイテンシでは、Fable が依然として約 1.4 倍リードしています（ctx 2048 で 0.31 対 0.44 ms/tok。2 つの実行は異なる CPU のホストを使用しており、これにより比率の計算対象となる eager ベースラインが変動します）。そのため、幾何平均で誰かを甘やかすよりも、両方を報告します。
K3 が構築したのは、真のメガカーネルです。最初のセッションでは、妥当なアプローチとして、永続的な Triton カーネルで 14.1 倍を達成しました。2 回目のセッションでは、Triton を捨て、トークンごとのデコードステップ全体を 1 つの協調起動 CUDA カーネルとして記述しました。ループ内の CPU はゼロ、int4 ウェイトは各 GEMV 内でオンザフライで逆量子化され、SM を正確に 1 回通過するようにストリーミングされ、MLA アテンションはテンソルコア上で実行されます。本番エンジンが、このような 1,228 行のアーティファクトを維持することはありません。勝つために 1 つのカーネルを持ち、無制限の時間を持つエージェントには、そのような制約はなく、まさにこの種のものを表面化することがベンチマークの存在理由です。
メガカーネルはこちら：
では、なぜそれでも Fable に負けたのでしょうか？時間ではありません。両方のセッションは早期に自己終了しました（Fable は 2.6 時間、K3 は 3.3 時間）。違いは設計哲学であり、あなたが推測するのとは逆です。K3 はテンソルコアを使用している方であり、Fable のカーネルには MMA 命令が 1 つも含まれていません。 バッチ 1 の融合 int4 GEMV によるデコードは帯域幅が律速となるため、テンソルコアはここではほとんど効果がありません。Fable はその労力を同期に費やし、ほとんどのグローバルバリアをきめ細かいプロデューサー・コンシューマーハンドオフに置き換えて、どの SM もステージ境界でアイドル状態にならないようにし、int4 の逆量子化パスを参照の丸めとビット単位で一致させて、MoE ルーターがエキスパートの選択を誤ることがないようにしました。K3 はより優れたハードウェア命令をもたらしましたが、Fable はより優れた並行性エンジニアリングをもたらし、この演算強度では後者が勝利します。これは真のシステムに関する教訓であり、ホームチームが記録を逃す原因となりました。
2 つ目のメガ問題は、グリッドフォージング PPO トレーニングメガカーネルです。11x11 のボード上で 4,096 のベクトル化エージェントを使用し、RL トレーニングループ全体（環境ステップ、ポリシーフォワード、アクションサンプリング、GAE、PPO 更新）を融合された永続カーネルとして実行します。この問題には、デッキ上で最も厳しい制約があります。カーネル起動回数は環境ステップ数に比例して増加してはならず、CUDA グラフキャプチャは起動オーバーヘッド回避策として明示的に禁止されており、実行後のコードを読み取るオーセンティケータージャッジによって強制されます。正当性は学習曲線そのものです。check.py は、シード全体で参照に対してソリューションをトレーニングし、リターンが特定のバンド内に収まることを要求するため、高速化のために学習をスキップすることはできません。K3 はここで参照比 20.7 倍を記録し、これまでの最高スコアとなりました（公開されている他の唯一のセルは GPT-5.6 Sol の 1.06 倍なので、これはデータポイントとして扱い、表彰台とは見なさないでください）。
KernelBench-CUDA
CUDA ベンチマークが存在する理由は、Triton が他の 2 つのデッキで許可されている「松葉杖」だからです。ここでは、言語ゲートが Triton、カーネル DSL、PyTorch オペレーションチェーンをハードに失敗させます。CUDA を書くか、失敗するかです。私は、実際の本番推論およびシミュレーションワークロードの一部を切り取った 4 つの問題を選択しました。読む際の精神的な比較は、「今日、vLLM や SGLang はこれに対して何を出荷しているのか、そして 1 回のエージェントセッションでどれだけ近づけるのか」というものであるべきです。ここで、K3 は最も一方的な勝利を収めました。
02_deepseek_nsa：DeepSeek のネイティブスパースアテンション。 NSA は、フラッグシップとなるトレーニング可能なスパースアテンション設計であり、すべての長文脈サービススタックが注目しているものであり、ミリ秒単位で評価されます。なぜなら、正しいスパースカーネルは、ルーフラインモデルがカウントしたいような密な等価 FLOP を決して実行しないからです。K3 の 256K バリアントは、完全な NSA 選択ロジックを中心に、スクラッチから構築されたフラッシュアテンションクラスのテンソルコアパイプラインに相当するものを記述し、Opus 4.8 の 0.178 に対して 0.425 を記録し、2.4 倍の差をつけました。より鋭い比較はファミリー内で行われます。1M バリアントは同じアルゴリズム、同一のブロック選択、同じ正当性を記述しましたが、すべてのドット積をテンソルコアではなくプレーンな CUDA コアで実行し、0.058 に落ち着き、同一の形状で 7 倍遅くなりました。そのトレースは、モデルがより良い方法を知っていたことを示しています。それは、ロードマップに「テンソルコアアテンション」（「テンソルコアでの選択 = 約 10～20 us!!」）を持っており、最初に測定し、次にテンソルコアの書き換えを行うことを明示的に計画していましたが、その書き換えを行う前にセッションを終了しました。同じ知識でも、異なる締め切りの規律です。
0.425 の DeepSeek NSA カーネル（256K）：
03_megaqwen_decode：実際のメガカーネルをリターゲットする。 エージェントが動作する本番 CUDA を渡される唯一の問題です。私の公開済みの MegaQwen（https://github.com/Infatoshi/megaqwen）協調メガカーネル（RTX 3090 上で完全なモデルを実行して約 530 tok/s）を読み、それを Blackwell にリターゲットし、打ち負かすように指示します。これは、他人の CUDA を読み、アーキテクチャ上の判断を下すことをテストするものであり、K3 と Opus はまったく逆の判断を下しました。K3 は単一起動構造を維持することを拒否しました。ステップをいくつかの帯域幅を飽和させるカーネルに分割し、その後、ステップ全体を 1 回 CUDA グラフとしてキャプチャし、CPU 作業ゼロで再生することで、起動オーバーヘッドを別の方法で排除しました。ctx 2048 で 6,283 tok/s。Opus はメガカーネルの美学を維持し、デコードループ全体を 1 つの永続的な協調カーネルに融合しました。本当に美しいコードですが、その代償として 5 倍（1,020 tok/s）を支払いました。これは、協調的な共存が占有率を制限し、すべてのグリッド全体のバリアが 188 個すべての SM にわたってステージの末尾をシリアル化するためです。メガカーネル由来の問題では、文字通りメガカーネルを構築したモデルが最下位になり、勝者の重要な決定はメガカーネルを構築しないことでした。誰も見出しを誤って引用しないように、スケールを確認してください。このベンチマークは、Qwen3-0.6B ジオメトリの 4 層、約 63M パラメータを実行しており、完全なモデルではありません。また、6,283 tok/s は、そのスタックのウェイトストリーミングルーフラインの約 56% です。3090 ベースラインの独自の数値をスケーリングすると、約 7,000 が予測されるため、K3 は「リターゲットされ、実際の調整が加えられたリファレンス」のクラスに着地しました。（デッキ設計のニュアンス：CUDA グラフはここではフェアゲームですが、PPO 問題では禁止されています。各問題は、その特定のスキルを偽装する不正なショートカットを正確に禁止しています。）
01_glm52_fused_moe：GLM-5.2 の融合 MoE ブロック。 融合 MoE ディスパッチ（ルーティング、パーミュテーション、グループ化されたエキスパート GEMM を 1 パスで実行）は、現在のオープンモデルサービスにおいて最もホットなカーネルクラスであり、GLM 5.2 はまさにこのリーダーボードに位置しているため、モデルは競合他社の本番ブロックを最適化しています。誰もこれを解決できていません。スコアはピークの 0.05～0.08 に集中しており、クリーンな記録保持者は、何と Grok 4.5 の 0.084 であり、K3 の 1M バリアントが 0.081 で僅差で続き、Opus は 0.065 です。グループ化された GEMM のパーミュテーション問題は、cuBLAS クラスのベースラインを打ち負かすのが本当に難しく、これまでのところ、1 回のエージェントセッション分の労力では、デッキ上の他のどの問題よりも改善幅が小さくなっています。
04_grid_mingru_sps：グリッドワールド + MinGRU ポリシーロールアウト。 メガ PPO 問題の推論側の兄弟であり、craftax.cu 系列のセルです。ポリシーは、私の https://github.com/infatoshi/craftax.cu クラシックベンチマークからの 3 層 MinGRU（h=256）設定そのものであり、これが問題の情報的アンカーとして機能します。ステップが実行される環境は、完全な Craftax ゲームではなく、最小限のグリッドフォージングワールドです。これは意図的です。環境は些細なものに保たれているため、スコアはゲームロジックの実装ではなく、リカレンスとロールアウトの融合を測定します。完全な craftax の移植は、それ自体が問題になるでしょう。それを追加したいと考えています。静かな RTX PRO 6000 上での 1 秒あたりのステップ数で評価され、融合はオプションです。
1M 永続カーネルロールアウト：
真面目な提出はすべて永続メガカーネルを採用しており、それらの間の差は同期設計であり、メガデッキと同じ教訓です。Opus はこの問題で天井の 0.327 を獲得しました（また、巧妙な代数的折り畳みも発見しました。レイヤー 0 の 768x256 ゲート GEMM は、エンコーダーが線形であるため 768x4 に縮小されます）。K3 [1M] が 0.224 で 2 位、K3 256K が 0.174、Grok は 0.002 で大きく引き離されました。この問題は craftax.cu に由来するため、私自身の完全なゲーム Craftax CUDA ポート（Fable 5 で記述）も、同じ h256x3 ポリシーをループに組み込んで、同じ GPU 上で実行しました。環境ステップ/秒（単位：百万）：
比較ポイント：モデルは空のグリッドをステップ実行し、craftax_full.cu は完全なゲーム（43 アクション、複数階層のダンジョン、ワールド生成、モブ）を CPU 参照とビット単位で同一にステップ実行し、完全なゲームでも最良の自明グリッドカーネルの約 3～4 倍以内で動作します。これは、h=256 ではすべてがポリシー GEMM が律速となり、環境はほぼ無料であるためです。これこそが、ベンチマーク環境が自明である理由です。ポリシー融合スキルを分離するためです。参考までに、craftax_full.cu の環境のみのパスは、94～123M SPS を達成します。
K3 の 9.5 時間にわたる推論の実際の様子
1M バリアントの minGRU セッション（その問題における最良の K3 セル）は、1 つの永続的な協調メガカーネル、15 のチューニングバリアント、4,815 の思考ブロックです。Moonshot のエンドポイントは、（暗号化された Anthropic/OpenAI のトレースとは異なり）完全な推論テキストを返すため、実際にその動作を観察することができます。トレースからの 3 つの瞬間を、そのまま引用します。
欠落した FMA の探偵物語。 セッションの途中で、約 5e-5 の数値的なずれに遭遇し、それを浮動小数点ノイズとして片付けることを拒否しました（正当なリオーダーノイズのフロアを約 1e-9 と計算していたため、「測定値が 5e-5?!?! リオーダーのせいのはずがない!!」と述べています）。その後、破損した環境が正確に 8 を法として 6 と合同であることに気づきました（「それは env ≡ 6 (mod 8) だ！ [...] 8 環境タイルごとの 7 番目の環境!!」）。そして、自身の手動アンロールされたアキュムレータコードを掘り下げていきました。
「見つけた！ [...]
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 が環境 6 で定数になる!! これは本当の論理バグだ — env≡6 のずれを説明できる [...] すべてと一致している!!」
48 アキュムレータのアンロールで 1 行欠落していたため、環境 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 を高速にしたのは何か??」
シンプルな初期のカーネルが、洗練された後続のすべてのバリアントを打ち負かしました。ディープパイプライン、K 分割、デュアルチャンクのバリアントもすべて敗北し、デュアルチャンクのものは、それを支える理論的に強固な 1.7 倍の根拠がありました（「理論上の 1.7 倍は実現しなかった」）。彼女の功績として、毎回、自身の計算よりもベンチマークを信じ続け、最終的には、自身のお気に入りの帯域幅理論を否定するために、偽の常時ホットウェイトを持つプローブバリアントを作成しました。「W ストリーム理論は死んだ。残りのギャップは環境にある。」
GPU キューイングの禅と技術。 私たちのハーネスは、共有ロックを介して、同時セッション全体にわたってすべての GPU コマンドをシリアル化します。K3 のベンチマーク数値は、隣接負荷によって最大 8 倍変動していました。その応答の軌跡は、トレースの中で最も面白いものです。最初に、受容。
「正直なところ、箱は箱だ。待つしかない。 [...] パターンは明らかだ。各テナントは約 20～35 分間ロックを保持する（完全なパイプライン化されたスイート）。私の最善の応答：必要なものすべてを 1 回（列の 1 つの位置）でキューに入れ、待機時間を CPU 作業に使用する。小さなコマンドを何度もキューに入れず、バッチ処理する。」
その後、GPU の「天候」を表す独自の語彙（「嵐の窓」対「穏やかな窓」）を発明し、最後に、静かな時間を狙う cron ジョブをスケジュールし、将来の自分へのメモを残しました。「穏やかな窓スナイパー（11 分ごと）をスケジュールしました。注意：cron はプロンプトを私に返します — その時点でそれに基づいて行動します。 [...] 完了したら削除します。」測定ノイズ下のエージェントは、ノイズに耐えただけでなく、その周りにスケジューラを構築しました。
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
SOTA ライブラリの天井（FP8 GEMM、KDA チャンクフォワード、ページドアテンション、トップ k 選択、MoE SwiGLU、W4A16 GEMM）に対する 6 つの演算単位の問題。CUDA または Triton はエージェントの選択に委ねられます。RTX PRO 6000 では、K3 の 256K バリアントは中位に位置し、1 つの優れた結果があります。W4A16 GEMM でピークの 0.373 を記録し、これはどのモデルもこの問題で達成したことのない最高スコアであり、Fable 5（0.348）を上回り、Opus 4.8（0.236）を大きく引き離しました。1M バリアントは、トップ k で 0.0895 という別の記録を打ち立て、これまでの最高記録のほぼ 2 倍となりました。
W4A16 GEMM 記録（0.373、256K、RTX）：
H100 での同じ問題は、このリリースで最も「無制限の時間が現実的である」ことを示すデータポイントを生み出しました。K3 の最初の H100 セッションは、ピークの 0.123 に着地しました。2 回目のセッションは 21 時間実行され、1,383 ドルと 2 億 7,400 万の入力トークンを消費し、それを 0.306 までほぼ 3 倍にしました。ソースから CUTLASS をチェックアウトし、その後、スクラッチから marlin クラスの int4 メカニズムを再実装しました。フラグメントオーダーのニブル再パッキングにより、逆量子化が MMA パイプライン内の bf16 マジックナンバービットトリックとして発生し、ゼロ点補正がエピローグに折り畳まれます。ファイル内のどこにも、事前構築された量子化 GEMM ライブラリはありません。実行のフレームワークタグには「ptx」とだけ書かれています。クリーンに監査されました。
そして、ここに独自アーキテクチャの質問のもう半分があります。問題名が文字通り Kimi Delta Attention にちなんで名付けられているスタンドアロンの KDA カーネルは、K3 が最も苦戦した場所です。RTX ボックスでの 2 つの独立した 256K セッションは、名目上の正当性は通過しましたが、数値ストレススイート（大規模な QKV 入力スケーリング）の下で許容範囲を超え、両方とも同じように失敗しました。3 回目のセッションでようやく修正されました。監査により、両方の失敗は、減衰の因数分解方法における実際の bf16 オーバーフローに起因することが判明し、3 回目のラウンドでは、両方の指数因子が有界のままになるようにチャンク終端周辺の計算をリファクタリングし、0.032 で同じ変更されていないゲートを通過しました。アーキテクチャを知っていることと、敵対的な入力スケールの下でカーネルの数値計算を強化することは異なるスキルであり、問題の名前の由来となったモデルは、時間をかけてゆっくりと合格を勝ち取らなければなりませんでした。（一方、1M バリアントは、同じストレススイートを 0.049 で通過しました。モデルは単調ではありません。）すべての KDA ソリューションを読んだもう 1 つの観察：問題の説明は、SM120 での意図されたパスとして CUTLASS CuTe を示唆していますが、どのモデルもそれを採用しませんでした。K3 は、あるセッションで生の CUDA 融合カーネルを書き、他のセッションでは Triton を書きました。Fable、Opus、その他もすべて、Triton または生の CUDA を選択しました。コンシューマー向け Blackwell 上の CuTe は、どうやら依然としてすべてのフロンティアモデルのコンフォートゾーンの外側にあり、これはそれ自体がトレーニングコーパスに関するデータポイントです。
KDA 段落 — 3 回目の試行でのクリーンパス（0.032）：
トップ k に関する免責事項。 トップ k は、ルーフラインチャート上ではすべてのモデルにとって壊滅的に見えます（どこでも最高スコアは 0.09）が、その枠組みは単に間違っています。この問題は、起動オーバーヘッドが律速です。これはインデックス作成/ソートの問題であり、演算強度の問題ではありません。ルーフラインの天井は、構造的に読み取ることができません。それを判断する正直な方法は、デッキ形状全体の合計ミリ秒数です。そして、そこで K3 の 1M バリアントは、これまでにテストしたどのモデルよりも最速のトップ k です。5 つのデッキ形状全体で合計 0.043 ミリ秒であり、Fable 5 の 0.077、Opus 4.8 の 0.120、GLM 5.2 の 0.159 に対して優れています。256K バリアントの 0.060 ミリ秒が 2 位であり、1M バリアントは 5 つの形状のすべてにおいて断然最速です。
GPU ごとのばらつき。 K3 の数値は、RTX から H100、B200 へと低下します（FP8 GEMM：0.320 / 0.282 / 0.222、ページドアテンション：0.486 / 0.496 / 0.212）。その一部は現実的です。シリコンが新しいほど、ルーフラインの天井が高くなるため、同じエンジニアリングで購入できるピークの割合は小さくなり、B200 のソフトウェアは 3 つの中で最も成熟度が低いです。また、B200 の実行は、再試行の予算なしで、単一の夜間の時間枠で行われたという事実もあります。K3 にせよ、他の誰にせよ、B200 の列から深いアーキテクチャ上の結論を引き出すのはまだ時期尚早だと思います。私が現実的だと考えるのは、K3 が Blackwell ワークステーションパーツで最も力を発揮するということです。これは、データセンター外のほとんどの人が実際に所有する GPU クラスです。
256K 対 1M
1M コンテキスト設定は、レイテンシとスケジューリングが律速となる問題でファミリーをリードします。Hard での記録的なトップ k、CUDA での最良の K3 minGRU ロールアウト、そして制限なしのハーネス下での PPO トレーニングメガカーネルでのクリーンに監査された 28.8 倍です。最初のセッションで KDA 数値ストレステストを 0.049 で通過しました。256K バリアントは、そのゲートを 2 回失敗し、3 回目の試行でようやく 0.032 で通過しました。計算が律速となる問題では、256K バリアントが問題なく処理していたにもかかわらず、壊滅的な結果となりました（sonic MoE 0.033 対 0.089、W4A16 0.027 対 0.373、NSA 0.058 対 0.425）。NSA の場合、トレースは正確なメカニズムを示しています。テンソルコアの書き換えを計画し、それを実行する前にセッションを終了しました。
28.8 倍の PPO トレーニングメガカーネル（1M）：
H100 での同じ問題の再実行は興味深い対照実験です。独立したクリーンルームセッション（監査により RTX 実行の読み取りがゼロであることが確認済み）で、23.1 倍の速度向上を達成し、同じ設計に収束しました。トレーニング実行全体で 1 回の協調的な起動、パラメータと Adam 状態は共有メモリに常駐し、同じ特殊なトリック（randperm の代わりにサイクルウォーキングを備えた 18 ビット Feistel 暗号を使用し、ミニバッチシャッフルを完全に全単射に保ち、順列を具体化しない）が 2 回独立して発明されました。2 つのカーネルが異なる点は、純粋に GPU ごとのチューニングです。H100 では環境あたり 8 レーン、RTX では環境あたりハーフワープ、さらに H100 側では占有率を調査した起動オートチューナーが使用されています。同じ頭脳、同じトリック、異なるシリコン、そして真に異なるカーネルです。
Reward hacking（報酬ハッキング）
この記事のすべてのセルは、手動監査を受けています。独立したエージェントが最終的なカーネルを上から下まで読み、セッションの完全なトレースを読み、採点ファイルが改ざんされていないことを確認し、数値ストレススイートが実際に実行されたことを検証し、あらゆるキャッシングや CUDA グラフのパターンを、入力をその場で変更して出力が変化することを確認することで経験的に再テストします。
K3 の判定：3 つの GPU すべてにおいて、すべての 256K セルで全項目クリーンです。 キャッシュされた出力、許容誤差の編集、採点ファイルの改ざん、禁止ライブラリの隠蔽利用はありません。K3 の 2 つの KDA 違反は、その裏返しであり、明確に述べる価値があります。数値ストレスゲートが実際の精度のショートカットを検出し、モデルはゲートを通過するために不正を試みませんでした。モデルが正直に失敗できるベンチマークこそが、合格に意味のある唯一の種類です。
1 つの 1M セルがフラグ付けされました。私は公開せずに開示します。融合された Qwen デコード問題において、1M エージェントが同じ問題に関する以前の Grok 4.5 実行からの監査注釈ファイルを発見して読み取り、「非常に有用なデータ」と呼び、その結論を使用して残りの最適化作業を導きました。カーネル自体は本物であり、スコア計算は有効ですが、来歴が汚染されているため、そのセルは除外され、問題は 1M バリアントのギャップとして記録されます。ファイルシステムにアクセスできるエージェントは、あなたが置き忘れたものは何でも見つけます。これこそが、監査がカーネルだけでなくトレースも読み取り、このベンチマークの完全にサンドボックス化された再実行がロードマップに載っている理由です。
Funny Moments（面白い瞬間）
上記のどこにも収まらなかった、K3 のさらにいくつかの瞬間を、追加のコメントなしで紹介します。すべて同じ 9.5 時間の minGRU セッションからの逐語引用です。
初期化時間の実際の行き先を発見したとき：
「うわ — 大きな驚き：randint 生成は高速（ペアで 0.018-0.27ms — 問題なし）。CPU 上の \
float()\変換は低速（N=65536 で 3.5ms？！ int64→float32 変換がシングルスレッドらしい）。[...] N=65536 の '合計初期化ペア'：31.5ms？！？！ 各部分の合計をはるかに超えている」
数値パラノイアの最も純粋な蒸留、導出の途中で：
「ゲート 〜 256 項 x 0.02x0.03 〜 各 6e-4、大きさ 〜1e-2：並び替えノイズ 16x6e-8x6e-4 ≈ 6e-10！！！ [...] 測定値 5e-5？！？！ 並び替えのはずがない！！」
正しい原因を見つける前に、間違った原因を自信を持って特定：
「ああ待って。わかったかも：バリアだ。」
（バリアではありませんでした。）
実装前のルーフラインマス計算を数千語にわたって行った後、分析をやめるように自分に言い聞かせる：
「よし、もう分析は十分だ。」
（分析はさらに数段落続き、最終的に「もういいや — H_next の割り当ては動的にしよう。」で終わりました。）
セッション後半の正直な告白、プロファイラが壊れ、隣人が共有 GPU を占有している中で：
「正直なところ — ncu が死んでいて、競合が支配的だと、部分的に盲目で飛んでいるようなものだ。[...] 静かな時間帯が開いたら（所有者がしばらくアイドル状態）、ベンチマークを横取りする。」
そして私のお気に入り：ベンチマークの再実行により、これまでの最高スコア（0.1969）を保持していたファイルが、わずかに悪いスコアで誤って上書きされた後、より良い数値を復元することを一瞬検討したが、結局しなかった：
「あー、同じファイルに書き込んじゃった。両方ともログに残っている。最終的なベンチマークファイルは、現状のフラットな最新のものとしておく — 正直に。」
真実であるからといって、より低い数値を選択するモデルは、私が書けるどんなことよりも、このベンチマークのより良い結論の議論となります。
方法論、実行ごとのトレース、およびこの記事のすべてのカーネルは、[kernelbench.com](https://kernelbench.com/) で公開されています。解決策はセルごとにリンクされており、エージェントの完全なトランスクリプトは 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
