16.1 Advanced Fine-Tuning Methods (LoRA, QLoRA, Full)

Advanced Fine-Tuning Methods (LoRA, QLoRA, Full)

Quick Answer: Microsoft Foundry Azure OpenAI fine-tuning uses low-rank adaptation (LoRA) — a parameter-efficient update, not a full-weight rewrite. Use it for style, format, and tool calling, not to inject facts (that is retrieval-augmented generation (RAG)). Training data is JSON Lines (JSONL) in Chat Completions format, UTF-8 with a byte-order mark (BOM), under 512 MB. Jobs need at least 10 examples; Microsoft recommends starting with 50 well-crafted ones and scaling to hundreds or thousands. Standard training stays in-region; Global copies data and weights for cheaper, faster queues.

Domain 5 of Exam AI-300 — Optimize generative AI systems and model performance (10–15%) — includes design and implement advanced fine-tuning methods. An MLOps engineer who treats fine-tuning as “upload a wiki and the model will memorize it” will fail both the exam and production. This section is about when to fine-tune, which method Foundry actually runs, and how to submit a job that will start.

Fine-tuning versus prompt engineering versus RAG

Fine-tuning is not the first customization lever. Microsoft’s fine-tuning considerations article ranks the cheaper controls first, and AI-300 expects you to do the same.

• Prompt engineering (system message, few-shot examples, structured-output instructions) is cheapest. Start here. When the few-shot prompt grows so long that token cost and latency hurt, you have a candidate for fine-tuning: you embed those examples into weights so each request can be shorter.
• RAG is how you supply knowledge that changes: policies, SKUs, ticket history, rate tables. Fine-tuning does not replace a search index. Facts baked into weights go stale, cannot cite sources, and are expensive to refresh.
• Fine-tuning shines when the behavior is stable: brand tone, a rigid JSON schema, calling the right tools, classification labels, instruction following, or distillation (using a large model’s production traces to train a cheaper small model such as GPT-4.1-mini).

Microsoft is explicit about the good use cases: reducing prompt overhead, modifying style and tone, generating outputs in a specific schema, enhancing tool usage, helping a model use retrieved context, and optimizing smaller models. Combining fine-tuning with retrieval can teach the model to consume Azure AI Search hits (and ignore junk), but the documents themselves still live in the index. Fine-tuning is not a knowledge base.

Exam scenario: A claims copilot must emit a five-field JSON object and call get_claim_status with a claim ID. After two weeks of prompt engineering, the system message is 4,000 tokens of examples and still misses the schema about 15 percent of the time. Fine-tune gpt-4.1-mini with hundreds of JSONL conversations that demonstrate the schema and tool calls. Keep the policy handbook in RAG. Do not fine-tune on the handbook text hoping the model will “know” next quarter’s deductible.

Common trap: Fine-tuning to “teach the model our product catalog.” Catalogs change weekly. You will retrain constantly, still hallucinate SKUs, and skip groundedness. Use RAG (Chapter 15) for facts; fine-tune for the answer shape.

LoRA, QLoRA, and full-weight updates

Low-rank adaptation (LoRA) is the method Microsoft documents for Foundry OpenAI fine-tuning. Instead of updating every weight, LoRA injects small low-rank matrices that approximate the change to the original high-rank weight matrix. Only that smaller subset of parameters is trained during supervised adaptation. Training is faster and cheaper than rewriting the base model; the resulting custom model is still served as a Foundry deployment.

Quantized LoRA (QLoRA) further compresses the frozen base weights (commonly 4-bit) so adapters can train on smaller GPUs. QLoRA is a standard recipe in open-source parameter-efficient fine-tuning (PEFT) stacks. Microsoft does not document QLoRA as a Foundry OpenAI fine-tuning API option. There is no qlora=true hyperparameter on fine_tuning.jobs.create. If an exam item mentions QLoRA, map it to a managed-compute custom job whose framework you configured (Azure Machine Learning / Foundry managed compute, your VM quota, a PEFT trainer). Verify the job YAML or component before you claim QLoRA is in use. Do not tell a stakeholder that clicking Fine-tune on GPT-4.1 in the portal “is QLoRA.”

Full-weight supervised fine-tuning (SFT) updates most or all parameters. It needs large GPU quota, more data, and more risk of catastrophic forgetting. On Foundry, full-weight customization is not what the Azure OpenAI fine-tuning job does. Full updates appear only if you run a managed-compute custom training stack on models that allow it (open-source catalog models or your own weights).

You can stack techniques: run SFT first to teach the task, then DPO to prefer one style over another. During SFT, obsess over data quality. During DPO, supply clear chosen versus rejected pairs.

Serverless versus managed compute

Foundry offers two modalities for fine-tuning. Do not confuse them with inference deployment types.

• Serverless uses Microsoft-managed capacity and consumption pricing. You do not need GPU quota. This is how you fine-tune Azure OpenAI / Foundry Models sold by Azure (GPT-4.1, GPT-4.1-mini, GPT-4.1-nano, GPT-4o, GPT-4o-mini, and listed open-source models on Global). Hyperparameter knobs are fewer than on a custom trainer. Microsoft’s classic overview cites consumption starting around $1.70 per million input tokens for serverless fine-tuning; always confirm the current Azure OpenAI pricing page before a cost review, because price lists move.
• Managed compute runs training on your virtual machines (Azure Machine Learning compute or Foundry managed compute). You need VM quota. OpenAI models are not trained this way. You get more hyperparameters and can choose PEFT recipes (LoRA, and in custom containers possibly QLoRA or full updates).

For most AI-300 GenAIOps work, serverless LoRA SFT on GPT-4.1 or GPT-4.1-mini is the path. Use managed compute when the model card says the model is only fine-tunable on dedicated GPUs (for example certain Llama catalog models). Serverless is also the only place you get exclusive access to OpenAI base models.

Open-source models listed for Foundry SFT in public preview (Ministral-3B, Qwen-32B, Llama-3.3-70B-Instruct, gpt-oss-20b) are supported on Foundry resources and the new Foundry UI, typically on Global training, not on Standard regional training. Check the current model table before you design a landing zone.

Customization methods on Foundry OpenAI

The portal customization method depends on the selected base model:

• Supervised fine-tuning (SFT): labeled input/output chat JSONL. Start here for almost every project.
• Direct preference optimization (DPO): preferred versus non-preferred completions. Computationally lighter than classic reinforcement learning from human feedback (RLHF) because you do not fit a separate reward model. Available on GPT-4o and the GPT-4.1 family.
• Reinforcement fine-tuning (RFT): grader or reward signals when there are many valid solution paths. o4-mini supports RFT. GPT-5 RFT is generally available but gated by invitation through your Microsoft account team. RFT is the wrong first choice for “make the JSON valid.”

You may fine-tune a previously fine-tuned OpenAI model (base-model.ft-{jobid}) on a new JSONL set — continuous fine-tuning, OpenAI models only. Use a suffix (up to 18 characters; Foundry names cannot contain dots) so iterations stay distinguishable.

Data format, size, and hyperparameters

Training and validation files must be JSONL in the Chat Completions messages schema, encoded UTF-8 with a BOM, each file under 512 MB. Roles are system, user, assistant, and optionally tool for tool-calling traces. Multi-turn conversations can sit on one JSONL line. Set "weight": 0 on assistant turns you do not want to train on, and "weight": 1 on the turns that matter (for example, skip a bland first reply and train only on the sarcastic rewrite).

Vision-capable bases (GPT-4o, GPT-4.1) accept image-plus-text user content in the same chat schema. Keep the same system message you will use in production in every training example. Microsoft warns that a different system message at inference is a documented reason a custom model “does not work.”

Jobs will not start with fewer than 10 training examples. Ten is not enough to change behavior. Microsoft’s guidance: start with 50 well-crafted examples, then grow to hundreds or thousands. Doubling a high-quality set can lift quality roughly linearly; a large dirty dump can make the model worse than the base. Seed quality beats volume.

Leave hyperparameters at portal defaults for the first job. n_epochs, batch_size, and learning_rate_multiplier can be left automatic (-1 where the API allows). Documented knobs — do not invent unpublished universal numbers:

• n_epochs: full passes over the training set. Auto is allowed. Too many epochs overfit (training loss falls while validation loss rises).
• batch_size: examples per forward/backward pass. Larger batches often suit larger sets. When set to -1, Microsoft calculates about 0.2 percent of the training set, capped at 256. Defaults and maxima are base-model specific.
• learning_rate_multiplier: scales the pre-training learning rate. If you leave auto, Microsoft suggests experimenting in 0.02 to 0.2. Smaller values reduce overfitting.

Pass a seed so the same job parameters usually reproduce. Importing training files from Azure Blob Storage requires the storage account to allow public network access. If corporate policy forbids that, upload locally or use the SDK.

Training types: Standard, Global, Developer

These are training tiers. They are not the same as inference deployment types (section 16.3), though the names overlap. In the Python SDK you set them with extra_body (trainingType: Standard, GlobalStandard, or developerTier) on a current preview API version.

If the exam asks which training type keeps training data in the resource region, the answer is Standard, not Global and not Developer. Microsoft recommends Global when residency is not a constraint because of cost and queue time.

Role-based access control (RBAC): Foundry Users may submit fine-tune jobs; Foundry Owner (or a custom role with Microsoft.CognitiveServices/accounts/deployments/write) is required to deploy. Role display names were recently renamed from Azure AI User / Azure AI Owner; the role IDs did not change. Automatic deployment after a successful job is optional, OpenAI models only, and still needs Owner — it is not a production promotion gate (section 16.3).

Checklist before you click Submit:

• You already failed to solve the task with a short prompt and with RAG for facts.
• Base model and customization method (SFT / DPO / RFT) match the model card.
• JSONL validates, has a BOM, and is under 512 MB.
• Training and validation files are disjoint.
• Training type matches residency policy.
• Hyperparameters are defaults unless a prior job overfit or underfit.
• Suffix and seed are set so you can tell v3 from v4.