ファインチューニング済みLoRAモデルの提供のスケーリング

AIアプリケーションのデプロイメントにおいて、ファインチューニングされたモデルの提供をスケールすることは、極めて重要な課題となっています。あるシナリオを考えてみましょう。あなたは、多様なニーズを持つ500社の顧客に対応するSaaSスタートアップで、社内サポートやパーソナライズされたマーケティングコンテンツのために、ファインチューニングされた大規模言語モデル（LLM）の適応が必要だとします。これは、約1000ものモデルをファインチューニングするという困難な作業を伴います。

これらの制限に対処するため、LoRAファインチューニングが登場しました。これは、コアとなるLLMを凍結し、特定の重みを更新されたデータに合わせて選択的に調整する手法です。この効率的でスケーラブルなアプローチは、LoRA構成で定義された元のパラメータのごく一部で動作します。

しかし、本当の課題は、これらのファインチューニングされたアダプターを効果的にデプロイすることにあります。

実験セットアップ

多くのオープンソースLLM提供フレームワークがLoRAアダプターの提供を組み込むために積極的に取り組んでいますが、包括的なソリューションはまだ見つかっていません。この実験では、私たちは LoRAX Predibaseによるもので、LoRAアダプターの提供とスケーリングにおいて、効率的にその秘訣を解き明かした有望なフレームワークです。

💡

PredibaseによるLoRAXに関するさらなる洞察については、彼らのブログを参照してください。 LoRAX - 1つのコストで何百ものファインチューニングされたLLMを提供

主な機能 LoRAX

LoRAXは、実装における3つの基本的な柱で際立っています。

1. 動的アダプター読み込み： ファインチューニングされたLoRAの重みをジャストインタイムで読み込むことで、実行時の同時リクエストに中断が生じないようにします。
2. 階層型重みキャッシュ： リクエスト間でLoRAアダプターを迅速にスワップすることを容易にし、アダプターの重みをCPUやディスクにオフロードすることで、メモリ不足の問題を防ぎます。
3. 連続マルチアダプターバッチ処理： システム全体の処理能力を最適化するため、公平なスケジューリングポリシーを採用し、複数のLoRAアダプターセットに並行して連続バッチ処理戦略を適用します。

性能評価： LoRAX

私たちの実験では、TinyLlama LLMモデルを使用して多数のファインチューニングされたアダプターを管理するLoRAXの性能を詳細に評価しました。実験全体を通して、複数のアダプターにわたる多数のリクエストを処理する際の効率性を測定しました。

前提条件： LoRAX セットアップ

私たちの実験を再現するには、以下の前提条件に従ってサーバーにLoRAXをセットアップしてください。

docker run \
   --gpus all \
   --shm-size 1g \
   -p 8080:80 \
   -v $PWD/data:/data \
   ghcr.io/predibase/lorax:latest \
   --model-id TinyLlama/TinyLlama-1.1B-Chat-v0.6 # base model used for finetuning


さらに、推論呼び出しのためにLoRAXクライアントを以下を使用してインストールしてください。

pip install lorax-client


推論に関する考察

LoRAファインチューニングモデルの提供にLoRAXを活用することで、明確な利点が得られました。これは、ベースとなるLLMモデルに単一のGPUを使用しつつ、リクエストごとに各アダプターを動的にロードできる能力によるものです。この動的なアプローチ（単一のGPUを使用し、アダプターをオンザフライでロードする）により、LoRAXは多数の ファインチューニングされたLoRAモデルを提供する最適なソリューションとして位置付けられます。.

推論コード例：

from lorax import Client

client = Client("https://example.lorax.truefoundry.tech", timeout=10)
generated_text = client.generate(
   prompt,
   do_sample=False,
   max_new_tokens=10,
   adapter_id=adapter_id,
   adapter_source="local"
).generated_text


我々の実験結果は、微調整されたLoRAモデルの提供にLoRAXを採用することの大きな利点を明確に示しました。リクエストごとの動的なアダプター読み込みと、ベースとなるLLMモデルに単一のA100 GPUを効果的に活用することで、LoRAXはパフォーマンスを著しく最適化しました。

パフォーマンスに関する考察

最近行った100個のアダプターの動的読み込みに関する実験では、そのパフォーマンス特性を詳細に調査しました。最初のリクエスト時に観測された初期レイテンシは、主にベースとなるLLMモデルをメモリに読み込む必要性から生じていました。しかし、その後のリクエストでは、LoRaxがアダプターを迅速に交換し、予測のためにリアルタイムでマージする能力により、レイテンシが減少しました。

以前、ブログでHuggingFace PEFTを使用してLoRA微調整モデルを読み込むプロセスについて説明しました。しかし、我々の実験では、このアプローチにはいくつかの重大な問題があることが浮き彫りになりました。

1) GPUメモリ上のアダプター増加に伴うレイテンシの増大：
最も大きな問題は、より多くのアダプターをGPUメモリに収めようとした際に明らかになりました。これにより、レイテンシが著しく急増しました。アダプターが追加されるごとに、レイテンシは大幅に増加し、全体的なパフォーマンスに影響を与えました。

2) GPUメモリの容量制限：
もう一つの重大な制限は、GPUメモリ内に収容できるアダプターの数が限られていることでした。この制約はスケーラビリティを妨げ、より多くのアダプターを同時に収容する上でのボトルネックとなりました。

パフォーマンスの違いをさらに明確にするため、以下の比較をご覧ください。

A100 GPUでの70トークン処理と10トークン生成の場合：
HuggingFace PEFT： レイテンシーは400～450ミリ秒でした。
LoRAX： 平均レイテンシーは170ミリ秒でした。

アダプターがレイテンシーに与える影響：
HuggingFace PEFT： ベースLLMに1000個のtinyllama Loraアダプターを追加すると、レイテンシーは3500～4000ミリ秒に急増し、約700%の増加となりました。
LoRAX： GPU上の動的ロードメカニズムにより、アダプターの数に関わらずレイテンシーは一貫して影響を受けず、モデル数が増加しても安定したレイテンシーを確保しました。

まとめると、HuggingFace PEFTはモデルの適応とアダプターの利用を容易にする一方で、アダプター数が増加するにつれてパフォーマンス上の課題に直面し、特にレイテンシーとスケーラビリティに影響を与えます。対照的に、LoRAXはアダプターを動的にロードし、リアルタイムで予測を実行する能力で際立っており、多数のLoraファインチューニングモデルを使用しても、一貫したパフォーマンスとスケーラビリティを確保します。

結論

LoRAXが、一貫したベースモデルを維持しながら、多様なファインチューニングされたLoRAモデルを効率的に処理できる優れた能力は、個々の顧客ニーズに合わせたスケーラブルなAIサービスを求める企業にとって、非常に有望です。

LoRAXの効率的なアダプターロード戦略を活用することで、企業は自信を持ってサービスを拡張し、何千もの特定のニーズに合わせたファインチューニングされたLoRAモデルに対応できるようになります。そのすべてにおいて、統一されたベースモデルを維持しながらです。

まとめると、LoRAXはファインチューニングされたアダプターの提供において画期的な存在となり、多様なAIモデルを効果的にデプロイしようとする企業にとって、スケーラブルで最適化されたソリューションを提供します。

TrueFoundry は、Kubernetes上で動作するMLデプロイメントPaaSであり、開発者のワークフローを加速させながら、モデルのテストとデプロイにおいて完全な柔軟性を提供し、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームが デプロイおよび監視 モデルを15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能とともに実行できるようにします。これにより、コストを削減し、モデルをより迅速に本番環境にリリースできるようになり、真のビジネス価値の実現を可能にします。