微調整された LLM をサーバーレスで導入:Pay-Per-Token 推論でコストを削減

はじめに

AI ワークフロー チームが新しいプロジェクトで実行できる最大のコスト削減手順の 1 つは、必要に応じてサーバーレス推論を活用することです。従来、AI モデルを 24 時間年中無休で実行するには、時間単位で支払われる専用の GPU が必要でした。サーバーレス推論エンドポイントを使用すると、チームは、時間ごとに料金を支払い、セットアップとメンテナンスを自分で管理するのではなく、トークンごとの支払いで多くのオープンソース モデルを使用するオプションを利用できます。これにより、チームは使用量に対してのみ支払いを行い、必要に応じて拡張できるため、新しい製品を実行するコストが削減されました。

サーバーレス アーキテクチャは以前から存在していましたが、カスタム モデルや微調整されたモデルを使用するチームは、依然として GPU の使用量に対して時間料金を支払うことがよくあります。ただし、微調整されたモデルをホストし、トークンごとの支払いでサーバーレス エンドポイント経由で配信することは可能です。微調整されたモデルをサーバーレスでホストする方法と、そのメリットとデメリットについて説明します。

重要なポイント

• LoRA のようなパラメータ効率の高い微調整方法により、共有された凍結されたベース モデルの上に重ねることができる小さなアダプター ウェイトを生成することで、カスタム モデルのサーバーレス ホスティングが実用的になります。これは、プラットフォームが単一の GPU から何百もの微調整されたバリアントを提供できることを意味し、モデルごとに専用のデプロイを行う必要がなくなりました。
• トラフィックが急増したり予測不可能なチームは、GPU を 24 時間稼働させるのではなく、サーバーレスの微調整されたエンドポイントに切り替えて、使用したトークンに対してのみ料金を支払うことで推論コストを削減できます。また、トレーニング済みのアダプターをマネージド プラットフォームにアップロードすると、インフラストラクチャをセットアップせずに数分でライブ API エンドポイントが生成されるため、デプロイも高速になります。
• 微調整されたモデルを使用したサーバーレス推論の主なトレードオフはコールド スタートです。コールド スタートでは、リクエストを処理する前にアイドル状態のアダプターをストレージから再ロードする必要があり、最大で数百ミリ秒のレイテンシが追加されます。これは、定期的なキープアライブ リクエストで軽減できます。また、フェッチする必要があるのは軽量アダプターの重みのみであるため、フルモデルのコールド スタートよりも遅延が小さくなります。

サポートされている微調整方法

この文脈で「微調整」と言うとき、モデルのすべての重みが新しいデータで最初から再トレーニングされる従来の完全な微調整を意味するものではないことをここで明確にすることが重要です。完全な微調整には費用と時間がかかり、オリジナルと同じ大きさのまったく新しいモデルが作成されます。そのモデルをサーバーレスでホストすることは、多くの異なるユーザー間で共有できないため、現実的ではありません。独自の専用 GPU の導入が必要です。

パラメーター効率の良い微調整 (PEFT) は、すべての重みを再トレーニングするのではなく、重みの小さなサブセットのみを更新し、元のモデルをフリーズしたままにします。これにより、カスタマイズを表す追加の重みのセットがはるかに小さくなりますが、重い基本モデルは変更されず、関連性のない多くの異なるユーザー間で共有できます。

最も広く使用されている PEFT 手法は、低ランク適応 (LoRA) です。 LoRA は、モデルの既存の重みを直接変更するのではなく、凍結された基本モデルの上に小さなトレーニング可能なアダプター行列を追加します。これらのアダプターは、基本モデル自体の数十または数百ギガバイトと比較して、タスク固有の動作をわずか数メガバイトの重みでキャプチャします。 LoRA には、QLoRA、DoRA、LoRA+ などのいくつかの亜種もあり、これらはすべてサーバーレス推論プラットフォームで広くサポートされています。

基本モデルはフリーズされており、すべてのユーザー間で同一であるため、プラットフォームはそれを GPU メモリに一度ロードして共有できます。各ユーザーの LoRA アダプターはリクエスト時に最上位にロードできるため、単一の GPU から数百の微調整されたバリアントを提供することが現実的になります。微調整されたモデルでサーバーレス推論をサポートするプラットフォームは、通常、特定の基本モデルでのみサポートされることに注意することも重要です。したがって、サポートされている基本モデルのいずれかでトレーニングされた LoRA アダプターが必要です。

複数の LoRA アダプタの管理

LoRA アダプターの重み (通常はそれぞれ 10 ～ 100 MB) は、推論サーバーによって管理される高速オブジェクト ストレージまたはメモリ内キャッシュに保存されます。特定のアダプターに対するリクエストが到着すると、サービス提供システムはそれらの重みをフェッチし、オンザフライでフォワード パスに融合します。

この融合プロセスは軽量です。 LoRA が適用される各トランス層で、アダプターは層の出力に低ランクの補正を生成する 2 つの小さな行列を追加します。推論中、サーバーはベース レイヤの出力を計算し、いくつかの追加の CUDA 操作に LoRA 補正を追加します。基本の重みは決して変更されないため、リクエスト間でアダプターを交換するには、基本モデルをリロードしたり CUDA カーネルを再起動したりするのではなく、GPU レジスタ内の小さな行列ペアを置き換えるだけで済みます。

最大の課題の 1 つは、単一のインスタンスで動作する数百のアダプターによるメモリ管理です。推論サーバーは、最近最も頻繁に使用されたアダプターの重みの小さな常駐キャッシュを VRAM に直接維持する必要があります。他のアダプタは VRAM から削除され、CPU RAM またはオブジェクト ストレージに戻されるため、リロード時間に数百ミリ秒のペナルティが発生します。

バッチ処理プロセスは、使用される LoRA メソッドに基づいて異なる場合があります。アダプタを共有するリクエストは通常​​、各サブグループの修正が実行される前にサブバッチにグループ化されますが、S-LoRA などの一部のシステムでは、異なるアダプタからのリクエストを同じフォワード パスにパックし、アクティブなアダプタをユニファイド メモリ プールに保存し、その後、異なるアダプタ修正を異なるシーケンス位置に同時に適用できるカスタム CUDA カーネルでアドレス指定します。このアプローチは、LoRA 多重化と呼ばれることもあります。これにより、トラフィックが一度に多くの異なる微調整されたバリアントに分散された場合でも、GPU が飽和状態を保つことができます。 vLLM は、時間単位でレンタルしている GPU 上で LoRA アダプタを交換することに興味があるユーザーのために、LoRA 多重化もネイティブにサポートします。

KV キャッシュ エントリは、それを生成したアダプタに結合されます。あるアダプタで生成されたキャッシュ エントリは、別のアダプタを使用するリクエストに再利用できません。これにより、最終的にはマルチアダプター設定の方が単一モデル展開よりも KV キャッシュのヒット率が低くなり、推論サーバーはリクエストのプロンプト トークンとアダプター ID の両方でエントリをキー キャッシュする必要があります。

サーバーレス微調整の使用による実際の影響

サーバーレス微調整の強みは、一貫性のないトラフィックのバーストが発生する新しいサービスを構築しているチームにとって最も明白であり、GPU を 24 時間 365 日稼働させる必要がなく、費用対効果も高くありません。夜間のアイドル時間に対して固定の GPU 時間料金を支払うのではなく、リクエストからのトークンに対してのみ料金を支払います。サーバーレス アーキテクチャに移行することで、推論コストを一桁削減できます。

導入速度も大幅に速くなります。 LoRA アダプターのトレーニングが完了したら、それをマネージド推論プラットフォームにアップロードすると、クラスターのプロビジョニング、コンテナー オーケストレーション、GPU ドライバー管理を必要とせずに、数分でライブ API エンドポイントが生成されます。これによりインフラストラクチャの負担が軽減され、チームはモデルと製品に集中できるようになります。基本モデルが共有され、効率的かつ手頃な価格で実行されている場合でも、モデルの動作の制御を維持することができ、アダプターの重みを所有することができます。

微調整されたモデルをサーバーレスでホストすることの最大の欠点は、コールド スタートです。アダプターが一定期間トラフィックを受信しない場合、推論プラットフォームは通常、トラフィックをゼロにスケールし、GPU メモリーから重みを削除し、他のユーザーのために VRAM を再利用します。これは、システムがオブジェクト ストレージから重みをフェッチしてロードし、順方向パスを開始するまで、次のユーザーは待機する必要があることを意味します。アダプタが小さいため、これには通常、数秒ではなく数百ミリ秒程度かかります。注意点として、基本モデルが頻繁に使用されず、それ自体が削除された場合 (一部のアーキテクチャではこれが発生する可能性があります)、コールド スタートに時間がかかる可能性があります。コールド スタートでは、出力トークンごとの時間 (最初のトークンの後にトークンが生成される速度) に影響を与えることなく、最初のトークンまでの時間 (TTFT) が特に急上昇します。 TTFT は、ストリーミング レイテンシを最小限に抑えようとするチームにとって注目すべき指標です。

コールド スタートは、いくつかの方法で軽減できます。まず、トラフィックが少ない時間帯に定期的にキープアライブ要求を送信するようにアーキテクチャを設定できます。 2 番目に、LoRA アダプターをトレーニングするときに、ロードをより効率的にするための手順を実行できます。トレーニング中、アダプターのサイズと表現力は、ランクまたは「r」と呼ばれるハイパーパラメーターによって制御されます。ランク 8 アダプターは、ランク 16 アダプターのトレーニング可能なパラメーターの約半分を生成します。ランク 8 アダプターは、他のすべてが等しい場合、コールド スタートからの TTFT が高速になります。また、LoRA が適用されるトランスフォーマー層により、ファイル サイズと推論オーバーヘッドが変更されます。 LoRA は通常、各アテンション ブロックのクエリおよび値射影行列に適用されますが、MLP (多層パーセプトロン) レイヤーに適用すると、モデルを特定のドメインに適応させる際の品質を向上させることができます。

結論

サーバーレスで微調整された推論は、将来的にますます人気のある製品になる可能性があります。現在の LLM の状況は、より大きく、より優れた推論を行うモノリシック モデルをスケーリングすることに重点を置いています。多くの専門モデルが連携して動作するアーキテクチャにはあまり注目されていません。最終的に、コミュニティは、この種のアーキテクチャが適切に機能する多くのモデルとユースケースを管理するためのより良い方法を見つけるでしょう。そうなると、LoRA の多重化は、多くのカスタム エージェントを手頃なコストで管理したいと考えているチームにとって役立ちます。

まだ答えをお探しですか?

この作品は、クリエイティブ コモンズ 表示 - 非営利 - 継承 4.0 国際ライセンスに基づいてライセンスされています。