{ "module": "FTDD-03 — Unsloth", "course": "3 — LLM Fine-Tuning Masterclass", "version": "1.0.0", "duration_minutes": 25, "total_questions": 10, "bloom_distribution": { "target": "40% recall / 30% application / 30% analysis", "actual": { "recall": 4, "application": 3, "analysis": 3 } }, "passing_score_percent": 70, "questions": [ { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "What are Unsloth's headline performance numbers, and what is the critical caveat about them?", "options": [ "~2x speed, ~60% less memory, and a new fine-tuning algorithm that produces better adapters.", "~2x training speed, ~60% less VRAM, with ZERO algorithmic changes — same fine-tuning, faster and cheaper, not different.", "~5x speed, ~90% less memory, using a proprietary closed-source kernel.", "~10x speed, no memory change, via a new optimizer." ], "answer_index": 1, "rationale": "Unsloth delivers ~2x training speed and ~60% less VRAM, with ZERO algorithmic changes. The third number is the most important: Unsloth does not change the fine-tuning algorithm (same LoRA/QLoRA, same adapter). It changes how fast and how cheaply the same fine-tuning runs — a drop-in acceleration layer, not a new method." }, { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "Name Unsloth's three engineering decisions that produce the performance win.", "options": [ "A new optimizer, a new loss function, and gradient checkpointing.", "Hand-written Triton kernels (forward/backward), manual autograd, and 4-bit optimizers.", "Mixed precision, data parallelism, and pipeline parallelism.", "Larger batch sizes, shorter sequences, and CPU offloading." ], "answer_index": 1, "rationale": "The three decisions: (1) HAND-WRITTEN TRITON KERNELS replacing PyTorch's generic forward/backward; (2) MANUAL AUTOGRAD computing gradients by hand for custom kernels, bypassing graph overhead; (3) 4-BIT OPTIMIZERS storing optimizer state at 4-bit (8x memory reduction). None is a new algorithm — all are implementation-level engineering wins." }, { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What is Unsloth's platform focus, and what should an Apple Silicon user do?", "options": [ "Unsloth is cross-platform; it works equally on CUDA, Metal, and ROCm.", "Unsloth is CUDA-focused (NVIDIA). Apple Silicon users should use MLX (FT20) instead — Unsloth's hand-written Triton kernels target NVIDIA and don't apply on M-series Macs.", "Unsloth is Metal-focused (Apple Silicon); NVIDIA users should use CUDA directly.", "Unsloth is CPU-only; GPU users should use TRL." ], "answer_index": 1, "rationale": "Unsloth is CUDA-focused — its hand-written Triton kernels target NVIDIA GPUs. On Apple Silicon (M-series Mac), the kernels don't apply. Apple Silicon users should use MLX (Apple's framework for Metal/unified-memory, covered in FT20). This is a deliberate scope boundary, not a defect: NVIDIA dominates the ecosystem, and the kernels are where the performance lives." }, { "id": "Q04", "bloom": "recall", "type": "multiple_choice", "prompt": "What are Dynamic 4.0 GGUF quants, and how do they differ from uniform quantization?", "options": [ "Dynamic 4.0 applies 4-bit precision to every layer uniformly, same as standard quantization.", "Dynamic 4.0 is Unsloth's intelligent PER-LAYER quantization — it analyzes each layer's sensitivity and assigns more bits to sensitive layers, fewer to robust ones, beating uniform quants at the same average size.", "Dynamic 4.0 is a training technique, not a quantization method.", "Dynamic 4.0 only works on Apple Silicon." ], "answer_index": 1, "rationale": "Dynamic 4.0 = intelligent per-layer GGUF quantization. Uniform quantization applies the same precision (e.g., 4-bit) to every layer, over-quantizing sensitive layers and under-quantizing robust ones. Dynamic 4.0 analyzes per-layer sensitivity: sensitive layers (attention, output projection) get more bits; robust layers (some MLPs) get fewer — same average bit-size, better quality. It beats uniform quants at the same footprint." }, { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "You have a single NVIDIA RTX 4090 and want to fine-tune a 7B model and export it to GGUF for Ollama. Which framework should you choose, and why?", "options": [ "Axolotl, because it supports multi-GPU scaling.", "Unsloth — it is the single-GPU optimizer (~2x speed, ~60% less memory) and its Dynamic 4.0 GGUF export gives you clean per-layer-quantized output for Ollama.", "TRL, because you need maximum control over the training loop.", "MLX, because it is the recommended framework for GGUF export." ], "answer_index": 1, "rationale": "For a single NVIDIA GPU with a goal of speed/memory optimization AND GGUF export, Unsloth is the right choice: ~2x speed and ~60% less memory via its hand-written kernels, plus Dynamic 4.0 GGUF quants for intelligent per-layer export to Ollama. Axolotl is for multi-GPU (overkill here); TRL is for maximum control (not the goal); MLX is for Apple Silicon, not CUDA." }, { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "You have a machine with 4 NVIDIA GPUs and need to fine-tune a large model for production. Which framework, and why not Unsloth?", "options": [ "Unsloth — its speed optimizations scale across multiple GPUs automatically.", "Axolotl (or TRL with Accelerate) — they support multi-GPU. Unsloth is single-GPU focused; choosing it would leave 3 GPUs idle, wasting compute.", "MLX — it is the only framework that supports 4 GPUs.", "SWIFT — it is the only multi-GPU framework." ], "answer_index": 1, "rationale": "For multi-GPU, choose Axolotl (config-driven, multi-GPU native) or TRL (with Accelerate). Unsloth is single-GPU focused — its optimizations target ONE GPU's speed and memory. With 4 GPUs, choosing Unsloth leaves 3 GPUs idle, wasting compute. This is the 'picking Unsloth for a multi-GPU job' anti-pattern: match the tool to the hardware." }, { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "A student runs a QLoRA fine-tune with Unsloth and gets a better-performing model than their previous TRL run. They conclude 'Unsloth produces better adapters.' What is the error in this conclusion?", "options": [ "There is no error — Unsloth's kernels genuinely produce better adapters.", "Unsloth does not change the fine-tuning algorithm — it produces the SAME kind of adapter as TRL, just faster. If the result is better, the cause is the data or hyperparameters (the actual steering wheel), not the kernel. The student is misattributing the improvement.", "The error is that TRL cannot do QLoRA.", "The error is that Unsloth only works on Apple Silicon." ], "answer_index": 1, "rationale": "The 'assuming the speedup changes the result' anti-pattern. Unsloth is faster and cheaper, NOT different — same LoRA/QLoRA algorithm produces the same kind of adapter. If the new run is better, the cause is the data or hyperparameters (the steering wheel, per FT00), not Unsloth's kernels. The student has misattributed a data/hyperparameter improvement to the optimizer. Unsloth makes the SAME model faster; it does not make a better model." }, { "id": "Q08", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why are Unsloth's performance gains described as 'engineering wins, not algorithmic changes,' and why does this distinction matter for someone learning fine-tuning?", "options": [ "Because engineering wins are always superior to algorithmic changes.", "Because Unsloth does not change the fine-tuning ALGORITHM (same LoRA/QLoRA, same math, same resulting adapter) — it changes the IMPLEMENTATION (kernels, autograd, optimizer precision). This matters because the conceptual content of the course (steering vs knowledge, LoRA, DPO, GRPO) is unchanged; Unsloth is a drop-in acceleration layer, so you don't have to learn a new method to use it.", "Because algorithmic changes would void the Apache-2.0 license.", "Because engineering wins are easier to publish than algorithmic changes." ], "answer_index": 1, "rationale": "The distinction is load-bearing. Unsloth's gains (Triton kernels, manual autograd, 4-bit optimizers) are all implementation-level — they change HOW the math runs (faster, less memory), not WHAT the math is (the fine-tuning algorithm is unchanged). This matters pedagogically: a learner does not need to learn a new fine-tuning method to use Unsloth. The course's conceptual content (FT00 steering thesis, FT08 LoRA, FT13 DPO, FT14 GRPO) applies identically whether you run through Unsloth or TRL. Unsloth just makes it runnable on cheaper hardware." }, { "id": "Q09", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the course frame Unsloth's democratization of fine-tuning as 'pedagogical, not just economic'? What does the ability to run many experiments enable that a single experiment cannot?", "options": [ "Because cheaper GPUs are inherently better for education.", "Because the FT00 thesis (fine-tuning steers behavior, not knowledge) is learned by FEEL — by running many experiments and observing the pattern repeatedly on one's own hardware. A student who can run a dozen experiments/day internalizes steering-vs-knowledge empirically; one who can afford a single experiment/day learns it from a textbook. Unsloth's economic win (cheaper GPU) enables the pedagogical win (more iterations = deeper intuition).", "Because running many experiments produces a better final model.", "Because the course requires Unsloth for grading." ], "answer_index": 1, "rationale": "The FT00 thesis is best learned empirically — by observing, repeatedly, that fine-tuning changes behavior without changing knowledge. That requires many experiments. Unsloth's ~2x speed and ~60% memory reduction lets a student run a dozen experiments/day on a $1,500 GPU instead of one experiment/day on expensive hardware. The economic win (cheaper, faster iteration) directly enables the pedagogical win (empirical intuition for the steering thesis). This is why Unsloth matters to a course built on students RUNNING experiments, not just reading about them." }, { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "How does Dynamic 4.0 GGUF quantization extend Unsloth's value across the FT00 steering stack, and what does 'per-layer sensitivity analysis' actually do?", "options": [ "Dynamic 4.0 only affects Layer 1 (the base) and has no connection to the export step.", "Unsloth optimizes Layers 2-3 (adapter + steer — training). Dynamic 4.0 extends the optimization to Layer 4 (the export). 'Per-layer sensitivity analysis' means: the model measures how much each layer degrades when quantized, then assigns MORE bits to sensitive layers (attention, output projection — which degrade fast) and FEWER bits to robust layers (some MLPs). Same average file size as uniform quantization, but better quality — more quality per byte for GGUF/Ollama/edge deployment.", "Dynamic 4.0 replaces the need for LoRA entirely.", "Per-layer sensitivity analysis means randomly assigning bit-widths to each layer." ], "answer_index": 1, "rationale": "Dynamic 4.0 extends Unsloth's optimization from training (Layers 2-3) into export (Layer 4). Per-layer sensitivity analysis measures each layer's quantization tolerance: sensitive layers (attention, output projection — which degrade quickly when quantized) receive higher precision; robust layers (some MLPs that tolerate aggressive quantization) receive lower precision. The average bit-size matches uniform quantization, but quality is higher because precision is allocated WHERE IT MATTERS. This yields better GGUF files for Ollama/local serving and edge devices — the full single-GPU/local-serving path optimized end-to-end." } ] }