When a simple LoRA run loses to full fine-tuning, the adapter may not be the limiting factor. Fireworks tested Qwen3.5-9B on three programmatically scored tasks and organized the diagnosis around data coverage, optimization, and adapter capacity.
Coverage moved the placement task first. Increasing the dataset tenfold raised LoRA validity from 34.33% to 68.33%. Tuning the learning rate then brought rank-32 LoRA to 82.67% on a common suite against 83% for FullFT, a 0.33-point difference inside the reported confidence interval. On an untouched final suite, the selected LoRA recipe scored 81.67% versus 80.33% for FullFT.
Capacity mattered on register allocation. Raising rank from 8 to 128 increased valid allocations from 80.5% to 90.5%, while FullFT reached 93%. The stricter exact-decision metric still favored FullFT, showing why validity and imitation quality should be measured separately.
The Nexa virtual-machine task exposed both recipe and curriculum effects. A learning-rate sweep reversed an apparent 31-point FullFT advantage on supported program lengths. Beyond the training horizon, randomizing register starts raised exact trace accuracy to 100% for LoRA and 99.22% for FullFT, demonstrating that rank cannot replace examples of unseen positions.
The comparison changed again when three tasks shared one fixed training budget. Tuned rank-128 LoRA reached 76.60%, while FullFT reached 80.89%. FullFT used 8.6% more active training compute and retained a 4.29-point lead. When per-task exposure was preserved instead of diluted, LoRA led the tested FullFT recipe.
For New Runtime, the decision should be an experiment protocol rather than a method preference. Broaden support, tune each method independently, test adapter rank, declare what the budget holds constant, and then include serving economics: many LoRAs can share one base deployment, while every FullFT variant needs dedicated capacity.