LoRA and QLoRA Fine-Tuning Interview Questions, With the Memory Math

Interview answer in one breath: LoRA freezes the base weights and trains two small matrices per layer whose product is added to the frozen weight, QLoRA does the same on top of a 4-bit quantised base model, and both exist because full fine-tuning an 8B model needs about 120 GiB for weights, gradients and optimizer state alone. The rest of the interview is whether you can prove those numbers and say when you'd skip fine-tuning altogether.

These are practice questions I wrote for this site. They aren't leaked and they don't come from any particular company. Each has a strong answer outline, the follow-up an interviewer tends to ask next, and a common wrong answer. The memory figures come from a script I ran on 2026-10-08. For other topics see AI engineer interview questions on RAG, agents and evals and prompt engineering interview questions with answers.

What is LoRA and why does it work?

Strong answer outline

• From the LoRA paper (Hu et al., 2021): freeze the pretrained weight matrix W and learn a low-rank update, so the layer computes W x + (alpha / r) * B A x, where A is r by d_in, B is d_out by r, and r is much smaller than either dimension.
• The hypothesis is that the weight change needed to adapt a model has low intrinsic rank, so a small number of parameters can capture it. The paper's abstract reports, for GPT-3 175B against fine-tuning with Adam, 10,000 times fewer trainable parameters and 3 times less GPU memory, with quality on par or better on the models and tasks they tested.
• Initialisation matters: B starts at zero, so the update is zero at step one and training begins from the base model's behaviour.
• At inference you can merge B A into W, so there's no extra latency, unlike classic adapter layers. Or you can keep adapters separate and swap them per task or per customer on one base model.

Follow-up: Which layers do you apply it to? The original paper adapted attention projections. Common practice since then, and in the QLoRA work, is to adapt all linear layers, because it tends to help quality at modest extra cost. I computed the parameter counts below so you can quote them.

Common wrong answer: "LoRA compresses the model." It doesn't. The base model stays at full size. LoRA reduces the trainable parameters and with them the gradient and optimizer memory.

How much memory do full fine-tuning, LoRA and QLoRA need?

This is the question that separates people who've read about it from people who've run out of memory. Do the arithmetic aloud.

Assumptions I used (state yours in the interview):

• Full fine-tuning with mixed-precision AdamW: 2 bytes for half-precision weights, 2 for gradients, 4 for an fp32 master copy and 8 for Adam's two fp32 moments, so 16 bytes per parameter. This accounting follows the memory analysis in the ZeRO paper (Rajbhandari et al.), from my recollection of its body, which I did not re-open for this post.
• LoRA: the frozen base in bf16 at 2 bytes per parameter, plus adapters trained in fp32 with AdamW (4 + 4 + 8 = 16 bytes per trainable parameter).
• QLoRA (Dettmers et al. 2023): the base in 4-bit NormalFloat with double quantization. Per the paper's scheme, block size 64 with 32-bit constants costs 0.5 bits per parameter, and quantizing those constants to 8 bits (second-level block size 256) brings that to 8/64 + 32/(64*256) = 0.127 bits. So the base costs about 4.127 bits, or 0.516 bytes, per parameter.
• Model shape: the Llama 3 8B config.json (4096 hidden, 32 layers, 32 query heads, 8 KV heads, 14336 intermediate, 128,256 vocabulary), which gives 8.03B parameters by my count. I fetched the config from a public Hugging Face mirror on 2026-10-08.
• Excluded: activations, the CUDA context, fragmentation. Those depend on batch size and sequence length and can be large.

Script output

Base params: 8.03B
Full FT (mixed precision, 16 B/param):          119.7 GiB
Full FT (bf16 + fp32 Adam, no master, 12 B):     89.7 GiB

setup                                 trainable % of base  base GiB adapt GiB total GiB
LoRA r=8  q,v  bf16 base              3,407,872     0.04%      15.0      0.05      15.0
LoRA r=16 q,k,v,o bf16 base          13,631,488     0.17%      15.0      0.20      15.2
LoRA r=16 all linear bf16 base       41,943,040     0.52%      15.0      0.62      15.6
LoRA r=64 all linear bf16 base      167,772,160     2.09%      15.0      2.50      17.5
QLoRA r=16 all linear NF4 base       41,943,040     0.52%       3.9      0.62       4.5
QLoRA r=64 all linear NF4 base      167,772,160     2.09%       3.9      2.50       6.4

70B-class: Full FT 16 B/param: 1043 GiB   LoRA bf16 base: 130 GiB   QLoRA NF4 base: 33.6 GiB

Read it like this: full fine-tuning an 8B model doesn't fit on one 80 GB card (about 74.5 GiB). LoRA fits comfortably, with the base weights dominating. QLoRA cuts the base from 15.0 to 3.9 GiB. For a 70B-class model the base alone is 33.6 GiB in 4-bit, which is consistent with the QLoRA paper's headline claim that a 65B model can be fine-tuned on a single 48 GB GPU, once you add adapters and activations.

Caveats worth saying out loud: real QLoRA setups usually keep some modules (embeddings, the output head) out of 4-bit, so my number is a lower bound. The 12-byte row is only valid if you accept pure-bf16 master weights, which can hurt training stability. And everything here excludes activations, so gradient checkpointing and sequence length can decide whether a run fits.

Follow-up: Why does QLoRA not lose all quality from 4-bit weights? The base weights are dequantised on the fly to bf16 for the forward and backward pass, and gradients flow through them into the adapters, which are kept in higher precision. The paper reports that it preserves full 16-bit fine-tuning task performance on the settings tested. That's a result on their benchmarks, so for a safety-critical task you'd evaluate it yourself.

Common wrong answer: "QLoRA trains the model in 4 bits." The weights are stored in 4 bits and frozen. What gets trained are the higher-precision LoRA adapters.

How do you choose rank and alpha?

Strong answer outline

• r sets the adapter's capacity and parameter count (it scales linearly: r=16 gave 41.9M trainable parameters and r=64 gave 167.8M in my table).
• alpha / r is the scale on the update. Here's the arithmetic for common settings:

r=  8 alpha= 16 -> alpha/r = 2.000
r= 16 alpha= 16 -> alpha/r = 1.000
r= 16 alpha= 32 -> alpha/r = 2.000
r= 64 alpha= 16 -> alpha/r = 0.250
r= 64 alpha=128 -> alpha/r = 2.000

• A common starting heuristic is to set alpha to r or to 2r, then tune the learning rate. I'm giving that as a heuristic, not a rule from the paper. Say that in the interview.
• Choose rank by experiment: start small (8 or 16), raise it if the training loss plateaus high or the eval gap suggests underfitting, and stop when gains flatten. The LoRA paper includes an empirical investigation into rank-deficiency, while the 2024 study below found that full fine-tuning learns updates with rank 10 to 100 times greater than typical LoRA configurations, which is one reason LoRA can lag on hard domain shifts.
• Dropout and weight decay are secondary knobs. Learning rate usually matters more, and the right value differs from full fine-tuning, so sweep it instead of copying a number from a blog post.

Follow-up: Training loss looks great and eval is bad. What do you check? Overfitting on a small dataset (cut epochs, lower rank, add dropout), data leakage between train and eval, formatting or chat-template mismatch between training and inference, and whether the eval measures the thing you changed.

Common wrong answer: "Higher rank is always better." It raises capacity and cost, and it can overfit small datasets.

Does fine-tuning cause forgetting, and does LoRA help?

Strong answer outline

• Yes, fine-tuning can degrade abilities outside the training distribution (catastrophic forgetting). A narrow dataset can make the model worse at general tasks, or lock in your data's style.
• The LoRA Learns Less and Forgets Less paper (Biderman et al., 2024) compared LoRA with full fine-tuning on programming and mathematics, in both instruction-tuning (about 100K prompt-response pairs) and continued-pretraining (20B tokens) regimes. Its abstract reports that LoRA substantially underperformed full fine-tuning in standard low-rank settings, but better preserved base-model performance outside the target domain, and mitigated forgetting more than weight decay or dropout.
• So the honest summary is a trade-off: LoRA learns less and forgets less. It's one study, so test on your own tasks.
• Mitigations: regression eval on general tasks before and after, mix general data into the training set, use smaller learning rates and fewer epochs, keep adapters separate so you can turn them off.

Follow-up: How do you detect forgetting before shipping? Keep a fixed regression suite of tasks you did not train on, run it on base and tuned models, and compare per-task scores. The same discipline as in LLM evaluation frameworks.

Common wrong answer: "LoRA can't forget because the base weights are frozen." The frozen base is unchanged, but the adapter changes the model's outputs, so behaviour outside your domain can still shift.

SFT or DPO: which one, and in what order?

Strong answer outline

• SFT (supervised fine-tuning) trains on input and ideal-output pairs. It teaches format, style, task behaviour. You need good demonstrations.
• DPO (direct preference optimization, Rafailov et al. 2023) trains on preference pairs (a chosen and a rejected response for the same prompt) with a classification-style loss. The paper's pitch is that it reaches the RLHF objective without fitting a separate reward model or doing reinforcement learning with sampling, so it's simpler and more stable.
• The usual order is SFT first, then preference tuning, because DPO adjusts which of the model's own plausible outputs are preferred. It's weak at teaching a behaviour the model never produces.
• Use DPO when you can express quality as "A is better than B" more easily than as a gold answer: tone, refusals, conciseness, ranking by a rubric.
• Data cost: preference pairs need comparisons, and noisy labels hurt. Draw them from your own model's outputs where possible.

Follow-up: What goes wrong with DPO? Verbose or degenerate outputs if preference data correlates with length, drift away from the reference model, and sensitivity to the beta setting that controls how far the policy may move. I'd tune on a validation set and watch length and style statistics.

Common wrong answer: "DPO replaces SFT." In most recipes it follows SFT.

When do you fine-tune, and when do you use RAG or prompting?

Interviewers love this because the right answer is often "neither, yet."

Decision rules (my judgment, not an industry standard; adjust to your constraints):

Process, in order: write the eval set; try prompting with examples; add retrieval if knowledge is the gap; then fine-tune if a measurable gap remains and you have clean data. The site's fine-tuning vs prompting in 2026, fine-tuning vs RAG vs prompting and the fine-tuning vs prompting lesson walk through the trade-offs in more detail.

Hidden costs to mention: dataset creation and cleaning, repeated training runs, evaluation, hosting adapters, and re-training when the base model is deprecated or you want to move to a newer one. Fine-tuned behaviour doesn't transfer to a new base model automatically.

Follow-up: Customer wants the model to "know our product docs." Fine-tune? Probably not. Fine-tuning is unreliable at injecting facts and they will change. Retrieval keeps them current and citable. See how RAG works.

Common wrong answer: "Fine-tune to add knowledge." Fine-tuning is better at behaviour than at memorising facts.

Run the memory script yourself

A trimmed version of what I ran. Replace the shape values with your model's config.json fields (hidden_size, num_hidden_layers, num_attention_heads, num_key_value_heads, intermediate_size, vocab_size).

GIB = 2**30
h, L, qh, kvh, inter, vocab = 4096, 32, 32, 8, 14336, 128256
hd = h // qh
kv_dim = kvh * hd

attn = h * h + 2 * h * kv_dim + h * h
mlp = 3 * h * inter
P = vocab * h * 2 + L * (attn + mlp + 2 * h) + h  # untied embeddings

def lora_params(r):
    shapes = [(h, h), (h, kv_dim), (h, kv_dim), (h, h),
              (h, inter), (h, inter), (inter, h)]  # q k v o gate up down
    return L * sum(r * (i + o) for i, o in shapes)

print("full FT GiB:", P * 16 / GIB)
n = lora_params(16)
print("LoRA r=16 GiB:", (P * 2 + n * 16) / GIB)
print("QLoRA r=16 GiB:", (P * 4.127 / 8 + n * 16) / GIB)

It should print about 119.7, 15.6 and 4.5, matching the table. Then compare against what nvidia-smi says for a real run and note the gap, which is your activation and overhead budget.

How to prepare for this round

• Memorise the three formulas: 16 bytes per parameter for mixed-precision AdamW, 2 for a bf16 base, about 0.5 for NF4. Everything else is multiplication.
• Run a small LoRA job once (a 1B-class model on one GPU is enough) and write down the peak memory you observed against your estimate.
• Have a story about a case where you decided not to fine-tune and what you used instead.
• Be able to cite four sources by name: LoRA, QLoRA, DPO, and the "forgets less" study.
• For the evaluation half of the answer, see prompt testing and evaluation and building evaluation datasets.

What I could not verify

I did not run any training job, so I have no measurements of speed, peak memory on real hardware, or final model quality. Every memory figure is arithmetic under the stated assumptions. The ZeRO 16-bytes accounting is from memory of the paper's body. The "alpha equals r or 2r" heuristic and the DPO failure modes are practitioner folklore that I believe is common, not claims from the cited papers. The Llama 3 8B shape came from a third-party mirror of the config.