ファインチューニング済みLLMをサーバーレスで導入:Pay-Per-Token推論でコストを削減

はじめに

AIワークフローを扱うチームが新規プロジェクトで実行できる最大のコスト削減策のひとつが、状況に応じたサーバーレス推論の活用です。従来、AIモデルを運用するには24時間365日稼働する専用GPUが必要で、稼働時間に応じて課金されていました。一方、サーバーレス推論エンドポイントを利用すれば、多数のオープンソースモデルをトークン単位の従量課金(Pay-Per-Token)で利用でき、セットアップや保守管理を自前で行う必要もありません。「使った分だけ支払い、必要に応じてスケールする」この仕組みにより、新製品の立ち上げコストは大幅に下がっています。

サーバーレスアーキテクチャ自体は以前から存在していましたが、カスタムモデルやファインチューニング済みモデルを保有するチームは、依然としてGPUの時間単位料金を支払っているケースが少なくありませんでした。しかし実は、ファインチューニング済みモデルをサーバーレスエンドポイントでホストし、トークン従量課金で提供することは可能です。本記事では、その具体的な仕組みと、メリット・デメリットを詳しく解説します。

要点まとめ

LoRAなどのパラメータ効率化ファインチューニング(PEFT)により、共有された凍結済みベースモデルの上に重ねられる小型のアダプタ重みが生成されます。これにより、プラットフォームは1つのGPUで数百種類のファインチューニング済みバリアントを提供でき、モデルごとの専用デプロイが不要になります。
トラフィックが断続的・予測不能なチームは、サーバーレスのファインチューニング済みエンドポイントへ切り替えることで推論コストを削減できます。24時間GPUを稼働させる代わりに、使用したトークン分だけ支払う形になります。デプロイも高速で、学習済みアダプタをマネージドプラットフォームにアップロードすれば、数分でAPIエンドポイントが稼働し、インフラ構築は一切不要です。
主なトレードオフはコールドスタートです。アイドル状態のアダプタは、リクエストを処理する前にストレージから再ロードする必要があり、最大数百ミリ秒のレイテンシが発生します。これは定期的なキープアライブリクエストで緩和できます。また、軽量なアダプタ重みだけを取得すればよいため、ベースモデル全体のコールドスタートよりも遅延は大幅に小さくなります。

対応しているファインチューニング手法

まず前提として、ここでいう「ファインチューニング」は、モデルの全重みを新しいデータで一から再学習するフルファインチューニングではありません。フルファインチューニングは高コストで時間がかかり、しかも元のモデルと同等サイズの全新モデルを生み出します。そのようなモデルは複数ユーザー間で共有できないため、サーバーレスでのホスティングは非現実的であり、専用のGPUデプロイが必要になります。

一方、パラメータ効率化ファインチューニング(PEFT)は、全重みを再学習するのではなく一部の重みのみを更新し、元のモデルは凍結したままにします。その結果、カスタマイズ内容を表す非常に小さな追加重みだけが生成され、重いベースモデルは変更されずに、まったく関係のない多数のユーザー間で共有できます。

最も広く使われているPEFT手法がLow-Rank Adaptation(LoRA)です。LoRAは既存の重みを直接書き換えるのではなく、凍結されたベースモデルの上に小型の学習可能なアダプタ行列を追加します。これらのアダプタはわずか数MBの重みでタスク固有の振る舞いを捉えます(ベースモデル自体は数十〜数百GB)。さらにLoRAにはQLoRA、DoRA、LoRA+といった派生手法があり、いずれも主要なサーバーレス推論プラットフォームで広くサポートされています。

ベースモデルは凍結され全ユーザーで同一であるため、プラットフォームはそれを一度GPUメモリにロードして共有できます。各ユーザーのLoRAアダプタはリクエスト時にその上へロードされるため、1つのGPUで数百種類のファインチューニング済みバリアントを提供することが現実的になります。なお重要な注意点として、ファインチューニング済みモデルのサーバーレス推論をサポートするプラットフォームは、一般に特定のベースモデルのみに対応しています。そのため、サポート対象のベースモデル上で学習されたLoRAアダプタを用意する必要があります。

複数のLoRAアダプタの管理方法

LoRAアダプタの重み(通常は1つあたり10〜100MB程度)は、高速なオブジェクトストレージ、または推論サーバーが管理するインメモリキャッシュに保存されます。特定のアダプタ宛てのリクエストが到着すると、サービングシステムは該当する重みを取得し、フォワードパスにオンザフライで融合(fuse)します。

この融合処理は非常に軽量です。LoRAが適用される各トランスフォーマー層において、アダプタは層の出力に低ランク補正を与える2つの小さな行列を追加します。推論時、サーバーはまずベース層の出力を計算し、その後いくつかの追加CUDA演算でLoRA補正を加算します。ベースの重みは一切変更されないため、リクエスト間でのアダプタ切り替えは、ベースモデルの再ロードやCUDAカーネルの再起動を伴わず、GPUレジスタ内の小さな行列ペアを差し替えるだけで完了します。

最大の課題のひとつは、1つのインスタンス上で数百のアダプタを扱う際のメモリ管理です。推論サーバーは、直近および高頻度で使用されるアダプタ重みの小さな常駐キャッシュをVRAM内に維持する必要があります。それ以外のアダプタはVRAMから退避(evict)され、CPU RAMやオブジェクトストレージへ戻されます。この際、再ロードには数百ミリ秒のペナルティが発生します。

バッチ処理の方式は、採用するLoRA手法によって異なります。同一アダプタを共有するリクエストは、一般にサブバッチへグループ化されてから各グループの補正が実行されます。しかしS-LoRAのようなシステムでは、異なるアダプタからのリクエストを同一のフォワードパスに詰め込み、アクティブなアダプタを統合メモリプールに格納した上で、異なるシーケンス位置へ同時に異なるアダプタ補正を適用できるカスタムCUDAカーネルで処理します。この方式は「LoRAマルチプレキシング」とも呼ばれます。トラフィックが多数のファインチューニング済みバリアントに分散していても、GPUを高い稼働率に保てるのが強みです。なお、vLLMもLoRAマルチプレキシングをネイティブにサポートしており、時間単位でレンタルしたGPU上でLoRAアダプタを入れ替えたいユーザーにとっても有用です。

もうひとつ見落とせないのがKVキャッシュの扱いです。KVキャッシュのエントリは、それを生成したアダプタに紐付いています。あるアダプタで生成されたキャッシュエントリは、別のアダプタを使うリクエストには再利用できません。その結果、マルチアダプタ環境におけるKVキャッシュのヒット率は、単一モデルのデプロイよりも低下します。推論サーバーは、キャッシュエントリを「リクエストのプロンプトトークン」と「アダプタ識別子」の両方でキー管理する必要があります。

サーバーレスファインチューニングの実際の効果

サーバーレスファインチューニングの強みが最も発揮されるのは、断続的なトラフィックのバーストが発生する新規サービスを構築するチームです。24時間365日稼働する予約GPUが不要、あるいは費用対効果が見合わないケースでは、夜間のアイドル時間に固定のGPU時間料金を支払う代わりに、リクエストで消費したトークン分だけを支払えばよいことになります。サーバーレスアーキテクチャへの移行により、推論コストを桁違い(オーダー・オブ・マグニチュード)に削減できる可能性があります。

デプロイの速さも大きな魅力です。LoRAアダプタの学習が完了すれば、マネージド推論プラットフォームへアップロードするだけで数分以内にAPIエンドポイントが稼働します。クラスタープロビジョニング、コンテナオーケストレーション、GPUドライバーの管理は一切不要です。インフラ負担が軽減され、チームはモデルとプロダクト開発に集中できます。ベースモデルは共有され、効率的かつ低コストに稼働していますが、モデルの挙動に対する制御は維持でき、アダプタの重みは自分たちの資産として所有し続けられます。

一方、サーバーレスでファインチューニング済みモデルをホストする最大の弱点はコールドスタートです。アダプタが一定期間トラフィックを受けないと、推論プラットフォームは一般的にそれをゼロにスケールし、GPUメモリから重みを退避させてVRAMを他のユーザー向けに解放します。次のリクエストでは、システムがオブジェクトストレージから重みを取得・ロードし、フォワードパスを開始するまで待機が必要になります。ただしアダプタは小型のため、所要時間は通常数秒ではなく数百ミリ秒程度です。注意点として、ベースモデル自体の利用頻度が低く、こちらも退避されている場合(一部のアーキテクチャでは起こり得ます)、コールドスタートはさらに長引くことがあります。

コールドスタートは、具体的にはTime-to-First-Token(TTFT)を悪化させますが、最初のトークン以降の生成速度(Time-per-Output-Token)には影響しません。ストリーミングレイテンシの最小化を目指すチームは、TTFTに注目すべき指標となります。

コールドスタートは主に2つの方法で緩和できます。

キープアライブリクエストの定期送信: 低トラフィック時間帯でも定期的にリクエストを送るようアーキテクチャを設定することで、アダプタを常時ウォーム状態に保ちます。
学習段階での工夫: アダプタのサイズと表現力は、ハイパーパラメータであるランク(rank / r)で制御されます。ランク8のアダプタはランク16の約半分の学習可能パラメータを持ち、他の条件が同一であれば、コールドスタート時のTTFTはより短くなります。また、LoRAを適用するトランスフォーマー層の選択もファイルサイズと推論オーバーヘッドに影響します。LoRAは一般的に各アテンションブロックのquery/value射影行列に適用されますが、MLP(Multi-Layer Perceptron)層にも適用すると、特定ドメインへの適応精度が向上する場合があります。

まとめ

サーバーレスでのファインチューニング済み推論は、今後ますます普及していくと考えられます。現在のLLM業界は、より大規模で高性能な推論能力を持つモノリシックなモデルのスケーリングに焦点が当てられており、多数の専門特化モデルが協働するアーキテクチャへの関心はまだ限定的です。しかし将来的に、コミュニティが多数のモデルを効率的に管理する手法や、この種のアーキテクチャが真価を発揮するユースケースを見出せば、LoRAマルチプレキシングは、妥当なコストで多数のカスタムエージェントを運用したいチームにとって強力な選択肢となるでしょう。