LoRAX: 1基のGPUに数千のLoRAアダプタを載せる推論サーバ

LoRAXが埋めるのは「モデル数ぶんのGPU」という穴

ファインチューニング済みモデルを1つ配るたびにGPUを1基占有する運用は、テナントやタスクが増えるほど破綻する。LoRAXはこの前提を崩す。READMEによれば、LoRAXは「serve thousands of fine-tuned models on a single GPU」するフレームワークであり、ベースモデルとアダプタを分離して扱う。ベースモデルは全アダプタで共有される事前学習済みの大きなモデル、アダプタはリクエスト単位で動的に読み込まれるタスク固有の重みである。対象読者は、顧客ごとに個別のファインチューニングモデルを返す必要があるSaaS、社内で多数の実験モデルを並行評価するML基盤チーム、そして推論コストをモデル数から切り離したい運用担当者だ。モデルごとにプロセスを立てる方式と違い、増えるのはアダプタの重みとその読み込み管理であって、ベースモデルの複製ではない。

アダプタIDをリクエストに載せるという設計

APIの形はこの設計をそのまま反映している。READMEのREST例では、/generate エンドポイントに inputs と parameters を渡し、parameters の中に adapter_id を入れる。adapter_id を省略すればベースモデルそのものへのプロンプトになり、指定すればそのアダプタを適用した応答になる。つまりルーティングはサーバ側の設定ファイルではなく、呼び出し側のペイロードで決まる。アダプタの取得元はHuggingFace Hub、Predibase、任意のファイルシステムの3系統がREADMEに挙げられている。Pythonクライアントでも同じで、client.generate(prompt, max_new_tokens=64, adapter_id=adapter_id) のように引数として渡す。OpenAI互換APIも用意されており、マルチターンのチャットをその形式で投げられる。アダプタをリクエスト時に合成するmerge adaptersの機能も文書化されているが、これはアンサンブルを作る操作であり、通常の推論経路とは別物として扱ったほうがよい。

異種バッチとアダプタ交換スケジューラ

性能を支える仕組みは2層に分かれている。1つはHeterogeneous Continuous Batchingで、異なるアダプタ向けのリクエストを同一バッチに詰め込む。READMEの表現では、同時に存在するアダプタ数が増えてもレイテンシとスループットをほぼ一定に保つとされている。もう1つがAdapter Exchange Schedulingで、GPUとCPUメモリの間でアダプタを非同期に先読み・追い出しし、リクエストのバッチングをスケジュールして系全体のスループットを最適化する。カーネル側はflash-attention、paged attention、SGMVといった事前コンパイル済みCUDAカーネルと、テンソル並列、量子化、トークンストリーミングが挙げられている。ここで押さえるべきは、数千アダプタが同時にGPUメモリへ載るわけではないという点だ。CPU側に待避させ、必要になった時点で転送する。したがって初回リクエストには転送のコストが乗り、ホットなアダプタとコールドなアダプタで応答特性が変わる。この非対称性はドキュメント上も明示的な数値としては与えられていない。

起動はDockerイメージから、ただしGPU世代の制約付き

READMEはカスタムCUDAカーネルのコンパイルを避けるため、プリビルドDockerイメージからの開始を推奨している。前提はNvidia GPU（Ampere世代以降）、CUDA 11.8対応のデバイスドライバ、Linux、Docker。nvidia-container-toolkitを導入したうえで systemctl daemon-reload と systemctl restart docker を実行し、次のように起動する。model=mistralai/Mistral-7B-Instruct-v0.1、volume=$PWD/data を設定し、docker run --gpus all --shm-size 1g -p 8080:80 -v $volume:/data ghcr.io/predibase/lorax:main --model-id $model というコマンドになる。ポートはコンテナ内の80をホストの8080に割り当てている。--shm-size 1g は共有メモリの確保であり、これを絞りすぎるとバッチ処理に影響しうる。ベースモデルはfp16のほか、bitsandbytes、GPT-Q、AWQでの量子化読み込みに対応する。アダプタ側はPEFTとLudwigで学習したLoRAを対象とし、モデル内の任意の線形層を適応させられる。Kubernetes向けのHelmチャート、Prometheusメトリクス、Open Telemetryによる分散トレーシングも用意されている。

向かない場面: アダプタが形式から外れるとき

LoRAXが無力になるのは、アダプタがLoRAでない場合だ。READMEが対応を明言するのはPEFTとLudwigで学習したLoRAアダプタであり、フルファインチューニングした独立モデルや、独自形式の差分重みはこの経路に乗らない。またベースモデル側にも制約があり、サポートアーキテクチャ一覧に載っていないモデルをベースに選ぶことはできない。Llama、CodeLlama、Mistral、Zephyr、Qwenが例として挙がっているが、これは例示であって全リストではない。もう1つの失敗モードはリソース側で、GPUがAmpere世代より前、あるいはCUDA 11.8対応ドライバを満たさない環境では、そもそもプリビルドイメージの前提が崩れる。単一モデルを大量リクエストでさばくだけの用途も、この構成を選ぶ理由が薄い。アダプタ交換のスケジューラとCPU待避の層は、アダプタを複数持つからこそ意味を持つ仕組みであり、アダプタが1つなら管理対象が増えるだけになる。

vLLMとの違いはアダプタを一級市民として扱うかどうか

比較対象として自然なのはvLLMだ。どちらもpaged attentionを採用し、連続バッチングでスループットを稼ぐ点は共通している。違いはアダプタの扱いにある。vLLMは基本的に1プロセス1モデルを軸に設計され、LoRA対応を加えた場合でも、アダプタの先読み・追い出しをスケジューラの中心に据えることはしない。LoRAXはAdapter Exchange Schedulingを独立した機構として持ち、GPUとCPUの間のアダプタ移動をリクエストバッチングと同時に最適化する。この差は、アダプタ数が数十を超えてメモリに載り切らなくなった時点で効いてくる。逆に、ベースモデルを1つだけ配る構成では、vLLMのほうが構成要素が少なく、バージョン間の互換性も追いやすい。どちらを選ぶかは、モデル数を増やす予定があるかどうかで決まる。

Apache-2.0とメンテナンスの見取り図

ライセンスはApache-2.0で、READMEは商用利用が自由であることを明記している。ただしこれはLoRAX自体のライセンスであり、読み込むベースモデルとアダプタにはそれぞれ別のライセンスが適用される。Llama系のベースモデルには独自の利用条件があり、アダプタも公開者が設定した条件に従う。配布物全体の条件は、LoRAXのライセンスだけでは決まらない。更新の面では、リポジトリはアーカイブされておらず、2026年5月時点で最終プッシュが記録されている。リリースはlorax-0.4.0が2025年1月、v0.12.1が2024年11月、v0.12.0が2024年11月で、v0.12.0ではマルチLoRAのプレフィックスキャッシュ、fp8 KVキャッシュ、Mllama、function callingが追加されたとリリースノートにある。バージョン番号が0.4.0と0.12.xで並行している点は、パッケージ名とタグ付けの体系が一致していないことを示しており、導入時はタグではなくリリースノートの中身で判断したほうがよい。

編集部の結論

多数の顧客別・タスク別LoRAアダプタを1つのベースモデル上で配りたいチームに向く。逆に、単一モデルを高スループットで回すだけの用途や、アダプタの学習側を自分で管理したくない場合には、ベースモデルを直接servingする構成のほうが単純である。導入前に確認すべきは、対象ベースモデルがサポートアーキテクチャ一覧に載っているか、アダプタがPEFTまたはLudwig形式で書き出されているか、そしてGPUがAmpere世代以降でCUDA 11.8対応ドライバを備えているかの3点である。

公式情報源

1. License: Apache-2.0
2. predibase/lorax on GitHub
3. Project website
4. README
5. Releases