Skip to content
tezvyn:

Full fine-tuning or LoRA on a tight compute budget?

Source: huggingface.coMediumHow cards are made

Full fine-tuning or LoRA on a tight compute budget?

This tests budget-constrained adaptation for many tasks. A strong answer picks LoRA: it trains only a small number of extra parameters, cutting compute and storage versus full fine-tuning while matching performance.

What's really being asked

The interviewer is checking whether you understand the practical economics of adapting large models to many tasks. They want to see you compare full fine-tuning against parameter-efficient methods like LoRA under resource constraints. Key concepts include trainable parameter count, storage overhead, compute cost, and performance parity.

The full answer

First, recommend LoRA or another PEFT method given a limited compute budget and multiple tasks. Second, explain that PEFT methods only fine-tune a small number of extra model parameters, which significantly decreases computational and storage costs. Third, note that these methods yield performance comparable to a fully fine-tuned model, making training accessible on consumer hardware. Fourth, contrast this with full fine-tuning, which updates all parameters and requires storing a separate complete copy of weights for each task, causing costs to scale linearly with task count. Fifth, mention inference implications: with LoRA you keep one base model and swap lightweight adapters, whereas full fine-tuning forces you to load entirely separate models or dedicate large memory to each checkpoint.

The mistakes people make

A major red flag is claiming that full fine-tuning always outperforms PEFT and is therefore worth the cost. Another mistake is ignoring storage overhead and only discussing training FLOPs; senior candidates should address the full lifecycle including checkpoint storage and inference serving. A third error is suggesting you can average full fine-tuned weights across tasks without mentioning catastrophic forgetting or interference, which reveals shallow understanding of multi-task dynamics.

What usually comes next

The interviewer may ask how you would serve hundreds of task-specific LoRA adapters efficiently at inference time. They might probe on rank selection and how it affects model capacity versus compute. They could ask when full fine-tuning is actually justified, such as when the pretraining distribution is very different from the target domain or when maximum capacity is needed and budget is not constrained. Another follow-up is adapter merging or composition strategies for multi-task inference.

A concrete example

Imagine you have a large base LLM and twenty downstream tasks. Full fine-tuning would require training and storing twenty complete checkpoints the same size as the base model, which is prohibitively expensive in GPU memory and disk space. Using LoRA, you train only a small number of extra parameters per task, store twenty small adapter checkpoints, and keep a single shared base model. This sharply reduces training cost and makes deployment feasible on consumer hardware, while the PEFT documentation notes that such methods achieve performance comparable to fully fine-tuned models.

Interview question

When adapting a large model to dozens of tasks on a tight compute budget, why is LoRA strongly preferred over full fine-tuning?

  • a.It trains only a small number of extra parameters per task, keeping one shared base model and sharply reducing compute, storage, and serving costs while matching performance.Correct
  • b.Full fine-tuning always outperforms LoRA, so the increased cost is justified when adapting to many tasks.
  • c.LoRA primarily lowers training FLOPs but has the same storage and inference requirements as full fine-tuning because each task still needs its own complete checkpoint.
  • d.You can average full fine-tuned weights across tasks to avoid storing multiple checkpoints, making full fine-tuning as storage-efficient as LoRA.
Why?

LoRA adds lightweight adapters per task around a single frozen base model, drastically cutting compute, storage, and inference costs while maintaining comparable performance. Distractor B is wrong because the card explicitly flags the belief that full fine-tuning always outperforms PEFT as a major red flag, and storing separate full checkpoints for many tasks is prohibitively expensive.

Just read this? Test yourself on what you have been reading.

Read the original → huggingface.co

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on llms — each one lists the topics its interview covers.

See open roles