"front"	"back"	"tags"
"What is Unsloth, and what are its headline performance numbers?"	"Unsloth = a single-GPU fine-tuning speed/memory optimizer. Headline numbers: ~2x training speed, ~60% less VRAM, on a single NVIDIA GPU. Achieved via hand-written Triton kernels, manual autograd, and 4-bit optimizers — NOT algorithmic changes."	c3::ftdd03::recall
"Name Unsloth's three engineering decisions and what each does."	"(1) HAND-WRITTEN TRITON KERNELS — replace PyTorch's generic forward/backward kernels with specialized ones. (2) MANUAL AUTOGRAD — compute gradients by hand for custom kernels, bypassing PyTorch's graph/intermediate-tensor overhead. (3) 4-BIT OPTIMIZERS — optimizer state at 4-bit (not 32-bit), 8x memory reduction."	c3::ftdd03::recall
"Why are Unsloth's gains 'engineering wins, not algorithmic changes'?"	"Unsloth does NOT change the fine-tuning algorithm. A QLoRA run through Unsloth produces the SAME kind of adapter (same rank, target modules, dynamics) as one through TRL. The math is identical; Unsloth changes HOW FAST and HOW CHEAPLY the same math runs. It's a drop-in acceleration layer, not a new method."	c3::ftdd03::analysis
"What is the 'consumer-GPU enabler' claim, and why does it matter pedagogically?"	"Unsloth made 7B QLoRA viable on a $1,500 RTX 4090. Before: needed 24GB+ ($2K-$5K tier) or compromises. After: reasonable batch/seq at ~2x speed. Pedagogically, this lets students run a dozen fine-tuning experiments/day on their own hardware — learning steering-vs-knowledge by FEEL rather than from a textbook. It makes the FT00 curriculum executable on a budget."	c3::ftdd03::analysis
"What are Triton kernels, and why does Unsloth write them by hand?"	"Triton is a language for writing GPU kernels at a higher abstraction than CUDA C but with near-CUDA performance. PyTorch/Transformers use GENERAL-PURPOSE kernels (handle many cases reasonably). Unsloth writes SPECIALIZED Triton kernels for the exact ops fine-tuning performs (attention, linear forward/backward), eliminating the overhead generic kernels carry."	c3::ftdd03::application
"What is 'manual autograd' in Unsloth, and what overhead does it eliminate?"	"PyTorch's autograd builds a computation graph dynamically and materializes intermediate tensors — general but wasteful for fine-tuning. Unsloth computes gradients BY HAND for its custom kernels, bypassing graph construction and intermediate-tensor overhead. Gradients are mathematically identical; the path to computing them is shorter."	c3::ftdd03::application
"Why do 4-bit optimizers save so much memory, and why is convergence barely affected?"	"The optimizer (AdamW) maintains state (momentum + variance) for every trainable param. At 32-bit this is a large memory cost. 4-bit = 8x reduction in optimizer-state memory. Convergence is barely affected because the state is STATISTICAL — it tolerates aggressive quantization. Combined with QLoRA's 4-bit weights, this is what fits 7B on an RTX 4090."	c3::ftdd03::analysis
"What is Unsloth's platform focus, and what should Apple Silicon users use instead?"	"Unsloth is CUDA-focused (NVIDIA GPUs). Its hand-written Triton kernels target NVIDIA. Apple Silicon (M-series Mac) is NOT the target — the CUDA kernels don't apply. Apple Silicon users should use MLX (Apple's framework for Metal/unified-memory, FT20) for both fine-tuning and inference. This is a scope boundary, not a bug."	c3::ftdd03::recall
"What are Dynamic 4.0 GGUF quants, and how do they differ from uniform quantization?"	"Dynamic 4.0 = Unsloth's intelligent PER-LAYER GGUF quantization. Uniform = same precision (e.g., 4-bit) on every layer. Dynamic = analyzes each layer's sensitivity; sensitive layers (attention, output proj) get MORE bits, robust layers get FEWER, hitting the same average bit-size. Result: same file size, BETTER quality — beats uniform quants at the same footprint."	c3::ftdd03::recall
"When do Dynamic 4.0 quants matter most?"	"(1) GGUF export for local/Ollama serving (FT19/FT20) — better quality at the same footprint, or same quality smaller. (2) Constrained edge devices (phone, small edge) — every megabyte matters; dynamic extracts more quality per byte. Pattern: Unsloth optimizes training (Layers 2-3), Dynamic 4.0 extends optimization to export (Layer 4)."	c3::ftdd03::application
"Compare Unsloth, Axolotl, and TRL on best-for, multi-GPU, and control level."	"UNSLOTH: single-GPU, speed/memory, GGUF export; NOT multi-GPU; optimized/opinionated. AXOLOTL: multi-GPU, production configs; multi-GPU yes; config-driven/broad. TRL: full control, custom loops, research; multi-GPU via Accelerate; maximum (it IS the library). TRL is the substrate Axolotl/Unsloth build on."	c3::ftdd03::application
"What is the heuristic for choosing Unsloth vs Axolotl vs TRL?"	"One GPU, go fast, export GGUF → Unsloth. Multiple GPUs, production configs → Axolotl. Custom training loop, maximum control → TRL. Common pattern: prototype in Unsloth (fast iteration on one GPU) → scale to Axolotl (multi-GPU) for production. TRL is what you reach for when neither abstraction fits."	c3::ftdd03::analysis
"Why is 'expecting Unsloth on Apple Silicon' an anti-pattern?"	"Unsloth is CUDA-focused — its hand-written Triton kernels target NVIDIA GPUs. On an M-series Mac, the optimizations DON'T APPLY. Installing Unsloth on Apple Silicon expecting a speedup is wrong — use MLX (FT20) instead. This is a scope boundary, not a defect in Unsloth."	c3::ftdd03::analysis
"Why is 'assuming the speedup changes the result' an anti-pattern?"	"Unsloth is faster and cheaper, NOT different. Same LoRA/QLoRA algorithm = same kind of adapter. If the result is 'better,' the cause is your data/hyperparameters (the actual steering wheel), NOT the kernel. Unsloth produces the SAME model, faster — not a better model. Expecting a quality jump from the optimizer misattributes the cause."	c3::ftdd03::analysis
"Why is 'picking Unsloth for a multi-GPU job' an anti-pattern?"	"Unsloth is single-GPU focused. With multiple GPUs, choosing Unsloth LEAVES COMPUTE ON THE TABLE — Axolotl or TRL (with Accelerate) will use the additional GPUs and finish faster. Unsloth is right when the constraint is ONE GPU's speed/memory, not when you have a cluster. Match the tool to the hardware."	c3::ftdd03::analysis
"Fill in the three numbers: Unsloth delivers ~___ speed, ~___% less memory, ___ algorithmic changes."	"~2x training speed, ~60% less VRAM, 0 (zero) algorithmic changes. The third number is the most important — Unsloth does not change what fine-tuning does; it changes how fast and how cheaply the same fine-tuning runs."	c3::ftdd03::recall
"Why does the course frame Unsloth's democratization as 'pedagogical, not just economic'?"	"A student who can run a dozen fine-tuning experiments/day learns steering-vs-knowledge (FT00) by FEEL — they see it repeatedly on their own hardware. A student who can afford one experiment/day learns it from a textbook. Unsloth makes the former possible. The economic win (cheaper GPU) enables the pedagogical win (more iterations = deeper intuition)."	c3::ftdd03::analysis
"How does Dynamic 4.0 extend Unsloth's value across the FT00 stack layers?"	"Unsloth optimizes Layers 2-3 (the adapter + the steer — the training). Dynamic 4.0 GGUF quants extend the optimization to Layer 4 (the export — quantization and serving). A model fine-tuned with Unsloth AND exported with Dynamic 4.0 is optimized end-to-end for the single-GPU/local-serving path — the full stack optimized for the consumer-hardware deployment."	c3::ftdd03::application