Stacked LoRA

Stacked LoRA keeps the inherited adapter contribution fixed and trains a new child contribution alongside it. The base remains frozen. Parent and child outputs add at the same selected projection; the child does not receive the parent's output as its input.

Choose it when you want the new stage's parameter updates confined to a new factor block. Frozen parent parameters do not guarantee preserved behavior: the new child still changes the effective projection seen by the model.

Add the contributions

For a base projection and one inherited adapter:

A_p, B_p and W0 stay fixed. Only the new A_c and B_c may change. For several inherited blocks, the parent term is their retained sum.

With the common accepted scale, concatenate the factor slices:

This is an additive factorization, not B_c A_c B_p A_p. No branch shares a trainable A matrix with another branch.

Capacity is part of compatibility

The current managed policy runtime uses a fixed rank-32 residual envelope. Inherited enabled rank plus new child rank must fit:

Passing this arithmetic does not qualify the rank, parent or runtime. The exact worker image must support the requested logical child rank and complete profile. Unused envelope positions remain reserved/zeroed rather than permission to train arbitrary extra factors.

For one projection, a rank-r_child child has r_child × (d_in + d_out) factor degrees of freedom. The physical runtime uses its fixed envelope, so that expression is not a claim about allocated GPU memory, serialized tensor sizes or measured speed.

How a stage begins

The runtime preserves the exact inherited slices, initializes the new child A and starts its B slice at zero. The initial child contribution is therefore zero even though A is initialized. New training can then develop a residual update from fresh GRPO attempts and rewards.

Gradient masks restrict updates to the active child slices. Retained manifests record block identities, offsets, ranks and the trainable block. Recovery checks that inherited factors still match their authorized immutable values.

This describes implementation behavior, not a guarantee of bit-for-bit parity on every GPU or a measured improvement. Inspect the admitted runtime's actual reload and equivalence evidence.

Configure and inspect

1. Choose New experiment → Stacked LoRA.
2. Select the exact compatible saved GRPO-trained parent. Its whole inherited contribution counts toward occupied envelope capacity.
3. Select the supported child rank, admitted training tasks, executable reward binding and independent holdout; review the exact parent/runtime and spend.
4. Explicitly start the reviewed preparation. A new cross-job stage has fresh optimizer state; recovery of an interrupted stage restores that stage instead.
5. Inspect the resulting block layout, frozen-parent evidence, optimizer updates, checkpoint publication and held-out comparison before accepting a candidate.

This path is not general SFT continuation or arbitrary adapter stacking. It preserves exact base/tokenizer/template, runtime and recipe compatibility. At capacity, another child cannot simply be appended. Do not assume a filled stack can be converted into a Shared or Merged training parent: those modes have their own single-slice and same-rank requirements. A derived-backbone parent is currently restricted to the Merged training path.

Compatible continual learning can retain this GRPO continuation choice, but still needs its saved admission, schedule, evaluation, budget and candidate rules. Serving activation is separate.

Compare Shared LoRA, which updates existing factors, and Merged LoRA, which materializes an eligible delta into a derived backbone. Use the GRPO preparation contract for the common reviewed execution flow.