※本稿は、Xiaozhe Yao,Ana KlimovicによるDeltaZipについてのプレゼンテーションの内容を要約したものです。
1. はじめに
1.1 言語モデルの進化と応用
過去1年間で、言語モデルは驚異的な進化を遂げました。これらのモデルは、単純な次の単語の予測から、ユーザーのプロンプトや文脈を理解し、適切な応答を生成する能力を持つようになりました。この進化により、チャットボット、コードアシスタント、コード理解、翻訳、カスタマーサポートなど、多様なアプリケーションの可能性が開かれました。
これらの言語モデルは、in-context learner（文脈内学習者）として非常に強力です。開発者は、機械学習パイプラインを構築したりトレーニングしたりする必要なく、ユーザーの要求を処理できます。単にプロンプトをモデルに入力するだけで、適切な応答を得ることができます。
1.2 言語モデルサービングの課題
しかし、この能力の向上には大きなコストがかかります。これらのモデルは、トレーニングが高価であるだけでなく、サービングも非常にコストがかかります。例えば、ChatGPTのようなカスタマイズされたバージョンを使用する場合、ユーザーの実際のプロンプトよりもはるかに長い入力が必要になります。この長い入力は、モデルの振る舞いを調整したり、外部の事実知識を組み込んだりするために使用されます。
クラウドプロバイダーは、この入力トークンに対して高額な料金を請求します。ユーザーベースが拡大するにつれ、このコストは累積的に増加します。そのため、これらの興味深いアプリケーションを開発することは容易ですが、プロダクション環境に展開すると非常にコストがかかるのが現状です。
1.3 ファインチューニングモデルの重要性
この状況を改善するために、ファインチューニングされたモデルが重要になってきています。多くの下流タスクにおいて、専門化された小さなモデルが、大規模なモデルと同等かそれ以上のパフォーマンスを発揮することがあります。例えば、ChatGPTはGPT-3からファインチューニングされており、GitHub CopilotもGPTモデルからファインチューニングされています。
ファインチューニングされたモデルは、長い文脈を必要とせず、少数の短い例で効果的に動作します。これにより、プロダクション環境でのコスト削減が可能になります。
1.4 マルチテナント言語モデルサービングの課題
しかし、現在のクラウドプロバイダーでは、これらのファインチューニングされたモデルを効率的に運用することが困難です。プロバイダーは、リクエストに応じてこれらのモデルをGPUにスワップインアウトするか、すべてのモデルをサーブするのに十分なリソースを過剰に確保する必要があります。
一部のモデルはあまり頻繁に呼び出されない可能性があるため、これらの運用コストを補うために、クラウドプロバイダーは通常、ファインチューニングされたモデルのサービングに対してより高い料金を請求します。例えば、OpenAIは、GPTのカスタマイズされたバージョンに対して2倍の料金を請求しています。
この状況から、多くの開発者やリサーチャーが、最小限のコールドスタート遅延で、トークンベースの支払いが可能な、ファインチューニングされたオープンモデルの効率的なサービングソリューションを求めています。しかし、現在のところそのようなソリューションは存在していません。
1.5 研究の目的
このような背景から、私たちは最も挑戦的な問題に取り組むことにしました。「複数の完全パラメータファインチューニングモデルを、効率的に、同時に、そしてシームレスにサービングする方法は何か？」この問いに答えるために、私たちはDeltaZipを開発しました。DeltaZipは、デルタ圧縮を用いたマルチテナント言語モデルサービングの新しいアプローチです。次のセクションでは、この技術の詳細と、それがどのようにマルチテナント言語モデルサービングの課題を解決するかについて説明します。
2. 言語モデルの現状と課題
2.1 言語モデルの能力と応用
言語モデルは、過去1年で驚異的な進化を遂げました。これらのモデルは、単純な次の単語の予測から、ユーザーのプロンプトや文脈を理解し、適切な応答を生成する能力を持つまでに成長しました。この進化により、多様なアプリケーションの可能性が開かれました。
具体的には、チャットボット、コパイロット（コードアシスタント）、コード理解、翻訳、カスタマーサポートなどの分野で、言語モデルの応用が進んでいます。これらのモデルは、in-context learner（文脈内学習者）として非常に強力です。開発者は、複雑な機械学習パイプラインを構築したりトレーニングしたりする必要なく、ユーザーの要求を処理できるようになりました。単にプロンプトをモデルに入力するだけで、適切な応答を得ることができます。
2.2 サービング時のコスト問題
言語モデルの能力向上には、大きなコストがかかります。これらのモデルは、トレーニングが高価であるだけでなく、サービングも非常にコストがかかります。例えば、ChatGPTのようなカスタマイズされたバージョンを使用する場合、ユーザーの実際のプロンプトよりもはるかに長い入力が必要になります。
私がChatGPTに「データベースのインデックスの仕組みを説明してください」と質問したところ、明確な回答が得られました。しかし、モデルとユーザー間で実際に行われた対話全体を見ると、ユーザーの実際のプロンプトよりもはるかに長い入力が使用されていることがわかりました。この追加の文脈は、モデルの振る舞いを調整したり、外部の事実知識を組み込んだりするために使用されています。
クラウドプロバイダーは、この入力トークンに対して高額な料金を請求します。ユーザーベースが拡大するにつれ、このコストは累積的に増加します。そのため、これらの興味深いアプリケーションを開発することは容易ですが、プロダクション環境に展開すると非常にコストがかかるのが現状です。
2.3 ファインチューニングモデルの重要性
この状況を改善するために、ファインチューニングされたモデルが重要になってきています。ファインチューニングは、特定のダウンストリームタスクに対してモデルの振る舞いを調整するプロセスです。多くの下流タスクにおいて、専門化された小さなモデルが、大規模なモデルと同等かそれ以上のパフォーマンスを発揮することがあります。
例えば、ChatGPTはGPT-3からファインチューニングされており、GitHub CopilotもGPTモデルからファインチューニングされています。これらのファインチューニングされたモデルは、長い文脈を必要とせず、少数の短い例で効果的に動作します。
ファインチューニングされたモデルの利点は以下の通りです：
- 小さなサイズ：元のモデルよりも小さくなる可能性があります。
- 特化した性能：特定のタスクに対して最適化されています。
- 低いコンテキスト要求：長い文脈を必要とせず、少数の短い例で効果的に動作します。
- コスト効率：プロダクション環境でのコスト削減が可能になります。
しかし、現在のクラウドプロバイダーでは、これらのファインチューニングされたモデルを効率的に運用することが困難です。プロバイダーは、リクエストに応じてこれらのモデルをGPUにスワップインアウトするか、すべてのモデルをサーブするのに十分なリソースを過剰に確保する必要があります。
一部のモデルはあまり頻繁に呼び出されない可能性があるため、これらの運用コストを補うために、クラウドプロバイダーは通常、ファインチューニングされたモデルのサービングに対してより高い料金を請求します。例えば、OpenAIは、GPTのカスタマイズされたバージョンに対して2倍の料金を請求しています。
この状況から、多くの開発者やリサーチャーが、最小限のコールドスタート遅延で、トークンベースの支払いが可能な、ファインチューニングされたオープンモデルの効率的なサービングソリューションを求めています。しかし、私たちの知る限り、現在のところそのようなソリューションは存在していません。
ファインチューニングされたモデルをサービングする際の主なボトルネックは、ロードコストです。例えば、100GBのモデルをメモリからGPUにロードすることは、レイテンシに敏感なアプリケーションにとっては致命的です。多くの研究論文では、すべてのモデルがGPU上に配置されていることを前提としており、このロードコストを無視しています。
圧縮は、このロードコストを削減するための有望なアプローチですが、現在の技術では4ビット未満に圧縮すると、モデルの品質が大幅に低下してしまいます。また、Low-Rank Adaptation（LoRA）などの新しい学習パラダイムも提案されていますが、これらは完全に新しい学習方法を必要とし、場合によっては完全なパラメータファインチューニングの性能に匹敵しないこともあります。
このような背景から、私たちは最も挑戦的な問題に取り組むことにしました。「複数の完全パラメータファインチューニングモデルを、効率的に、同時に、そしてシームレスにサービングする方法は何か？」この問いに答えるために、私たちはDeltaZipを開発しました。次のセクションでは、DeltaZipの概要と、それがどのようにマルチテナント言語モデルサービングの課題を解決するかについて説明します。
3. DeltaZipの概要
3.1 主要なアイデアと洞察
DeltaZipの開発にあたり、我々は重要な洞察を得ました。多くのファインチューニングされたモデルは、同じベースモデルから派生しているという事実です。私は個人的に、最終的には世界中の人々が、非常に優れた事前学習済みのベースモデルに収束していくのではないかと考えています。
過去には、多くの人々がLLaMAからファインチューニングを行っていましたが、現在ではMistralのようなモデルが使用されています。将来的には、オープンソースで非常に優れたベースモデルが登場すれば、ほとんどの人々がそのモデルをベースにファインチューニングを行うようになるでしょう。
この傾向は、ファインチューニングが事前学習に比べてはるかに少ないデータ、時間、リソースで行えることに起因しています。事前学習には数百万ドルの費用がかかる可能性がありますが、ファインチューニングは個人のノートパソコンでも実行できるほど軽量です。
ファインチューニングにこれほど少ないリソースしか必要としないという事実から、直感的に、このプロセスで導入される新しい情報量はそれほど多くないはずだと考えられます。言い換えれば、ベースモデルとファインチューニングされたモデルの間の「デルタ」（差分）は、現在考えられているよりもはるかに小さいはずです。
現在、ベースモデルとファインチューニングされたモデルの差分を取ると、同じ数のパラメータ、つまり同じサイズになります。しかし、私はこれが正しくないと考えています。デルタは実際にはもっと小さくなるはずです。
この直感を確認するために、我々はベースモデルとファインチューニングされたモデルの重み分布をより深く分析しました。左側の図は、ベースモデルとファインチューニングされたモデルの重み分布を示しています。ここで注目すべき点は、分布が大きく変動しているように見えますが、外れ値はほぼ同じインデックスで発生しているということです。
右側の図では、同じスケールでデルタの分布をプロットしています。ここでは分布がはるかに滑らかで、ゼロを中心に集中していることが分かります。これは非常に高い疎性を示唆しています。
我々は、モデル内のすべての線形モジュールでこの同じパターンを観察しました。この例はLLaMA 7Bとそのファインチューニングされたバリアントから抽出したものですが、我々が実験したほぼすべてのファインチューニングされたモデルで同様のパターンが観察されました。
左側のベースモデルとファインチューニングされたモデル自体は圧縮が難しい可能性がありますが、右側のデルタはより滑らかな分布を持っているため、はるかに圧縮しやすいはずです。
量子化の観点から見ると、この圧縮のしやすさがより明確になります。量子化は本質的に、16ビットの範囲を2ビットで表現するようなものです。外れ値が存在すると、量子化のグリッドが引き伸ばされ、16ビットの範囲を表現するためにより多くのビットが必要になります。しかし、デルタの分布が滑らかで外れ値が少ない場合、量子化グリッドをより密にすることができ、元の16ビットの重みと量子化された重みの差が小さくなります。つまり、エラーが小さくなるのです。
3.2 システムアーキテクチャ
これらの洞察に基づいて、我々は圧縮されたモデルデルタをサービングする最初のプロトタイプシステムを構築しました。このシステムは、以下の主要なコンポーネントとプロセスから構成されています：
- 学習後圧縮： 与えられたファインチューニングされたモデルと対応するベースモデルから、我々はデルタを圧縮します。この圧縮は2段階で行われます： a) 量子化と疎性を用いた損失のある圧縮 b) 損失のある圧縮で潜在的に高い疎性を活用するための損失のない圧縮
- 永続ストレージ： 圧縮されたデルタは、NFSやハードドライブなどの永続ストレージに保存されます。
- サービングステージ： 我々は、低帯域幅の相互接続でストレージに接続されたアクセラレータ（例：GPU）を想定しています。ここでロードコストが発生します。
- アクセラレータの分割： アクセラレータを2つの部分に分割します： a) ベースモデル用 b) デルタ用
- ベースモデルの固定： ベースモデルは、サービング段階全体を通じてアクセラレータに固定されます。
- リクエスト処理： リクエストが来ると、以下の手順が実行されます： a) 小さな圧縮されたデルタをストレージからロード b) アクセラレータ内で解凍を実行 c) 低速な相互接続を介してロードされるデータ量を大幅に削減
- 推論の実行： 解凍後、実際の推論が行われます。これは基本的に2つの部分の推論を実行し、結果を集約することで行われます。
このアーキテクチャの主な利点は、観察結果を活用して、低速な相互接続を介してロードされるデータ量を大幅に削減できることです。また、ベースモデルを固定することで、複数のファインチューニングされたモデルを効率的にサービングすることができます。
この方法により、我々はデルタを大幅に圧縮し、効率的にサービングすることができます。次のセクションでは、デルタ圧縮の技術的詳細について深く掘り下げ、どのようにしてこの高い圧縮率と効率的なサービングを実現しているかを説明します。
4. デルタ圧縮の技術詳細
4.1 重み分布の分析
デルタ圧縮の技術的詳細を理解するために、まず重み分布の分析から始めましょう。私たちは、ベースモデルとファインチューニングされたモデルの重み分布を詳細に調査しました。
左側の図は、ベースモデルとファインチューニングされたモデルの重み分布を示しています。一見すると、これらの分布は大きく変動しているように見えます。しかし、注目すべき重要な点があります。外れ値、つまり分布の端に位置する値は、ほぼ同じインデックスで発生しているのです。
右側の図では、同じスケールでデルタの分布をプロットしています。ここで興味深い現象が見られます。デルタの分布は、ベースモデルやファインチューニングされたモデルの分布と比べて、はるかに滑らかになっています。さらに、この分布はゼロを中心に集中しています。これは非常に高い疎性を示唆しています。
この観察結果は、モデル内のすべての線形モジュールで一貫して見られました。私たちが例として使用したのはLLaMA 7Bとそのファインチューニングされたバリアントですが、実験したほぼすべてのファインチューニングされたモデルで同様のパターンが観察されました。
この分析から、左側のベースモデルとファインチューニングされたモデル自体は圧縮が難しい可能性がありますが、右側のデルタはより滑らかな分布を持っているため、はるかに圧縮しやすいことが示唆されます。
4.2 量子化の観点からの圧縮可能性
次に、量子化の観点からこの圧縮のしやすさを考えてみましょう。量子化は本質的に、16ビットの範囲を例えば2ビットで表現するようなものです。ここで重要なのは、外れ値の存在です。
外れ値が存在すると、量子化のグリッドが引き伸ばされることになります。つまり、16ビットの範囲を表現するためにより多くのビットが必要になるのです。これは圧縮効率を下げる要因となります。
一方で、デルタの分布が滑らかで外れ値が少ない場合、量子化グリッドをより密にすることができます。これにより、元の16ビットの重みと量子化された重みの差が小さくなります。言い換えれば、エラーが小さくなるのです。
このように、デルタの滑らかな分布は、量子化の観点からも圧縮に適していることがわかります。外れ値が少ないため、より効率的な量子化が可能となり、結果として高い圧縮率を実現できるのです。
4.3 Optimal Brain Compressionフレームワーク
デルタの圧縮にあたり、私たちは Optimal Brain Compression フレームワークを採用しました。これは一見すると直接的なアプローチに思えるかもしれませんが、実際には慎重な考慮が必要でした。
Optimal Brain Compression は、過去の世紀から続く研究の系譜に属しています。具体的には、Optimal Brain Damage と Optimal Brain Surgeon という古い論文に基づいています。これらの論文は、重み行列を量子化およびプルーニング（枝刈り）して、キャリブレーションデータセットに対するエラーを最小化するという考え方を提示しています。
例えば、線形モジュールがある場合、入力行列をキャリブレーションデータセットとして使用します。そして、行列乗算を行った後のエラーを最小化するように重みを調整します。
このフレームワークにデルタを組み込むのは、実は小学校レベルの数学で可能です。具体的には、重みをベースの重みとデルタの和として表現します。これにより、Optimal Brain Surgeon の理論全体にデルタを組み込むことができ、結果として類似の式を得ることができます。
4.4 デルタの抽出と圧縮プロセス
デルタの抽出と圧縮のプロセスは、一見すると直接的に思えるかもしれませんが、実際にはいくつかの重要な考慮事項があります。
最も単純なアプローチは、すべてのパラメータを列挙し、差分を取り、それを何らかのブラックボックス圧縮アルゴリズムで圧縮するというものです。しかし、残念ながらこのアプローチは一般的に機能しません。
その理由は、デルタのスケールが小さいことと、フォワードパス全体にわたって長い線形活性化関数があることに関係しています。例えば、多層の完全結合ニューラルネットワークがあり、入力を与えると、各層でデルタは元の値の10分の1程度のスケールになります。この結果、出力はどんどん小さくなり、最終的にはすべてゼロになってしまう可能性があります。
この状態で圧縮アルゴリズムを適用すると、「なぜすべての入力がゼロなのに重み行列が必要なのか？」と判断し、すべてをゼロに設定してしまいます。確かに圧縮率は完璧になりますが、これでは意味のある圧縮とは言えません。
幸い、この問題を解決する方法は比較的シンプルです。私たちが行ったのは、重みをその場で再構築するアプローチです。具体的には以下のようなプロセスを踏みます：
- 線形モジュールがある場合、デルタだけでなくベースモデルの重み行列も取得します。
- この2つを使って、この線形層への実際の入力がどのようなものかを再構築します。
- デルタのみを圧縮し、ベースの重みは破棄します。
- 圧縮されたバージョンを次の層に渡します。
- 次の層でも同様に、ベースの重みを取得し、このプロセスを繰り返します。
このプロセスを、すべてのデルタが圧縮されるまで続けます。つまり、各線形モジュール、各圧縮したいモジュールについて、ベースの重みを考慮する必要があるのです。
この方法により、デルタの小さなスケールと長い線形活性化関数の問題を克服し、効果的な圧縮を実現することができます。また、この方法は各層で独立して適用できるため、モデル全体の圧縮を効率的に行うことができます。
以上が、DeltaZipにおけるデルタ圧縮の技術的詳細です。この方法により、ファインチューニングされたモデルの差分を効果的に圧縮し、効率的なモデルサービングを実現することができます。
5. 圧縮されたデルタモデルのサービング
5.1 ナイーブなアプローチとその問題点
圧縮されたデルタモデルをサービングする最も直接的な方法は、デルタをベースモデルに加算し、そのリクエストを処理するというものです。このアプローチには以下のステップがあります：
- デルタをロードします。ここでは圧縮のおかげで少ないバイト数をロードできます。
- デルタを16ビットに解凍します。これは元のベースの重みに加算するために必要です。
- ベースの重みにデルタを加算します。
- 推論を実行します。
- 次のクエリが異なるデルタを使用する可能性がある場合、ベースからデルタを削除します。
このプロセスには大きな問題があります：
- 低精度のデルタを解凍するのはGPUにとって非効率的です。
- ベースモデルに対して「ロック」をかけているようなもので、同じデルタに対する少数のリクエストしか同時に処理できません。
- 異なるデルタを持つ複数のモデルを同時にサービングできません。
- 過剰なメモリ使用が必要です。デルタを解凍してGPU RAM上に保存する必要があるためです。
このような高コストなプロセスは避けたいところです。
5.2 DeltaZipの効率的なサービング手法
そこで、私たちは異なるアプローチを考案しました。トークン生成は基本的に2つのステップから成り立っています：
- プリフィル（事前処理）：通常計算量が多いです。すべての入力トークンがあり、それらをバッチ処理できるためです。
- トークン生成：通常メモリバウンドです。新しいトークンを1つ生成するたびに、基本的に行列とベクトルの乗算を行うからです。
この特性は一般的には望ましくないかもしれませんが、私たちはこの性質を利用して、より多くのデルタを並列に処理することを目指しました。
私たちの手法は以下の通りです：
- デルタをベースモデルに加算せず、別々に処理します。
- すべてのファインチューニングされたモデルは同じベースを共有しているため、ベースモデル部分で大きなバッチ行列乗算を実行します。
- デルタ部分に関しては、低精度の行列乗算を行います。
理想的には、これはGPUによってネイティブにサポートされるべきです。しかし、すべてのGPUがあらゆるビット精度の行列乗算をサポートしているわけではありません。そのため、任意のビット精度の行列乗算のニーズに対応できるカーネルを設計する必要があります。
5.3 低精度行列乗算の最適化
低精度行列乗算を最適化するために、私たちは解凍操作と行列乗算を融合させることを目指しました。具体的なプロセスは以下の通りです：
- 低精度のデルタをGPUのHBM（High Bandwidth Memory）から取り出します。
- ストリームマルチプロセッサ内でデルタを解凍します。
- 解凍したデータを使用して行列乗算を実行します。
- 結果をHBMに書き戻します。
この方法には、いくつかの重要な利点があります：
- GPUのHBM上に16ビットのデルタを保存する必要がなくなります。HBMは非常に貴重なリソースであり、この方法によりその使用を最小限に抑えることができます。
- 結果のみをHBMに書き戻せば良いので、メモリ使用量が削減されます。
先行研究によると、この方法は3〜5倍のスピードアップをもたらすことが示されています。これは非常に大きな改善です。
さらに、この方法は共有ベースモデルに対するバッチ処理を可能にします。例えば、5倍のスピードアップが得られた場合、5つのデルタを同時に処理できることになります。ベースモデルに対してバッチサイズ5で処理を行うと、コスト2でコスト1の処理と同等の効果が得られます。つまり、5つの異なるモデルに対する5つのリクエストを、わずか2倍のコストで処理できるのです。
この最適化は、Transformerブロック全体に適用されます。各リクエストに対して、線形モジュールの前でバッチ処理を行い、その後でアンバッチします。これにより、ベースモデルとデルタモデルの1つに対する2つのリクエストを同時に効率的に処理できます。
この方法により、私たちは圧縮されたデルタモデルを効率的にサービングし、複数のモデルを同時に処理することが可能になりました。これはマルチテナント言語モデルサービングの課題に対する効果的な解決策となります。
6. 実験と評価
私たちはDeltaZipの性能を二つの側面から評価しました：モデル性能と、スループットです。
6.1 モデル性能の評価
6.1.1 圧縮率vs精度のトレードオフ
まず、圧縮率と精度のトレードオフについて調査しました。x軸に圧縮率、y軸にファインチューニングタスクにおけるダウンストリーム精度をプロットしました。
結果は非常に興味深いものでした。モデルを12倍まで圧縮しても、性能がまったく低下しないことを発見しました。比較のために、当時の最先端アルゴリズムであるSparseGPTを使用した場合、4ビット以下に圧縮すると性能が低下し始めることがわかりました。
6.1.2 具体的なタスクでの性能比較
次に、異なるタスクにおける性能を評価しました。グラフの各ノブは異なる設定を表しており、具体的には異なるビット幅と疎性度の組み合わせです。
結果は、タスクによって多少の違いが見られました。一部のタスクではより容易に圧縮できる一方で、他のタスクではより困難でした。しかし、重要なのは、評価したすべてのタスクにおいて、6倍から8倍の圧縮率でも高い品質を維持できたことです。
これらの実験は3Bパラメータモデルを用いて行われました。一般的に、小さなモデルほど圧縮が困難であることを考えると、これは非常にチャレンジングな設定です。
さらに、このプロセスは再学習を必要としません。圧縮は完全に消費者向けのハードウェアで行うことができ、バックプロパゲーションなどのトレーニング手順は必要ありません。ユーザーが性能に満足できない場合、簡単により低い圧縮率に戻すことができます。
実験では、3Bパラメータモデルの圧縮に単一のRTX 3090を使用し、わずか5分で完了しました。これは、あらゆるタイプのファインチューニング（全パラメータ微調整、SFT、RLHF等）に適用可能です。
6.2 スループット評価
6.2.1 エンドツーエンドシミュレーション結果
次に、エンドツーエンドのシミュレーションを行い、DeltaZipのスループットを評価しました。この実験では、実際のトレースを使用してモデルのスワッピングをシミュレートし、異なるバックエンドのスループットを比較しました。
実験設定では、モデルを4ビットに量子化し、圧縮率は4倍としました。200トークンを生成する場合、ラムダ分布のワークロードにおいて、私たちのシステムは従来のアプローチと比較してスループットを2倍に向上させました。
他の設定でも、1.5倍から3倍のスループット向上が観察されました。
6.2.2 バッチサイズの影響
さらに、バッチサイズがパフォーマンスに与える影響を調査しました。実験結果から、バッチサイズを増やすことで並列計算を可能にし、メモリ効率を向上させることができることがわかりました。
これらの実験結果は、DeltaZipが圧縮率、モデル性能、およびスループットの面で非常に効果的であることを示しています。特に、高い圧縮率を実現しながらモデルの性能を維持できること、そして複数のモデルを効率的に同時サービングできることは重要な成果です。
これらの結果は、DeltaZipがマルチテナント言語モデルサービングの課題に対する有力な解決策となる可能性を示唆しています。
7. ユースケース：チャットモデルの圧縮と展開
DeltaZipの実用性を示すために、私たちはチャットモデルの圧縮と展開に関する具体的なユースケースを検討しました。このセクションでは、実際のチャットモデルに対してDeltaZipを適用した結果について説明します。
7.1 チャットモデルの圧縮例
私たちは、チャットモデルを対象にDeltaZipを適用して圧縮を行いました。具体的な圧縮率については、前のセクションで説明した通り、6倍から8倍の圧縮率でも高い品質を維持できることが示されています。
圧縮プロセスは、前述の通り、単一のRTX 3090 GPUを使用してわずか5分で完了しました。これは、DeltaZipが非常に効率的なアルゴリズムであることを示しています。また、この迅速な圧縮プロセスは、多数のモデルを短時間で処理する必要があるプロダクション環境において特に有用です。
7.2 圧縮後のモデル出力品質の分析
圧縮後のモデル出力品質を評価するために、私たちは圧縮されたモデルを使用していくつかの対話を生成し、その結果を分析しました。
圧縮されたチャットモデルは、一貫性のあるテキストを出力し、意味のある応答を生成できていることがわかりました。実際、この回答は理にかなっており、モデルがまだ有用な情報を生成できることを示しています。
私たちは、50の対話についてこのような分析を行い、その結果を論文の付録に記載しました。これらの分析結果は、DeltaZipが高い圧縮率を実現しながらも、モデルの出力品質を大幅に低下させることなく維持できることを示しています。
この結果は、DeltaZipがマルチテナント言語モデルサービングにおいて非常に有効であることを示唆しています。高い圧縮率により、より多くのモデルをメモリに保持することができ、同時に高品質の出力を維持することができます。これにより、サービスプロバイダーは限られたリソースでより多くのユーザーや異なるモデルバージョンをサポートすることが可能になります。
これらの結果は、DeltaZipが単なる理論的な提案ではなく、実際のアプリケーションで有効に機能することを示しています。圧縮されたモデルが依然として意味のある、一貫性のある応答を生成できるという事実は、この技術の実用性を強く裏付けています。
8. 今後の研究方向
DeltaZipの開発と評価を通じて、私たちはいくつかの興味深い研究方向を特定しました。これらは、DeltaZipの性能をさらに向上させ、その適用範囲を拡大する可能性を持っています。
8.1 混合精度圧縮
現在、私たちはベースモデルに対してはフル精度（FP16）を使用し、デルタに対しては異なる精度を適用しています。しかし、さらなる最適化の余地があります。今後の研究では、ベースモデルも同時に圧縮し、デルタに対しては異なるビット幅や疎性を適用する可能性を探ります。この混合精度アプローチにより、モデル全体のサイズをさらに削減しつつ、性能を維持することができる可能性があります。
8.2 レイヤーごとの自動設定探索
現在、私たちは全レイヤーに対して同じ設定（同じ精度、同じ疎性）を使用しています。しかし、異なるレイヤーは圧縮に対して異なる感度を持っている可能性があります。そのため、レイヤーごとに最適な設定を自動的に探索するアルゴリズムの開発が有望な研究方向です。これにより、各レイヤーの特性に応じた最適な圧縮が可能になり、全体的な性能と圧縮率のバランスをさらに改善できる可能性があります。
8.3 キャッシュと活性化の圧縮
現在、多くの研究者がキャッシュと活性化の圧縮にも興味を持ち始めています。DeltaZipの概念をこれらの領域にも拡張することで、モデルの実行時メモリ使用量をさらに削減できる可能性があります。特に、ベースモデルだけでなく、複数のデルタモデルを同時に扱う場合、キャッシュと活性化の効率的な圧縮は重要な課題となります。
8.4 スケジューリングの課題
マルチテナントモデルサービングのシナリオでは、スケジューリングが重要な課題となります。多くの研究者がこの問題に取り組んでおり、様々なアプローチが提案されています。DeltaZipと効率的なスケジューリングアルゴリズムを組み合わせることで、リソース利用率とレスポンス時間を最適化できる可能性があります。
8.5 新しいハードウェアアーキテクチャの活用
ETHの研究グループとして、私たちは特に異種混合および最新のハードウェアに興味を持っています。例えば、NVIDIA Hopper GPUは低精度FPAの計算をネイティブにサポートしています。また、FPGAを使用して1ビットまで圧縮する可能性も探っています。これらの新しいハードウェアアーキテクチャを活用することで、DeltaZipの性能をさらに向上させ、より効率的なモデルサービングを実現できる可能性があります。
これらの研究方向は、DeltaZipの将来的な発展に重要な役割を果たすと考えています。各方向性には独自の課題がありますが、それらを解決することで、大規模言語モデルの効率的なサービングという大きな課題に対してさらなる貢献ができると期待しています。私たちは、これらの方向性に沿った研究を進めることで、マルチテナント言語モデルサービングの分野に継続的に貢献していきたいと考えています。
9. 質疑応答
プレゼンテーション後の質疑応答セッションでは、DeltaZipに関する興味深い質問がいくつか提起されました。
9.1 デルタモデルのストレージに関する質問と回答
質問者から、デルタモデルのストレージに関する質問がありました。具体的には、デルタモデルが十分に小さい場合、GPUメモリに直接格納することで、ホストからデバイスへの通信コストを削減できるのではないかという提案でした。
この質問に対して、私は以下のように回答しました。確かに、デルタモデルをGPUメモリに直接格納することは可能です。しかし、これは一種のトレードオフの問題です。仮に1000個のデルタモデルがあり、それぞれを10倍に圧縮したとしても、GPUメモリに全てを格納することは望ましくありません。なぜなら、そのGPUメモリは他の用途、例えばKVキャッシュや活性化、バッチサイズの拡大などに使用したいからです。
私たちの研究では、数千のデルタモデルがあり、ホストメモリさえも全てを格納できない状況を想定しています。そのため、一部のデルタモデルはハードドライブに保存する必要があります。
つまり、デルタモデルの保存場所の選択は、利用可能なリソースと具体的なユースケースに応じて柔軟に判断する必要があります。
9.2 LoRAとの比較に関する議論
次に、LoRA（Low-Rank Adaptation）との比較に関する質問が出ました。質問者は、LoRAアダプターが通常、元のモデルの1%から10%程度のサイズであることを指摘し、DeltaZipの圧縮率との比較を求めました。
これに対して、私は以下のように回答しました。私たちの圧縮されたデルタは、元のモデルの約10分の1のサイズです。つまり、LoRAアダプターと比較すると、おおよそ10倍大きいことになります。ただし、ランクによっては、LoRAアダプターが元のモデルの10%になることもあるため、その場合はサイズが同等になります。
現時点では、私たちの手法はLoRAよりも10倍程度大きいですが、両者を直接比較するのは難しいです。なぜなら、LoRAは完全に新しい学習パラダイムを必要とし、場合によっては全パラメータのファインチューニングと同等の性能を達成できないこともあるからです。
9.3 解凍プロセスの最適化に関する提案と議論
最後に、解凍プロセスの最適化に関する提案がありました。質問者は、最近のPIKAやASoRAのような手法が、カスタム作成したCUDAカーネルを使用してアダプターの重みをバッチ処理する方法を提案していることを指摘しました。これらの手法を用いれば、解凍の臨界パスを短縮できる可能性があるという提案でした。
この提案に対して、私は非常に興味深いアイデアだと応答しました。確かに、解凍プロセスをさらに最適化する余地はあります。私たちの現在のアプローチでは、解凍と行列乗算を融合させていますが、これをさらに改善できる可能性があります。
具体的には、大きなバッチの解凍を一度に行い、それをストリームプロセッサ内で行うことができます。これにより、臨界パスを短縮し、並列性を高めることができるかもしれません。
これらの提案は、DeltaZipの性能をさらに向上させる可能性があり、今後の研究方向として非常に興味深いものです。私たちは、これらのアイデアを取り入れ、さらなる最適化を進めていく予定です。
この質疑応答セッションを通じて、DeltaZipにはまだ改善の余地があること、そして他の研究者からのフィードバックが非常に貴重であることを再認識しました。これらの議論は、今後の研究方向を決定する上で重要な指針となるでしょう。
10. 結論
10.1 DeltaZipの主な貢献
DeltaZipの開発と評価を通じて、私たちはマルチテナント言語モデルサービングの分野に重要な貢献をしました。
私たちの主な発見は、デルタ、つまりベースモデルとファインチューニングされたモデルの差分が大きく過剰にパラメータ化されており、したがって高度に圧縮可能であるということです。この洞察は、効率的なモデルサービングの新しい可能性を開きました。
具体的には、私たちはデルタを最大12倍まで圧縮しても、モデルの性能が全く低下しないことを実証しました。これは、当時の最先端アルゴリズムであるSparseGPTが4ビット以下で性能低下を示すのと対照的です。
また、私たちは評価したすべてのタスクで、6倍から8倍の圧縮率でも高品質を維持できることを示しました。これは、3Bパラメータモデルを用いた実験で得られた結果であり、小さなモデルほど圧縮が困難であることを考えると、非常にチャレンジングな設定での成果です。
さらに、DeltaZipは再学習を必要とせず、消費者向けのハードウェアで短時間で圧縮を行うことができます。3Bパラメータモデルの圧縮が単一のRTX 3090で5分以内に完了することを示しました。これは、あらゆるタイプのファインチューニング（全パラメータ微調整、SFT、RLHF等）に適用可能です。
スループットの面でも、DeltaZipは従来のアプローチと比較して大きな改善を示しました。200トークンを生成する場合、ラムダ分布のワークロードにおいて、私たちのシステムはスループットを2倍に向上させました。他の設定でも1.5倍から3倍のスループット向上が観察されました。
これらの成果は、DeltaZipがマルチテナント言語モデルサービングの課題に対する有効な解決策となる可能性を示しています。特に、高い圧縮率を実現しながらモデルの性能を維持できること、そして複数のモデルを効率的に同時サービングできることは、リソースの制約が厳しい環境でも高品質なモデルサービングを可能にします。
10.2 マルチテナント言語モデルサービングの未来展望
DeltaZipの成功は、マルチテナント言語モデルサービングの未来に明るい展望をもたらします。
私たちが示した今後の研究方向は、この分野のさらなる発展を示唆しています。混合精度圧縮、レイヤーごとの自動設定探索、キャッシュと活性化の圧縮、効率的なスケジューリング、新しいハードウェアアーキテクチャの活用など、これらの方向性は各々が大きな可能性を秘めています。
特に、新しいハードウェアアーキテクチャの活用は興味深い方向性です。NVIDIA Hopper GPUの低精度FPA計算のネイティブサポートや、FPGAを使用した1ビットまでの圧縮など、ハードウェアの進化とDeltaZipのようなソフトウェア技術の組み合わせは、言語モデルのサービングにおける大きなブレークスルーをもたらす可能性があります。
また、質疑応答セッションで提起された解凍プロセスの最適化に関する提案も、将来の改善の余地を示しています。大きなバッチの解凍を一度に行い、ストリームプロセッサ内で処理することで、さらなる性能向上が期待できます。
結論として、DeltaZipはマルチテナント言語モデルサービングの分野に重要な一歩を記しました。しかし、これは始まりに過ぎません。私たちの研究は、この分野にはまだ多くの可能性が残されていることを示しています。
私たちは、DeltaZipがこの分野の発展に貢献し、より効率的で柔軟な言語モデルサービングの実現に向けた重要な一歩となることを願っています。今後も研究を続け、この技術をさらに発展させていく所存です。