You trained an adapter. It works. Now you have a deployment decision that is easy to make badly, because the two options look similar and lock you into different architectures.
Keep the adapter separate and it applies at inference, adding a small computation to every forward pass and letting you swap it per request. Merge it into the base weights and that overhead disappears entirely — along with any ability to serve a different customisation.
What changed in 2026
- Multi-adapter serving became production-ready. Serving frameworks gained efficient support for many adapters against one base model, which made the separate-adapter path genuinely practical at scale.
- Merging research grew and stayed unpredictable. Techniques for combining several adapters improved without producing reliable guarantees about what survives.
- Per-customer customisation became common. Products offering tenant-specific tuning made multi-adapter serving the norm in that segment.
- The precision pitfall got documented. Merging into a quantised base rather than full precision emerged as a common and avoidable quality loss.
Merged versus separate
|
Merged |
Separate adapter |
| Inference overhead |
None |
Small per-request cost |
| Memory for N customisations |
N full models |
One base plus N small adapters |
| Swap per request |
No |
Yes |
| Deployment artefact |
A full model |
Base plus small files |
| Rollback |
Redeploy the model |
Change which adapter loads |
| Best for |
One customisation, latency-critical |
Many customisations |
The memory row is the one that decides most architectures. Ten merged models means ten copies of a large model in memory. Ten adapters against one base means one large model and ten small files — a difference of an order of magnitude or more, which frequently determines whether the product is economically viable at all.
The rollback row is underrated. A separate adapter makes reverting a bad fine-tune a configuration change. A merged model makes it a deployment.
Merging several adapters
The appealing idea: you trained one adapter for tone and another for a domain, so merge both and get both.
It works unevenly. Adapters trained independently modify overlapping weights toward different objectives, and combining them produces interference — some capability from each survives, some is lost, and which is which is difficult to predict without testing.
Weighted merging, where each adapter contributes proportionally, gives a dial and does not eliminate the problem. Techniques that resolve conflicts more carefully help further and still require empirical validation.
The reliable alternatives: train one adapter on combined data covering both objectives, which avoids the conflict entirely, or keep them separate and route requests to whichever is appropriate.
If you do merge several, evaluate each capability independently afterwards. The failure mode is a merged model that is mediocre at both things rather than obviously broken at one, which no single aggregate score reveals.
The precision trap
A specific and avoidable mistake: if you trained with a quantised base model — as QLoRA does — do not merge the adapter into that quantised copy.
The quantised weights already carry error. Merging into them and then serving compounds it, and the result is measurably worse than it needs to be.
Merge into the full-precision base model, then quantise the merged result if you need a quantised artefact for serving. The order matters, and getting it wrong produces a quality loss that is easy to misattribute to the fine-tuning itself.
Common mistakes
- Merging when you serve several customisations. Multiplies memory for no benefit.
- Merging into a quantised base. Compounds quantisation error unnecessarily.
- Merging several adapters without per-capability evaluation. Interference is quiet.
- Assuming merged and separate are identical. They are mathematically equivalent only when merged at full precision.
- No adapter versioning. Small files are easy to lose track of; treat them as release artefacts.
- Ignoring the base model version. An adapter is tied to the base it trained against; pairing it with a different one produces nonsense.
FAQ
Does merging change the output?
At full precision it should be equivalent. In practice small numerical differences arise, and larger ones if precision is lost during the merge — which is why validating merged output against the unmerged pipeline is worth the ten minutes.
How much overhead does a separate adapter add?
Small per request, and not free. On latency-critical paths with a single customisation, merging is a legitimate optimisation. On anything serving multiple adapters, the overhead is dwarfed by the memory saving.
Can I unmerge?
Not reliably. Keep the base model and the adapter file so you can reproduce or change the merge, rather than treating the merged model as the only artefact.
What about merging full fine-tunes rather than adapters?
Model merging techniques exist for that too, with the same interference caveats and a larger blast radius. The evaluation burden is correspondingly higher.
Where to go next
For the training method that produces these adapters, read QLoRA. For serving them at scale, AI inference autoscaling, and for tracking which artefact is deployed, AI model registry.