MoEとDenseの違い：活性パラメータが小さくてもメモリが必要な理由

MoEのエキスパートは、モデル内の計算ブロックです。学習したルーターが入力に応じてブロックを選び、その結果で計算を続けます。人が「韓国語担当」「コーディング担当」と決めた小さなモデルの集合ではなく、トークンごとに計算経路を選ぶ構造として理解すると分かりやすくなります。

Denseでは各層の重みの大部分が計算に参加します。MoEでは共有部分と選ばれたエキスパートが参加し、次のトークンでは別のエキスパートが選ばれることがあります。そのため、あるトークンで使わなかった重みも、後の計算で実行プログラムが参照できる必要があります。

Bは10億個のパラメーターを意味します。全体35Bは共有部分とエキスパートの重みを合わせた規模で、アクティブ3Bは1トークンの計算経路に参加する規模です。ダウンロードとメモリでは全体の数を、トークンごとの計算ではアクティブ数を先に見る理由です。

すべてを4ビットで保存する単純な例を計算すると、350億×4ビット÷8は175億バイト、十進単位で17.5GBです。アクティブ3Bだけなら1.5GBですが、全体のモデルには残りのエキスパートも必要です。実際のQ4ファイルには量子化³の補助値、メタデータ、別の精度で残す部分が加わるため、配布ファイルの実際の容量を確認します。

全体規模が近いDenseよりMoEのアクティブ規模が小さいと、各トークンの計算量を減らせます。選ばれた重みを実行プログラムが効率よく取得して計算できれば、デコード⁴に利点が生まれます。全体のB数だけで速度を順位付けしにくい理由です。

実際には、ルーティング、不規則なメモリアクセス、エキスパートの負荷、実行カーネルにも時間がかかります。一部の重みをシステムRAM⁵に置くオフロード⁶では、転送時間も加わります。アクティブ規模の小ささを生かすには、現在の機器でのメモリ配置とモデルの対応経路を確認します。

たとえば、空文字列でエラーになる関数を修正してみます。2つのモデルに同じコードとエラー説明を送り、「戻り値の形式を維持して空の入力に対応して」と依頼します。通常入力、空入力、既存の呼び出し元のテストを実行すれば、求めた動作が保たれたか確認できます。

最初の返答までの時間、コードの生成速度、テストを通すまでの追加修正回数を分けて記録します。返答が速くても何度も修正が必要なら、作業全体は長くなることがあります。自分のコードで必要な結果が得られるかと待ち時間を合わせて比べると、使うモデルを選びやすくなります。

配布ページで使いたいQ4ファイルを確認し、実行プログラム、他のアプリ、KVキャッシュ⁷のメモリも残します。短い質問で読み込みを確かめてから、普段のプロジェクトの入力長で試すと、実際の作業でメモリに余裕があるか分かります。

その条件でコードの結果とプリフィル⁸・デコードを比較します。全体のファイルが安定して収まり、必要な修正ができるMoEなら、今の機器でも候補になります。読み込めるのに待ち時間が長ければ帯域幅と実行オプションを、読み込みから失敗するなら容量とオフロード対応を次に調べましょう。