179 questions
No questions match those filters.
You switch a fine-tuning run from FP16 to QLoRA so it f...
This is one of the questions in the full AI/ML interview bank. Pro unlocks all 1789 questions; Premium includes the same bank plus the highest daily Practice limit.
See plansThe instinct that 4-bit weights should mean roughly 4x less data moved and therefore faster training conflates two different resources: how much data sits in VRAM, and how fast the GPU can compute with it. QLoRA genuinely shrinks the first — the frozen base model’s weights occupy about a quarter of the footprint they would in FP16 — but it does nothing to speed up the second, because NVIDIA tensor cores don’t execute the matrix multiplications used in training directly on 4-bit integers. Before every GEMM operation, the stored 4-bit weights have to be dequantized back up to BF16 or FP16 in the GPU’s cache, which is an extra, unavoidable kernel launch on top of the actual computation.
So the real shape of the tradeoff is: FP16 training loads larger weights but computes on them immediately, while QLoRA loads smaller weights quickly and then pays a dequantization tax before every forward and backward pass. If your training run wasn’t memory-bandwidth constrained to begin with, that dequantization step is pure added latency with no offsetting benefit — which is exactly the “slightly slower” result you’re seeing.
None of this makes QLoRA a bad choice — it’s the right tool when the actual bottleneck is fitting a 70B model onto hardware that can’t hold it at FP16 at all, and being able to train at all beats training fast. The mistake is expecting a memory optimization to also be a compute optimization; they’re independent axes, and QLoRA was never designed to move the second one.