Research-backed calculator guide
Azure Fine-Tuning Lifecycle Cost: SFT, RFT, Grading and Hosting
Estimate Azure OpenAI fine-tuning lifecycle cost by separating SFT or RFT training, grader and evaluation tokens, hosting idle time, and inference usage.
Azure OpenAI fine-tuning lifecycle cost is not one training invoice. It is the sum of the experiment, the quality checks, the time a custom model remains deployed, and the tokens it serves. The most reliable estimate keeps those meters separate until the end.
Quick answer
For supervised fine-tuning (SFT), start with the training-file token count, multiply by the number of epochs, and multiply by the selected training rate. Microsoft Foundry documents the formula as training tokens × epochs × price per token. Add evaluation or judge calls, then add deployment hosting and production input/output inference. SFT training time on the clock is not the same as token-based SFT billing. [1]
For reinforcement fine-tuning (RFT), use elapsed billable training hours × the model's hourly training rate, then add grader input and output tokens at their applicable rates. A model grader can therefore make an RFT run materially more expensive than the training-hour line alone. [1] DPO follows the token-based pattern, while interactive or programmed training has its own prefill, cached-prefill, sampling, and training-token meters. [1] The exact rate depends on model, training type, deployment type, geography, agreement, and date, so treat any worked number here as an estimate rather than a Microsoft quote.
The practical answer to “what will fine-tuning cost?” is a ledger:
lifecycle cost = training + grading + evaluation + hosting/capacity + inference + optional data and operations
Start with the Azure OpenAI cost and PTU calculator, but enter training and serving as separate scenarios. A calculator designed only for monthly inference can understate a one-off fine-tuning project if it omits repeated runs, grader tokens, or idle hosting.
What the lifecycle includes
1. Data preparation and experiment runs
The service meter starts after you have prepared the data, but your budget should start earlier. Count the training file after formatting and tokenization, not only the number of rows. Keep validation and final test data outside the training set. Microsoft’s SFT procedure calls for separate training and validation JSONL files and recommends comparing held-out results rather than training performance alone. [3]
A useful internal ledger has one row per run: dataset version, model ID, training type, region or data zone, token count, epochs, rate snapshot, job ID, outcome, and whether a deployable checkpoint was retained. This makes a second or failed run visible instead of silently replacing the first estimate. A run that is canceled after training begins can still have completed work; your estimate should not assume every experiment is free.
2. SFT and DPO training
SFT learns from prompts and desired responses. DPO learns from preferred and rejected responses. Foundry describes both as managed-training methods, but model availability and supported training types vary by model. [2] For a token-priced run:
SFT cost = (training tokens ÷ 1,000,000) × epochs × rate per 1M training tokens
If the validation file is not included in the billable training-token definition for your selected offer, do not add it automatically. Confirm the model’s current pricing and usage definition before submitting the job. That distinction is important: a dataset with 2 million tokens and three epochs represents 6 million token-passes for this estimate, regardless of whether the service’s wall-clock duration is one hour or four.
3. RFT, grading, and evaluation
RFT uses a grader to score generated responses. Foundry’s cost guide separates RFT hourly training from model-grader inference. Its formula is:
RFT cost = (billable training hours × hourly training rate) + (grader input tokens ÷ 1,000,000 × grader input rate) + (grader output tokens ÷ 1,000,000 × grader output rate) [1]
Do not assume that an RFT run’s visible response count equals grader tokens. Reasoning, prompts, generated completions, repeated rollouts, validation samples, and the grader’s output can all change usage. Record input and output tokens independently. If you run a separate judge on a held-out test set, add that as evaluation rather than hiding it inside the training row.
A low-cost control is to make the first RFT experiment small. Limit validation and evaluation samples, select a grader that meets the quality requirement, and monitor the run. Foundry notes that a managed RFT job can pause at its spending limit and create a checkpoint for review; resuming is a new budget decision, not proof that the original estimate was sufficient. [1]
4. Deployment and fine-tuned model hosting cost
A completed model is not necessarily a production model. Serverless Standard or Global Standard deployments can combine input/output token charges with an hourly custom-model hosting fee. Provisioned Throughput bills capacity such as PTU-hours rather than ordinary per-token usage. Developer deployment is an evaluation option with no hourly hosting fee in the documented table, but it has availability and data-residency limitations and is removed after 24 hours. Managed compute bills GPU-hours while the deployment runs, even if requests are quiet. [1] [2]
This is why hosting hours × hourly rate belongs in the lifecycle ledger. If a deployment remains live for a 30-day month, 720 hours is the upper bound for continuous hosting. A model with a modest token bill can still create a large fixed line when kept deployed during testing, weekends, or an approval delay. Include the intended idle period and a deletion rule in the estimate.
Microsoft’s public price pages state that displayed prices are estimates, not quotes, and can vary with agreement, date, and currency conversion. [4] Model-specific Foundry pricing also separates training per million tokens, hosting per hour, and input/output usage for listed models. [5] Use the page for the selected model and region on the day you approve the run; do not copy a historical Q&A answer into a current budget.
5. Production inference and break-even
Fine-tuning may reduce prompt examples or improve task consistency, but it does not make inference free. Compare the tuned path with a baseline path using the same traffic and quality acceptance rule:
monthly tuned cost = monthly hosting + tuned input tokens × input rate + tuned output tokens × output rate
If fine-tuning is a one-time project, calculate a payback view only after you have measured the baseline. One simple comparison is:
incremental fixed cost ÷ monthly variable savings = estimated months to recover
This is an estimate, not a promise of ROI. Variable savings can be negative if the tuned model produces longer outputs, requires a larger model, or needs extra evaluation and fallback traffic. The model pricing comparison and LLM cost calculator can help normalize baseline and tuned inference assumptions.
Worked cost example: SFT plus hosting
The following example uses the listed Qwen3 32B Global figures on the Foundry Models fine-tuning pricing page as an illustrative rate snapshot: $3.20 per 1 million training tokens, $0.30 per hosting hour, $0.30 per 1 million input tokens, and $1.20 per 1 million output tokens. [5] These are displayed estimates for that listed model and deployment context, not a universal Azure OpenAI fine-tuning quote. We assume three SFT epochs, a 2-million-token training file, 720 hours of hosting, 20 million monthly input tokens, and 40 million monthly output tokens.
| Step | Input or assumption | Formula | Output |
|---|---|---|---|
| SFT training | 2M training tokens, 3 epochs, $3.20/M | 2 × 3 × $3.20 | $19.20 |
| Hosting | 720 hours, $0.30/hour | 720 × $0.30 | $216.00 |
| Monthly input inference | 20M tokens, $0.30/M | 20 × $0.30 | $6.00 |
| Monthly output inference | 40M tokens, $1.20/M | 40 × $1.20 | $48.00 |
| One-time training + first month serving | Training + hosting + input + output | $19.20 + $216 + $6 + $48 | $289.20 |
This ledger excludes separate evaluation calls, data preparation labor, storage, network transfer, taxes, support plans, retries, and any PTU or gateway charge. If evaluation costs $12 in a separate test pass and data preparation is an internal $10 estimate, the planning total becomes $311.20. Those two additions are assumptions, not vendor prices. The important result is the shape: in this scenario, continuous hosting is larger than the one-time SFT run, so deleting an unused deployment changes the budget more than shaving a small amount from the dataset.
For a second month with no retraining, the same assumptions produce $270.00 of hosting plus inference. If the model is deployed for only 160 hours while a release is tested, hosting becomes $48.00 and the monthly serving subtotal becomes $102.00. The right answer depends on actual deployment hours, not only on token volume.
Worked cost example: RFT with a grader
Use variables when the selected RFT rate is not yet confirmed:
RFT total = (H × training hours) + (I × grader input millions) + (O × grader output millions)
Suppose a planning worksheet—not a quote—assumes four billable training hours at H = $100/hour, 5 million grader input tokens at I = $1.00/M, and 4.9 million grader output tokens at O = $4.00/M. The estimate is:
(4 × $100) + (5 × $1) + (4.9 × $4) = $400 + $5 + $19.60 = $424.60
If a separate held-out evaluation costs $20 in assumed judge usage and the model is then hosted for 100 hours at an assumed $0.30/hour, the pre-production subtotal is $474.60. The assumptions deliberately remain visible. Replace H, I, O, and the hosting rate with current values for the selected model, data zone, and deployment. Do not infer a current RFT price from the SFT token rate.
A practical budget worksheet
Before submitting, record these inputs:
- Model and scope: model ID, version, training method, training type, region or data zone, and deployment type.
- Training meter: token count and epochs for SFT/DPO, or expected billable hours for RFT.
- Grader meter: grader model, expected input tokens, expected output tokens, rollouts, and validation samples.
- Quality meter: offline evaluation set size, judge calls, human review, and the pass/fail threshold.
- Serving meter: hosting hours, PTUs or GPUs if applicable, monthly input tokens, monthly output tokens, and expected retries.
- Controls: spending limit, pause/cancel owner, deployment deletion time, and the rate page snapshot date.
The AI token cost calculator is useful for normalizing input and output assumptions. Keep the fine-tuning rows separate from ordinary prompt-token rows so an evaluation pass is not mistaken for production traffic. When the experiment is complete, reconcile the ledger to the Azure usage export and retain the job ID, dataset version, and deployment interval.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
FAQ
Is Azure OpenAI fine-tuning billed by training time?
It depends on the training method. SFT and DPO are documented with token-based training formulas using training tokens and epochs, so elapsed queue or processing time is not the primary charge. Managed RFT uses billable training time and a separate grader-token charge. Interactive training uses separate token categories. Confirm the current model-specific rate before budgeting. [1]
Is RFT always more expensive than SFT?
Not inherently. SFT and RFT use different billing meters and solve different learning problems. A small RFT run with few grader tokens could cost less than many large SFT retries, while repeated rollouts and a costly grader can make RFT larger. Compare the actual token and hour assumptions, plus evaluation quality, instead of choosing by method name.
How do I calculate fine-tuned model hosting cost?
For an hourly hosting deployment, multiply billable deployment hours by the current hourly hosting rate, then add inference input and output charges. For 30 days of continuous deployment, use 30 × 24 = 720 hours. PTU and managed-compute deployments use capacity or GPU-hour formulas instead. Developer deployment has different limitations and is not a general production substitute. [1] [2]
Are grader tokens included in the RFT training price?
The Foundry cost guide treats model-grader inference as a separate charge. Track grader input and output tokens separately and add them to the hourly training amount. A separate final evaluation or judge pass should be another ledger row, because it is not automatically covered by the RFT formula. [1]
What costs are excluded from this estimate?
The worked numbers exclude labor, data labeling, storage, network transfer, taxes, support, retries, gateway fees, human review, and the cost of a fallback model. They also do not assume a particular discount, committed agreement, quota reservation, or currency conversion. Add those items when they apply to your environment.
How often should I refresh Azure fine-tuning rates?
Refresh rates when the model, training type, geography, deployment type, or commercial agreement changes, and immediately before approval of a new run. Microsoft describes public pricing as estimates that can vary by date and agreement. Record the checked date and the source URL beside the estimate rather than overwriting an old rate without an audit trail. [4]
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.