ニュース

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

新しい知恵のレポート

編集者：喬楊

【新しい知恵の紹介】スケーリングの法則はまだ終わっておらず、「小型モデル」は徐々にトレンドとなり、テクノロジー大手が追いつきつつあります。 Meta が最近リリースした MobileLLM シリーズは、規模が 1B 未満にまで縮小されており、2 つのバージョンのパラメータはそれぞれ 125M と 350M のみですが、より大規模なモデルよりも優れたパフォーマンスを実現しています。

5月と6月に行われたいくつかのテクノロジー大手の記者会見から、クラウドデータセンターから個人ユーザーへ、大規模サーバーからノートブックやモバイルデバイスへというAIの重要な発展傾向をすでに漠然と感じることができます。

スケーリングの法則に従うことはもはや唯一の方法ではなく、「小さくして大きく勝つ」モデルの物語は展開し続けています。

最初に Microsoft がそれを更新し、次に Google がそれを使用しました。

ハードウェアの面では、AI 機能が徐々に電子製品に深く統合されていくのが見られます。

たとえば、Microsoft の悪名高い Recall 機能はその重要な部分を占めており、Apple も Apple Intelligence 傘下でアプリをリリースし、iOS とのシームレスな統合に努めています。

現在、LLM のパラメータは数百億に達することが多く、Apple 3B のパラメータはすでに非常に小さいですが、携帯電話などのモバイル デバイスには依然として高いしきい値があります。

2 ビットと 4 ビットの混合精度圧縮モデル (重みあたり平均 3.5 ビット) を使用するだけでなく、実行するには少なくとも 8G のメモリと M1 チップも必要です。

Meta が最近発表した論文では、新しく提案された MobileLLM モデルのパラメータ数はさらに削減できることが示されていますが、それでもパフォーマンスは優れています。

論文アドレス: https://arxiv.org/abs/2402.14905

ルカン氏はまた、個人的にこの研究を支持するツイートをし、パラメータの数を合理化した一連の操作を賞賛した。

この論文は ICML 2024 に受理されており、モデル トレーニング コードは GitHub でオープンソース化されています。

GitHub アドレス: https://github.com/facebookresearch/MobileLLM

導入

まず仮定を立ててみましょう。GPT-4 (約 1 兆のパラメータを持つ) が 50 トークン/秒の推論速度で導入される場合、どのようなハードウェアが必要になるでしょうか。

答えは 1 億個の H100 GPU です。モバイルデバイスはもちろん、家に置くこともできません。

では、標準を下げて、LLaMA-v2 7B のようなモデルを 8 ビット量子化と組み合わせて使用​​したらどうなるでしょうか?

単純な計算では、モデル パラメーターを保存するだけで約 7GB が必要であることがわかりますが、これはストレージ領域ではなく、貴重な動作メモリ領域 (DRAM) です。

さらに、オペレーティング システムやその他のアプリケーションの動作を考慮すると、DRAM を AI モデルで完全に占有することはできません。LLM メモリ比率は 10% を超えることはできません。

図 2 の統計によると、さまざまなブランドから最近発売されたモバイル デバイスには、一般に 6 ～ 12 GB の DRAM が搭載されています。これは、携帯電話に正常に展開したい場合は、モデルのパラメータの数を 1B 未満に減らす必要があることを意味します。

ストレージだけでなく、消費電力も大きな問題です。 7B モデルのエネルギー消費量は約 0.7J/トークンで、完全に充電された iPhone では約 50kJ が無駄になります。計算上、生成速度が 10 トークン/秒の場合、携帯電話をフル充電してもモデルと通話できるのは 2 時間だけです。

上記の考慮事項に基づいて、モバイル端末に 1B 未満のモデルを展開することがより理想的な選択となるため、MobileLLM のパラメータ サイズは、Apple の 3B モデルよりも 1 桁小さい 125M/350M に設定されます。 「ミニの中のミニ」と言えるでしょう。

ただし、スケーリングの法則に制限されないでください。パラメーターが小さいからといって、機能が弱いわけではありません。モデル アーキテクチャの重要性が改めて認識されるはずです。

MobileLLM は、同じサイズのモデルで SOTA パフォーマンスを達成するだけでなく、アーキテクチャの深さが幅よりも重要であることも提案しています。 「深くて狭い」「細い」小型モデルで抽象的な概念も学習できます。

アーキテクチャとメソッド

パラメータが 125M/350M しかないため、限られた範囲内でアーキテクチャ設計をいかに最適化するかが重要な課題となっています。

LLM <1B の場合、著者は 4 つの効果的なアーキテクチャ設計手法を検討しました。

1) SwiGLU フィードフォワード ネットワークを使用する

2) ネットワーク全体の形状を「細長く」、つまり深く狭いものにする

3) 埋め込み共有メソッドを再利用する

4) グループ化されたクエリ アテンション メカニズムを使用する (グループ化されたクエリ アテンション)

これに基づいて、著者は、追加のメモリ オーバーヘッドを導入せずにモデルの精度をさらに向上できるブロック単位のレイヤー共有方法も提案しました。ただし、デコード プロセスの推論遅延は増加します。

レイヤ共有メカニズムが追加されたこのモデルには、MobileLLM-LS というラベルが付けられます。

スケーリングの法則に反論する: 小さなモデルのアーキテクチャ設計は非常に重要です

2020年にスケーリング則を提案した論文では、トレーニングデータの量、パラメータの量、トレーニングの反復回数がパフォーマンスを決定する重要な要素であり、モデルアーキテクチャの影響はほぼ無視できると考えられています。

しかし、本稿の著者は比較実験を通じて、この法則は小型モデルには当てはまらないことを提案した。

モデル パラメーターが 125M または 350M に固定されている場合、30 ～ 42 層の「狭い」モデルは、約 12 層の「短くて太い」モデルよりもパフォーマンスが大幅に優れています (図 4)。常識的な推論、質疑応答、読解力など。8 すべてのベンチマークにわたって同様の傾向が見られます。

これは実際、非常に興味深い発見です。なぜなら、これまで、125M 程度の小規模モデルのアーキテクチャを設計する場合、通常、12 層を超える層を積み重ねることはなかったからです。

なぜ「コード共有」に戻るのか

「埋め込み共有」手法は、OPTなどの小規模モデルで最初に提案されましたが、これは小規模モデルでは符号化層のパラメータがかなりの割合を占めるためです。

たとえば、125M モデルは、コンテキスト長 32k、次元 512 のエンコーディングを使用します。入力および出力エンコーディング層には、20% を占める 16M のパラメーターが含まれています。

比較すると、大規模モデルのコーディング層パラメータの数は無視できるほどです。たとえば、LLaMA-7B ではこの割合は 3.7% に低下し、LLaMA-70B ではさらに 0.7% にすぎませんでした。したがって、LLM には共有コーディングは必要ありません。

大規模モデルの時代におけるコード共有の廃止は、このテクノロジーがモデル アーキテクチャをよりコンパクトで効率的にできることを意味しません。

表 1 に示すように、コード共有後、モデルは全体として元のパフォーマンスを維持しながら、パラメーターの合計数が 16M 減少し、一部のベンチマークも改善しています。

レイヤー共有メカニズム

前述したように、論文の実験結果では、小型モデルを「細く」することが性能向上に有利であることがわかりました。そこで著者は次のように考えました。レイヤー共有メカニズムを導入すると、パラメータの総数は変えずにモデルの深さを増やすのと同じではないでしょうか。

実験では、この方法が実際にパフォーマンスを向上させることが証明されており、この論文では、さまざまなレイヤー共有方法も比較しました (図 6)。最終的には、デバイスのメモリ、パフォーマンス、推論レイテンシーを比較検討した後、即時ブロック単位の共有 (即時ブロック単位の共有) を採用しました。 、図6b）。

評価実験

著者は、125M および 350M パラメータを使用して MobileLLM/MobileLLM-LS モデルを構築し、1T データセットでトレーニングしました。

事前トレーニングされたモデルは、ARC-easy、ARCchallenge、HellaSwag、WinoGrande、TQA、RACE などの一般的に使用されるベンチマークを含む、ゼロ サンプルの複数のデータ セットでテストされます。

表 3 は、MobileLLM シリーズは基本的に包括的な SOTA を達成しており、以前にリリースされた OPT や BLOOM などのクラシック モデルを上回るだけでなく、最近リリースされた GPT-neo、Gaoptica、 RWKV およびその他のパラメータ。

質問応答と読解力の点では、MobileLLM は依然として優れたパフォーマンスを示しています (表 4)。他のモデルと比較して、125M および 325M MobileLLM は TQA でそれぞれ >6.4 ポイントおよび約 10 ポイント向上しています。

下流タスク

このペーパーでは、ベンチマーク テストのスコアの実行に加えて、アプリケーション シナリオを展開する際のモデルのさまざまな要件も考慮に入れ、対応する評価を実施します。

AlpacaEval と MT-Bench は、それぞれシングルラウンドとマルチラウンドのチャット タスクでモデルのパフォーマンスをテストします。他の 3 つのベースライン モデルと比較すると、MobileLLM は依然として最高のパフォーマンスを示しており、3 億 5,000 万のパラメーターを使用して他のモデルのパフォーマンスを上回ることもできます。パラメータ >1B モデル。

ダイアログを除いて、API 呼び出しシナリオでは、MobileLLM の EM スコアは 7B パラメータの LLaMA-v2 の EM スコアと一致します。

さらに、MobileLLM は量子化 (PTQ) との互換性も優れています。 W8A8 の定量化後、モデルのパフォーマンスは 0.5 ポイント未満低下しましたが、レイヤー共有メカニズムとの互換性が維持されているため、より厳しいハードウェア条件下での展開に適応できます。

著者について

この記事の責任著者である Zechun Liu は、Meta Reality Labs の研究員です。彼女は復旦大学で学士号を取得し、香港科技大学で博士号を取得し、メタに入社する前は CMU で客員研究員を 2 年以上務めていました。

Zechun 氏の研究対象は、ネットワークの 2 値化と量子化、ネットワーク チャネルのプルーニング、アーキテクチャに焦点を当てた、不十分なリソースの制限、コンピューティング リソースと精度の間のトレードオフなど、現実のシナリオでのディープ ラーニングの応用です。デザイン、知識の蒸留など。

参考文献:

https://x.com/ylecun/status/1810035281472491665

https://arxiv.org/abs/2402.14905