nanochat 8,000行でLLM製造工程を辿る — GPT-2訓練の値段は2026年いくらか
私はここ数年、LLMを「使う側」に居続けていました。ChatGPTのAPIを叩き、Claude Codeを走らせ、たまに気分でCursorを開く。中で何が起きているかは、なんとなく論文で見た図で理解した気になっていて、いざ「pretrainingとSFTの違いを説明して」と後輩に聞かれると口ごもる、あのタイプのエンジニアです。
その状態を7月の連休3日で終わらせたくてKarpathyのnanochatを読みました。Pythonとシェルスクリプト合わせておよそ8,000行。想定より小さかった、というのが第一の感想です。
そして数字も想定より小さかった。2019年にOpenAIが$43,000かけて訓練したGPT-2級のモデルが、2026年7月現在は$50前後で作れます。7年で900分の1。この記事はその「値段の時系列」と、なぜここまで下がったのかをコードに紐づけて残しておく個人メモです。
この記事で扱う「GPT-2級」の定義
先に線を引いておきます。GPT-2級=DCLM CORE指標でオリジナルGPT-2の0.2565を上回るモデル、と本記事では呼びます。パラメータ数ではなく評価スコアで揃えるやり方で、nanochatのリーダーボードもこの流儀です。
なぜこの流儀を採るか。パラメータ数で揃えると「1.6BをGPUで訓練しました、以上」となり、データセットもアーキテクチャも吸収されてしまって比較になりません。CORE指標で揃えると、「同じ品質に到達するのに、いくらかかったか」という工学的な問いに落ちます。
私が最初にこれで詰まったので、同じ地雷を避けるために書いておきます。
訓練コストの時系列: $43,000 → $50
nanochatのリーダーボードに載っている数字を並べます。時間は「Time to GPT-2」、コストはその時点の8×H100レンタル価格から私が概算した値です。

| 日付 | Time to GPT-2 | 訓練コスト概算 | 誰が / 何で |
|---|---|---|---|
| 2019 | 168時間 | $43,000 | OpenAI / 32×TPU v3 |
| 2026-01-29 | 3.04時間 | $97 | nanochat run 1 / 8×H100 |
| 2026-02-05 | 2.76時間 | $88 | run 3 / 総バッチ100万トークンへ拡大 |
| 2026-03-04 | 2.02時間 | $64 | run 4 / ClimbMixデータセット |
| 2026-03-14 | 1.65時間 | $53 | run 6 / autoresearchで最適化 |
出典: karpathy/nanochatのdev/LEADERBOARD.mdおよびREADME.md、Lambda Labs公式価格ページ(8×H100 SXMをオンデマンド$31.92/hrで計算)。スポットインスタンスならさらに半額前後になります。
168時間→1.65時間は約100倍の短縮です。7年で900倍近くと冒頭に書いた内訳は、時間短縮100倍にGPU時給の下落約8倍を掛けたオーダーです。TPU v3の時給$8がH100 SXMの1枚あたり$3.99前後まで下がった(8枚束ねても$32/hr)ぶんも効いています。
nanochatが実装した「値段を下げる4つのレバー」
面白いのは、900分の1がどこか1箇所の魔法ではないことです。nanochatの runs/speedrun.sh を上から下まで読むと、レバーが少なくとも4本あるとわかります。
レバー1: fp8で行列積を2倍速に
nanochat/fp8.py の Float8Linear が線形層を丸ごと差し替え、torch._scaled_mm の8bit浮動小数点カーネルで行列積を走らせます。bf16比で約2倍速いとされる cuBLAS カーネルです。
私はここで「FP8対応のtorchaoで良くない?」と思ってtorchaoを覗きに行ったのですが、あちらは約2,000行あります。nanochatは「tensorwise scaling」1種類に絞って約150行に収めていて、読む側としてはこの割り切りが助かる。torchaoが提供する精度モードは複数ありますが、実運用で使うのはたいてい1つだけなので、教材としてはnanochatの方が正しい。
レバー2: Flash Attention 3で長系列を高速に
nanochat/flash_attention.py はFA3が使えるハードウェアならFA3を、使えなければPyTorchのSDPAにフォールバックする層です。Hopper (sm90)・Ada (sm89)・Ampere (sm80/86) 世代のGPUで、bf16のときにFA3が有効になります。
Attentionの計算はO(N^2)なので、系列長2048ではここが素直な速度差になります。ネットで「なんかH100だと訓練が速い」と言われている理由の多くは、実はFA3が効いていることに起因しています。
レバー3: --depth1つで学習量まで自動で決まる設計
私が一番好きなのはここです。scripts/base_train.py が受け取るモデル形状関連のハイパーパラメータは事実上 --depth の1つだけ。層数を決めれば、モデル次元、ヘッド数、目標学習トークン数、バッチサイズ、学習率補正、weight decayまで機械的に落ちます。
target_tokens = int(args.target_param_data_ratio * num_scaling_params)
--target-param-data-ratio はデフォルト12(Chinchillaの経験則は20)で、speedrunでは8まで下げています。GPT-2に必要最低限だけ学習して余計なコストを払わない、という判断がコードに直接書かれている。教科書のスケーリング則の話が、シェルスクリプトの引数1つになって降りてくる感覚は、実装を読んで初めて掴めました。
レバー4: best-fitで詰めてパディング0
データローダーの tokenizing_distributed_data_loader_with_state_bos_bestfit は、系列長2048の枠にドキュメントをbest-fitで詰め込みます。パディングトークンは発生しません。
代わりに、枠に収まらないドキュメントの尻尾は約35%クロップされる、とファイル冒頭コメントが正直に書いています。すべての行が <|bos|> から始まる文脈で学習させることを優先した設計です。私は最初「35%も捨てて大丈夫?」と思いましたが、実際のCORE指標を見るとGPT-2は問題なく越えていて、要は「無駄なパディングに払うより、BOSから始まる綺麗な文脈を増やす方が効く」ということでした。損失関数を最小化する競技として、率直に上手いトレードオフだと思いました。
Chinchillaのスケーリング則が、シェル1行に化ける
もう1歩踏み込むと、上のレバー4本の裏には共通の設計思想があります。「経験則に従う定数は、コードにハードコードして人間が触らない場所に格納しろ」というやつです。
たとえばバッチサイズ。d12モデルの最適バッチサイズ B_REF = 2**19 を起点に、Power Lines論文の経験則 B ∝ D^0.383 で目標トークン数から外挿し、計算効率のいい2のべき乗に丸めます。学習率の補正は η ∝ √(B/B_ref)。この2式が scripts/base_train.py の中でひっそりと数十行を占めていて、外からは --depth=24 としか見えません。
私が普段のプロダクトコードでもよくやるやつです。設定ファイルに50個並べたパラメータの相関を、後任のエンジニアが把握できるはずがない。それをKarpathyは、ML研究のパラメータ空間でやっている。
「工程を所有する」ということ
nanochatを読み終えたあと、私は自分のClaude Codeへの向き合い方が少し変わりました。
以前は「Claude 4.7ってなんで性能上がったの?」と聞かれても「まあ、なんか賢くなったんじゃないですかね」と返していました。いまは「事前学習の質・量・アーキテクチャ・SFTデータ・RL報酬・推論時のツール実行、どこが変わったかによります」と分解して答えられます。答えとしては同じ「知らない」なのですが、分解できるかどうかは業務上ぜんぜん違う。デバッグで「どのレイヤの問題か分からない」状態と、「エラーはネットワーク層じゃなくてアプリケーション層です」まで絞れる状態くらい違います。
$50でGPT-2が作れる時代に、LLMの内部工程を1つのブラックボックスとして扱い続けるのは、私にとってはさすがにもったいない選択でした。8,000行を読む労力は、AWS入門を1冊読むのと大差ないので、興味があるならおすすめします。
まとめ
- GPT-2級モデルの訓練コストは、2019年の$43,000から2026年7月の約$50まで、7年で900分の1になった
- 短縮の内訳はGPU時給の下落・fp8・FA3・データセット改良・スケーリング則自動化の積み重ねで、単一の魔法ではない
- nanochatを読むと、この積み重ねが具体的にどのファイルのどの関数で起きているかまで追える
- 訓練工程を「所有する」感覚があると、日常のLLM選定の解像度が変わる
参考: karpathy/nanochat / nanochat LEADERBOARD.md / Lambda GPU Cloud Pricing
この記事は役に立ちましたか?