vLLM Multi-LoRAのメモリと信頼境界検証

先に結論

Multi-LoRAの採用判断は、adapter fileの小ささや単発requestの成功だけでは決められません。vLLM v0.26.0、base revision、adapter revision、rank、`max_loras`、`max_lora_rank`、`max_cpu_loras`、request混在率を固定し、base-onlyを基準にVRAM、TTFT、throughput、error、task品質を同じrunへ結び付けます。動的load APIとremote resolverは性能機能ではなくartifactを実行経路へ入れる管理面です。公開trafficから切り離し、完全にtrustedな境界でだけ評価します。

確認日時: 2026年8月13日（Asia/Tokyo）
対象version: vLLM v0.26.0、commit 568afb3。LoRAのparameterとsecurity警告は2026年8月13日時点のstable／latest公式文書を照合。
検証区分: 公式releaseとdocumentationに基づく机上調査・実験計画です。model推論、load test、benchmarkは実行しておらず、速度、memory、品質の実測値や推奨閾値は示しません。
適用外: 非対応modelへのLoRA適用、base revisionが異なるadapter、layout未確認のMoE LoRA、untrusted clientへ公開した動的更新endpoint、複数nodeへの単純な一般化。

比較単位をartifactとserver設定まで固定する

vLLM公式文書は、LoRAを使える対象をSupportsLoRA実装modelとしています。比較前にbaseとadapterの互換性を確認し、名前だけが同じfamilyの組み合わせを試しません。

区分	固定する値	分離したい影響
runtime	vLLM `0.26.0`／`568afb3`、container digest、PyTorch、CUDA／ROCm、driver、build	kernel・依存関係差
base	repository、revision、dtype、quantization、tokenizer、chat template、最大context	base weight・KV cache差
adapter	repository、revision、file hash、対応base、rank、target modules、license	adapter容量・互換性差
capacity	`max_loras`、`max_lora_rank`、`max_cpu_loras`、GPU memory utilization	予約領域・resident数差
workload	prompt ID、入力／生成token、sampling、同時数、base／adapter比率	request mix差
observation	cold／warm、反復数、timeout、TTFT、total time、VRAM取得間隔	cache・測定窓差

--max-lora-rankは受け入れるadapter rankの上限です。公式文書は、実際の最大rankより不必要に大きくするとmemoryを浪費し、performanceへ影響し得るため、予定するadapterの最大rankへ合わせるよう案内しています。rank 16、32、64を使うなら64から始め、根拠なく256を予約しません。

max_lorasとmax_cpu_lorasもserver-wideな条件です。値の意味だけでmemory量を推定せず、GPUへresidentになるadapter、CPU側の保持と入替、実際のrequest混在を観測します。config値を変えたrunは別seriesにします。

baselineから一変数ずつ増やす

最初にLoRAなしのbase-onlyを測定します。次にstatic loadのadapterを一つだけ加え、rank、adapter数、request mixの順に広げます。

BASE_MODEL_ID="meta-llama/Llama-3.2-3B-Instruct"

# baseline
vllm serve "$BASE_MODEL_ID" \
  --host 127.0.0.1 \
  --port 8000

# static LoRA initial condition
vllm serve "$BASE_MODEL_ID" \
  --host 127.0.0.1 \
  --port 8000 \
  --enable-lora \
  --max-loras 1 \
  --max-lora-rank 64 \
  --max-cpu-loras 2 \
  --lora-modules sql-lora=jeeejeee/llama32-3b-text2sql-spider

この制作環境ではcommandを実行していません。使用するv0.26.0 binaryのvllm serve --helpでoptionの存在と型を保存し、adapter実rankが64以下であることをmetadataから確認してから実行します。64は公式文書の説明例であり、全adapterに対する推奨値ではありません。

比較段階は次のように分けます。

base-only、concurrency 1で正常系とmemory基準を作る。
static LoRA 1件、LoRA requestだけでloadと出力を確認する。
base／LoRAを50／50など固定比率で混ぜ、schedulerとlatencyを観測する。
rankの異なる互換adapterを一つずつ入れ、max_lora_rankを実最大へ合わせる。
max_lorasとadapter種類数を増やし、同一batchに現れる組み合わせを記録する。
GPU／CPUのresidentと入替を確認した後だけ、production相当のarrival patternへ広げる。

同じadapterを別名で重複登録して件数を水増しせず、adapter ID、revision、hashをrun manifestへ結び付けます。

観測値を性能・品質・運用へ分ける

各runはclient側のclockとserver metrics／logを同じrun IDへ保存します。単発の最速値は採用根拠にしません。

観測値	比較方法	採用時に防ぐこと
startup／adapter load時間	process開始からready、adapter認識まで	deploy時間の見落とし
peak／steady VRAM	起動前、ready後、負荷中を同じ間隔で取得	file sizeだけのmemory推定
CPU RAM	static load後と入替時を取得	`max_cpu_loras`増加の見落とし
TTFT／total time	base-onlyと同一prompt、同一concurrencyで比較	queue遅延の隠蔽
request throughput	固定時間窓と固定mixで完了requestを比較	短い回答だけが有利な比較
error／timeout	HTTP status、server error、OOM、load失敗を集計	成功runだけの選別
task品質	adapter用途別の固定testとrubricを通す	起動成功を品質と誤認

sampling、prompt、生成上限を固定しても、baseとadapterで生成token数が変わる場合があります。総時間だけでなく、完了token、task判定、TTFTを併記します。LoRAによる品質差を測るtestと、capacityを測るsynthetic loadを同じscoreへ混ぜません。

base request、adapter A、adapter Bを混ぜる場合は、順序と比率をseed付きで固定します。adapterごとのp50／p95、error、throughputを分け、全体平均だけで少数adapterの遅延を隠さないようにします。

動的loadを別のsecurity testとして扱う

vLLMはVLLM_ALLOW_RUNTIME_LORA_UPDATING=Trueで/v1/load_lora_adapterと/v1/unload_lora_adapterを有効にできます。しかし公式LoRA文書はsecurity riskを明記し、隔離された完全にtrustedな環境でないproduction利用を避けるよう警告しています。公式Security文書も、これらのendpointをuntrusted clientへ公開せず、trusted administratorだけへreverse proxyまたはnetwork controlで制限するよう求めています。

したがってstatic loadの性能testと動的loadのsecurity testを分けます。動的loadを評価する場合でも、最低限次をgateにします。

public inference routeと管理routeをnetwork上で分離する。
adapterのrepository／revision／hash／licenseをallowlist化する。
arbitrary pathや任意remote repositoryをclient入力として渡さない。
load／unload主体、時刻、artifact、結果を監査logへ残す。
同名差し替え、同時load、失敗途中、disk不足、OOM、timeoutを試す。
旧adapterへ戻す手順と、process再起動でstatic manifestを復元する手順を持つ。

remote resolverは未登録model名を契機にartifactを探して取得し得るため、便利さだけで一般公開serverへ入れません。取得元の信頼、cache directoryの権限、network egress、署名／hash、容量上限を管理できない構成は適用外です。

MoE LoRAのlayoutをload成功だけで判定しない

2026年8月13日時点のstable LoRA文書は、2DのMegatron形式と3DのPEFT形式を同じengineで扱う場合、is_3d_lora_weightを明示すると説明しています。同時に、vLLMは申告値からcheckpoint layoutを自動検証せず、誤指定でもload時errorなしに不正な出力を作り得ると警告しています。

MoE adapterはcheckpoint keyを監査し、2D／3D layout、expert数、target module、base側layoutをmanifestへ保存します。load成功、HTTP 200、短い自然文だけでは合格にしません。既知inputに対するtask品質、baseとの差、複数expertを通るtest、NaN／異常logまで確認します。layoutが不明なartifactは検証matrixへ入れません。

採用gateと適用範囲

Multi-LoRAを採用するのは、次をすべて満たす範囲だけです。

baseと全adapterのrevision、hash、license、対応関係を固定できる。
目標request mixで品質gate、error、timeoutの許容条件を満たす。
peak VRAM／RAMがcapacity margin内に収まり、base-onlyのSLOを許容外へ悪化させない。
max_lora_rank、max_loras、max_cpu_lorasの変更理由を説明できる。
adapter追加／削除と旧static manifestへのrollbackを再現できる。
動的loadが必要なら、管理面を完全にtrustedな境界へ閉じられる。

本稿から「Multi-LoRAは常にmemory効率が良い」「rankが低ければ常に速い」「dynamic loadが安全」という順位や保証は導けません。hardware、base architecture、adapter target、request mix、vLLM releaseが変われば再測定します。複数nodeではadapter配布、worker間の一致、失敗時の部分状態が増えるため、単一nodeの結果をそのまま適用しません。

入門記事

初めて試す場合は、vLLMでLoRAをリクエスト別に切り替える入門で、動的loadを使わず、公式例の一adapterをlocalhostへ固定してbase／LoRAのmodel名を切り替える手順から確認してください。

既存記事では、vLLM V1 Engineの基本がruntime全体、vLLM本番API serverが公開時の運用、llama.cpp LoRA scale比較が別runtimeのadapter評価を扱います。本稿はvLLMのrequest単位Multi-LoRAと信頼境界へ範囲を限定しています。

参考資料

vLLM LoRA Adapters公式文書（2026年5月18日更新、2026年8月13日確認）
vLLM Security公式文書（2026年8月13日確認）
vLLM v0.26.0 release（commit 568afb3、2026年7月27日公開）
vLLM LoRA with Quantization公式例（2026年8月13日確認）