Shared LoRA

Shared LoRA continues training the parent's existing A and B factors. The base weights remain frozen. It adds no new residual adapter branch and does not mean sharing one A matrix across several independently trained B branches.

Choose it when the next GRPO stage should update the same factorization. This keeps the same rank and starting factorization; it does not guarantee that new training preserves earlier behavior.

The weight update

For one projection, let:

• W0 be the frozen d_out × d_in base weight;
• A_p have shape r × d_in and B_p shape d_out × r;
• s be the accepted LoRA scale, conventionally alpha / r.

The next stage starts from the inherited values:

Both factors can change. If G = dL/dW_effective, their gradients have the form:

The inherited contribution is therefore not a frozen branch. For changes delta_A and delta_B, its effective change is:

That last term helps explain why continuing factors is different from adding a separate child adapter. These equations describe the selected projection; they are not a measured optimizer step or a promise about answer quality.

What stays fixed

Example: a second rank-8 stage

Suppose an eligible parent has one rank-8 factor block. A compatible Shared stage also requests rank 8. It begins at the exact parent A/B values and lets the new reward signal change them. Its active logical rank remains 8.

A request for rank 16 is not the same continuation. The current resolver rejects that mismatch rather than refactorizing the parent approximately. A multi-block Stacked parent is also not automatically eligible for Shared. The current resolver rejects a derived-backbone parent outside the Merged path.

This is a configuration example, not an executed training result. Only exact runtime capability discovery establishes whether the selected rank and parent are available.

Configure and review

1. Open New experiment → Shared LoRA.
2. Select an exact compatible saved GRPO-trained Model checkpoint. A mode card alone supplies no parent, and an SFT artifact is not a supported substitute.
3. Review admitted reward-training tasks, executable graders, independent evaluation and supported GRPO limits.
4. Prepare the run and inspect the exact parent Job, checkpoint, artifact hash, factor identity, rank, reference rule and spending before explicitly starting.

The service checks base, tokenizer, chat template, engine/topology, recipe compatibility and signed artifact lineage. Current cross-job continuation also preserves the compatible learning-rate setting. A shape-compatible tensor pair alone is not sufficient authority to continue a parent.

Interpret the result

• Inspect actual optimizer updates, factor/checkpoint publication and reload evidence; a completed label alone does not establish a changed model.
• Compare the candidate on separate target and regression tasks. The same factors can change behavior learned in an earlier stage.
• Save or accept the qualified candidate separately from serving activation.
• Compatible continual learning can retain Shared as its future GRPO strategy. Selecting it does not create a schedule, admit examples or authorize automatic serving.

For a frozen inherited contribution with a fresh child, see Stacked LoRA. For a materialized derived backbone, see Merged LoRA. The GRPO guide contains the shared preparation/Start contract. The LoRA architecture comparison explains why a shared-A architecture is a different construction.