メモリとモデル

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

モデル名の数字が大きくなると遅くなるように思えますが、35Bモデルが27Bモデルよりも速く回答するケースもあります。大きな数字を誤解した可能性はありますか？実際には、この2つの数字は保存されるモデルのサイズを指すもので、1トークンを作成する際にすべて同じ量を計算しているとは限りません。

まず、二つのモデルに同じ仕事をさせる

速度だけを35Bと27Bで比較する前に、質問と回答の長さ、量子化および実行プログラムを一致させる必要があります。異なるタスクから得られた数字であれば、構造的な差異を確認するのは難しいです。ここでは、同じデバイス上で同じ種類のリクエストを送った状況を想定します。

密集型のDenseモデルは、新しいトークンを生成する際にほとんどの重みを使用します。モデルが大きくなるにつれて、読み込む必要のある重みの数も増加する傾向があります。そのため、より大きなDenseモデルが遅いと予想することは、自然な出発点と理解できます。

複数の専門家が重みの収納箱の一部だけを開けてトークンを処理するMoEモデルのワークスペース図 — MoEは全専門家をメモリに保持しますが、トークン1つを計算する際には選ばれた一部の専門家のみを使用します。

MoEは全体を保持しながら一部を選択します

MoEには複数の専門家ブロックがあります。各トークンでルーターが一部を選び計算します。すべての専門家が毎回一緒に働く構造ではありませんので、全体のパラメータが大きても、1トークンで使用される部分は小さく抑えられます。

たとえば、全体35Bのモデルで活性化されるのは約3Bと表示されているモデルについては、保存されるスケールとトークンあたりの計算スケールを別々に読み取る必要があります。この数字は、構造的な例として3Bの密集モデルと同等の速度や品質を約束するものではありません。共有層およびルーティングコストも残っています。

密集モデルと、専門家パスのみを通過するMoEモデルを比較した図 — パラメータ数が大きいMoEでも活性計算量が小さい場合、デコード速度においては小さな密集モデルよりも優れた組み合わせが生まれる可能性があります。

計算が減るとなぜ回答が速くなるのでしょうか？

ある人が回答を受け取る際には、GPUの計算能力に応じてメモリから重みを取得する速度が重要になる可能性があります。選択された重みだけを読み込み、計算を行う経路が効率的であれば、より小さなDenseモデルよりも少ない処理で次のトークンを生成できます。

しかし、実行プログラムのMoE処理が非効率的であれば、その利点を十分に得ることはできません。専門家を選択し、分散されたメモリにアクセスするコストもあります。モデル構造を知れば速さの可能性は説明できますが、実際のtok/sまで構造だけでは確定することはできません。

大きなメモリ収納構造内で、少数の活性専門家経路のみが高速に繋がる構造図 — MoEデバイス選定では、全重みが収まるメモリと実際に活性化されるパスの生成速度を別々に確認すべきです。

速いモデルは小さいメモリに収まるものではありません

ここでは最も不適切な誤解が生じます。活性化部分だけを見て、小さなGPUを購入したものの、モデルファイルが読み込まれない場合があります。次のトークンがどの専門家を選択するかは不明であるため、全重みはアクセス可能なメモリまたはストレージデバイス上に存在しなければなりません。

一部をRAMまたはSSDに保持する方法があるものの、必要な部分を取得するまでの遅延が生じます。計算量を減らしたことで得られるメリットよりも送信時間の方が大きくなる可能性もあります。モデルがアップロードできるかどうかをまず確認した上で、その中で速度を比較する必要があります。

より大きなモデルを使う理由も、作業から見つけることができます

MoEが速いからといって、回答の正確性まで自動的に優れているとは限りません。私が指示したコードの修正やドキュメントの要約において、どのモデルの結果がより有用かを確認しなければなりません。誤った答えを速く受け取ってしまうと、検証時間はむしろ増える可能性があります。

35Bという数字に負担を感じたなら、実際のファイルサイズと活性規模を割り算してみてください。逆に活性3Bだけを見て軽いと感じたなら、全体のロード量を再確認してください。名前が与える印象よりも、メモリ・速度・作業結果の3つの観点で正しいモデルを残すことが目的です。