"Question"	"Answer"	"Tag"
"What is Axolotl, and what is the core pattern it champions?"	"Axolotl is a config-driven, multi-GPU-capable production wrapper over TRL. The core pattern: the training recipe is a DECLARATIVE YAML file (config-as-source-of-truth), not a program. Model, data, PEFT, hyperparams, distributed, and eval are all one diff-able, version-able, CI-validatable file."	c3::ftdd05::recall
"How does Axolotl relate to TRL under the hood?"	"Axolotl WRAPS TRL — it is not a competing engine. An SFT config uses SFTTrainer; DPO uses DPOTrainer; GRPO uses GRPOTrainer. The optimizer, loss, and checkpointing are all TRL's (= the HuggingFace Trainer's). Your TRL knowledge transfers directly; Axolotl just names/organizes the knobs in YAML."	c3::ftdd05::recall
"What two substantial things does the Axolotl wrapper add over raw TRL?"	"(1) Opinionated cross-family defaults — known-good sequence lengths, gradient accumulation, precision, and PEFT configs across Llama/Mistral/Qwen, so you don't re-derive a baseline each time. (2) Battle-tested multi-GPU orchestration — curated FSDP/DeepSpeed ZeRO configs that are fiddly and error-prone to write by hand."	c3::ftdd05::recall
"State the three properties config-as-source-of-truth gives you that a hand-written training script cannot."	"(1) Reproducibility is a file — 'reproduce my run' = 'run this file.' (2) Diff-able and version-able — a git diff shows exactly what changed between runs. (3) CI-validatable — a YAML can be linted/schema-validated before touching a GPU; a Python script cannot. Same reason Kubernetes manifests are YAML."	c3::ftdd05::recall
"Give the three-way decision rule for Axolotl vs Unsloth vs raw TRL."	"Multi-GPU production + must reproduce + standard recipe -> Axolotl. Single-GPU + sub-30B + speed/VRAM constrained -> Unsloth (~2x faster, ~half VRAM via Triton kernels). Custom reward / non-standard loop / brand-new method / full control -> raw TRL (Python API). Standard recipe + zero code + no wrapper -> raw TRL CLI."	c3::ftdd05::recall
"What is the 'hybrid pattern' many practitioners use for Axolotl and Unsloth?"	"Unsloth as the default backend for sub-30B single-GPU work (for speed), Axolotl for anything multi-GPU or above 30B (for orchestration + reproducibility). Not indecision — each tool for its strength. Unsloth's TRL-compatible API makes the transition mostly a config change, not a rewrite."	c3::ftdd05::application
"For a job that needs a custom Python reward function with GRPO, why is Axolotl the wrong choice?"	"Axolotl is CONFIGURED, not programmed. A custom reward function (Python callable) cannot be fully expressed in a static YAML — the reward is code. You would fight the tool. Drop to raw TRL's Python API for non-standard loops. Use Axolotl for the standard recipes (SFT/DPO/GRPO with built-in rewards) it excels at."	c3::ftdd05::application
"In an Axolotl YAML, how do you switch between QLoRA, LoRA, and full fine-tuning?"	"Change the `adapter:` line — `adapter: qlora`, `adapter: lora`, or `adapter: none` for full. One line, not a rewrite. This is the declarative pattern in action: the change is localized to the config, not scattered through code. The LoRA rank/targets are separate keys (lora_r, lora_target_modules)."	c3::ftdd05::application
"How is multi-GPU expressed in an Axolotl config, and why is this a decisive advantage over raw TRL?"	"Via a config value: `deepspeed: <config>.json` or an `fsdp:` block. Axolotl's curated FSDP/DeepSpeed configs are the value-add — raw TRL gives you the ABILITY to shard but hands you the RESPONSIBILITY of writing the fiddly config (sharding dim, CPU offload, ZeRO stage, gradient-checkpointing interaction). Axolotl's known-good recipes remove that tax."	c3::ftdd05::application
"Why is 'reaching for Axolotl when you know it' an anti-pattern for a single-GPU 7B speed-critical job?"	"You leave throughput on the table. Unsloth would be ~2x faster at ~half the VRAM via Triton kernels. The tool is chosen by CONSTRAINT (multi-GPU vs single-GPU speed vs control), not by familiarity. 'I know Axolotl' is not a constraint; 'this is single-GPU and VRAM-constrained' is."	c3::ftdd05::application
"Why does assuming 'Axolotl removes the need to understand TRL' lead to failure?"	"Because Axolotl WRAPS TRL, a TRL-level problem (a bad learning rate, the wrong loss, a misunderstood trainer, the wrong data shape) is STILL your problem. The wrapper configures the trainer; it does not absolve you of knowing what the trainer does. Learn TRL first (FTDD-04); Axolotl is the layer above."	c3::ftdd05::analysis
"What is the cost of Axolotl's abstraction layer, and when does it bite?"	"(1) Latency on the bleeding edge — when a new trainer lands in TRL, it takes time to surface cleanly in Axolotl's config schema; raw TRL gets you there first. (2) Debuggability — when something breaks you debug through Axolotl -> TRL -> Transformers, and the error may surface far from its cause. Rare for standard recipes; real for exotic setups."	c3::ftdd05::analysis
"Why is 'treating the config as documentation, not source' an anti-pattern, and how do you avoid it?"	"If you 'tweak live' via CLI overrides or Python edits so the on-disk YAML no longer matches what ran, the config loses its reproducibility guarantee. Avoid it by making the config the COMPLETE source of truth: every override gets written into the YAML and committed. If a run differs from the YAML, the YAML is wrong."	c3::ftdd05::analysis
"State the six-item reproducibility checklist for an Axolotl config."	"(1) Every hyperparameter pinned (no reliance on a default). (2) Dataset path AND split explicit. (3) Distributed strategy declared (single-GPU/FSDP/named DeepSpeed). (4) Precision known (what did bf16:auto resolve to). (5) Eval declared (val_set_size/eval_steps). (6) Could a colleague reproduce from the YAML alone? Six yeses = reproducible."	c3::ftdd05::analysis
"Why is the config-as-source-of-truth pattern said to recur at different altitudes across the ecosystem?"	"You see it three times: Axolotl's YAML, the TRL CLI's YAML (`trl sft --config`), and the broader infra-as-config movement (Kubernetes, Terraform). Same idea, different layers. Axolotl proved it for LLM fine-tuning; TRL v1.0's CLI adopted it; now the expectation is that a fine-tuning job is described by a file, not a script."	c3::ftdd05::analysis
"Why is Axolotl described as 'preferred by practitioners for real multi-GPU configs'?"	"Because raw TRL makes YOU write the DeepSpeed/FSDP config — and those configs are notoriously fiddly (sharding dim, CPU offload, ZeRO stage, gradient-checkpointing interaction). Axolotl's curated, battle-tested multi-GPU recipes remove that configuration tax. For 2/4/8-GPU jobs on large models, it is the path of least resistance in the open-weights world."	c3::ftdd05::analysis
"A team's config.yml runs successfully, but a teammate cannot reproduce the loss curve. Name three likely checklist failures."	"(1) An unspecified default that changed between TRL versions (e.g., riding the default learning_rate). (2) Dataset split not pinned ('whatever the default split was'). (3) CLI overrides applied at runtime that were never written back into the YAML (config-as-documentation, not source). Possibly also: precision ambiguity (bf16:auto resolved differently on different hardware), or a distributed strategy not declared."	c3::ftdd05::analysis