35BのMoEが、小さな密モデルより速いことがある理由

Denseは新しいトークンを作る際、各層の重みの大部分を使います。MoEはルーターがトークンに合うエキスパートを選び、共有部分と一緒に計算します。全体35Bでもアクティブ約3Bなら、そのトークンには全体の一部が参加します。その結果、大きなモデルの方がトークンごとの計算量が少なくなる場合があります。

実行プログラムが選ばれた重みを素早く供給し、エキスパートの演算を効率よく処理できると、少ない計算量がデコード³速度につながります。ルーティングと不規則なデータアクセスにも時間がかかるため、同じ機器の実行結果を合わせて確認することが重要です。

次のトークンでは別のエキスパートが選ばれる場合があります。実行中は全体の重みにアクセスする必要があるため、実際の配布容量と量子化⁴を確認します。KVキャッシュ⁵、実行プログラム、エディター、ブラウザーの空間も残し、普段の条件で比較します。

すべてがVRAM⁶にあるモデルと一部をRAM⁷にオフロード⁸するモデルでは、データ取得の経路が異なります。オフロードは実行できる規模を広げますが転送時間が加わります。ファイル名と配置を記録すると、計算削減とデータ移動の影響を合わせて理解できます。

問題の関数、関連する呼び出し元、エラーログを同じように送ります。「戻り値の形式を維持し、空の入力を安全に扱う」と範囲を決めると結果を比べやすくなります。最初のモデルが変更したファイルではなく、同じ基準コミットやコピーから別々に開始し、ログとdiffを分けて保管してください。

モデルファイル、量子化、実行プログラム、思考モード、入力、出力上限、同時リクエスト数を記録します。プリフィル⁹とデコードを分け、最初のトークン時間と全体の完了時間を記録してください。モデルでトークン分割が異なるため、tok/sと作業完了時間を合わせて比べると役立ちます。

個人のコーディング支援では、まず1件のリクエストで比較します。共同サーバーでは、別途同時リクエストを試します。入力によって別のエキスパートが選ばれ、メモリアクセスとスケジューリングも変わります。全体処理量に加えて各利用者の遅延も記録してください。

空入力と通常入力、既存の呼び出し元をテストします。戻り値の形式が維持され、エラーが解決したか確認してください。失敗したら同じモデルにログを送り、修正したdiffを確認して再テストします。その時間まで含めると、実際に作業が速くなったか判断できます。

サイトの比較画面では、機器と入力長を保ちながら35B MoEと27B Denseを切り替えられます。モデルごとに推奨形式と高速化が異なるため、実際に使う構成を検討するために利用します。キャッシュの余裕を残して収まり、自分のコードで必要な修正ができる候補から選びましょう。