Xiaohongshuと北京大学がUltraEPを発表、静的MoE負荷分散に挑戦

Xiaohongshuと北京大学は、大規模なmixture-of-expertsインフラストラクチャを支える基本的な前提に疑問を投げかけるUltraEPの研究成果を発表した。UltraEPのMoE負荷分散は、どのエキスパートが過負荷になるかを予測するのではなく、各レイヤーのルーターが実際の需要を明らかにした後で対応する。

この違いが重要なのは、エキスパートへの需要がマイクロバッチ、レイヤー、プロンプトの分野によって変動し得るためだ。直近の履歴に基づく配置計画は、システムが使用する前に陳腐化する可能性がある。UltraEPは、過負荷となったエキスパートの一時的なレプリカを作成し、現在の処理内でトークンを再ルーティングすることで対応する。

著者らによると、UltraEPは3つの大規模MoEモデルにおいて、人為的に均衡させた理想的な学習性能の94.6%に到達した。また、平均学習スループットはMegatron-LMより42%高く、プリフィルスループットはSGLangの1.56倍だったと報告している。

これらの結果はチーム独自の実験によるもので、独立した追試によるものではない。UltraEPの論文は2026年6月に投稿され、北京大学、Xiaohongshu、上海AI研究所、および独立研究者の所属が記載されている。

論文には、実装と評価に関する詳細が豊富に示されている。しかし、公開されたUltraEPのソースリポジトリは明記されていない。そのため、ランタイムコードとライセンスが公に検証可能になるまでは、この研究を完全なオープンソースと表現する際に注意が必要だ。

より重要なのは、そのアーキテクチャだ。UltraEPは、負荷分散を定期的な制御タスクから、すべてのMoEレイヤーの実行パスへと移行させる。これにより、EPLBを含む既存の履歴ベース手法は直接的な圧力にさらされる。

UltraEPのMoE負荷分散はルーティング後に対応する

UltraEPは、分散MoEシステムが作業の負荷分散を決定するタイミングを変える。

mixture-of-expertsモデルには、エキスパートと呼ばれる多数の特化型フィードフォワードネットワークが含まれる。ルーターは各トークンを、それらのエキスパートのうち少数のサブセットに割り当てる。

この設計は、すべてのトークンに対してすべてのパラメーターを使用する場合と比べ、実際に行う計算を削減する。一方で、分散システム上の問題も生じる。同じレイヤー内で、人気のあるエキスパートが隣接するエキスパートよりはるかに多くのトークンを受け取る可能性がある。

エキスパート並列化では、それらのエキスパートを複数のGPUに分散する。通常、トークンはall-to-all通信を介して、選択されたエキスパートをホストするデバイスへ送られ、計算後に戻される。

人気のあるエキスパートを保持するGPUは、より多くのトークンを処理しなければならない。他のGPUは先に処理を終え、同期ポイントで待機することになる。その結果、最も遅いランクが処理全体の速度を決定しかねない。

この不均衡は通信とメモリにも影響する。過負荷のランクは、より多くのトークン活性値を受け取り、より多くのデータを転送し、より多くの一時メモリを必要とする。したがって、1つのルーティング決定が相互に関連する3つのボトルネックを引き起こす可能性がある。

既存のバランサーは多くの場合、最近の測定結果を用いて、冗長なエキスパートコピーの配置先を決定する。例えば、DeepSeekのEPLBプロジェクトは、記録された負荷から均衡の取れたエキスパート配置を算出する。

この手法は、エキスパートの人気度が緩やかに変化する場合には機能する。しかし、プロンプトの構成、トークンの内容、または学習の動態によって、再分散の間隔よりも速く需要が変化すると、信頼性が低下する。

UltraEPの研究者らは、大規模なエキスパート並列構成でこの問題を測定した。レイヤー、ワークロード、隣接するマイクロバッチの間で大幅な変動が見られたと報告している。特にDeepSeek-V3の学習では、短期的な変動が顕著だった。

UltraEPは、ゲーティング処理によって正確なルーティング割り当てが生成されるまで待機する。その後、対象となる特定のレイヤーとマイクロバッチに対して負荷分散計画を算出する。

ランタイムは、予約済みのGPUメモリ内に、負荷の高いエキスパートの追加の物理コピーを作成できる。また、選択されたトークンを元のエキスパートと一時的なレプリカの間で分割する。

これは、モデルの論理的なルーティング決定を変更することなく行われる。トークンは引き続き、モデルが選択したエキスパートを使用する。UltraEPが変更するのは、どの物理コピーが計算を実行するかだけだ。

この分離は、学習のセマンティクスにとって重要だ。著者らによると、レプリカの勾配は逆伝播中に集約される一方、プライマリーパラメーターは引き続き学習フレームワークによって管理される。

UltraEPは、一時的なレプリカをチェックポイントとオプティマイザー状態からも除外する。それらは新たに学習されるエキスパートではなく、実行用リソースである。

したがって、これは単なる高速化されたカーネル以上の意味を持つ。ハードウェアが十分な速度で重みを移動できるなら、エキスパート配置を実際のルーティングへの即時応答に変えられると提案している。

大規模MoEシステムで古い計画のコストが高まる理由

モデルがより多くのエキスパートをより大規模なGPUグループ上で使用するにつれ、負荷分散への圧力は高まる。

細粒度のMoEモデルには、数百もの小規模なエキスパートが含まれる場合がある。大規模なエキスパート並列グループでは、それらのエキスパートを32または64のランクに分散できる。

この構成では、各ランクが保持するのはエキスパートプール全体のごく一部だけとなる。そのため、1つのエキスパートへの需要の変化が、1台のデバイスのワークロードにより直接的に反映される。

ランク当たりのエキスパート数が少ないと、偏りを平均化するための無関係なワークロードも少なくなる。システムは個々のホットスポットに対してより敏感になる。

NVIDIAのMegatron Coreガイドには、複数のルーター負荷分散オプションが記載されている。これには、補助損失、シーケンスレベル損失、グローバル損失、動的エキスパートバイアスが含まれる。

こうした手法は、モデルのルーティング分布に影響を与える。しかし、ルーターが実際のトークンに遭遇した後に生じる瞬間的な変動を排除するものではない。

学習ワークロードは、モデルの学習に伴って変化する。サンプリングによってさらなる揺らぎが生じ、レイヤーごとに異なるルーティングパターンが形成される可能性もある。

推論のプリフィルは、さらに予測しにくい。プリフィルは、トークン単位の生成が始まる前に入力プロンプトを処理する。プロンプトの長さ、主題、到着率、バッチ構成のすべてが同時に変化し得る。

コーディングのバッチは、数学や長文コンテキストのバッチとは異なる形で需要を集中させる可能性がある。無関係なリクエストを組み合わせると、数秒後にはまた別のパターンが生じ得る。

UltraEPの著者らは、履歴ベースのエキスパート配置では、こうした変化に十分な速さで追従できないと主張する。実験では、EPLBが学習時にはグローバルバッチ3回ごと、プリフィル時には50ステップごとに再分散するよう設定された。

論文によると、古くなった配置によってランク間の不均衡が悪化する場合もあった。以前は人気だったエキスパートが需要の移動後もレプリカを保持する一方、新たなホットスポットは集中したままになる可能性がある。

これがUltraEPをめぐる主な競争軸だ。正確なリアルタイム負荷分散と、過去の負荷に基づく定期的な予測との対比である。

これは主に、企業としてのXiaohongshuとNVIDIAまたはSGLangの競争ではない。Megatron-LMとSGLangは、統合フレームワークおよび実験上のベースラインである。どちらも新しい負荷分散システムを組み込める可能性がある。

むしろ圧力がかかるのは、エキスパート配置を低速なコントロールプレーン上の決定として扱うインフラストラクチャ設計だ。UltraEPは、その決定をホットパスへと引き込む。

論文では、128基のGPUを用いてGLM-4.5-106Bの学習を評価している。Qwen3-235BとDeepSeek-V3の学習には、4つのラックにまたがる256基のGPUが使用された。

Qwen3-235B-A22Bは、その規模を理解するうえで有用な例だ。公式のQwenリポジトリでは、総パラメーター数2,350億、トークン当たりのアクティブパラメーター数220億のモデルと説明されている。

本番環境でのテストでは、研究者らは32-wayエキスパート並列構成で、社内モデルRefMoE-288B-A16Bを使用した。その実行中、UltraEPは理想的なスループットの92%以上を維持したと報告している。

またチームは、負荷分散を行わない期間のサンプルと比較して、平均9.6%の改善を報告している。論文によると、学習損失曲線は予想された推移をたどった。

この本番テストは、短いベンチマーク期間を超えている点で価値がある。しかし論文では、ワークロード全体、クラスターの経済性、運用上の障害履歴は開示されていない。

したがって、この結果は著者らの環境における本番利用の実現可能性を裏付けるものではあるが、あらゆる大規模MoEクラスターが同様の改善を得られることを立証するものではない。

その仕組みは高速なエキスパート複製に依存する

UltraEPは、配置とトークンの再ルーティングを同時に解決し、レプリカ移動の大部分を計算処理の背後に隠すことで機能する。

ランタイムは、ルーティング後に生成された正確な負荷行列から処理を開始する。この行列には、各ソースランクからのトークンが各論理エキスパートを何個選択したかが記録される。

次にUltraEPは、目標とするワークロードのしきい値を探索する。その目的は、利用可能なレプリカスロットの範囲内で、すべてのGPUランクをそのしきい値未満に保つことだ。

クォータ駆動型のプランナーが、どの高負荷エキスパートにコピーが必要か、そのコピーをどこで実行するか、各インスタンスが何個のトークンを受け入れるべきかを決定する。

この統合的な決定は、先にエキスパートのレプリカを選択し、後でトークンを分配する方法とは異なる。レプリカは、計画によって有用な作業が割り当てられる場合にのみ作成される。

プランナーは局所性も優先する。システムが残りの需要を他の場所へ送信する前に、トークンは近隣またはローカルのエキスパートインスタンスの処理能力を利用できる。

集約クォータが設定された後、ランタイムはそれらをトークン単位の送信先に変換する。論文では、このステップを累積クォータに対する局所的なルックアップと説明している。

プランナーは完全にGPU上で動作する。これにより、各レイヤー内でのCPU同期やホストとデバイス間のメタデータ転送を回避する。

この選択は、リアルタイム負荷分散に関する明白な懸念の1つに対処する。正確な計画であっても、その計算による停止時間が不均衡による遅延を上回るなら、ほとんど価値がない。

計画は問題の半分にすぎない。再割り当てされたトークンを処理するには、対象GPUがエキスパートの最新の重みを保持している必要がある。

学習ではオプティマイザーの更新後に重みが変化するため、これはさらに難しくなる。ランタイムは、何バッチも前にコピーされたレプリカが最新の状態を保っていると仮定できない。

UltraEPは、各ランクに冗長なエキスパートスロットを確保する。レイヤーの実行中、デバイス側の転送タスクを用いて、必要なエキスパート状態をそれらのスロットにストリーミングする。

論文では、これを永続的タイルストリーミングと呼んでいる。エキスパートのテンソルは小さなタイルに分割されるため、転送ではラックファブリックを継続的に利用しながら、他の処理と重ね合わせることができる。

多数のGPUが同じエキスパートを要求すると、単一のソースランクが通信のホットスポットになる可能性がある。UltraEPは、リレーベースのファンアウトによってこの問題に対処する。

元の保持元は、選択されたリレーランクにチャンクを送信する。それらのランクは、転送を継続しながらチャンクを他の送信先へ転送する。

この構造により、利用可能な帯域幅を持つデバイス間で送信トラフィックが分散される。1つのソースからポイントツーポイントのコピーを繰り返すのではなく、ストリーミング型の配信ツリーに似ている。

研究者らによると、この通信設計は、評価対象となった主要な通信バックエンドより3.1～5.5倍高速にエキスパート状態を複製した。

UltraEPは、トークンのディスパッチと結合にDeepSeekのDeepEPライブラリを統合している。DeepEPがルーティングされたトークンデータの移動を処理する一方、UltraEPは動的なエキスパート複製と負荷分散を管理する。

スタンドアロンのUltraEPランタイムは、デバイスカーネルを含め、約9,600行のC++とPythonで構成されていると報告されている。Megatron-LMとSGLangへの各統合に必要だった追加コードは、いずれも1,000行未満だった。

このモジュール性は、導入にとって重要だ。1つのモデルフレームワークに結び付いたバランサーでは、本番環境への導入経路がはるかに限定される。

この設計では、プライマリーエキスパートについて、フレームワークが管理する状態も維持される。一時的なレプリカは共有内部バッファーを使用するため、オプティマイザー状態の重複や永続的なチェックポイントの肥大化を回避できる。

これらの選択は、UltraEPがレイヤー単位でどのように再バランスできるかを説明しています。同時に、その中核的な依存条件も明らかにしています。このシステムは、ラックスケールノード内で極めて高速な通信が行われることを前提としています。

ベンチマーク上の性能向上にはハードウェア上の境界がある

UltraEPの最も優れた結果は、一般的なマルチノードクラスタではなく、ラックスケールGPUファブリックに当てはまります。

ラックスケールノードは、高帯域幅のスケールアップ接続を単一サーバーの範囲外まで拡張します。論文のテスト環境では、各ラック内の16台のサーバーに64基のGPUが配置されていました。

著者らによると、ラックのスケールアップリンクは、スケールアウトRDMAネットワークの8倍から10倍の帯域幅を提供しました。

UltraEPは、各エキスパート並列グループをこの高速な領域内に維持します。ラックをまたぐ拡張には、データ並列処理またはパイプライン並列処理を使用します。

このトポロジーにより、ランタイムはルーティング後にエキスパートの重みを移動しつつ、転送遅延全体を顕在化させないだけの帯域幅を確保できます。

一般的なEthernetまたは低帯域幅のRDMAクラスタでは、この条件を満たせない可能性があります。エキスパートの状態をコピーするコストが、過負荷状態のランクを待つコストを上回る場合があります。

この論文は、コモディティクラスタ全般における普遍的な性能を主張していません。そのタイトルとシステム設計は、ラックスケールノードを明確に対象としています。

この制約によってアプローチが無効になるわけではありません。このアプローチが合理的に成立する市場を定義しているのです。

NVIDIA、AMD、クラウドプロバイダーは、高速なアクセラレータファブリックを備えた、より高密度なラックスケールシステムを構築しています。UltraEPは、そのハードウェアを動的なモデル実行のためのプログラム可能なリソースとして扱います。

報告されたトレーニング比較では、バランシングなしのベースラインとしてMegatron-LMが使用されました。GLM-4.5-106B、Qwen3-235B、DeepSeek-V3において、UltraEPは平均スループットを42%向上させました。

評価されたその他のバランシング手法でもスループットは向上しましたが、その幅はより小さいものでした。論文では、その性能が低かった理由として、レイアウトの遅延、レプリカ予算の制限、または再ルーティングの有効性不足を挙げています。

UltraEPは、強制的にバランスさせたトレーニングの理想値に対して平均94.6%を達成しました。この理想値では、トークンを均等に分配するようルーターが変更されているため、実運用可能なモデルの挙動ではなく、人為的な上限を示しています。

サービングのプリフィルでは、UltraEPは理想的なスループットの平均93.9%を達成しました。個別のテスト結果は90%から97%の範囲だったと報告されています。

研究者らは、各バランシングアルゴリズム間で負荷条件を一定に保つため、SGLangから取得したルーティングトレースを再生しました。その結果、SGLangの1.56倍、EPLBの1.29倍のスループットを達成したと報告しています。

SGLangはすでに、エキスパート並列通信用および計算用の複数のバックエンドをサポートしています。そのエキスパート並列処理のドキュメントでは、デプロイ結果がハードウェア、量子化、バックエンドの選択にどのように左右されるかが示されています。

UltraEPとSGLangの比較では、バージョン0.5.9と指定されたコミットが使用されました。この分野のソフトウェアは急速に進化しているため、後続のフレームワークリリースでは、測定された差が縮小または変化する可能性があります。

また、この評価はトレーニングとサービングのプリフィルに重点を置いています。UltraEPを自己回帰デコードの汎用的なソリューションとして提示しているわけではありません。

デコードでは、ステップごとに処理する新規トークン数が少なく、多くの場合、メモリ帯域幅がボトルネックになります。このような短い処理中にエキスパートの重み全体を移動すると、コスト構造が異なります。

ベンチマーク手法には、もう一つ制約があります。3つの公開モデルを用いたトレーニング比較では、後期段階のチェックポイントから再開し、追加で20グローバルバッチを実行しました。

研究者らは、複数のバランシング間隔を網羅するためにこの期間を選択しました。しかし、これは各ベースラインについて完全に独立したトレーニングを実行する代わりにはなりません。

著者らは、社内の本番環境でより長期間のトレーニングも実施し、収束が維持されたと報告しています。しかし、外部の研究者は、非公開モデル、コーパス、正確なクラウド環境を再現できません。

メモリオーバーヘッドにも注意が必要です。UltraEPは冗長エキスパート用のスロットを予約しますが、論文では、バランシング後にトークンアクティベーションのピークメモリが減少したと報告されています。

それでも運用者は、一時的な重みと通信バッファ用の容量を確保する必要があります。適切な予約容量は、エキスパートのサイズ、精度、ワークロードの偏り、トポロジーによって異なります。

最後に、一般公開の状況は依然として不明です。論文では実装規模と統合の詳細が開示されていますが、確認可能なUltraEPのリポジトリリンクは提供されていません。

論文が公開されていることと、ソフトウェアがオープンソースであることは同じではありません。コード、ビルド手順、ライセンスが公開されるまでは、外部チームは仕組みを研究できても、実装を直接監査することはできません。

UltraEPの結果はMoEインフラを巡る議論を変える

この論文は、将来のMoE効率向上が、静的カーネルの改善だけでなく、ワークロードの状態への対応からもたらされることを示唆しています。

分散MoEの最適化は、多くの場合、3つの領域に集中してきました。チームはトークンディスパッチを改善し、グループ化された行列演算を融合し、トレーニング中のルーターの挙動を調整します。

UltraEPは、そこにもう一つのレイヤーを追加します。ルーターの実際の決定を確認した後、物理的な実行レイアウトを変更します。

この設計は、通信ライブラリや高速な行列カーネルを置き換えるものではありません。それらの上位に位置し、各エキスパートの計算をどこで実行するかを決定します。

この違いにより、複数の改善を積み重ねる余地が生まれます。デプロイ環境では、より優れたルーティング目標、最適化されたall-to-allディスパッチ、高速なエキスパートカーネル、リアルタイムの物理レプリケーションを組み合わせられる可能性があります。

履歴ベースの配置がなくなることはありません。需要の変化が緩やかな場合や、ハードウェアがエキスパートの重みを迅速に移動できない場合には、引き続き低コストだからです。

予測によって、正確な需要が到来する前にシステムを準備することもできます。ハイブリッド方式では、履歴をベースライン配置に使用し、正確な負荷情報を限定的な補正に使用できるでしょう。

UltraEPによって、その比較が測定可能になります。将来のシステムは、正確な負荷に基づく補正が実用化された後も、予測的配置が競争力を維持できるかを示す必要があります。

この研究は、インフラチームが使用率を解釈する方法も変えます。GPUの平均使用率が低い場合、カーネルの性能不足ではなく、同期上の問題が隠れている可能性があります。

あるランクが過負荷となり、ほかのランクが待機している場合、平均的なカーネル速度を向上させても、クリティカルパスはほとんど変わらない可能性があります。最も遅いランクの負荷を均衡させることで、システム全体としてより大きな改善を得られます。

この教訓は、基盤モデルのトレーニング以外にも及びます。大規模なプリフィルワークロードは、分類、文書分析、レコメンデーション、検証、バッチ推論サービスにも現れます。

多様な企業文書を処理する企業では、エキスパート需要が急速に変化する可能性があります。法律文書、ソースコード、財務報告書、サポート対応では、それぞれ異なるエキスパートの組み合わせが活性化される可能性があります。

このようなワークロードは、不均一なバッチとして到着することもあります。キューの内容が、短い顧客メッセージから長い技術文書へ、予告なく切り替わる場合があります。

UltraEPが報告した優位性は、このような変動下で大きくなります。そのため、このシステムはフロンティアモデルを事前トレーニングするチームだけでなく、異種のプロンプトを処理する運用者にも関係します。

それでも、経済的な妥当性は使用率とハードウェアコストに左右されます。スループットが一定割合向上したからといって、ラックスケールへの移行が自動的に正当化されるわけではありません。

チームは、追加で予約するメモリ、ファブリック要件、エンジニアリングの複雑さ、信頼性を、スループット向上の価値と比較する必要があります。

運用上の制御も必要です。動的なエキスパートレプリケーションは、バッファ管理、同期、勾配集約、転送スケジューリングに関する新たな障害モードを生み出します。

この論文が提示しているのは、慎重に協調設計されたランタイムであり、どのクラスタでも安全に有効化できる設定フラグではありません。

Megatron-LM、SGLang、vLLM、DeepEPのコントリビューターにとって、UltraEPは具体的な実装目標を提示します。フレームワークのメンテナーは、同様のプランニングを既存のランタイムに組み込むべきかを検証できます。

アクセラレータベンダーにとって、この論文はピアメモリアクセスとデバイス起動型通信の価値を強調しています。ソフトウェアが不規則なエキスパート転送を効率的にスケジュールできなければ、高速なリンクだけでは不十分です。

モデル設計者にとって、この結果は特化型ルーティングに伴うシステム上のペナルティを一つ軽減します。実行時のバランシングを改善すれば、厳格で人為的な均一性を強いることなく、トークンのニーズに従ってルーティングできる可能性があります。

これは微妙な論点です。ルーター側のバランシング損失によって、トークン割り当てを均等なエキスパート使用率へ近づけられますが、過度な圧力はエキスパートの専門化を妨げる可能性があります。

UltraEPは、モデルの論理的な選択を維持し、その物理的な実行だけをバランスさせようとします。独立した追試で再現されれば、この分離が最も重要な貢献となる可能性があります。

UltraEPのリリース後に注目すべき点

UltraEPがインフラの標準的なパターンになるのか、それとも魅力的な研究プロトタイプにとどまるのかは、3つの兆候によって決まります。

最初の兆候は、コードの公開です。検証可能なリポジトリには、ランタイム、対応ハードウェア、ビルドプロセス、フレームワークへのパッチ、テスト、ライセンスが含まれている必要があります。

コードにアクセスできれば、外部チームはGPUプランナーとレプリケーションパイプラインを調査できます。また、「オープンソースUltraEP」という表現がソフトウェアを指すのか、単に公開された研究を指すのかも明確になります。

Qwen3-235Bを使用した独立した再現実験により、報告された主張の信頼性が高まるでしょう。比較可能な結果では、GPUの種類、ファブリックトポロジー、精度、バッチ設定、フレームワークのコミットを開示する必要があります。

独立したチームが論文のトレーニング結果である94.6%に近づけば、正確な負荷に基づくバランシングは再現可能な手法としての信頼性を獲得します。大きな差が生じれば、環境固有の優位性があることを示唆します。

2つ目の兆候は、単一のラックアーキテクチャを超えたサポートです。異なるラックスケールプラットフォームでテストすれば、性能のどの程度がアルゴリズムに由来し、どの程度が特定のファブリックに由来するのかが明らかになります。

より小規模なクラスタでの結果も、同様に有益です。動的レプリケーションのコストが利益に見合わなくなる帯域幅のしきい値を特定できる可能性があります。

デコードのサポートも、この兆候の一部です。UltraEPは現在、重み転送を隠蔽できるだけの計算量が存在し得るトレーニングとプリフィルを対象としています。

将来のデコード設計では、異なるレプリケーション戦略、より小さな転送単位、またはステップ間でのより強力な再利用が必要になります。デコードに対応できなければ、UltraEPの対象はサービングの一部に限られたままとなります。

3つ目の兆候は、フレームワークへの採用です。Megatron-LM、SGLang、vLLM、DeepEPへのネイティブまたは実験的な統合により、より幅広いワークロードでシステムを検証できるようになります。

フレームワークへの採用により、新しいカーネルや通信バックエンドとの比較も、より公平になります。現在のベースラインは、著者らの評価で使用された特定のバージョンを表しています。

本番環境のテレメトリは、単一のベンチマークより重要です。運用者は、テールレイテンシ、メモリの余裕、プランナーのオーバーヘッド、レプリカの入れ替わり、ハードウェア障害時の挙動を報告する必要があります。

また、完全な実行を通じて精度とトレーニングの収束を測定する必要があります。物理的な再ルーティングはモデルの意味論を維持するはずですが、長期的な運用は短い継続実行よりも強力な検証になります。

UltraEPのMoE負荷分散は、明確な主張を提示しています。ラックスケール通信によって即時レプリケーションのコストを許容できる場合、正確なルーティング情報は履歴ベースの配置を上回り得ます。

論文の数値は、著者らの環境内でその主張を裏付けています。トレーニングで42%の向上、プリフィルで1.56倍という結果は注目に値するほど大きい一方、追試を省略できるほど決定的ではありません。

開発者は、デプロイを計画する前に、コードと再現可能なベンチマークの公開を待つべきです。インフラ購入者は、自社のファブリックが各レイヤーのクリティカルパス上でエキスパートの移動を支えられるかを確認する必要があります。

この研究を評価するチームは、論文、ベンチマークのメモ、デプロイに関する決定を、検索可能なエンジニアリング知識ベースに保存できます。当面の焦点は、独立した検証結果によってUltraEPが印象的な論文からデプロイ可能なMoEインフラへと変わるかどうかです。