"Question"	"Answer"	"Tag"
"State the LoRA decomposition equation and what each term means."	"W = W0 + BA. W0 is the FROZEN pretrained weight matrix (d × k). B is a trainable matrix (d × r) initialized to ZERO. A is a trainable matrix (r × k) initialized to random Gaussian. Their product BA is the low-rank update ΔW added to W0. r is the rank — the number of directions of change."	c3::ft08::recall
"Why is B initialized to zero in LoRA, and what does this guarantee?"	"B starts at zero so BA = 0 at step 0 — the adapter contributes nothing and the model behaves EXACTLY like the base. This makes LoRA a residual steer: it begins as the identity (the base, unchanged) and learns a perturbation on top. You cannot make the model worse than the base by accident in the first few steps — a guarantee full fine-tuning does NOT have."	c3::ft08::recall
"What is the trainable-parameter arithmetic for a LoRA layer (d × k weight at rank r)?"	"LoRA adds (d·r + r·k) = r·(d + k) trainable parameters per targeted layer. For a 4096×4096 layer at r=8: 8·(4096+4096) = 65,536 params, versus 16.7M for the full ΔW — a 256× reduction. Across all layers of a 7B model at r=16, all-linear: ~40M trainable / 7B total ≈ 0.5–1%."	c3::ft08::recall
"Name the four knobs of a LoRA config and their modern defaults."	"(1) Rank r — default 16 (8 for narrow tasks, 64 for complex multi-task). (2) Alpha α — convention α ≈ 2×r (so r=16 → α=32). (3) Target modules — modern default ALL attention + MLP: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj (NOT attention-only). (4) Dropout — default 0.05 (0.1 for small data/high rank, 0 for very large data)."	c3::ft08::recall
"What is the alpha convention and why does it exist?"	"α ≈ 2×r (e.g., r=8→α=16, r=16→α=32). The adapter contribution is scaled by α/r before being added to W0. The convention keeps the effective magnitude of the adapter stable across rank choices, so you do NOT have to retune the learning rate when you change r. Too-low α → base dominates (underfit); too-high α → adapter overpowers base (forgetting)."	c3::ft08::recall
"What is the modern default for LoRA target modules, and why is it NOT attention-only?"	"Modern default: ALL linear projections — q_proj, k_proj, v_proj, o_proj (attention) PLUS gate_proj, up_proj, down_proj (MLP). Attention-only (q,v_proj) was the 2021 original default — cheap but weaker. All-linear is stronger because behavior steering touches the MLP feature pathway too, not just attention. Empirically matches/beats attention-only at comparable param budgets. The single biggest quality lever in the config."	c3::ft08::recall
"State the intrinsic dimension hypothesis (Aghajanyan) and how it justifies LoRA."	"Aghajanyan et al. 2020 (arXiv:2007.07784): the USEFUL changes during fine-tuning live in a low-rank subspace of the full parameter space — the effective dimension of the optimization is tiny compared to the nominal parameter count. This is the theoretical license for LoRA: you can capture the needed changes with adapters under 1% of params because the task is intrinsically low-rank. It is also the FT00 thesis made rigorous — steering is low-rank; knowledge injection would be high-rank."	c3::ft08::recall
"Name QLoRA's three innovations (Dettmers et al. 2023)."	"(1) NF4 (NormalFloat 4-bit) quantization — quantile bins matched to the normal distribution; information-theoretically optimal for Gaussian weights. (2) Double quantization — quantize the quantization CONSTANTS themselves to 8-bit, saving ~0.37 bits/param. (3) Paged optimizers — use NVIDIA Unified Memory to page optimizer states to CPU, avoiding OOM spikes during checkpointing. All three compose; drop any one and the method degrades."	c3::ft08::recall
"What is NF4 and why is it information-theoretically optimal for neural weights?"	"NF4 (NormalFloat 4-bit) chooses its 16 quantile bins to match the NORMAL distribution rather than using uniform bins. Neural-network weights are approximately Gaussian — most cluster near zero, few in tails. NF4 places more bins where the weights actually are (near zero) and fewer in the sparse tails, minimizing expected quantization error for that distribution. Result: 4-bit storage with quality closer to 6–8 bit uniform quantization."	c3::ft08::recall
"What does double quantization save, and why does it matter on a 24GB card?"	"Double quantization quantizes the FP32 scaling constants (one per ~64-weight block) to 8-bit, saving ~0.37 bits/param of overhead — ~0.3 GB on a 7B model. Small in absolute terms, but on a 24GB card fighting for every gigabyte it is the difference between fitting and OOMing at the margin. No quality cost, always on."	c3::ft08::recall
"What problem do paged optimizers solve in QLoRA?"	"They solve the OOM SPIKE during checkpointing, not steady-state memory. When the optimizer pages its state to CPU/disk, there is a momentary memory spike exceeding steady-state by several GB — on a card sized to steady-state, this crashes the job partway through. Paged optimizers use NVIDIA Unified Memory to transparently page optimizer states to CPU under pressure and back in when needed, absorbing the spikes that would otherwise OOM the run."	c3::ft08::recall
"Derive the ~10–14 GB footprint for a 7B QLoRA at 4K context from the FT01 consumers."	"4-bit base (NF4): 0.5 B/param × 7B ≈ 3.5 GB. Double-quantized constants: ~0.16 GB. LoRA adapter (r=16, all-linear, ~40M params × ~10 bytes grad+AdamW): ~0.4 GB. Activations (4K ctx, batch 1, grad checkpointing, FlashAttn): ~4–7 GB. CUDA context + fragmentation: ~1–2 GB. Total ≈ 10–14 GB. This is why it fits a 24GB RTX 4090 — the 10× spread vs full FT (~100–160 GB)."	c3::ft08::application
"State the full 5-step QLoRA workflow."	"(1) Load base in 4-bit (BitsAndBytesConfig: nf4, double_quant, bf16 compute). (2) prepare_model_for_kbit_training(model) — the forgotten step. (3) Attach adapters: get_peft_model(model, lora_config); print_trainable_parameters() → expect <1%. (4) Train adapters only (SFTTrainer or manual loop; 4-bit base never moves). (5) Merge (merge_and_unload) or save adapter separately."	c3::ft08::recall
"What does prepare_model_for_kbit_training do, and what happens if you forget it?"	"It enables gradient checkpointing on the 4-bit base and prepares the frozen quantized model for adapter attachment (input embedding layer handling, etc.). If you forget it, you attach LoRA to an unprepared base: gradient checkpointing is off, training is unstable or slow, and you may hit OOM you would otherwise avoid. One line, easy to forget, always include it before get_peft_model."	c3::ft08::recall
"Contrast merge_and_unload() vs keeping the adapter separate — when do you use each?"	"merge_and_unload() bakes the adapter into the base (W0 := W0 + (α/r)BA), producing ONE self-contained model with no adapter runtime overhead — best for DEPLOYMENT (one artifact, fast inference, can re-quantize to GGUF/AWQ). Keeping the adapter separate (adapter_model.safetensors, <100 MB; load via PeftModel.from_pretrained) is best for HOT-SWAPPING — one base, many adapters, swap at runtime like loading a config. Default deploy = merge; default experimentation/multi-tenant = keep separate."	c3::ft08::application
"Why does the FT00 thesis ('fine-tuning steers behavior; it does not teach knowledge') imply that LoRA at <1% params can match full fine-tuning on steering tasks?"	"Because steering is a LOW-RANK operation. If fine-tuning were injecting large amounts of new knowledge, you would need to move large amounts of parameters (high rank or full FT). But steering is redirecting probability mass the base already has — that redirection lives in a low-rank subspace (Aghajanyan intrinsic dimension). A tiny adapter (B·A) captures it. Had the task required full-FT-scale updates, that would be evidence you are trying to TEACH, not steer — and should use RAG or continued pretraining instead."	c3::ft08::analysis
"A colleague sets r=128 'to be safe.' Diagnose the two problems this creates."	"(1) Overfitting — a 500-sample steering dataset cannot usefully fill 128 directions of change; the adapter memorizes noise. (2) Memory — at r=128 you approach full-FT VRAM for LoRA's structural limitations. Shuttleworth et al. 2024 showed LoRA and full FT find DIFFERENT (not approximate) solutions, so paying full-FT cost for LoRA's geometry is the worst of both worlds. Fix: start at r=16, escalate only with evidence (measured underfit on a held-out set)."	c3::ft08::analysis
"A colleague uses target_modules=['q_proj','v_proj'] because 'the original LoRA paper did.' What quality issue will they hit and what is the fix?"	"Underfit / weaker steer on modern bases. Attention-only targeting (the 2021 default) leaves the MLP feature pathway untouched, but behavior steering (persona, format) lives partly in the MLP layers. They will need a much higher rank to compensate, approaching all-linear param count for worse quality. Fix: use the modern all-linear default (q,k,v,o_proj + gate,up,down_proj) at moderate rank. This is the single biggest quality lever in the config."	c3::ft08::analysis
"A QLoRA run fits in steady-state VRAM but OOMs partway through, always around a checkpoint. Diagnose and fix."	"This is the OOM SPIKE problem that paged optimizers exist to solve. During checkpointing the optimizer pages state to CPU/disk, causing a momentary memory spike exceeding steady-state. Fix: use optim='paged_adamw_8bit' (bitsandbytes) — it uses NVIDIA Unified Memory to transparently page optimizer states under pressure, absorbing the spikes. This is QLoRA innovation 3 and is why QLoRA runs reliably on a card that barely fits steady-state."	c3::ft08::application
"Write a production-quality LoraConfig for a Qwen2.5-7B SFT (r=16, all-linear)."	"LoraConfig(r=16, lora_alpha=32, target_modules=['q_proj','k_proj','v_proj','o_proj','gate_proj','up_proj','down_proj'], lora_dropout=0.05, bias='none', task_type='CAUSAL_LM'). Alpha=2×r (convention). All 7 projection modules (modern default). Dropout 0.05 (standard SFT). This yields ~0.5–1% trainable params — the LoRA promise."	c3::ft08::application
"A QLoRA SFT loss explodes to NaN. Per FT07/FT08, what is the most likely root cause and how do you confirm it?"	"It is almost certainly an FT07 tokenizer/template bug, NOT a QLoRA bug. The most common cause is EOS mishandling or cross-family template misuse (e.g., a Llama template on a Qwen base). Confirm with the FT07 inspection loop: take one training example, apply_chat_template(tokenize=True, return_assistant_tokens_mask=True), decode it, and read it — verify role tokens match the family, EOS is appended and equals tokenizer.eos_token_id, and the assistant mask is correct. QLoRA does not cause NaN; mis-tokenized data does."	c3::ft08::analysis
"Shuttleworth et al. 2024 found LoRA and full-FT produce 'structurally different' weight matrices. What does this imply about the r=128 'more rank = closer to full FT' intuition?"	"The intuition is WRONG. LoRA does not approximate full FT — it finds a DIFFERENT low-rank solution via different geometry, reaching similar behavior through different weights. Raising r to 128 does NOT make LoRA converge toward full FT's solution; it just gives you a poorly-regularized, high-memory LoRA. If you genuinely need full-FT-style updates, DO full FT (Module FT10). Do not pay full-FT cost for LoRA's inherently different geometry."	c3::ft08::analysis
"After QLoRA training you call merge_and_unload() on the 4-bit base. Why is the merged model LARGER than the 4-bit base, and what do you do for production deployment?"	"merge_and_unload() computes W0 := W0 + (α/r)BA and writes the result. On a 4-bit base this DEQUANTIZES the merge — the merged weights are stored at full precision (FP16/BF16), so the model is larger than the 4-bit base you trained on. For production: RE-QUANTIZE the merged model afterward — to GGUF for Ollama (FT19) or AWQ for vLLM (FT20). The merge bakes in the steer; the re-quantize compresses for deployment. This two-step (merge then re-quantize) is the standard Layer 2 → Layer 4 path."	c3::ft08::analysis
"Match the symptom to the LoRA misconfiguration: 'loss plateaus high, the style never quite lands in the output.'"	"Rank TOO LOW (underfit). The adapter literally cannot express the required change at the chosen rank — there are not enough directions of change. Fix: raise r (e.g., 8 → 16 or 32) and compare. This is the underfit arm of the rank anti-pattern (the overfit arm being r=128 on small data)."	c3::ft08::application
"Why can a LoRA adapter at r=16, all-linear, often match full fine-tuning on a style/persona SFT task, despite <1% of the params?"	"Because the task is steering, not knowledge injection (FT00). Style and persona shifts are LOW-RANK: the base already possesses the vocabulary and capability from pretraining; fine-tuning only redirects probability mass to use it reliably and in the target format. The intrinsic dimension hypothesis (Aghajanyan) predicts the useful change lives in a small subspace, which B·A at r=16 captures. Full FT's extra capacity goes unused on such tasks — you pay 10× the VRAM for no observable quality gain. This is the entire economic argument for PEFT."	c3::ft08::analysis