SemiAnalysis、MoE 推論の内部を解説。4段階で最適解が変わる

SemiAnalysis が、MoE（Mixture of Experts）モデルを推論ハードウェアに載せる際の構造とデータの流れを整理した解説を公開した。主張の起点は、MoE がフロンティアモデルで広く使われるようになったことで、サービングの構造と「役に立つ推論」の経済性の両方が変わった、という点にある。トークンごとにどのテンソルが有効になるか、何を互いに近くへ置かねばならないか、どの転送に強いローカル帯域が必要でどれなら弱いネットワークリンクで許容できるかが変わったとする。

推論は、NVIDIA Dynamo や Mooncake、あるいは独自スケジューラといったオーケストレーション層が調整するクラスタの中で動き、これらは vLLM などの推論サーバと密に連携する。ユーザーが投げたリクエストと応答の組が「ターン」で、応答の一部はクライアントアプリが横取りし、コードの編集や社内規程の検索として実行する。その結果がまた新しいリクエストとして戻るため、長時間タスクにエージェントを走らせれば1時間に数千ターンに達することもある。会話は数時間から数日中断して再開することもあり、サーバはこの蓄積を KV キャッシュとして保持する。

記事が要と置くのは4つの動作領域の区別である。新しいトークンのブロックをまとめて処理する Prefill、既存のキャッシュ済みコンテキストに継続リクエストを継ぎ足す Midfill、コンテキストから新しいトークンの素を作る Decode attention、そして大きな専門家集合から選ばれた一部が各トークンを仕上げる Decode expert だ。Prefill は演算強度（計算量とデータ移動量の比）が高く、コンテキストを探して読む待ち時間もない。Midfill は新規トークンが少なく既存データの移動が多い分、演算強度は中程度になる。decode 側の2つは、先行コンテキストや expert の重みに比べて新規トークンが少ないため演算強度が低い。一方で attention と expert のテンソルはトークンの値によらず同じなので、1回の読み出しをできるだけ多くのトークンで共有する価値がある。同時に走っている無関係な他ユーザー由来のトークンであっても、ネットワーク的に十分近ければ相乗りさせた方が得になる。

この整理が効いてくるのは、段階を別々のマシンに分ける（disaggregated）か、1台のサーバが段階ごとに構成を組み替える（aggregated）かという設計判断である。Transformer の各層で起きる手順は事前に分かっていて延々と繰り返されるから、同じハードウェア資源を時点ごとに別の工程へ割り当てられる。逆に言えば、4つの領域を一括りの「推論」として扱った瞬間に、この割り当ての自由度は消える。