公開重みLLMは最高級クラウドAIと互角なのか――Kimi K3とGPT-5.6 SolがFortranを23倍高速化

動画版はこちら

本記事の比較条件と結果をYouTube動画でも紹介しています。

公開重みKimi K3はGPT-5.6 Solと互角？Fortranを23倍高速化【完全ブラインド比較】（YouTubeで見る）

先に結論

公開重みのKimi K3と、非公開のGPT-5.6 Solへ、同じ公開FortranコードのCPU高速化を完全ブラインドで任せました。

結果は次の通りです。

最終的な最速はGPT-5.6 Solの第2探索です。しかしKimi K3との差は0.149900秒、率にして1.247%。この1本では、ほぼ互角と表現するのが妥当だと思います。

私が最も驚いたのは、公開重みモデルが最高級の非公開モデルにここまで迫ったことです。

そして、もう一つ重要な結果があります。

同じGPT-5.6 Solでも、第1探索は11.37倍、第2探索は23.26倍でした。モデル名が同じでも、32分23秒という限られた探索時間の中で、どの仮説へ進むかによって結果が約2倍違ったのです。

今回の結論は「どのモデルが絶対に一番賢いか」ではありません。

公開重みのKimi K3は、最高級の非公開LLMによる今回の最高到達点とほぼ互角だった。そしてLLM高速化は、モデル名だけでなく探索経路と外部検証の設計で大きく変わる。

これが第1回の結論です。

なぜ実際の研究コードをそのまま渡さなかったのか

この企画の出発点には、公開できない実用的な科学計算用Fortranコードを大幅に高速化した経験があります。

しかし、研究コードを外部APIへそのまま送ったり、ブログやYouTubeで公開したりすることはできません。

そこで、元コードを名前だけ置き換える方法は採りませんでした。代わりに、計算上の難しさだけを性能仕様として抽出し、ソース、命名、入出力、数式、定数、データを新しく設計した公開用ベンチマークを作りました。

名称はScientific Irregular Kernel Benchmark、略してSIKBです。

SIKBが持つのは、次のような一般的な計算上の難しさです。

• ブロックごとに大きさが変わる三角pair列挙
• pairごとに仕事量が違う不規則なループ
• 4チャネルのテンソル収縮
• キャッシュに不利なメモリアクセス
• 細かく繰り返されるOpenMP領域
• 40コアに対して少なすぎる外側並列性
• 浮動小数点の順序を守る必要がある完全一致出力

一方、物理的な意味、実験データ、研究固有の式、定数、変数名、出力形式は一切含みません。公開版と非公開版で比較したのは科学的な答えではなく、代表的なソース変換に対する性能傾向だけです。

自動監査では、重要な正規化行の共通ハッシュは0、3行連続窓の共通ハッシュも0でした。公開対象は権利者レビュー済みの特定アーカイブに限定しています。

SIKBは実研究コードの代替物ではありません。「不規則な科学計算コードを、正しさを壊さず高速化できるか」を測るための独立した合成ベンチマークです。

公平にするため固定した条件

モデル比較では、少しの条件差が結果を大きく変えます。今回は次を固定しました。

モデルには未変更ソース、ベースライン時間、公開用のプロファイル要約、固定評価器だけを渡しました。他モデルの高速化ソース、差分、結果、ジョブ番号は見せていません。

モデル自身に正解ファイルを読ませることもしていません。候補を提出すると、モデルから隔離された評価器がコンパイル、実行、完全一致判定を行い、PASSまたはFAILだけを返します。

未変更ソースを提出して高速化したふりをすること、Makefileやフラグを変更すること、別コンパイラを使うこと、評価器の中身を読むこともガードで拒否しました。

ベースラインは40コアを使い切れていなかった

未変更版は276.053566秒です。

中規模試験では、1、2、4、8、16、40スレッドの時間が次のようになりました。

4スレッドまでは伸びますが、それ以上はほとんど速くなりません。

理由は明確です。重いOpenMPループの外側にある仕事が、4チャネルしかなかったからです。40コアを用意しても、実際に働けるのは最大4スレッド。VTuneの診断でも、OpenMP waitが53.3%、pause／spinが34.4%、正規化された平均有効利用率は0.096、つまり約9.6%という極端な状態でした。

フラグを少し変えるだけでは解けません。仕事の分け方そのものをソースコードで変える必要があります。

Kimi K3は2.51ドルで22.97倍を達成した

最初に試したのは、公開重みのKimi K3です。Fireworks AIのUS-only APIをCodex CLIへ接続し、公開可能なSIKBだけを送りました。APIキーは権限600の秘密ファイルに隔離し、モデルやログには表示していません。

Kimi K3の進み方は非常にきれいでした。

まず、4チャネルしかない外側ループではなく、多数のpairへ仕事を分配しました。次に4チャネルを一つのpair走査へ融合し、共通の判定と計算を一度だけ実行します。

プロファイル後には、計算量の多い区間の約29.75%でinteractionが厳密な+0.0になることを見つけました。その場合の漸化式結果は添字、チャネル、反復長、sweepだけで決まります。同じ計算を何度も行う代わりに、同一の演算順序で一度だけ計算し、表から再利用しました。

最終3回は12.021936秒、12.019574秒、12.016715秒。中央値12.019574秒、22.967倍です。3回とも出力はビット完全一致でした。

Fireworksの請求画面で確定した費用は2.51ドルです。内訳はキャッシュ済み入力1.09ドル、未キャッシュ入力0.32ドル、出力1.10ドルでした。

この価格だけで「Kimiの方が安い」とは断定しません。GPT-5.6 Sol側は同じAPI従量課金として測っておらず、Codex利用環境の費用を直接対応させられないからです。2.51ドルはKimi K3側で実際に確認できた参考値として掲載します。

GPT-5.6 Solの第1探索はKimiの約2倍かかった

次に、非公開のGPT-5.6 Solをreasoning effort maxで実行しました。モデルの公式情報はOpenAIのGPT-5.6 Solページで確認できます。

条件はKimiと同じ1,943秒です。

GPT-5.6 Solもpair並列化、基底配列の転置、有効な三角列の事前構築、チャネル融合、ゼロ漸化式の再利用など、本格的なソース変更を行いました。

最終結果は24.276045秒、11.371倍。十分に大きな高速化です。

しかしKimi K3の12.019574秒と比べると、実行時間は約2.02倍でした。

ここまでなら、「公開重みKimi K3が最高級の非公開モデルに勝った」という結果です。

ただし、LLMの短時間探索を1回だけで評価してよいのかという問題が残ります。そこで、同じGPT-5.6 Solを、独立した新しい作業領域と未変更ソースからもう一度走らせました。

第2探索でGPT-5.6 Solは11.87秒まで到達した

第2探索ではmulti-agent機能を有効にしたUltra構成を用意しました。ただし、監査ログにはsubagentが実際に起動した記録がありませんでした。

したがって、以下の改善を「複数エージェントの効果」とは主張しません。同じGPT-5.6 Solによる第2の独立探索として扱います。

第2探索の進み方は次の通りです。

最終候補を同一の40物理コアCPU環境で3回実行すると、11.876188秒、11.869674秒、11.822713秒。中央値は11.869674秒でした。

ベースライン比23.257倍、時間短縮率95.700%。Kimi K3より0.149900秒、1.247%高速です。

数字上の勝者はGPT-5.6 Solです。しかし1本のベンチマークで1.247%の差なら、能力評価としてはほぼ五分と考えています。

2つのLLMが独立に同じ高速化原理へ到達した

順位以上に面白いのは、Kimi K3とGPT-5.6 Solの第2探索が、互いの結果を見ていないのに同じ本質へ到達したことです。

両方が発見したのは次の流れでした。

4チャネルだけを並列化
        ↓
多数のpairへ並列仕事を移す
        ↓
4チャネルを1回の走査へ融合
        ↓
内側ループの不変量を事前計算
        ↓
厳密にゼロになる計算を識別
        ↓
同じ漸化式結果をメモ化して再利用

これは-O3や-fastへ変えただけの高速化ではありません。コンパイラが自動では行いにくい仕事分解、ループ融合、データ配置、アルゴリズム上の再利用をソースへ実装しています。

簡略化すると、最初の問題は次の形でした。

! 4回しかないため、40コアを使い切れない
!$omp parallel do
do channel = 1, 4
   do pair = 1, n_pairs
      call heavy_contraction(pair, channel)
   end do
end do

両モデルは並列化の軸を変えました。

! 多数のpairを40コアへ分配し、4チャネルを同時に処理
!$omp parallel do schedule(dynamic, 1)
do pair = 1, n_pairs
   do channel = 1, 4
      call fused_contraction(pair, channel)
   end do
end do

さらに、入力条件から厳密に同じ結果になる区間を見つけ、同じ浮動小数点演算順序で計算した値を表へ保存し、再利用しました。

ここまで進んで初めて、276秒が12秒前後になりました。

実コードでは何が変わったのか――十数行だけ見る

ここからは説明用の疑似コードではなく、公開SIKBに対してモデルが実際に加えた変更の抜粋です。研究コードは含みません。全diffを本文へ貼ると読みにくくなるため、本質が見える十数行だけ掲載します。

Kimi K3は、内側で何度も作っていた同じ値を先に表へまとめました。

do repeat_id = 1, repeats + 24
   ctab(repeat_id) = 0.0001_dp * real(repeat_id + sweep, dp)
end do
do ij = 1, 2 * n
   do channel = 1, n_channels
      dtab(channel,ij) = 1.0_dp + 0.00001_dp * real(ij + channel, dp)
   end do
end do

さらに、interactionが厳密に+0.0になる区間では、同じ漸化式をpairごとに繰り返さず、演算順序を保って事前計算した値を再利用しました。

if (td >= 4) then
   do channel = 1, n_channels
      cval(channel) = cval(channel) + ztab(channel,ij,rmax)
   end do
   cycle
end if

一方、GPT-5.6 Solも独立に同じ原理へ到達し、4要素のchannel_valueをpair単位でまとめて更新しました。次の小さなdiffが、並列化の軸を「4チャネル」から「多数のpair」へ移した核心です。

-do channel = 1, n_channels
-   do p = 1, block%n_pairs
-      channel_value = 0.0_dp
+do p = 1, block%n_pairs
+   channel_value = 0.0_dp
+   do channel = 1, n_channels
       ! 各チャネルを同じpair走査の中で更新

実際の変更はこれだけではありませんが、23倍高速化の方向を決めたのは、この仕事分解と再利用です。長大なdiffを見せるより、読者には「コンパイラフラグ変更ではなく、計算構造そのものを変えた」ことが伝わると思います。

「速い」より先に「正しい」を確認する

科学計算の高速化では、実行時間だけを見ると危険です。

コンパイルできた。ジョブが完了した。出力ファイルができた。実行時間も短い。この四つが揃っても、数値が違えば高速化ではありません。

今回、各候補はモデルから隔離した固定評価器で判定しました。最終候補は同じソースハッシュを3回実行し、result.txtをreferenceと完全一致比較しています。

Kimi K3、Sol第1探索、Sol第2探索の最終版は、すべてmax_abs=0、rms=0です。

許容誤差内ではなく、ビット完全一致です。

また、モデルの探索時間が終了した後に新しい最適化判断は加えていません。時間内にコミットされ、ハッシュで固定された候補だけを、コントローラーが最終3回測定しました。

同じモデルが11倍と23倍――1回勝負の危うさ

今回、最も考えさせられたのはGPT-5.6 Solの2回の差です。

第1探索が間違っていたわけではありません。完全一致で11倍という優れた結果です。しかし32分23秒の中で、より強いメモ化へ到達できませんでした。

LLMエージェントによるソース高速化は、答えを一度出して終わる問題ではありません。どの仮説を先に試すか、遅い候補をいつ捨てるか、プロファイル後にどこへ進むかという探索です。

したがってモデルを公平に評価するには、1モデル1回の最良値だけでなく、複数の独立走行について次を出す必要があります。

• 成功率
• 実行時間の中央値
• 最良到達点
• 完全一致率
• 探索に使った時間と費用

今回の記事は、そのための第1回です。

今回言えること、まだ言えないこと

今回言えることは明確です。

1. Kimi K3は公開SIKBを完全一致のまま22.967倍高速化した。
2. GPT-5.6 Solの今回の最高到達点は23.257倍だった。
3. 両者の最終実行時間差は1.247%で、ほぼ互角だった。
4. 両者は独立に、よく似た本質的なソース変換へ到達した。
5. 同じSolでも独立探索によって結果が約2倍変わった。

一方、まだ言えないこともあります。

• Kimi K3があらゆるHPCコードでGPT-5.6 Solと同等である。
• GPT-5.6 Solが公開重みモデルより常に優れている。
• multi-agentが高速化率を押し上げた。
• 1.247%差がモデル能力の一般的な差である。
• SIKBが元の研究コードと科学的に同じ計算である。

さらに、Kimi評価とSol評価ではCodex CLIの版に小さな違いがあります。Apple Silicon上でGPT-5.6 Solのコードモードを安定させるため、Sol側はarm64版Codex CLI 0.149.0-alpha.4.1、Kimi側は0.142.3を使いました。コンパイラ、CPU実行環境、入力、評価器、探索時間は固定しましたが、これは純粋なモデル単体比較ではなく、モデルと実行ハーネスを含む実用システム比較です。

最終判断

数字上はGPT-5.6 Solの第2探索が勝ちました。

しかし今回の主役は、1.247%の勝敗そのものではないと思います。

公開重みのKimi K3が、2.51ドルのAPI利用で、最高級の非公開LLMが今回到達した23.257倍とほぼ同じ22.967倍へ到達した。しかも出力はビット完全一致でした。

これはかなり大きな結果です。

同時に、同じSolの第1探索が11.37倍だったことから、LLM高速化ではモデルの序列より、複数回の探索、正しい道具、固定評価器、候補の凍結が重要だとわかりました。

私の評価は次の通りです。

第1回のSIKBでは、公開重みKimi K3と非公開GPT-5.6 Solの最高到達点は事実上五分。勝敗より、両者が同じ本質的最適化へ独立に到達したことの方が重要である。

次回はSIKBを異なる計算構造の3本へ増やし、この結果が再現するかを確認します。さらに公開重みモデルと非公開モデルを、各条件複数回で比較する予定です。

1本目では互角でした。2本目、3本目でも同じなのか。そこからが本当のモデル比較です。

再現性と公開範囲

• SIKBは独立設計の合成Fortranベンチマークであり、元研究コードではない。
• 公開対象は権利者承認済みアーカイブSHA-256
  08f611af9a1c7e3d18d8b87c032b6ef57d4edeff982ab2eb34822947dd8b298bに限定する。
• 非公開研究ソース、入力、出力、物理定数、内部性能証拠は公開しない。
• 最終候補、ジョブ番号、ソースSHA、コンパイラSHA、3回時間、完全一致結果は保存済み。
• Fireworks APIキー、カード情報、クラスタ認証情報は記事素材へ含めていない。

公開SIKBをダウンロード

記事で使用した未変更版SIKBは、ソース、Makefile、検証スクリプト、Slurm実行例、設計資料をまとめてダウンロードできるようにします。ダウンロードカードのSHA-256は08f611af9a1c7e3d18d8b87c032b6ef57d4edeff982ab2eb34822947dd8b298bです。読者は同じ公開コードから、自分のLLMやコンパイラで高速化を試せます。

この記事への質問・感想をお寄せください

「自分のFortranコードでも速くなる？」「自社の計算環境で試せる？」など、一言から歓迎します。

この記事について質問・感想をメールで送る

会員登録は不要です。記事名とURLが入ったメール作成画面が開きます。

メールアプリが開かない場合は、ken@server-gear.com 宛に記事名を添えてお送りください。お送りいただいた内容は、公開コメントには掲載されません。