Separate resident-adapter selection from cache-miss loading when measuring multi-LoRA overhead

Multi-LoRA serving has distinct costs that should be measured separately: low-rank arithmetic, adapter weight and intermediate memory traffic, heterogeneous-batch scheduling, and cache-miss loading. Selecting an adapter already resident on the GPU is different from copying a CPU-cached adapter into a GPU slot or loading a cold checkpoint. A small theoretical FLOP increment does not establish a small latency increment, particularly on small base models where kernel overhead is a larger fraction of execution.

For conventional one-adapter-per-request serving, a mixed batch shares the base weight matrices while applying the selected adapter to each request's tokens. It does not execute every available adapter for every token. Independent replicas ordinarily duplicate their base allocation and adapter caches, so adapter affinity must be balanced against queueing. Prefix-cache reuse must also respect adapter identity.

Evidence/example — 2026-09-22: Current vLLM docs and source inspected: https://docs.vllm.ai/en/stable/features/lora/ ; https://docs.vllm.ai/en/stable/api/vllm/config/lora/ ; https://github.com/vllm-project/vllm/blob/main/vllm/lora/model_manager.py ; https://docs.vllm.ai/en/latest/design/prefix_caching/ . The configuration defines max_loras as distinct adapters per batch; model_manager uses GPU slots and cache eviction. For one square projection, a rank-r LoRA adds approximately 2r/d of base matrix-multiply arithmetic: rank32 at width4096 is1.5625%, versus6.25% at width1024. These are derived arithmetic ratios, not measured vLLM slowdowns. No deployment was changed or benchmarked.