Track B — Managed Fine-Tuning on Azure AI Foundry

Lesson 7: Track B — Managed Fine-Tuning on Azure AI Foundry

In Track A you owned every moving part. Track B is the opposite trade: you supply a JSONL file and a model name, and Microsoft handles GPUs, checkpoints, safety evaluation and serving. You give up control and gain a deployment that behaves exactly like the base models you already call.

Under the hood it is still LoRA. The Azure documentation is explicit that they use low-rank adaptation to fine-tune models "in a way that reduces their complexity without significantly affecting their performance," approximating the original high-rank matrix with a lower-rank one. Same mathematics as Lesson 3 — you just never see the adapter.

What Azure AI Foundry actually offers

Three fine-tuning methods, and not every model supports every method. This table is the single most useful thing to check before you start:

Note also the two distinct model populations: Microsoft's proprietary models (the GPT family — frontier quality, closed weights, endpoint-only) and open-weight models (Qwen-32B, Llama-3.3-70B, Ministral-3B). The open-weight ones are dramatically cheaper to host — as Lesson 8 shows, $0.30–0.33/hour against $1.70/hour.

The data format — and the two requirements people miss

Azure consumes the same conversational JSONL you would feed Unsloth. It must be formatted as JSON Lines in the conversational format the Chat Completions API uses. There are two hard requirements that catch people out:

{"messages": [{"role": "system", "content": "You are a claims adjudicator. Respond only with valid JSON."}, {"role": "user", "content": "Claim: rear-ended at a stoplight, police report filed."}, {"role": "assistant", "content": "{\"decision\":\"approve\",\"payout_usd\":4200}"}]}

Three capabilities worth knowing about:

{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."},
              {"role": "user", "content": "What's the biggest city in France?"},
              {"role": "assistant", "content": "Paris", "weight": 0},
              {"role": "user", "content": "Can you be more sarcastic?"},
              {"role": "assistant", "content": "Paris, as if everyone doesn't already know that.", "weight": 1}]}

On volume: a fine-tuning job will not proceed with fewer than 10 training examples, Microsoft's guidance is to start with 50 well-crafted examples, and the stated best practice is "hundreds, if not thousands." That is consistent with everything in Lesson 4 — the floor is a technical limit, not a recommendation.

The workflow

import os
from openai import OpenAI

client = OpenAI(
    api_key = os.getenv("AZURE_OPENAI_API_KEY"),
    base_url = "https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/"
)

training_response = client.files.create(file=open("training_set.jsonl", "rb"), purpose="fine-tune")
validation_response = client.files.create(file=open("validation_set.jsonl", "rb"), purpose="fine-tune")

training_file_id = training_response.id
validation_file_id = validation_response.id

response = client.fine_tuning.jobs.create(
    training_file = training_file_id,
    validation_file = validation_file_id,
    model = "gpt-4.1-2025-04-14",
    suffix = "my-model",     # no dots/periods allowed in Foundry model names
    seed = 105,
    extra_body = { "trainingType": "GlobalStandard" }   # or "Standard", "Developer"
)

job_id = response.id

To set hyperparameters explicitly, use the method parameter:

client.fine_tuning.jobs.create(
    training_file = "file-abc123",
    model = "gpt-4.1-2025-04-14",
    suffix = "my-model",
    seed = 105,
    method = {
        "type": "supervised",
        "supervised": {
            "hyperparameters": { "n_epochs": 2 }
        }
    },
    extra_body = { "trainingType": "GlobalStandard" }
)

Metrics are visible during the run, and you can pause a job — which is not just a cancel button. Pausing creates a deployable checkpoint once safety evaluations complete, so you can evaluate what you have, then either deploy it or resume training. This is a genuinely useful cost lever for a run that is obviously drifting.

# ARM/REST shape for the deployment itself
sku: { name: "GlobalStandard", capacity: 1 }

You can also enable automatic deployment so a successful run deploys itself, with the deployment named from the generated model name plus your suffix.

The hyperparameters Azure exposes

This is a deliberately short list — a real difference from Track A, where you set a dozen values:

Training tiers — the cost/risk dial

RFT: the method that behaves differently

Reinforcement fine-tuning optimises behaviour from reward signals rather than labelled answers. You supply graders — which can be deterministic code (did the unit test pass?) or another model acting as a judge — and the model learns from its own sampled outputs.

Serving: four deployment types

Where the managed path fits

The two tracks also compose well: many teams prototype on a free GPU with Unsloth to nail the dataset and prompt, then run the production job on a managed platform for a proprietary model once the approach is proven. The dataset is portable — the conversational JSONL is identical apart from the BOM.

Further Reading

• Microsoft Learn — Customize a model with fine-tuning
• Microsoft Learn — When to use fine-tuning
• Microsoft Learn — Reinforcement fine-tuning
• Microsoft Learn — Direct preference optimization