100のファインチューニング、1GPUで1.5TBから19.3GBに

ファインチューニングされたモデルを提供する際、多くのチームは各バリアントをマージして個別のエンドポイントを立てる。これは単純だが、ベースモデルが同じでも完全なモデルコピーとワーカープールをバリアントごとに複製する。記事は、このレイアウトがメモリとワーカーの両方を浪費することを示す。

代わりにベースモデルを1回ロードし、小さなLoRAアダプタを並べてロードする。vLLMがリクエストごとに必要なアダプタを適用するため、抽出、SQL、ルーティングのリクエストが同じGPUを共有できる。新しいバリアントの追加は15.2GBではなく約40MBのアダプタメモリで済む。ただし、すべてのアダプタが同じベースモデルから来る必要があり、アダプタはGPUメモリを消費する。

起動時にアダプタを登録する方法は小規模で安定したカタログに向く。リクエスト時にロードする方法は、数百の顧客アダプタがあり少数しか同時にリクエストされない場合に適するが、未ロードのアダプタへの最初のリクエストは遅くなる。

Runpod Serverlessでの実験では、共有エンドポイントは別々のエンドポイントよりもワーカーを再利用でき、コールドスタートの影響を抑えられた。別々のレイアウトは短時間のテストでは請求ワーカー秒が少なかったが、それはリクエストの完了数が少なく、ほとんどが2分以上待たされたためだ。この結果は、メモリ節約だけでなくワーカー再利用が運用上の利点であることを示す。ただし、コストはGPUタイプやワーカーモード、トラフィックのパターンに依存するため、実際の導入では自身の計測値で評価する必要がある。