# なぜモエの訓練はこんなに難しいのか 最近、小規模で研究に特化したトレーニングリポジトリを欲しがっています 小さな実験も素早く簡単にできます。これらの実験は幅広く 新しい注意力アーキテクチャ(MLA、SWA、NSA、KDA―すべてプラグイン可能)からマルチプレシジョントレーニングまで、多くの人が試しています 最近、マルチオプティマイザーのセットアップに「新しい」オプティマイザーが導入されました。3専攻を試しました 候補者(ニモ、メガトロン、トーチタイタン)ですが、さまざまな理由で 私の目的には全く合わず、どれもかなり痛かった セットアップ、使用、安定して稼働させましょう。またしてもGoogleで使ったツールが恋しかったです そして、この目的のために制作トレーニングのスタックを書き直すこと(これは「テーダー」です) 大規模なインフラの監視と安定性のために作られた)もまた、貧しいと感じました 時間の使い方が悪いと、古いリポジトリも新しいリポジトリも悪化します。 しかし、なぜフロンティアのトレーニング品質が「やや小さい」のか考えさせられました。 MoE(例えば合計20Bパラメータ未満)がそんなに難しいですか?なぜリポジトリやリブIはそうしなかったのか すでに指名手配されているのか?しばらく考えた結果、ほとんどの 私が思いついた課題は3つの異なることに集約されました。 - フロップス/フロップ効率 - 負荷分散/ルーターの安定性 - データの質と量 フロップ 最近では、密度の高いモデルのトレーニングはかなりシンプルです。訓練 ダイナミクスは主に結合されており、アーキテクチャに十分なパラメータがあれば、 モデルはあなたの多くのミスにもかかわらずほぼ学習します(これが私を噛みました お尻を何度も。[DeepSeekスタイルの超スパール](MoEは訓練のダイナミクスが異なるため異なります ある程度切り離された感じです。特定のトークンに対して有効であるMLPの一部だけです。 そして研修が進むにつれて、現役の専門家は変化し、進化していきます。これは なぜマルチエポックトレーニングやデータの言い換えがMoEにとってこれほど効果的なのか (特に大きなものは)。大きな推論効率の勝ちと小さな推論効率が生まれます トレーニング効率が勝つが、その代償として訓練ダイナミクスの切り離し( 予測可能で安定してトレーニングするのは難しいです)そして、もっと多くの失敗をしなければなりません ある程度最適なルーティングポリシーを学び、専門家の指導を確実にしてください さまざまな政策に関与している人は、十分な訓練を受けています。ここで フロップ/フロップ効率の課題が生じます。最初の課題は、 自然、超限量のMoEは膨大なHBMを消費して、 専門家とは、多くのGPUが必要で、そのため多くのアイドルGPUが存在することを意味します あなたのシステムです。FSDP(および他の様々なシャーディングトポロジー)はほとんど遺物です 密集した訓練の専門家であり、すべてを十分に活用できていません あの取り残された失敗作。そのため、多くの人にとっては(低)一桁のMFUが使われてしまいます 超限度なMoEトレーニング。対処法はいくつかありますが (これについては今後もっと詳しく話しますが)私は2つの具体的なことに注目しました。 - 新しいシャーディングトポロジー(GPUを忙しく保つ新しいエキスパート・パラレルディスパッチシステム) - 混合精密訓練 負荷分散/ルーターの安定性 新しいシャーディングトポロジーについては専用の解説にしますが、混合精密トレーニングは迷う余地なく選択できます。この多角的なHBMがたくさんあるので、エキスパートの精度を下げて、その子を1/2か1/4(それぞれFP8とNVFP4)カットしてください。理論上は良いですが、実際には混合精密トレーニングでは、マスターウェイトとグラデッドをより高い精度に保ち、マスターウェイトを低精度の表現に量子化してキャッシュし、次のフォワードパスのためにキャッシュしなければならず、より多くの重みを使います。そのため、推論効率の向上には役立ちます(より多くの失敗が強化や推論に移行する中でこれは大きな勝利です)が、その代償としてさらに多くのHBMやトレーニング中の失敗が増えます。精度の混合によるオーバーヘッドの削減は、特に注目すべき分野です。しかし、重量の精度や精度を下げるものは、最終的にトレーニング全体の不安定さを招きます。MoEの場合、最初にこの問題が現れるのはルーターの安定性です。 DeepSeek-V3の技術レポートでは、ノブが非常に少なく、ダイナミクスが非常に明確な非常に洗練されたaux損失フリーのトレーニングセットアップについて説明されています。これらは明らかに熟練者向けに設計されたツールで、わずかなノブでダイナミクスを正確に出すのは非常に難しいです。重要なのは、DeepSeekがルーターの安定化のために大量のバッチサイズに大きく依存していることです。限られたハードウェアの調査ではそのような贅沢はありません。だからこそ、小規模なランを安定的で効率的かつ有益なものにするために、特に努力しなければなりません。特にミックスプレシジョンエキスを対象に彼らのセットアップを再現しようと実験を始めると、グラデラーはFP8やNVFP4には小さすぎてルーターが学習できず、エキスパートが飢えているのが明らかになりました。最初は精度を下げたバックパスであらゆる手を尽くし、最終的にはFP32マスターウェイトやグラデリングでも試しましたが、ルーターの崩壊は続きました。タイミングよく良かった論文として、Character AIのブログ記事で、彼らのint8安定性介入について説明しました。すべて試しましたが、システムの安定性をかなり悪くしてしまいました。だから一つずつ見ていきました。最初の例は、muPの埋め込みスケーリングが10.66、logitのスケーリングが0.125でした。ルーターの安定性以外にも明らかな利点はたくさんありましたが、このスケールが明らかにしたのは、非常に小さなFP8やNVFP4のエキスパートグレードを、ルーターがついに学習し始めた段階までスケールアップしたことです!しかし、これらの勝利はBF16の卒業標準を爆発的に拡大させ、通常のベストプラクティスである卒業生のクリッピングやグラッドスケーリングが学習を妨げていました。では、解決策は?すべてのクリッピングを除去したら、YOLO!最後に、安定した混合精密ルーターのトレーニングを行いました。もう一つ非常に有用だった怪獣介入は、専門家の事前出力標準値の出力に単一のバンジーバーチャルスカラーを2.0で初期化し、bf16グラデーションスケールに合わせることでした。これにより、nvfp4とFP8はベースラインのbf16トレーニングランとほぼ同じ損失曲線を示すように訓練力学が調整されました(FP8-BF16のギャップは~0.8から<3,000歩で0.1)。ここでは他にも多くのコツや「ベストプラクティス」が使われています(これらについては今後の投稿で詳しく触れます)が、見出しは以下の通りです: - muPスケーリングの追加 - 他のすべてのクリッピングを取り除き、野生側で生きる - バンジー仮想スカラープリ出力ノルム - AUX損失をフリーにし、トークン選択のルーティングを守ること(この家では正しいと間違っている区別がわかっているから) データ 比較的安定したトレーニングダイナミクスが得られた今、もしこのリポジトリを誰かと共有したいなら、このトレーニングライブラリを最大限に活用するにはより良いデータが必要だと明らかになりました。もう一つのタイミングの良いリリースは[OLMo-3](オープンソースのデータ混合レシピ(Ai2を称賛!!)でリリースしました。しかし、huggingfaceのOLMo-3ミックスを直接使ってみたところ、通常のFineWeb-Eduの基準値と比べてかなりひどい結果でした。こうしてデータ探検が始まり...データセットはかなり汚れていました。そこで、誰でもやることをして、このトレーニングリポジトリを最大限に活用するために、フロンティアにインスパイアされたデータパイプラインを構築しようとしました。 このパイプラインにはいくつかの重要な要素があります: - **ヒューリスティックなプリフィルター**:言語ID、長さフィルター、MinHashの修正、nグラムの重複、パープレキシティの異常値、毒性 - GPUサイクルを使う前に明らかなゴミを除去するための標準的な処理 - **SeqIOスタイルの動的混合**:決定的で再開可能なサンプリングで、総トークン予算に関係なく目標比率(40% CC、20%コードなど)を維持します。6.7Tトークンで訓練しないプロキシ実行で非常に重要です - **モデルベースの品質スコアリング**:ここからが面白くなります 品質評価については、[Seed-Coder]( のパターンに従いました:大規模なオラクルモデルでトレーニングラベルを作成し、高速分類器に抽出します。最初はいくつかのオラクルモデル(Kimi-K2、DeepSeek-V3.2、そして[gpt-oss](120B))を試しましたが、最終的には120Bクラスのモデルだけをオラクルとして使うことにしました。これらは常に微妙な品質判断において最も優れていました。オラクルは、一般的な内容(有用性、正確性、一貫性、複雑さ、冗長度 - 0-4)と、コードの4次元(可読性、モジュール性、明瞭さ、再利用可能性 - それぞれ0-10)でデータを評価しました。次に凍結したGPT-OSS 20Bの骨格を使い、小さなヘッドを2つ取り付けました: - **プローブヘッド、レイヤー18:線形(2880→5)→平均プールされた隠れた状態。超安価で、明らかなゴミを早めに見つけられます - **ジャッジヘッド、レイヤー24:小型トランスエンコーダ→全シーケンス注意 → Linear(512→5)。価格は高めですが、細かい品質の問題を指摘できます 早期退出設計が重要です。Probeのスコアが閾値以下なら、Judgeは完全にスキップします。大規模であれば、これにより約15%の計算コストを節約しつつ品質を維持します。閾値(τ_drop、τ_keep)は、目標保持率を達成するホールドアウトセットで校正されます。 驚いたことに、OLMo-3データセットの保持率はCCやインターネットソースで約30%、コード、数学、科学で約50%でした。これは多くのフィルタリングですが、プロキシモデルの評価では、未フィルタリングのベースラインに比べて明確な改善が見られました。 最終的に、私が大規模トレーニングインフラで好きだった要素や、以前使っていた優れたツールをすべて再現しつつ、研究や小規模なモデル生産のための小型MoEトレーニングに特化した、まあまあ機能的なシステムができました。しかし、そのリポジトリは絶え間ない実験とトラブルシューティングの結果、完全にダメになってしまいました。また、私の開発チームは私とAIエージェントの艦隊で構成されています。ヴィクが最近言ったように、「泥で生き、泥で死ぬ」と。普段はとても勉強熱心で「この家に泥は絶対になし」と厳格に守っているが、一晩中トラブルシューティングの残骸や様々な放置された実験体の死体が私のリポジトリに散らばっていた。構成やブートストラップの複雑さも爆発的に増加しました。[ナノチャット]にインスパイアされたものが、今ではメガトロンにずっと似ている(悪気はない)。 その結果は?限られたハードウェアで意味のあるMoE研究が可能になりました。7B2Aプロキシを単一のB200 GPUに、16B4Aを8×B200ノードに搭載し、どちらも30k〜40kトークン/秒/GPUに対応しています。さらに重要なのは、スケーリングが予測可能である点です。1→8回のGPU実行では一貫した挙動を示し、小規模なプロキシでの研究がより大きな実行に応用できると自信を持っています。次は32と64のGPUスケーリングを検証します。 解決策は?最初からやり直し、より大きなコミュニティと共有する動機を持ってすべて書き直すのです。だから、今はそれをやっている。今後数週間で、さまざまなトレーニングリポジトリ、ブログ投稿、データグレーディングモデルの重み、W&Bスタイルの可視化および実験追跡システムをコミュニティに公開していく予定です。また、フルインフューレンスエンジンなどのロードマップも控えています。野心の範囲と完全な書き直しの両面で、思ったより少し時間がかかりそうですが、コミュニティの皆さんにも私と同じくらい役に立つことを願っています。 --- 参照： - [DeepSeek-V3技術報告書]( - 【Inside Kaiju: Building Conversational Models at Scale】( - [Moonlight: A Compute-efficient MoE トレーニングフレームワーク]( - [シードコーダー技術報告書]( - [OLMo-3:同クラスで最高の完全オープンモデル]( (NVIZダッシュボードからの初期FP8トレーニングランの写真)

Breakpointのコンテンツは意外とSランクです 内容が充実し、チームが大きな発表をし、クリップも素早く投稿されています もうすぐ2026年ですが、ソラナのように本当にやっている人はいません。全く違います