# Serving LoRA adapters: estimating GPU-server capacity

Estimate LoRA serving through the base model, adapter compatibility, switching, mixed traffic, memory and task-specific quality checks.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/lora-serving-capacity/
Language: en

LoRA enables specialized variants around a base model, but does not mean a server can serve unlimited tasks without additional resources. Owners need the actual workload composition, while funders should distinguish artifact size from a running service's capacity.

## Separate the base model and adapter

[Hugging Face PEFT explains LoRA](https://huggingface.co/docs/peft/main/en/conceptual_guides/lora) through added trainable parameters. [vLLM documents adapter serving](https://docs.vllm.ai/en/stable/features/lora/) with its own settings and restrictions. Record exact base and adapter revisions. Similar names or small files do not establish compatibility.

Check usage conditions for original and derived artifacts separately. An adapter being downloadable does not establish permission for a particular commercial use.

## Define the working traffic

Identify which tasks use adapters, how often they switch and whether they must run simultaneously. These modes have different memory and scheduling requirements. Prepare short pilot tasks with expected output properties, then test the base, each variant separately and mixed traffic.

Record the selected adapter ID without client content so configuration-selection errors can be distinguished from model-quality problems.

## Measure memory and switching

Observe VRAM, host RAM, artifact loading and delays. When adapters reside outside GPU memory, establish the time needed to return them to service. Compare first requests and repeats: one warmed example does not describe a large, irregularly used collection.

Adapter memory is not the entire budget. Base weights, request state and service structures remain, with requirements influenced by context and concurrency. Preserve those conditions alongside the observed capacity.

## Check quality under mixed traffic

A result must satisfy the intended task, not merely finish without an exception. Test answer structure, terminology and required restrictions for each variant. Alternate requests, then add supported concurrency. Record incorrect format and wrong configuration selection as separate errors.

Repeat after changing the base or adapter. Previous capacity cannot automatically transfer to a new revision without compatibility and behavior checks. Also test an unknown or incompatible adapter in a safe configuration. The service should reject it predictably rather than silently substitute the base. Save the expected error and observation method for future expansion tests.

## Justify the resource

The outcome is a bounded configuration: tested base, variants and traffic. Catalog adapter count alone does not measure useful capacity. It is a technical-assessment topic, not an announced ready-made LoRA service catalog.

Continue with [model selection and licensing](/journal/model-licenses/), [KV-cache economics](/journal/kv-cache-economics/) and [model updates](/journal/model-update-canary/).