きみはNanoGPT speedrunを知っているか？

PredNext代表の徳永です。バズり目的で書いたClaude Codeの記事が全くウケなかったので、もっと露骨にウケ狙いの記事を書きたいと思いつつ、どうすればバズれるのか全く想像がつきません。とりあえず、今日はNanoGPT speedrunの話をします。

NanoGPT speedrunとは

NanoGPT speedrunは、Andrej Karpathyが公開した小型のトランスフォーマー実装であるnanoGPTをベースに、学習の高速化を目的として行われる非公式な性能競争です。

nanoGPTはもともと教育目的で設計されており、読みやすいコードではありますが、実用的な大規模学習には適していません。しかし、その簡潔さゆえに改造しやすく、これを活かしてKeller Jordanという人がこのspeedrunを始めました。

レギュレーションとしては、NVIDIA H100x8が計算資源の上限で、FineWebというデータセットのvalidation lossが3.28以下になるまでの時間を競います。当初は2024年5月に45分かかっていた学習は1年も経たないうちに大幅に高速化され、2025年7月13日の記録は2.863分になっています。

ここまでの道のりはどれもこれも非常に興味深いものなのですが、今回はその中からMuonというOptimizerを取り上げたいと思います。

Muonとは

Muonはspeedrunを企画したKeller Jordanが開発した最適化の手法で、勾配の移動平均(いわゆるmomentumですね)を計算し、momentumをNewton-Schulz iterationという手法を用いて近似的に直交化し、その結果を使ってパラメーターを更新します。

行列の直交化を行うわけですから、当然、パラメーターが行列になっているレイヤー（Linear層や畳み込み層）にしか使えません。それ以外のパラメーターはAdamWを用いてパラメーター更新をすることが勧められています。

直交化が収束を早める理由として、学習において重要な情報となる「稀な方向」のスケールが増幅されるのではないか、とJordanのブログにおいて述べられています。直交化によって各列のノルムが1になるように正規化されますから、これが重要なのではないか、ということですね。

Muonが痛快なのは、提案されてから1年も経たないうちに[2502.16982] Muon is Scalable for LLM Training において 3B/16B-parameter MoEモデルで実用性を示され、この2025年7月に公開されたKimi K2という32B/1T-parameter MoEモデルにおいてもOptimizerとして採用されている点です。(ref: Kimi K2: Open Agentic Intelligence) これまで多くのOptimizerが主流となれずに消えていった事を考えると、快挙と言ってよいでしょう。

Kimi K2は現時点ではDeepseek-R1ほどの注目度はありませんが、一方で、実際に使ってみた人からはかなり高い評価を得ているようです。Claude Sonnet 3.5に匹敵する、もしくはもうちょっと上、くらいの感触を持っている人が多いようです。Claude Sonnet 3.5はコーディング用モデルとしてはかなり実用的なので、Kimi K2もコーディング用LLMとして実用レベルに到達したと言えるでしょう。

Muonで学習したモデルをAdamWでfinetuningしたり、またはその逆をしたりするとあまりうまくいかない(3.5.1 Ablation Studies on the Interchangeability of Pretrain and SFT Optimizersを参照))という話もありますが、それでも、AdamWよりも収束が50%近く早いとなると、これは無視できません。開発者はMuonの利用を検討しなければならなくなるでしょうし、Muonを採用する事例は今後増えてゆくことでしょう。

というわけで、NanoGPT speedrunの紹介と、そこから実際に、新しい技術が出てきていますよ、という紹介でした。

残念ながら、日本ではNanoGPT speedrunはほとんど注目されていません。Kaggleと違って賞金が出ない割に、ベンチマークするのにH100を8枚も調達してこないといけない（ご家庭にはH100x8を搭載したサーバーはほぼ確実に置いてないので、Modalなどを使って一時的に借りてくることになるでしょうが、例えば、ModalでH100x8を1時間借りるとだいたい32ドルくらいかかります。なお、speedrunの実行は3分で済みますが、事前準備としてtorch.compileに10分ちょっとかかりるので、１回の実験にはなんだかんだで15分くらい必要です。）というところがネックなのかもしれませんが、もうちょっとチャレンジする人がでてくるといいなと思います。

ただ、最近、記録更新が減ってきていることから推測がつきますが、このspeedrunの記録を破るのは本当に難しいです。ちょっとしたチューニングで記録を塗り替えられるとは期待しない方がよいでしょう。

おまけ

私も当然、このspeedrunにはチャレンジしてみました。いくつかの方法を試してみましたがうまくいきませんでした。供養として、うまくいかなかったことを挙げておきます。

• MuonをCautious Optimizer化する。直交化によってgradientとmomentumの方向が変わってしまいそうなので、うまくいかなくても仕方がないような気もします。
• DiLoCoを使う。1GPUだとよかったのですが、GPUが増えると遅くなるという問題がありました。Muonはパラメーター更新時に行列積を数回実行しますが、複数のGPUを使える場合はこの行列積をレイヤー単位で複数のGPUで分散して実行するという工夫が入っています。これとDiLoCo（inner optimizerは通信してはいけない）の相性が悪く、同一step数で比較した場合の収束は早まるものの、1stepあたりの処理にかかる時間が伸びてしまって、トータルは収束性能が悪化してしまいました。
• Dynamic Tanhをnormalizationに使う。PyTorchで書くとすごく遅くなるのでTritonでカーネルを書いてみましたが、それでもRMS normに精度も速度も勝てませんでした。精度はハイパーパラメータチューニングをもっと真面目にやればよくなったのかなぁ、と思いつつも、お金がかかるので探索できませんでした。
• long attentionとshort attentionの組み合わせを変えてみる。適当にやると確実に収束が遅くなる。この組み合わせを見つけた人は大量に実験を繰り返したのか、もしくは、すごく運がいいのか、どちらにせよすごいです。
• MLP層をfp8化する。fp8への型変換に時間がかかるのか、ふつうに遅くなってしまいました。

まとめ

NanoGPT speedrunは素晴らしいです。1台のサーバーでできるLLM学習のための実装としてはこれ以上の高速化が難しいくらいに極まっています。speedrunの記録更新に挑んでみてもよいし、このコードを土台に別のチャレンジに取り組んでみるのもよいでしょう。

お仕事募集中

PredNextでは現在、もう少しだけお仕事の依頼を募集しています。得意分野は自然言語処理や画像処理を中心とするAI関連技術ですが、その中でもとくに軽量化、高速化を得意としています。ご興味のある方はお問い合わせフォームからご連絡ください。