Fine-Tune an LLM on Amazon SageMaker Without GPUs: Serverless Customization for Qwen3.8 27B, Muse Glimmer and Ministral 3 (SFT, DPO, RFT, LoRA), Real Prices and Step-by-Step Setup

Amazon SageMaker serverless model customization lets you fine-tune an open model on your own data without choosing, starting or paying for GPU instances. You upload a JSONL dataset, pick a model and a technique in SageMaker Studio (or the Python SDK), and SageMaker provisions the GPUs, trains, and cleans up. On October 22, 2026, AWS added Qwen3.8 27B, Meta Muse Glimmer 30B and Ministral 3 (3B, 8B and 14B) to a list that already covered Qwen, Gemma 4, Llama, gpt-oss, DeepSeek, Nemotron and Nova models. It runs in N. Virginia, Oregon, Tokyo and Ireland. Pricing is where most people's guesses go wrong. Supervised fine-tuning (SFT) and DPO are billed per million training tokens: dataset tokens times epochs, $0.50 per million for 8B-class models with LoRA and $3 per million for Qwen3.8 27B (US Regions). Reinforcement fine-tuning is billed by the hour, at $80 per hour with LoRA or $100 per hour for full fine-tuning, and that is the same rate for a 0.6-billion-parameter model as for a 120-billion one. So fine-tuning Qwen3.8 27B on 2 million tokens for 3 epochs costs about $18, while a single hour of reinforcement learning on the tiniest model in the list costs $80. This guide covers the techniques, every supported model and price, the dataset format, step-by-step setup in Studio and Python, evaluation, deployment, and what to check before you spend anything.

Jake's shop has 3,000 past repair estimates, each with the device, the fault, the parts and a short note in Jake's own words. Ethan wanted a model that writes new estimates the same way, with the shop's part names and the shop's tone, and prompting alone kept getting the part names wrong. "Can we teach it our way?" Jake asked. "We can," Ethan said, opening the price list. "The question is whether teaching costs $5 or $500." Both numbers turned out to be possible, depending on one choice, and this page is about that choice.

New to SageMaker? Amazon SageMaker AI is AWS's service for building, training and hosting machine learning models. Fine-tuning means taking a model that already understands language and training it a little more on your own examples, so it picks up your terminology, format or style. It is different from calling a model on Amazon Bedrock, where you use a model as it is and pay per request. Here you change the model's weights, then host the result. If you have only ever run models on your own PC, our guide to Hugging Face models on AWS bridges the two worlds.

What SageMaker serverless model customization is

SageMaker offers three ways to fine-tune a model. In serverless mode, SageMaker runs the infrastructure. It provisions GPU instances (from the P5, P4de, P4d and G5 families, chosen by model size and technique), applies a pre-tuned training recipe, streams metrics and logs to the console, and removes everything when the job ends. You never pick an instance type, wait for capacity or forget a running cluster. With SageMaker AI Training Jobs, you choose the instance type and run AWS's training recipes. With HyperPod, you run persistent clusters for large distributed training. The same model list is available on all three, and serverless is the right starting point for almost everyone.

Serverless customization is available in four Regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Tokyo) and Europe (Ireland). You can drive it three ways: the guided interface on the Models page of SageMaker Studio, the SageMaker Python SDK, or SageMaker's agent skills inside a coding assistant such as Claude Code, Cursor or Kiro, which turns a plain-English request into the API calls. Each finished job produces a logged model in a model package group, with lineage tracking that links datasets, training jobs, evaluations and deployments.

Should you fine-tune at all? Prompting vs RAG vs fine-tuning

You have three ways to make a model fit your task, and fine-tuning is the most expensive of them and the slowest to change:

• Prompt engineering fits when the model's answers are acceptable but need a better tone, format or style. It requires no training, and you can iterate in minutes.
• Retrieval-augmented generation (RAG) fits when the model lacks knowledge of your domain, such as your product catalog, policies or documents. You give it the right documents at question time, with no retraining. When the facts change, you update the documents, not the model.
• Fine-tuning fits when the model must consistently learn a new behavior, style or specialized skill that prompts cannot reliably produce, such as a strict output format, domain shorthand, or a reasoning pattern. It changes the weights.

Ethan's case was a mix. The part names were knowledge, so RAG with the parts list fixed most of them. The way Jake writes, short, plain and always ending with the warranty line, was style and format, and 3,000 examples of it were perfect SFT data. "So the parts list goes in the prompt, and your voice goes in the model," Ethan told Jake. A common pattern is exactly that: fine-tune for behavior, retrieve for facts.

SFT vs DPO vs reinforcement fine-tuning, and LoRA vs full fine-tuning

You make two choices for every job: how the model learns (the technique) and how much of it changes (the training type).

LoRA (low-rank adaptation) trains a small set of adapter weights on top of the frozen model. It is cheaper and faster, and usually enough for style, format and narrow skills. Full fine-tuning (FFT, also called full rank) updates every weight. It costs 50 percent more per token for SFT and DPO and $20 more per hour for RL, but it can change the model more deeply. Start with LoRA. Move to full fine-tuning only if a LoRA run on good data clearly falls short. You can also chain techniques ("continuous customization"), for example SFT first to teach the format, then DPO to polish the tone.

Supported models and model IDs (October 2026)

Every model below supports serverless customization as well as Training Jobs and HyperPod. The model ID is what you pass to the SDK:

Amazon Nova models (Micro, Lite, Lite v2 and Pro) are customized through their own Nova workflow on the same service. Not every model supports every combination of technique and training type. For example, the two 120B models and the Llama 3.1 and 3.2 models support LoRA only, and a few models lack DPO with full fine-tuning, so check the model's options in the console before you plan a job. Each model also has a maximum training sequence length per technique: Qwen3.8 27B allows up to 16K tokens per example for SFT and DPO, and Muse Glimmer 30B allows 32K with LoRA and 16K with full fine-tuning. Examples longer than the limit you set are truncated.

Qwen3.8 27B, Muse Glimmer 30B or Ministral 3: which base model to fine-tune

The three models added on October 22 cover very different budgets, and the right one depends on your task more than on benchmarks:

• Ministral 3 (3B, 8B, 14B) is the budget choice at $0.50 per million training tokens with LoRA, with evaluation from $0.11 to $0.22 per million tokens. The 8B is a strong default for narrow, repetitive tasks such as estimates, classification, extraction and routing, where a small specialist beats a big generalist. It is also cheap to host, which matters more over a year than the training bill.
• Qwen3.8 27B is the capable all-rounder at $3 per million tokens, with up to 16K tokens per training example. Pick it when the task needs real reasoning or long, structured answers, and when the 8B-class models fall short on your test set. Our Qwen3.8 27B guide covers running the base model yourself.
• Muse Glimmer 30B also costs $3 per million tokens. It allows longer training examples with LoRA (32K tokens) and has the cheapest evaluation input in its class ($0.35 per million). Pick it when your examples are long, such as documents, transcripts or multi-turn conversations. See our Muse Glimmer guide for the base model.

The practical method is the same as for any model choice. Train the smallest candidate first on your real data, evaluate it against the base model with a good prompt, and move up a size only if the test set says you must. Each step up multiplies training cost by six (from $0.50 to $3) and raises hosting cost too, so the smallest model that passes is almost always the right one to ship.

Pricing: what serverless fine-tuning costs

SFT and DPO are charged for the total tokens processed during training, which is the number of tokens in your dataset multiplied by the number of epochs. Reinforcement learning (RLVR and RLAIF) is charged per hour of training, billed per second. These are the US East (N. Virginia) prices on October 22, 2026, and US West (Oregon) matches them:

Not every model offers every combination. Prices exist only for the options a model supports, so a missing price means that technique or training type is not available for it. Prices are higher outside the US. In Europe (Ireland), Qwen3.8 27B SFT with LoRA costs $3.414 per million tokens (about 14 percent more) and RL $91.04 per hour. In Asia Pacific (Tokyo) they are $3.507 and $93.52. Two more items can appear on the bill. Synthetic data generation, where SageMaker writes training examples from your samples and guidelines, costs $0.50 per million input tokens and $1.50 per million output tokens. LLM-as-a-judge evaluations that use Amazon Bedrock models are billed as Bedrock usage, separately from SageMaker.

Notice the RL column. Every model, from Qwen3 0.6B to gpt-oss 120B, pays the same $80 an hour for RL with LoRA, because you are renting a fixed slice of managed GPU time rather than paying per token. A small model trains more steps per hour, but the meter runs at the same speed. "So the little model isn't cheaper for that one?" Jake asked. "Not per hour," Ethan said. "Only per result, if it learns faster."

Worked cost examples

• Jake's estimate writer, SFT with LoRA on Ministral 3 8B: 3,000 examples of about 400 tokens each is 1.2 million tokens. Three epochs make 3.6 million training tokens, and 3.6 × $0.50 = $1.80.
• The same data on Qwen3.8 27B: 3.6 × $3.00 = $10.80 with LoRA, or 3.6 × $4.50 = $16.20 with full fine-tuning.
• A bigger dataset: 2 million tokens for 3 epochs on Qwen3.8 27B is 6 × $3 = $18. The same job at 10 epochs costs $60. The epoch setting is a straight multiplier, so start with 1 to 3 and add more only if validation results keep improving.
• A small Llama job: Llama 3.1 8B, SFT with LoRA, 1.5 million tokens for 5 epochs: $0.50 × 5 × 1.5 = $3.75.
• Reinforcement learning: a 30-minute RLVR run with LoRA costs $80 × 0.5 = $40 on any model. A 3-hour run is $240, or $300 with full fine-tuning.
• Evaluation: scoring 500 test prompts of 1,000 tokens that produce 500-token answers on Qwen3.8 27B is 0.5 million input and 0.25 million output tokens: 0.5 × $0.90 + 0.25 × $0.90 = about $0.68.

Training is usually the smallest part of the total. The ongoing cost is hosting the custom model (see deployment), which you pay for as long as it is available. Ethan's first run cost less than a sandwich. The decision that mattered was where to host the result.

Prerequisites: domain, permissions and data in S3

1. A SageMaker AI domain with Studio access in one of the four supported Regions. If you do not have one, create it from the SageMaker console. Quick setup is fine for a single user.
2. Permissions on the execution role. With a quick setup domain, model customization permissions are included by default. With a custom setup, select the "Model customization" ML activity for the execution role. For domains created by CLI, SDK or CloudFormation, or for an existing role, attach the AWS managed policy AmazonSageMakerModelCustomizationCoreAccess (the recommended option), or write an equivalent inline policy.
3. Your dataset in Amazon S3 as a JSONL file, in a bucket the execution role can read, plus an S3 location for the output.
4. A budget alarm on your AWS account before the first job, so a mistyped epoch count shows up as an email, not a surprise.

Dataset format: JSONL for SFT, DPO and RL

Every technique takes JSONL: one JSON object per line, one training example per object. SFT accepts two shapes, and a system message is optional in both:

{"messages": [{"role": "system", "content": "You write repair estimates for a phone shop."}, {"role": "user", "content": "iPhone 15, cracked back glass, camera OK"}, {"role": "assistant", "content": "Back glass replacement, $129. Camera tested and working. 90-day warranty on parts and labor."}]}

{"system": "You write repair estimates for a phone shop.", "prompt": "Galaxy S25, battery swelling", "completion": "Battery replacement, $89. Swollen battery removed safely. 90-day warranty on parts and labor."}

DPO needs the same prompt answered twice: a chosen (preferred) and a rejected response, each as a full message list, with an identical system message in both if you use one. RLVR needs each prompt with reward metadata, a reward_model object whose style is "rule" and whose ground_truth is the correct answer. A code reward function then scores the model's attempts. Preset reward functions exist for grade-school math (gsm8k), code correctness (prime_code) and math reasoning (prime_math).

Data quality decides the result far more than the model or settings do. Keep these rules in mind:

• Diverse prompts: vary the wording, length and kind of request, or the model learns one phrasing.
• Consistent answers: if three examples contradict each other, the model learns the confusion.
• Real data: 1,000 real, clean examples beat 10,000 sloppy ones.
• A held-out test set: keep 5 to 10 percent of examples out of training, or set train_val_split_ratio.
• No secrets: anything in the training data can come back out of the model. Remove customer names, phone numbers and keys first.

Ethan's 3,000 estimates needed one evening of cleanup: customer names removed, prices checked against the current list, and a dozen joke estimates from slow Fridays deleted. "The ones where I wrote 'replaced user'?" Jake asked. "Especially those," Ethan said.

Step by step: fine-tune a model in SageMaker Studio

1. Open SageMaker Studio in a supported Region and choose Models in the left panel. The base models are listed there (the JumpStart base models tab).
2. Pick a model, for example Ministral 3 8B or Qwen3.8 27B, and open its model card.
3. Choose Customize model, then Customize with UI.
4. Name your custom model, and choose the technique (SFT, DPO, RLVR or RLAIF) and the training type (LoRA or full).
5. Select your dataset. Register it on the Assets page (which holds datasets and evaluators) or point to the S3 file.
6. Set the hyperparameters (next section). The defaults are sensible, but check max_epochs and dataset_max_len, because they set your cost and your truncation.
7. Submit the job. Studio opens the training job page with live metrics and logs. When it finishes, choose Go to Custom Model to see performance, artifacts, the configuration used and the logs.
8. Evaluate on held-out data, then deploy from the same page.

The hyperparameters that matter

Serverless jobs expose a short list of settings and preset the rest. For SFT with LoRA, these are the ones worth understanding:

• max_epochs (1 to 100): passes through the data. This multiplies the token bill. One to three epochs is the usual start.
• learning_rate (5e-07 to 1e-04): how big each update is. Too high and the model forgets what it knew. Too low and it barely changes.
• global_batch_size (8 to 1,024, in powers of two): examples per optimizer step.
• lr_scheduler (cosine or constant) and lr_warmup_steps_ratio (0 to 1): how the learning rate ramps up and decays.
• dataset_max_len (256 to 131,072, capped by the model's limit): the longest example in tokens. Longer examples are truncated, so set it above your longest real example.
• lora_rank (8 to 128) and lora_alpha (16 to 256): adapter size and strength. The effective learning rate scales with alpha divided by rank. Rank 16 or 32 with alpha twice the rank is a common start.
• lora_dropout, weight_decay and gradient_clipping: guards against overfitting and unstable training.
• merge_weights: merges the LoRA adapter into the base model after training, so you deploy one model instead of a base plus an adapter.
• train_val_split_ratio (optional): holds out part of your data for validation metrics.

Change one thing at a time, and compare runs on the same held-out set. The cheapest way to tune is a small model first. A Ministral 3 8B run costs about a sixth as much as Qwen3.8 27B per token, so use it to find a good learning rate and epoch count before you train the big one.

Serverless vs SageMaker Training Jobs vs HyperPod

The same models can be customized on three kinds of infrastructure. The choice is about control versus effort:

Serverless hides the full recipe and exposes the settings that matter most, so it is the fastest path to a first result. Training Jobs give you the complete list of hyperparameters from the SageMaker AI recipes repository, at the cost of choosing and paying for instances by the hour. That is worth it when you need something the serverless settings do not offer. HyperPod suits teams that train all the time, where a standing cluster is cheaper and more convenient than starting fresh each time. Searches for "SageMaker JumpStart fine-tuning" land in the same place: the base models live on the JumpStart tab of the Models page, and "Customize model" there starts a serverless job.

Fine-tune on AWS or on your own GPU?

If you already run models at home, you might wonder why you would pay to fine-tune. Local fine-tuning with tools like Unsloth is free per run, private, and fine for small models with LoRA. Training needs much more GPU memory than running the same model, because the optimizer state, gradients and activations sit in memory alongside the weights. So a model you can comfortably run on one consumer card, like Qwen3.8 27B, is usually out of reach to fine-tune on that same card except with aggressive tricks.

Serverless customization fills that gap. You get data-center GPUs (P5, P4de, P4d and G5) for exactly the length of the job, and none of the setup. For Ethan's $2 job, renting the hardware himself would have taken longer to set up than the training took to run. A sensible split many teams use is to prototype the dataset and prompt format on a small model locally, then train the model you will actually ship on SageMaker, and either host it on AWS or download the weights and run them wherever you like.

No training data? Synthetic data generation

The most common blocker is not money but data: you need hundreds or thousands of good examples, and you have twenty. SageMaker's data generation jobs write training examples for you, from a few samples, your annotation guidelines and, optionally, contextual documents such as manuals or policies that ground the output in your facts. It costs $0.50 per million input tokens (your samples and documents) and $1.50 per million output tokens (the generated examples). Generating 1 million tokens of examples from 2 million tokens of input costs about $2.50.

Synthetic data is a starting point, not a substitute for review. Read a sample of what it produced, delete the bad ones, and mix in every real example you have. Models trained on unchecked synthetic data tend to learn its quirks, such as the same opening phrase or an oddly formal tone. Jake read 200 generated estimates and binned 30. "It invents warranties," he said. "Then it learns from the 170 you kept," Ethan said, "plus the 3,000 real ones."

Customizing Amazon Nova models

Amazon's own Nova models are customized through the same service with their own workflow. SFT is priced per million training tokens at $1 for Nova Micro, $2 for Nova Lite, $3.78 for Nova Lite v2 and $8 for Nova Pro (US East). Nova Lite v2 also supports reinforcement learning at $80 per hour with LoRA and $160 per hour with full fine-tuning, the one exception to the $100 full-rank RL rate. Nova models make sense if you already use them on Amazon Bedrock and want a customized version that stays in the Nova family. The open models above make sense if you want the weights, portability, or a specific open model's strengths.

Before you press Start: a seven-point checklist

1. Is fine-tuning the right tool? Try your best prompt and, for facts, RAG first. Fine-tune for behavior, format and style.
2. Is the data clean? Check for valid JSONL, consistent answers, no personal data, and a held-out test set.
3. Is the model small enough? Start with an 8B-class model at $0.50 per million tokens, and move up only if it falls short.
4. What will it cost? For SFT or DPO, dataset tokens × epochs × price. For RL, hours × $80 or $100. Write the number down.
5. Is the sequence length right? Set dataset_max_len above your longest example, within the model's limit.
6. How will you judge it? Decide the evaluation before training: the test set, the scorer, and the base-model baseline.
7. Where will it live? Pick the hosting option and its monthly cost before you train, because that is the bill that lasts.

Fine-tune with the SageMaker Python SDK

Everything in the console is also available in code. Here is a DPO job with LoRA in the SageMaker Python SDK:

from sagemaker.modules.train.dpo_trainer import DPOTrainer
from sagemaker.modules.train.common import TrainingType

trainer = DPOTrainer(
    model=BASE_MODEL,                       # e.g. "huggingface-vlm-qwen3-8-27b"
    training_type=TrainingType.LORA,
    model_package_group_name=MODEL_PACKAGE_GROUP_NAME,
    training_dataset=TRAINING_DATASET,      # your JSONL dataset
    s3_output_path=S3_OUTPUT_PATH,
    sagemaker_session=sagemaker_session,
    role=ROLE_ARN,
)

The SDK's model customization section covers the other techniques the same way, with the technique, the training type (LoRA or full), the dataset, an output path, the execution role and a model package group that collects every version. Running jobs from code makes them repeatable, which matters once you are comparing several runs or retraining monthly as new data arrives.

Agent skills. If you use an AI coding assistant, open-source SageMaker AI skills are available in the AWSLabs Agent Plugins repository on GitHub. In Claude Code or Cursor you install the sagemaker-ai plugin, and for tools without plugin support (Kiro, as of March 2026) you install the MCP server and skills separately. You then describe the job in plain English ("fine-tune Ministral 3 8B on this JSONL with SFT and LoRA, then evaluate it"), and the assistant writes and runs the SDK calls. Review what it plans to run before you approve it, because it spends real money.

Evaluate your custom model before you trust it

A lower training loss does not prove the model got better at your task. Evaluate on examples it never saw, in two ways. Custom scorers are code that checks outputs, such as exact match, JSON validity or a price within the right range. LLM-as-a-judge uses a Bedrock model with a grading prompt for qualities like tone and helpfulness. Evaluation jobs are billed per million input and output tokens at each model's evaluation rate (about $0.68 for the 500-prompt example above), and Bedrock judge usage is billed on the Bedrock side. Evaluation features powered by Bedrock may process data in other AWS Regions within your geography, which matters if your data must stay in one Region.

Always compare against the base model with your best prompt, not against nothing. If the fine-tuned model only matches a well-prompted base model, you have paid for hosting without gaining quality. Ethan's comparison was 100 held-out estimates, scored by Jake by hand. The fine-tuned model followed the format and the warranty line more consistently than the base model with a long prompt, and that gap was the business case.

Deploy the custom model: SageMaker endpoint or Amazon Bedrock

From the custom model's details page, you can deploy in two ways:

• A SageMaker AI inference endpoint. SageMaker runs the model on instances you choose, and you pay for those instances by the hour while the endpoint exists, whether or not it is busy. You get full control over instance type, scaling and networking. Our SageMaker pricing guide covers how endpoint costs add up.
• Amazon Bedrock Custom Model Import. The model is served by Bedrock, so your apps call it through the same Bedrock APIs as other models, with Bedrock's own pricing for imported models. This suits teams that already use Bedrock and do not want to manage endpoints. Our Bedrock pricing guide explains how Bedrock bills.

Whichever you pick, hosting is the bill that keeps running. A model you trained for $2 can cost far more per month to keep online. So shut down test endpoints the same day, and size production hosting to real traffic. For low or bursty traffic, serving that bills by use usually beats an always-on instance.

Cleaning up a test endpoint takes one command: aws sagemaker delete-endpoint --endpoint-name YOUR_ENDPOINT, followed by aws sagemaker delete-endpoint-config --endpoint-config-name YOUR_CONFIG if you no longer need its configuration. You can also delete it from Inference, then Endpoints, in the SageMaker console. Your trained model stays registered in its model package group and its artifacts stay in S3, so you can redeploy it later in minutes without paying to train again.

Training session APIs: write your own training loop (advanced)

Also announced on October 22, 2026, training session APIs give ML teams the GPUs without the predefined workflow. You open a serverless, stateful session with a model loaded on GPUs, then call operations like forward_backward(), optim_step() and sample() yourself. That lets you build custom reinforcement learning loops, custom loss functions (GRPO, DRO, DAPO) and multi-stage pipelines, while SageMaker handles distributed execution and isolation:

from sagemaker.train.training_session import ServiceClient, AdamParams

svc = ServiceClient(region="us-west-2", role_arn="arn:aws:iam::111122223333:role/MyRole")
tc = svc.create_lora_training_client(base_model="openai/gpt-oss-20b", rank=32, alpha=64)
sc = tc.create_sampling_client()
# ...sample rollouts, score them, then:
# tc.forward_backward(batch, loss_fn="ppo").result()
# tc.optim_step(AdamParams(learning_rate=5e-5)).result()
tc.stop()

This is for researchers and teams with their own algorithms. If you are fine-tuning on examples, the managed SFT and DPO workflows above are simpler and cheaper to run correctly. Training sessions are billed separately from the token-priced jobs, so check the Model Customization tab of the SageMaker pricing page before you open one, and always call stop() when you finish.

Common problems and fixes

• Access denied when starting a job. The execution role lacks model customization permissions. Attach AmazonSageMakerModelCustomizationCoreAccess, or add the "Model customization" ML activity to the role.
• The model or technique is not offered. You are outside the four supported Regions, or that model does not support that technique or training type. The 120B models and Llama 3.1 and 3.2 are LoRA-only, for example.
• Dataset validation fails. The file is not valid JSONL (one object per line, no trailing commas, UTF-8), uses the wrong field names for the technique, or has a system message that is not first (or not identical in chosen and rejected for DPO).
• Answers come out cut short. dataset_max_len was lower than your longest examples, so they were truncated during training. Raise it, up to the model's limit.
• The model forgot general skills. The learning rate or epoch count was too high for the data size. Reduce them, or add some general examples to the dataset.
• The bill was higher than expected. Multiply tokens by epochs for SFT and DPO, and remember that RL bills hours, plus evaluation, Bedrock judges and hosting.
• Quota errors on deployment. The endpoint instance type you chose is above your account limit. Our ResourceLimitExceeded guide shows how to request more.

Troubleshooting by symptom

I cannot find Customize model in Studio

Check the Region (N. Virginia, Oregon, Tokyo or Ireland) and that you opened the Models page in Studio, not the classic interface.

My SFT job cost five times what I estimated

You set five epochs. SFT and DPO charge dataset tokens times epochs, so the epoch count multiplies the bill.

RL training on a tiny model was not cheap

RLVR and RLAIF bill $80 or $100 per hour for every model size. Use SFT if you can show correct answers.

The fine-tuned model is no better than the base model

Compare against the base model with your best prompt. If they tie, improve the data or use RAG instead of paying for hosting.

The custom model costs money while nobody uses it

A SageMaker endpoint bills per instance hour. Delete test endpoints, or deploy through Bedrock Custom Model Import.

My data must stay in one Region

Training runs in your chosen Region, but evaluation features powered by Bedrock may process data elsewhere in your geography. Plan evaluation accordingly.

SageMaker serverless fine-tuning: frequently asked questions

Ethan's estimate writer runs on a fine-tuned Ministral 3 8B. The training cost about two dollars, and the evaluation cost less than the coffee he drank while reading the results. Jake read the first batch of new estimates and found one he would have written differently. "One," he said. "Out of fifty." "Then we have our next fifty training examples," Ethan said.

Revision note. Written October 22, 2026, the day Qwen3.8 27B, Muse Glimmer and Ministral 3 joined SageMaker serverless customization, with the AWS price list and documentation of that date. "Practice makes perfect," the proverb says, and fine-tuning is practice for a model.