CursorはMoKをオープンソース化し、トークンスケジューリング、GPU間通信、エキスパート計算を同一のGPUカーネルに統合しました。このソリューションはGB300 NVL72でMXFP8のフォワード処理を最大2.37倍、バックワード処理を1.78倍高速化し、512枚のGB300 GPUを使用したトレーニングのスループットを41%向上させて1070.2トークン/秒を実現しました。シグナリング遅延は103μsから18μsに低下しました。分析によると、NVLinkの帯域幅がすでに130 TB/sに達した今日、GPU内のデータ移動時間が新たな性能ボトルネックとなっています。この突破は、AI競争が「スタック全体の主権」の段階に入ることを示しており、コードがGPUメモリやレジスタに近い企業ほど、より大きな価格決定権を有することになります。記事執筆者、出典：雷峰網
7月21日、NVIDIAはGB300 NVL72を用いてDeepSeek-V3をトレーニングした最新の成績を発表しました。256枚のGPUで、1枚あたりのパフォーマンスは1,648 TFLOPSに達しました。
2週間も経たないうちに、CursorはMixture-of-Kittens（MoK）をオープンソース化した。より高速な行列乗算を追求するのではなく、MoEの実行方式を一から書き直し、トークンスケジューリング、GPU間通信、エキスパート計算をすべて同じGPUカーネルに統合した。
これはやや直感に反します。GB300 NVL72は72枚のGPUを同じNVLinkドメインに統合しており、ラック全体のNVLink総帯域幅は130 TB/sに達しています。この仕様から見ると、GPU間のデータ転送は十分に高速であるはずです。
大規模MoEトレーニングにおいても、通信はエキスパート計算のボトルネックとなります。
問題はMoEのデータフローにあります。ルーターは各ステップでトークンをどのエキスパートに送るかを再決定し、エキスパートは異なるGPUに分散しています。トークンはまず別のカードに送信され、計算が完了した後、再び送り返される必要があります。送信前には位置を整理し、到着後はデータが完全に到着するのを待つ必要があります。MXFP8とBlackwell Tensor Coreによってエキスパートの計算時間が短縮されるにつれ、かつては計算の裏で隠れていたこれらの待機時間が次第に目立つようになっています。
CursorがMoKを実装する際は、ここから着手する。一度のDispatchでどれだけ速く伝送できるかだけを追求するのではなく、トークンが専門家に到達する方法、計算をいつ開始するか、そして通信と計算をどのようにGPUを同時に占有させるかを再構成している。
今日、算力リソースがBlackwellとNVLinkによって極限まで積み上げられた中で、開発者は気づいた：ハードウェアがどれほど速くても、非効率なソフトウェアのオーケストレーションは救えない。
MoKのオープンソース化は、カーネルの勝利であるだけでなく、「アプリケーション層がオペレーターを定義する」時代の幕開けを示している：最後の30%の計算能力を引き出すために、AIスタートアップが基盤の主権を奪う戦いを開始している。
しかし、Cursorのこの設計がなぜ効果的なのかを理解するには、まずMoEがどこで「通信税」を支払っているかを明確に見極める必要があります。
01
MoEの「通信税」
トークンを送るだけでは済まない
通常の密接FFNでは、トークンが通過する重みは基本的に固定されています。MoEにルーターを導入すると、各トークンは一時的に複数のエキスパートを選択します。エキスパート並列化を採用すると、エキスパートは複数のGPUに分割されるため、1回のフォワードプロパゲーションで少なくとも2回のデバイス間通信が発生します。
最初のラウンドはDispatchで、トークンを専門家がいるGPUに送信します。専門家が計算を完了すると、Combineを通じて結果をトークンの元の位置に戻します。トレーニングには逆伝播も含まれ、これに対応して逆方向の通信をさらに二回実行します。
ただ大きな連続データをAからBに移すだけであれば、NVLinkは十分に高速である。MoEの課題は、Routerが各ステップで異なるデータ分布を出力する点にある。
ある専門家はこのステップで多くのトークンを受け取り、次のステップでは非常に少ないトークンを受け取る可能性があります。システムはまず、各専門家が持つトークンの数を正確に数え、それらのトークンをターゲットGPU上のどの位置に配置するかを決定する必要があります。また、同じ専門家のデータはできるだけ隣接して配置する必要があります。Grouped GEMMは、整然とした入力を得て、Tensor Coreに効率的に供給できるようにします。
通信が終了しても、すぐに計算を開始することはできません。対象GPUは、リモートからの書き込みがすべて完了し、データが確実に可視化されたことを確認する必要があります。また、専用負荷は完全に均等ではなく、一部のGPUは早く終了しても、最も負荷の高い専用が終了するまで待つ必要があります。
したがって、「通信」フェーズでは、データ移動、レイアウト生成、同期、負荷の不均衡が混在しています。130 TB/sは、ラック全体が提供可能なピーク帯域幅を示しており、毎回の動的で細分化されたMoE通信がこれらのリンクを同時に満たすことを意味するわけではありません。
DeepEPはそのデータ移動を非常に高速に実現しています。これはExpert Parallel向けに設計された高性能通信ライブラリであり、専用のDispatchおよびCombineカーネルを提供し、FP8をサポートし、通信に使用するSM数を制御できます。最新バージョンでは、より少ないSMで高い通信スループットを維持することが可能です。
単一のMoEでも、ディスパッチ、グループ化GEMM、およびコンバインの間で繰り返しやり取りが必要です。
ここで実際的な矛盾に直面します：十分なトークンが揃うまで待ってから計算すると、行列が大きくなり、Tensor Coreが効率よく動作しますが、計算の開始が遅れます。一方、トークンが少しでも揃い次第計算を開始すると、通信と計算をより早く重ねることができますが、行列が小さくなりすぎて、GPUの多くのSMに十分な作業量が与えられません。
複数のCUDAストリームを使用すると、通信と計算を並列化できますが、両側が常に適切なGPUリソースを確保することは困難です。
MoKの後続のデザインは、基本的にこの「リズム」の問題に対処しています。
02
トークンを送信しながら計算するにはどうすればよいですか？
MoKの最も興味深い変更の一つは、フロントディスパッチをPushからPullに変更したことです。
従来のPushは直感的です：ソースGPUがトークンを保持している場合、自らそれをターゲットGPUに書き込みます。問題はターゲットアドレスにあります。1枚のGPUは、他の多くのGPUから同時にトークンを受け取ります。
各送信者は、どのセクションに書き込むべきかを事前に把握しなければならず、重複してはならない。同じ専門家のトークンは連続して配置するのが最良であり、そうでなければ後続のGEMMが再整理されてしまう。
参加するGPUが増えるにつれて、このスケジューリングプロセスはますます重くなります。Pullは別の方法を採用しました：エキスパートが自身の目的GPUを保存し、必要なトークンを自ら読み取ります。トークンがどのソースGPUにあり、ソースデータのどの位置にあるかを知れば、ローカルへの保存場所は自分で決定できます。
これにより、送信者間でターゲットアドレスを調整する必要がなくなりました。受信したデータは、ローカルのエキスパートによって直接整理できます。
興味深いことに、Pullはデータを少なく送信しているわけではありません。Cursorのマイクロベンチマークでは、同じ256×256 BF16データブロックについて、PushはNVLink上で約159.6 KBを移動するのに対し、Pullは読み取りに追加のリクエストを送信するため、172.0 KBに達します。
Pullの利点は別の点にあります：MoEの通信は断片的で、負荷が不均等です。NVLinkの両方向には独立したチャネルが備わっており、Pullはリクエストとデータ返信の両方向を同時に活用できます。専門家負荷が不均等なテストでは、CursorがNVLinkの利用率を最大29%向上させました。
同期の差がより明確になります。Pushでは、書き込みが完了した後、ターゲットGPUは他のGPUの完了シグナルを待つ必要があります。Expert Parallelの規模が大きい場合、1つのrankは最大で71個のピアに関与する可能性があります。PullはローカルGPUが自ら読み取りを開始し、データが戻ってきた時点で直接使用できます。
Cursorのマルチノードマイクロベンチマークにおいて、このシグナリング遅延はPushの約103マイクロ秒からPullの18マイクロ秒に低下しました。
MoKはすべての場所でPullを使用しているわけではありません。前方ではPull DispatchとPush Combineを使用し、後方ではPull Reverse-CombineとPush Reverse-Dispatchを使用します。Dispatch段階では、多くのソースからのトークンを専門家入力に再構成する必要があり、Pullの方が調整が省略できます。Combine段階では、各結果がどのトークンに戻るべきかが明確であるため、直接Pushで戻す方が簡単です。
通信方向を変更した後、MoKは通信とエキスパート計算を同じMegakernelに統合しました。
それはGPUのSMを二つの部分に分割します。一方はディスパッチ、コンバイン、ステータス管理を担当し、もう一方は専門的なFFNの実行に特化します。通信側は一連の完全なトークンを取得した後、GPUのローカルカウンターを通じて計算側に通知します。計算が完了すると、計算側が通信側に通知し、結果を返送します。
これにより、通信に使用するSMの数と計算に使用するSMの数を直接決定でき、複数のCUDAストリームが勝手に競合する必要がなくなります。ここで最も重要なパラメータはminibatchであり、一度にエキスパートに渡すトークンの数を意味します。
大きすぎると、最初の計算に長い時間がかかります。小さすぎてもいけません。専門家のGEMMは最終的に多数の計算タスクに分割され、SMに割り当てられます。トークンが少なすぎると、タスク数が不足し、多くのSMが空き状態になります。
カーソルはwaveを使用してこの境界を判断します。1つの完全なwaveは、すべての計算SMにタスクが割り当てられた状態と簡単に理解できます。MoKは、1つのミニバッチで少なくとも2つの完全なwaveが形成され、Tensor Coreが十分なタスクを継続的に実行できるようにしたいと考えています。
実際の結果が明確に示しています。Hidden Sizeが7168、エキスパートの中間次元が2048のKimi 2.5構成では、Cursorはminibatchに少なくとも約2368トークンが必要と推定しています。512トークンではMoKのフォワード処理時間が5.981 msですが、2560トークンに増やすと3.425 msに低下します。さらに増やしても、速度は明確な改善を示さなくなります。
言い換えれば、通信をより細かく分割しても常に速くなるわけではありません。効率的な重複を実現するには、通信を早期にデータを渡す一方で、GEMMをあまりにも小さく分割しないことが必要です。
しかしMoEにはもう一つの問題があります。ルーターが完了する前に、各GPUが最終的にどのくらいのトークンを受け取るかはわかりません。
最悪のケースに備えてバッファを確保すると、多くのVRAMが無駄になります。GPUがトークンを数えてからCPUに空間の割り当てを通知すると、GPUはCPUを待って停止しなければなりません。
MoKは固定サイズのRing Tokenバッファを使用します。一度Dispatchされたトークンが専門家によって処理され、Combineが結果を送信すると、その領域は直ちに次のトークンのバッチに再利用されます。前のマクロバッチのCombine処理は、次のマクロバッチのDispatchと同時に実行できます。
リングバッファはここではバッファ層のように機能します：通信が一時的に速く進むと、データがそこで蓄積され、計算が速く消費されると、次のトークンの到着を待ちます。このプロセス全体はGPU上の状態によって進行し、CPUが毎ラウンドごとに次のステップを決定する必要はありません。
Cursorは、MXFP8の活性化をDispatch、Grouped GEMM、SwiGLUのデータパスに組み込み、独立したquantizeカーネルを削減し、HBMにおける中間結果の往復読み書きを1回減らしました。
Pull、minibatch、SMパーティション、およびRing Bufferを統合することで、MoKはようやく連続したMoEパイプラインとなる。
03
一連の高度に特化された実行方法
Cursorのベンチマークは、スケジューリング、ディスパッチ、エキスパートFFN、結合、そして最終的な重み付き合計を含む完全なMoE層を測定しており、比較対象にはNCCL + PyTorch、DeepEP、TransformerEngine、およびHybridEP + Megatronが含まれます。
GB300 NVL72において、MoKのMXFP8は、各シナリオの最速公開ベースラインと比較して、フォワードで最大2.37倍、バックワードで最大1.78倍の向上を達成した。BF16では、フォワードで最大1.92倍、バックワードで最大1.58倍の向上を達成した。
より重要なのはエンドツーエンドのトレーニングである。Cursorの元の本番環境ではDeepEPが使用されていたが、512枚のGB300 GPUでMoKに変更したところ、1枚のGPUあたりのスループットは秒間760.9トークンから1070.2トークンへと約41%向上した。
この結果も境界を明確に理解する必要があります。Cursorは完全な個別アブレーションを公開していないため、2.37倍のうちどれだけがPull、どれだけがMegakernel、どれだけがRing Bufferによるものかを正確に述べることはできません。
PullによるNVLinkの利用率とシグナリング遅延の改善は個別に確認できますが、その他のメリットは、全体の実行手法の組み合わせによるものです。
MoKはハードウェアへの依存度も高い。BlackwellやNVL72のような高速NVLinkドメインを対象としており、リモート読み取り、通信、計算の細粒度なインタリーブは、GPU間で低遅延で相互のメモリにアクセスできることが前提となっている。モデルのHidden Size、Top-k、エキスパート規模が変更されると、適切なminibatchサイズや通信SMの数もそれに応じて変化する。
これはMoKの最も注目すべき点でもある。過去にはMoEの最適化を議論する際、しばしば2つの数値に注目していた：GEMMのTFLOPSとAll-to-AllのGB/s。しかし、GB300世代では、これらの数値をさらに引き上げるだけでは、すべての性能を説明できなくなっている。
トークンがいつ到着するか、どのように専門家が必要とするレイアウトに並べるか、どれだけ貯めると計算を開始するか、通信でどれだけSMを取得するか、バッファがいつ解放されるかという実行の詳細が、直接トレーニング速度を決定する。
130 TB/sのNVLink帯域幅を備えたラックでも、MoEのためにGPUカーネルを再書き換える必要がある理由はここにあります：リンクはすでに十分に高速であり、次に削減すべきはGPUがデータを待つ時間です。
CursorがGPUカーネルを再書き換える行動は、AI 2.0時代の競争が「フルスタック主権」の新段階に入ったことを示している。
以前、私たちは「専門分野は別々にすべき」と信じ、アプリケーションはアプリケーション（Cursor）を、基盤は基盤（NVIDIA）を手がけるべきだと考えていた。しかし、現在のAI競争は「仲介者を排除する」新たな段階に達しており、Cursorは「やりたいから」ではなく、「やらざるを得ないから」コアを開発している。
DeepSeekはエンジニアリングの搾取の新時代を開いた一方で、Cursorはこの火をアプリケーション層まで広げた。この「仲介者排除」の傾向は、AIの価格決定権を再構築している。今後、AI企業の評価を決めるのは、どれだけのトークンを保有しているかではなく、そのコードがVRAMやレジスタにどれだけ近いかになる。
底层のブラックボックスを突破できないAI企業は、結局「凡庸税」の泥沼に残ることになる。