Merged LoRA

Merged LoRA folds an eligible parent's adapter contribution into a derived backbone and freezes that backbone. A new LoRA adapter then trains on top of it. The original base and parent artifacts remain immutable; the derived model has its own retained materialization identity.

Choose it when the qualified next stage should begin from that materialized parent behavior with fresh factors. It is not an in-place overwrite of the original Model or a general command for merging arbitrary adapters.

The computation

For one projection, first construct a derived weight:

Freeze that result and train a new adapter:

The parent A/B pair is not an active trainable branch in the new stage. Its contribution is already represented by W_derived. Adding it again would apply the same delta twice.

Precision and lineage matter

The current merge algorithm adds each accepted delta in FP32 and casts the result to BF16 after each stage:

Sequential materialization retains the original model inventory, ordered delta inventories, hashes and algorithm identity. Each stage delta must appear exactly once. Because rounding occurs per stage, a different grouping or order is not silently treated as the same backbone.

In ideal arithmetic, an untrained fresh child with zero contribution starts at the parent effective weight. Actual materialization still needs the retained precision, parity and fresh-reload checks. A mathematical equality alone does not prove equivalent outputs from a deployed runtime.

Current training requirements

The accepted materialization profile pins the original dense BF16 model and its inventory. Quantized models, arbitrary backbones and unqualified GPU images are not implied. Read-only evaluation may have its own signed-stack folding path; that does not expand the narrower training-parent requirements above.

Example: rank-8 parent to rank-8 fresh adapter

Suppose a compatible parent has one rank-8 factor slice. Merged materializes that delta into its derived backbone, then starts a new rank-8 adapter with a fresh optimizer and the required zero-KL recipe. The inherited contribution is frozen in the backbone; the new factors learn the next residual.

A rank-16 request against that rank-8 parent fails the current same-rank check. A two-block rank-8-plus-rank-8 Stacked parent is not the required single slice, even though its total enabled rank is 16. These are illustrative compatibility examples, not executed runs or quality claims.

Zero KL means this recipe does not apply that explicit KL penalty. It does not mean unlimited authority, guaranteed retention or automatic candidate acceptance. Use independent target and regression evaluation before deciding on the result.

Configure and review

1. Choose New experiment → Merged LoRA and select the exact compatible saved GRPO-trained parent.
2. Review the derived-backbone lineage, supported rank, zero-KL/reference rule, admitted reward-training tasks and independent evaluation plan.
3. Inspect the prepared materialization, runtime and component spending limits, then explicitly start the retained preparation.
4. Inspect actual merge/parity/reload evidence and new-stage optimizer/checkpoint evidence separately from answer-quality results.
5. Accept or save a qualified candidate, then separately authorize its compatible serving deployment. Keeping a prior immutable version supplies a decision boundary; materialization alone does not switch serving.

Compatible continual learning can retain Merged as its GRPO strategy. Selecting the mode does not create a schedule, approve data or authorize activation. Interrupted-job recovery remains separate from beginning another cross-job stage.

Compare Shared LoRA for updating the original factors and Stacked LoRA for adding a child beside frozen parent factors. The GRPO guide contains the common preparation and Start contract.