トランスフォーマーにおけるエキスパート混合（MoEs）

記事に戻る トランスフォーマーにおけるエキスパートの混合 (MoEs) 11 件の高評価 ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1594651707950-noauth.jpeg) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1613845120202-noauth.png) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1617264212503-603d25b75f9d390ab190b777.jpeg) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/6141a88b3a0ec78603c9e784/DJsxSmWV39M33JFheLobC.jpeg) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/620b7c408f5871b8a1a168a7/49M2lucv3I24rOMJFnhVd.jpeg) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/62d648291fa3e4e7ae3fa6e8/oatOwf8Xqe5eDbCSuYqCd.png) 過去数年間、稠密な言語モデルのスケール拡大が大規模言語モデル (LLM) の進歩を牽引してきました。初期のモデルであるオリジナルの ULMFiT（約 3000 万パラメータ）や GPT-2（15 億パラメータ、当時は「公開するには危険すぎる」と考えられていた 🧌）から始まり、最終的には今日のような数百億パラメータを持つシステムに至るまで、そのレシピは単純でした。 より多くのデータ + より多くのパラメータ = より良いパフォーマンス。 スケール則はこの傾向を強化しましたが、稠密なモデルのスケール拡大には実用的な限界があります。 - 学習コストがますます高くなる。 - 推論レイテンシが増大する。 - デプロイには大量のメモリとハードウェアが必要となる。 ここで登場するのがエキスパートの混合 (Mixture of Experts: MoEs) です。 MoE についてすでに知識があり、トランスフォーマーにおけるエンジニアリングの実装に直接飛び込みたい場合は、"Transformers and MoEs" のセクションへ直接お進みください。 稠密からスパースへ：MoE とは何か Mixture of Experts モデルは Transformer のバックボーンを維持しつつ、特定の稠密なフィードフォワード層を複数のエキスパートのセットに置き換えます。「エキスパート」とは、「数学エキスパート」や「コードエキスパート」のようなトピック特化型モジュールではなく、単なる学習可能なサブネットワークです。各トークンに対して、ルーターが処理のために小さなサブセットのエキスパートを選択します。 ![](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/moe-transformers/moe_routing.png) 図 1: 4 つのエキスパートのうち 1 つが活性化されている（出典：Maarten Grootendorst） 異なるトークンは、その隠れ表現に基づいて異なるエキスパートを活性化します。 モデルの容量は総パラメータ数に依存しますが、推論速度はアクティブなパラメータ数に依存します。 これが核心となる考え方です。 例えば、gpt-oss-20b を考えてみましょう。 800 / (3.6 * 2) この極めて高速な処理速度は、モデルが約 3.6B パラメータのモデルとして動作していることを裏付けていますが、同時に 21B パラメータのモデルと同等の容量（または品質）を有しています。 （注：モデルが使用するネイティブの mxfp4 量子化にカーネルを使用すれば、速度はさらに向上します） MoE は以下の理由から魅力的です： より優れた計算効率 固定されたトレーニング FLOP バジェットにおいて、MoE は稠密な対照モデルを凌駕することが多いです。 ![](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/moe-transformers/faster_training.png) 図 2: 稠密型と MoE のトレーニング曲線の比較（出典：OLMoE: Open Mixture-of-Experts Language Models） これは、より迅速な反復と優れたスケーリング効率を意味します。 自然な並列化軸 エキスパートは計算グラフにおいて構造的な境界を提供します。異なるトークンが異なるエキスパートに関与するため、エキスパート間での並列化が可能になります（この点については後述する「エキスパート並列性」で詳しく議論します）。 業界における採用 過去数週間に発表された主要なオープンモデルの MoE リリースには、Qwen 3.5、MiniMax M2、GLM-5、Kimi K2.5 などがあります。 この傾向は、2025 年 1 月の DeepSeek R1 の成功により加速し、DeepSeek V2 などの先行システムを基盤としています。また、早期の MoE の一例として、Mixtral-8x7B が 2023 年 12 月にリリースされています。 ![](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/moe-transformers/moe_2y_timeline.png) 図 3: トランスフォーマーへの MoE モデル追加の 2 年間のタイムライン クローズドな研究機関もまた MoE を採用しています。ChatGPT がスパースアーキテクチャを使用しているという噂は長く存在しており、オープンソース化された gpt-oss モデルでは確かにその実装が確認されています。 MoE 全般についてさらに学びたい場合は、当ブログ記事の閲覧と、ルーティングに関する最近の YouTube ビデオのご視聴を強くお勧めします。 トランスフォーマーと MoE エコシステム内のほとんどのツール（モデルの読み込み、デバイス配置、量子化、バックエンド実行など）は、もともと密なモデルのために設計されました。MoE はこれらの前提に挑戦しています。 トランスフォーマーにおける MoE のファーストクラス・シチズン化への取り組み - 重み読み込みのリファクタリング - エキスパート並列性 - トランスフォーマーを用いた MoE のトレーニング 重み読み込みのリファクタリング AutoModelForCausalLM.from_pretrained("model_id") MoE の場合、より複雑になります。ほとんどの MoE チェックポイントでは、各エキスパートは独立してシリアライズされています。DeepSeek-V3 チェックポイントのインデックスの中身を覗いてみると、以下のようなキーが見られます: model.layers.3.mlp.experts.0.gate_proj.weight ... model.layers.3.mlp.experts.255.gate_proj.weight 各エキスパートには独自の重み行列セットがあり、要するに 256 個（DeepSeek-V3 を例にとれば 0 から 255 の合計）の小さな順方向ネットワークが並んで保存されています。しかし実行時には、GPU は最適化されたカーネルを実行します。グループ化 GEMM や融合 MoE 実装といった最新の MoE カーネルは、エキスパートを一つずつループ処理するのではなく、単一の操作ですべてのエキスパートを処理するように設計されています。 これを効率的に行うためには、エキスパートの重みを単一の連続したテンソルにパッキングする必要があります。 つまり、以下のような不一致が生じます: チェックポイント: 256 個の別々のテンソル 実行時: 1 つのパックされたテンソル このギャップを体系的に埋めることが、重み読み込みのリファクタリングによって可能になります。 汎用的な WeightConverter の導入により、思考モデルは以下のように変化しました: 「チェックポイントはすでに私の実行時のレイアウトと一致しており、読み込みは主にキーごとのコピーである」 から 「チェックポイントは単なるテンソルのシリアライズされたソースに過ぎず、読み込みは望む実行時レイアウトへ変換する変換パイプラインである」 WeightConverter による動的重み読み込み このリファクタリングによって導入された中心的な抽象化は、WeightConverter を介した動的重み読み込みです。 WeightConverter ソースキーパターン → ターゲットキー (複数可) + 演算 プリミティブ演算（チャンク、結合など）は合成可能です。MoE において特に有用な 2 つの演算: MergeModulelist MergeModulelist WeightConverter( ["block_sparse_moe.experts.*.w1.weight", "block_sparse_moe.experts.*.w3.weight",], "mlp.experts.gate_up_proj", operations=[ MergeModulelist(dim=0), Concatenate(dim=1), ], ) SplitModulelist WeightConverter( "mlp.experts.down_proj", "block_sparse_moe.experts.*.w2.weight", operations=[SplitModulelist(dim=0)], ) テンソルの遅延初期化 (Lazy Materialization) このリファクタリングは、存在する変換の種類だけでなく、それらのスケジューリング方法も改善します。 ローダーはチェックポイントキーを一度スキャンし、コンバーターパターンと照合して、各コンバーターごとにテンソルをグループ化します。あるキーが必要であると識別されると、それは未来のタスクとして登録され、スレッドプールを通じて初期化されます。変換演算は、依存関係が満たされた後にのみ実行されます。例えば、MergeModulelist これにより、繰り返されるスキャンが回避され、メモリのピーク値が削減されます。 ベンチマーク：重み読み込みパイプラインの改善 新しい重み読み込みパイプラインによって導入された改善を評価するために、transformers の v4 バージョンと v5 バージョンをベンチマークしました。 v4 と v5 を以下を使用してベンチマークしました: v4 ブランチ: https://github.com/ariG23498/transformers/tree/bench-v4 v5 ブランチ: https://github.com/ariG23498/transformers/tree/bench-v5 from transformers import AutoModelForCausalLM model_id = "Qwen/Qwen1.5-110B-Chat" model = AutoModelForCausalLM.from_pretrained(model_id) 関連する 2 つの環境変数: HF_ENABLE_PARALLEL_LOADING HF_DEACTIVATE_ASYNC_LOAD モデル：Qwen/Qwen1.5-110B-Chat device_map="auto" device_map="auto" device_map="auto" 非同期（デフォルト） device_map="auto" ![](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/moe-transformers/loading_benchmark.png) 図 4：読み込みベンチマーク（v4 vs v5） 高速化は単に「スレッド数が増える」だけではありません。 それは、シングルパスルーティング、非同期マテリアライゼーション、変換認識スケジューリングの組み合わせによるものです。これらが一体となることで、不要なマテリアライゼーションやメモリピークを回避しつつ、読み込み時にエキスパートのパッキングと射影融合を可能にします。 量子化がどこに位置するか このリファクタリングにより、まずランタイムモジュール構造を作成し、その後重みをその構造に変換することが可能になりました。また、変換パイプライン内で任意に量子化を付与できるようになり、量子化自体が重み読み込みパイプラインの一部となりました。これは極めて重要です。なぜなら、「エキスパートごと」の量子化は、エキスパートが予測可能なパッキングレイアウトとして存在して初めて意味を持つからです。 このエンドツーエンドのパイプラインは以前は不可能でしたが、現在は公開 API としてユーザーに提供されています。 エキスパートが単一のランタイムテンソルにパッキングされた後、別の疑問が生じます： 実際にどのように効率的にそれらをルーティングすればよいのでしょうか？ Mixture of Experts モデルでは、各トークンは異なるエキスパートへルーティングされます。つまり、ランタイムはトークンを選択されたエキスパート重みにディスパッチし、射影を効率的に実行し、ルーティング重みを適用した上で、結果を集約して再順序付けする必要があります。 これは、PR #42697 で紹介された Experts Backend システムが解決する課題です。Experts Backend は、専門家の計算をモデル実装から切り離すプラグイン可能な実行アーキテクチャを導入します。各 MoE モデル内にディスパッチ戦略をハードコードするのではなく、このシステムにより専門家層はランタイムでバックエンドを動的に選択できます。 これはデコレータパターンを通じて実装されます: @use_experts_implementation デコレータは専門家クラスをラップし、計算を選択されたバックエンドへ自動的にディスパッチします。 現在、3 つのバックエンドが提供されています: torch._grouped_mm ![](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/moe-transformers/expert_backend.png) 図：専門家バックエンドの概要図 専門家の並列処理 (Expert Parallelism) Mixture of Experts (MoE) モデルは数百億ものパラメータを持つ可能性があります（単一の GPU に収まる量をはるかに超えます）。専門家の並列処理 (EP: Expert Parallelism) は、専門家を超えた複数のデバイスに分散させることでこの課題に対処します。各デバイスは割り当てられた専門家のサブセットのみを読み込み、その専門家に対する計算を行い、その後結果の集約に参加します。このアプローチにより、各トークンが活性化するのは少数の専門家だけであるため、計算コストを増やすことなく、モデルをさらに大規模なパラメータ数にスケールさせることが可能になります。 専門家の並列処理は、enable_expert_parallel を通じて有効化されます。 import torch from transformers import AutoModelForCausalLM, AutoTokenizer from transformers.distributed.configuration_utils import DistributedConfig distributed_config = DistributedConfig(enable_expert_parallel=True) model = AutoModelForCausalLM.from_pretrained( "openai/gpt-oss-120b", dtype="auto", distributed_config=distributed_config, ) torchrun --nproc-per-node N script.py When enable_expert_parallel=True Core components of EP lie in: GroupedGemmParallel num_experts / num_devices Training MoEs with Transformers MoEs are excellent for scaling inference, but training them is significantly more complex. MoEs have a Massive parameter count, the distributed expert communication is complicated, there are routing in-stabilities that need to be handled. To address this, we collaborated with Unsloth to enable significantly faster Mixture-of-Experts training: ~12× faster MoE training >35% VRAM reduction ~6× longer context 12–30× overall speedup compared to v4 We leverage the Expert Backend abstraction, standardize around PyTorch's torch._grouped_mm For full details, we recommend reading: Unsloth's official guide As sparse architectures continue to evolve, we want the transformers library to evolve with them. If you're building with MoEs or experimenting with new sparse ideas, we'd love to hear from you. Let us know what abstractions, kernels, or workflows you'd like to see next in transformers More Articles from our Blog Hot Continuous batching from first principles ![](https://cdn-avatars.huggingface.co/v1/production/uploads/6123945a0ed258ebc83f3d56/8wMHFQHEV24G_ljl4kPxQ.jpeg) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1674683851722-62441cb7456803e95009a08f.jpeg) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1666977434736-617bc8d1000dbbbf7c2

トランスフォーマーにおけるエキスパート混合（MoEs）

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト