TEMPO、実測実行時間に基づきMoEエキスパートを割り当て、Qwen3‑235Bのp99トークンレイテンシを約15.6%削減

エキスパート並列MoE推論では各層が最も遅いGPUを待つため、一般的なディスパッチャーはトークン数、またはGPUごとにアクティブ化されるエキスパート数を均等化する。TEMPOの測定によると、どちらの代理指標もgrouped GEMMの区分的なコストを見落としている。各エキスパートのトークン数が約156～168未満の場合、時間の大半はHBMからの重みロードに費やされる。しきい値を超えると、今度は計算量が128トークン単位のM-tileへ切り上げられる。同じエキスパートをより多くのレプリカに分割すると、重みの転送を重複させると同時に、パディングによる余分な計算を生む可能性がある。

チームはこれを`t=max(a+bG, c+βN)`としてモデル化した。ここでGはGPU上でアクティブ化されたエキスパートレプリカ数、Nはトークン数であり、さらに大規模なprefillを処理するためのtile項を加えた。実際のdecodeバッチには通常、少数の人気エキスパートと多数のコールドエキスパートが同時に含まれる。4種類のトレースでは、バッチの92～100%がメモリ律速領域と計算律速領域の両方にまたがっており、単一のバランス指標には必ず機能しない範囲が生じる。

TEMPOはバッチごとの割り当てを固定費用付きmakespan問題として定式化し、ミリ秒単位で動作するヒューリスティックソルバーを使用する。求解処理は独立したプロセスへ移し、割り当てとカウントはCUDA graph内のkernelへ統合したうえで、SGLangに組み込んだ。Qwen3‑235B-FP8が予測上の有効領域にある場合、エンドツーエンドのスループットは約4～6%向上し、中程度のPoisson負荷ではp99のトークン当たりレイテンシが226ミリ秒から191ミリ秒へ低下した。DeepSeek‑V3ではGPU当たりのエキスパート数が多く、通信の比率も高いため、すべての適応型戦略が静的割り当てを約2～3%下回った。これは、TEMPOが汎用アクセラレーターではないことを示している。

エンジニアリング上、最も採用価値があるのは固定戦略ではない。まずkernel、モデル形状、バッチ、ネットワークトポロジーを測定し、回収可能な不均衡が存在するかどうかを判断することだ。論文ではGPUモデルが匿名化されており、EP32以上の結果の一部は依然としてキャリブレーション済みシミュレーションに基づく。ドライバーやkernelを更新した場合も再キャリブレーションが必要で、現時点ではエキスパート配置とバッチ単位の割り当てを共同最適化していない。