필사 모드: 公開された学習事例から学ぶ — 何を試し、何が失敗したか

• はじめに — 報告書から読むべきは点数表ではありません
• 選んだ事例と確認基準
• Llama 3 405B — 障害が定数である規模で設計する
• DeepSeek-V3とKimi K2 — スパイクをなくす二つの層
• Olmo系列 — 安定性修正がアーキテクチャに残した痕跡
• OPT-175BとBLOOM — 失敗を記録する文化の原型
• SmolLM3とMarin — 小規模で公開された実験ノート
• 横断して読む — 繰り返されるものと最後まで出てこないもの
• おわりに — 再現できない部分を知ることが読む技術です

はじめに — 報告書から読むべきは点数表ではありません

技術報告書をベンチマーク表だけ見て閉じると、得られるものはほとんどありません。点数は自分の状況に移せませんが、何が壊れ、どう直したかは規模が違っても移せます。

この記事は公開報告書とログブックからその部分だけを抜き出しました。損失スパイクとその対応、ハードウェア故障率とチェックポイント周期の関係、データ混合を途中で変えた効果、そしてスケーリング決定の根拠です。各事例の終わりには報告書が語らなかったことを別途記しました。再現可能性を判断するにはそちらの方が重要です。

選んだ事例と確認基準

すべて2026年8月2日にリンクを確認しました。引用した数値は原文または原文を直接引用した報道から取り、確認できなかったものは本文にそう記しました。

Llama 3 405B — 障害が定数である規模で設計する

もっとも引用する価値があるのはこの報告書の中断統計です。16,384枚のH100 80GBで54日間動かす間に予期しない中断が419件あり、報告書はそのうち78パーセントを確認済みまたは疑わしいハードウェア問題に分類しています。詳細な分類は、報告書の表を引用したデータセンター業界の報道によれば以下の通りです。

54日で419件なら平均3.1時間に一度です。この規模では障害は例外ではなく定数です。 だから設計が変わります。人が介入して再起動する運用は成立せず、障害検知とノード交換、再開が自動で回らなければなりません。

ここからすぐに導かれる実務計算がチェックポイント周期です。平均故障間隔3.1時間に保存が5分かかるなら最適周期は43分前後で、それでも全体時間の20パーセント以上が保存と再計算に消えます。計算過程はLLM Opsの記事にまとめてあります。

並列化はテンソル、コンテキスト、パイプライン、データの4次元の組み合わせを使い、BF16基準でモデルFLOPs活用率は38〜43パーセントの区間で報告されています。この数字は覚えておく価値があります。よくチューニングされた大規模学習でも理論性能の半分を使えていません。 自社クラスタで30パーセント台が出たからといって、必ずしも何かが間違っているわけではありません。

報告書が語らないこと: 学習データの正確な構成比率とフィルタリング分類器の閾値、失敗して捨てた予備実験、そして障害検知と自動復旧を担った内部運用ソフトウェアの実装です。統計は公開されましたが、その統計を作った道具は公開されていません。

DeepSeek-V3とKimi K2 — スパイクをなくす二つの層

二つの報告書を並べて読むと、損失スパイクへの対処における異なる戦略が見えてきます。

DeepSeek-V3は671Bパラメータのうちトークンあたり37Bを活性化するMoEを14.8Tトークンで学習し、全学習に2.788M H800 GPU時間かかったと報告しています。ここにはコンテキスト拡張119K時間と事後学習5K時間が含まれます。そして報告書にはこういう文があります。全学習過程で復旧不能な損失スパイクを経験せず、ロールバックを行わなかったというものです。

この安定性がどこから来たのか、報告書は直接断言していません。ただし一緒に記述されていることがヒントです。FP8混合精度学習を導入しつつ精度に敏感な演算は高精度のまま残し、パイプラインバブルを減らすDualPipeで計算と通信を重ね、MoEのロードバランシングを補助損失なしで処理する方式を使いました。最後の項目が特に重要です。補助損失で専門家の使用を均等化すると、その損失が主目的関数と競合して不安定を生みますが、その項をなくしたのです。

後続の回顧論文Insights into DeepSeek-V3はハードウェア側の設計を扱います。マルチヘッド潜在アテンションでトークンあたりのKVキャッシュを70.272KBまで減らしたという数値が出ており、同じ表でLlama-3.1 405Bは516.096KBです。そしてクラスタネットワークとして多平面ファットツリー・トポロジーを使ったと記しています。モデル構造の決定がそのままインフラの決定になる事例です。

Kimi K2は別の層で同じ問題を解きます。総パラメータ1.04TのうちActiveなのが32BのMoEを15.5Tトークンで学習しながら損失スパイクが観測されなかったと報告しており、その手段がオプティマイザです。MuonオプティマイザにQK-Clipを組み合わせたMuonClipを使い、更新直後にアテンションのクエリとキーを再調整してロジットの暴走を抑えました。学習率スケジュールはWSD系列で、500ステップのウォームアップ後10Tトークンを定数学習率で回し、残りの5.5Tをコサインで減衰させたと記述されています。事前学習のコンテキストは4,096です。

二つのアプローチの違いを整理するとこうです。

報告書が語らないこと: 両方の報告書とも成功した最終構成だけを記述しています。FP8導入過程でどのレイヤーが先に壊れたのか、MuonClipのクリッピング閾値をどう見つけたのか、その前に何回失敗したランがあったのかは出てきません。そして両方ともデータ構成は公開していません。

Olmo系列 — 安定性修正がアーキテクチャに残した痕跡

Allen AIのOlmo 3は7Bと32Bモデルを出しながら、チェックポイントとデータセット、依存関係まで開発パイプライン全体を公開しました。この完全公開が重要な理由はベンチマークスコアのためではなく、第三者が汚染の有無とデータ出所を直接監査できる唯一の形態だからです。

技術的に注目すべきは、安定性の修正がハイパーパラメータではなくアーキテクチャに残ったという点です。Olmo 3はOLMo 2で安定性改善として確認された構成を維持します。RMSNormを使いつつ正規化位置を後置とし、アテンション計算の前にクエリとキーにもう一度正規化をかけ、埋め込みには重み減衰を適用しません。

三つとも事前学習を始めたあとは変えられない決定です。だからこの事例が与える教訓は実務的に冷静です。不安定対応のもっとも良いタイミングは最初のスパイクが起きる前です。 すでに3Tトークンを回した状態で正規化位置を変える選択肢は存在しません。

報告書が語らないこと: データとチェックポイントは公開されましたが、この規模を再び回す計算資源はほとんどの組織にありません。「完全公開」は監査可能性を与えますが、再現可能性は与えません。この区分ははっきりさせておく方がよいでしょう。

OPT-175BとBLOOM — 失敗を記録する文化の原型

今の技術報告書が磨き上げられた最終稿だとすれば、2022年の二つの事例は生の記録です。

OPT-175Bのchroniclesディレクトリには全体のログブックPDFと共に、進捗10パーセント、27パーセント、56パーセント、そして最終時点の更新ノートが入っています。リポジトリの説明はこれを「OPT-175Bの学習に使った全体のログブックと、過程で直面した困難を整理したノート」と紹介しています。ログブックには繰り返される再起動、損失発散、学習途中のハイパーパラメータ変更、ハードウェア交換が日付と共に残っています。

ここで学ぶべきは特定の技術ではなく、記録そのものが成果物であるという姿勢です。学習中どんな決定をなぜ下したかがその時点で記録されなければ、二か月後には誰も再構成できません。

BLOOMはフランスのJean Zayスーパーコンピュータで48ノード、ノードあたりA100 80GB 8枚、合計384枚で約3.5か月間学習し、1,082,990計算時間を使いました。資源計画で目を引くのはハードウェア障害の可能性のために予備ノード4個を別途確保していたという点です。ノード間接続はノードあたり100Gbps Omni-Pathリンク4本で、共用スパコンだったためファイルシステムを他のユーザーと共有していました。

384枚規模で予備ノードを8パーセント程度確保したこの決定は、そのまま持ち出して使える実務規則です。資源申請書に予備ノードを盛り込まなければ、ノードが一つ死んだ瞬間に学習全体が待ち行列の最後尾に回されます。

報告書が語らないこと: 両事例とも当時のソフトウェアスタック(旧版Megatron-DeepSpeed、旧版PyTorch)の上にあり、コードをそのまま動かすことはできません。そしてログブックの判断は当時のハードウェアとフレームワークの制約に縛られているので、結論ではなく思考過程だけを持ち帰るべきです。

SmolLM3とMarin — 小規模で公開された実験ノート

前述の事例はほとんどの組織が真似できない規模です。そこでより実用的な二つの事例を加えます。

SmolLM3は3Bモデルを11.2Tトークンで学習しながら、データ混合をどう決めたかを公開しました。3段階の事前学習でウェブ、コード、数学の比率を段階ごとに変え、その比率は3Bモデルを50Bから100Bトークン規模で回す小規模実験で決めたと記述しています。第1段階の構成はウェブ85パーセント(うち多言語12パーセント)、コード12パーセントというように数字まで出ています。

この方法論が肝心です。 11.2Tトークン分の決定を100Bトークンの実験で下したのです。混合比率の候補をいくつか立てて小規模で回し比較したのち本学習に適用する手順は、3Bでも30Bでも同じように使えます。併せて公開されたSmol Training Playbookは384枚規模の作業で損失スパイクをデバッグした過程のような、論文に入らない部分を扱います。384枚は多くの組織が実際に手を出せる規模です。

Marinはスタンフォード発の公開実験室で、あらゆる研究の試みをまずGitHubのissueとして登録し、そのissueが一種の事前登録の役割を果たします。8Bモデルを12Tトークン以上学習する過程でデータ混合を継続的に磨き上げ、後半の冷却フェーズで学習率を下げながらデータを高品質側に切り替える方式を回顧文書として残しています。

事前登録という慣行は特に持ち帰る価値があります。実験結果を見てから仮説を書くと、ほとんどすべての結果が成功に見えます。 回す前に何を期待するか記しておくだけで、この偏りは大きく減ります。

報告書が語らないこと: SmolLM3の小規模代理実験が本規模でどれだけよく予測できたかは定量的に検証されていません。小規模実験が大規模に移らない場合が実際に存在するので、この方法論は「完璧な予測」ではなく「根拠のない推測よりましな手順」として受け止めるのが妥当です。

横断して読む — 繰り返されるものと最後まで出てこないもの

七つの事例を重ねると、繰り返されるパターンが五つ見えます。

1. 損失スパイク対応には四つの層があり、下に行くほど安く、上に行くほど遅くなります。 目的関数設計、アーキテクチャ、オプティマイザ、運用の順に介入コストが大きくなります。ところが大半のチームはもっとも高価な運用層でのみ対応しています。
2. 障害率はGPU数に比例し、チェックポイント周期と自動化水準を決めます。 384枚では予備ノードで十分ですが、16,384枚では自動検知と交換が必須です。規模が十倍になれば運用方式も変わらねばなりません。
3. データ混合は最初から最後まで固定されません。 複数の事例が段階別混合と後半冷却区間の高品質データへの切り替えを記述しています。「データセットを決めて学習を始める」というモデルは現実と違います。
4. スケーリング決定は小規模代理実験から出てきます。 大きな決定であるほど小さな実験が根拠になります。実験設計能力がGPU数より重要になる地点です。
5. モデル構造の決定はインフラの決定です。 KVキャッシュサイズを減らすアテンション設計がサービング費用を変え、MoEの選択がネットワークトポロジー要件を変えます。

逆に、ほとんどすべての報告書で最後まで出てこないものも整理しておきます。このリストを知っておいてこそ、報告書を過信せずに済みます。

• 失敗したランの数と費用。 最終ランのGPU時間は出ますが、そこに到達するまでに燃やした資源はほとんど公開されません。公開されたGPU時間をそのまま予算根拠に使うと大きく不足します。
• データの正確な構成とフィルタ閾値。 比率は出ても元の出典と重複除去パラメータ、品質分類器のカットオフは大抵抜けます。
• ハイパーパラメータ探索過程。 最終値だけ出て、その値をどう見つけたかは出てきません。
• 運用人員と道具。 何人が何交代で張り付いたか、どんな内部ツールが障害を検知したかが抜けます。これが実際にはもっとも大きな参入障壁です。
• 評価セット汚染検査の詳細。 検査したという記述はあっても、方法と閾値、発見された重複の規模まで記す場合は稀です。

おわりに — 再現できない部分を知ることが読む技術です

公開報告書は成功の設計図ではなく、あるチームが特定の制約の下で下した決定の記録です。16,384枚で有効だった自動復旧設計は8枚のノードでは過剰であり、384枚で通用した手動対応は16,384枚では成立しません。

だから読む方法はこうまとめられます。数字はそのチームの規模に縛られているので持ち出さず、決定の根拠を持ち出してください。なぜこの時点でチェックポイント周期を決めたのか、なぜこの層で不安定を防ぐことにしたのか、なぜこの実験からあの決定を下したのか。そして報告書にない項目のリストを常に一緒に携えてください。ないものが何かを知っている人だけが、その報告書を根拠に計画を立てられます。

並列化の基本はマルチGPU学習の四つの並列化に、これらの決定を実行する道具はLLM学習スタック地図とSlurm実務ガイドにまとめてあります。