There are two front doors to a foundation model on AWS, and teams walk through the wrong one all the time. One is Amazon Bedrock, a serverless API where you never see a server. The other is SageMaker JumpStart, where you pick a model, click deploy, and end up owning a running endpoint on an instance you chose. Same goal, a model answering requests. Very different bill, and a very different amount of control. Part 5 drew the Bedrock versus SageMaker line at the platform level. This part goes inside JumpStart and shows what you actually get and what you actually pay.
What JumpStart actually is
SageMaker JumpStart is a feature of SageMaker AI, not a separate product. It is a catalog of pretrained models, open-source and proprietary, that you can deploy, fine-tune, and evaluate with far less setup than raw SageMaker hosting would take. AWS keeps the catalog in a place called the SageMakerPublicHub, and you reach it either from the Models landing page in the current SageMaker Studio or straight from the SageMaker Python SDK. Open weight families like Llama, Mistral, and Falcon sit next to instruction-tuned models like FLAN-T5, along with vision and tabular models that predate the current generation.
Every model in the catalog has a model card. In the upper corner of that card you get four actions: Deploy, Fine-tune, Customize, and Evaluate. Not every model exposes all four, but Deploy is the one that matters first. When you click it, JumpStart does the thing that defines the whole feature: it stands up a real-time inference endpoint on a SageMaker ML instance that you picked, loads the model onto it, and hands you an endpoint name you can call. There is no shared token pool. That endpoint is yours, it runs on your instance, and it bills by the second the instance is up.
One housekeeping note before you design anything. The old Studio Classic experience stopped taking new onboarding on November 30, 2023, and AWS steers everyone to the current Studio. More recently, on March 13, 2026, AWS delisted a set of models from the JumpStart catalog to focus on well-supported options. Endpoints already running on a delisted model keep working, but you cannot deploy a fresh copy of one that is gone. Check the catalog for your exact model this week, not from memory.
How JumpStart differs from Bedrock
The two services solve the same first problem, getting a model to answer, and then split hard on everything after. Bedrock is serverless. You send tokens, you pay per token, and when no one is calling, you pay nothing. JumpStart is instance based. You reserve an ML instance, the model runs on it, and you pay for that instance every hour it exists, busy or idle. That single fact drives most of the design choices below.
Control is the other axis. On Bedrock you get the models AWS chose to offer and the knobs AWS exposes. On JumpStart you get the open weights themselves, running inside your account and your VPC, on an instance type you selected, which you can fine-tune deeply and inspect. If you need an open model that Bedrock does not carry, or you need the endpoint isolated on dedicated hardware for a compliance reason, JumpStart is the path. If you just want a capable model behind an API with zero infrastructure, Bedrock wins and you should not be reading a section about instance types.
| Dimension | Bedrock | JumpStart |
|---|---|---|
| Hosting | Serverless, managed pool | Your SageMaker endpoint |
| Billing | Per token, zero when idle | Per instance-hour, always on |
| Model access | AWS-curated managed models | Open weights plus proprietary |
| Isolation | Shared service | Dedicated instance in your VPC |
| Best when | Spiky or low traffic, fast start | Steady load, open model, isolation |
Deploy a model in a few lines
The reason people reach for JumpStart over plain SageMaker is that it removes the container, artifact, and serving-stack wiring. You name a model ID, you name an instance type, and the SDK does the rest. The JumpStartModel class wraps all of it. Here is a deploy that stands up a text-generation endpoint.
from sagemaker.jumpstart.model import JumpStartModel
model = JumpStartModel(
model_id="meta-textgeneration-llama-3-8b-instruct",
instance_type="ml.g5.2xlarge",
)
predictor = model.deploy(accept_eula=True)
response = predictor.predict({
"inputs": "List three checks before I put an LLM endpoint in production.",
"parameters": {"max_new_tokens": 128, "temperature": 0.2},
})
print(response)
# tear it down or it bills all month
predictor.delete_endpoint()Expected output: the deploy call takes several minutes while SageMaker pulls the model and boots the instance, then returns a predictor bound to an in-service endpoint. The predict call returns generated text. The delete call removes the endpoint so the meter stops.
Failure mode: the two that bite first are a missing accept_eula on a gated model, which fails the deploy with a license error, and a ResourceLimitExceeded when your account has no quota for that instance type in that Region. The instance quota is per account and per Region and starts low, so request an increase before you script this. Confirm the exact model_id in the current catalog, since the March 2026 trim moved some. [VERIFY model_id availability]
Fine-tune without renting a cluster
Deploying a base model is half of JumpStart. The other half is fine-tuning one on your data without standing up training infrastructure yourself. This is transfer learning, which means you start from a pretrained model and keep training it on a smaller, task-specific dataset instead of training from scratch. You point a JumpStartEstimator at a model ID and a training dataset in S3, call fit, and SageMaker runs the job on managed instances you never have to configure, then gives you a fine-tuned model you can deploy the same way as the base.
from sagemaker.jumpstart.estimator import JumpStartEstimator
estimator = JumpStartEstimator(
model_id="meta-textgeneration-llama-3-8b-instruct",
instance_type="ml.g5.12xlarge",
environment={"accept_eula": "true"},
)
estimator.set_hyperparameters(epoch="3", learning_rate="0.0001")
estimator.fit({"training": "s3://my-bkt/support-data/"})
tuned = estimator.deploy(instance_type="ml.g5.2xlarge")Two things to hold onto. First, the training instance and the serving instance are separate choices. You often train on something large like an ml.g5.12xlarge for a few hours, then serve on a smaller ml.g5.2xlarge for the life of the endpoint, so the training bill is a one-time spike and the serving bill is the recurring one. Second, fine-tuning here supports both instruction tuning and domain adaptation, where domain adaptation trains on unlabeled domain text rather than input and output pairs. Which one you want is the same decision I laid out for Bedrock in Part 16, so I will not repeat it here.
Private hubs and model access control
In a single-person project the public catalog is fine. In an organization it is a governance problem, because you rarely want every data scientist deploying any model with any license from the full public hub. Private hubs, also called curated hubs, are the answer. An administrator creates a private hub with the SageMaker Python SDK, adds a chosen subset of models to it, and uses IAM policies to control who can see and deploy from that hub. Teams then browse a shortlist that legal and security already blessed, not the whole catalog.
The feature has grown past a static allowlist. AWS added the ability to fine-tune models directly inside a private hub, to add your own custom-trained models to it, and to share a hub across accounts so a platform team can curate once and let many accounts consume it. For a regulated shop this is the difference between JumpStart being a compliance headache and being the control point. You decide the menu, and the menu is enforced by IAM rather than by a policy document nobody reads.
What it costs, and where the meter runs
JumpStart itself is free. You pay for the SageMaker instances it deploys onto, billed per second the instance is in service, with no serverless option for these endpoints. The number that matters is the hourly rate of your serving instance times the hours it runs, which for an always-on endpoint is roughly 730 hours a month. A small GPU instance is affordable. A large multi-GPU one is not, and the gap is wide, so the instance choice is the cost decision.
| Instance | Rough $/hour | Always-on $/month | Typical use |
|---|---|---|---|
| ml.g5.xlarge | 1.41 | ~1,030 | 7B to 8B, light load |
| ml.g5.2xlarge | 1.52 | ~1,110 | 8B serving, steady |
| ml.g5.12xlarge | 5.67 | ~4,140 | fine-tune, larger models |
| ml.p4d.24xlarge | 37.69 | ~27,500 | very large models |
Rates are illustrative us-east-1 figures and move often. Confirm on the SageMaker pricing page before you plan. [VERIFY current instance rates]
Worked example
Say you serve a Llama 3 8B chat feature on an ml.g5.2xlarge at about 1.52 dollars an hour. Always on, that is roughly 1,110 dollars a month before a single token of value, whether you get 100 requests a day or 100,000. Now price the same traffic on a serverless Bedrock model. At low volume the Bedrock per-token bill is a fraction of 1,110 dollars, so Bedrock wins outright. The JumpStart endpoint only pulls ahead once your steady traffic is heavy enough that the same tokens on Bedrock would cost more than the flat monthly instance floor. Estimate your monthly token volume, price it both ways, and compare against that 1,110 dollar floor before you deploy. [VERIFY current ml.g5.2xlarge rate]
Where JumpStart trips teams up
The forgotten endpoint is the classic one, and I keep hammering it because it keeps happening. Someone deploys a model to test an idea on a Friday, the endpoint runs all weekend, and Monday the instance has quietly billed for 60 idle hours. There is no serverless fallback that scales this to zero. If an endpoint is not carrying traffic, delete it, and if it needs to survive but sees bursty load, look at whether async or a smaller instance fits better than a large one held warm.
Instance quotas are the second trap. SageMaker endpoint instance limits are separate from EC2 limits, per Region, and default low, so your first deploy of a GPU instance often fails with a limit error until you file an increase, which is not instant. Plan that request days ahead of a launch, not the morning of. The third is version drift. A JumpStart model ID pins a specific version, and AWS updates the catalog, so a script that worked last quarter can point at a model that has moved or, after the March 2026 trim, is gone. Pin versions deliberately and re-test when you upgrade.
The last one is oversizing. It is tempting to deploy an 8B model on a big multi-GPU instance because it feels safe, but you pay for every one of those GPUs whether the model uses them or not. Start on the smallest instance the model card recommends, load test it against your real latency target, and only move up if you miss the target. Buying headroom you never use is the most expensive habit on this service.
When I pick JumpStart over Bedrock
My default on AWS is Bedrock, and I move to JumpStart for three reasons only. I need an open-weight model that Bedrock does not offer. I need the endpoint isolated on dedicated hardware inside my VPC for a compliance requirement. Or I have steady, heavy traffic where a right-sized always-on instance genuinely costs less than the same tokens metered on Bedrock. Miss all three and Bedrock is the cheaper, calmer choice, and the instance you would have babysat is pure overhead.
When I do use JumpStart, I curate a private hub so teams see an approved shortlist, I pin model versions, I start on the smallest instance the model tolerates, and I put a hard budget alarm on the account so a forgotten endpoint cannot run silently for a month. Treat the endpoint as a standing cost you have to justify, the same way you would a reserved database, not as a free side effect of a deploy button.
Part 19 moves from single endpoints to training at real scale with SageMaker HyperPod, where you stop borrowing managed instances and start running resilient GPU clusters of your own. If you work across clouds, the closest parallel to JumpStart is deploying open models on Azure Machine Learning, which trades the same serverless simplicity for the same instance control. This week, run one command: list your in-service SageMaker endpoints, note which ones served zero requests in the last day, and delete them. That one habit pays for itself faster than any tuning you will do on this service.
References
• SageMaker JumpStart pretrained models
• Private curated hubs for foundation model access control
• Deploy and fine-tune foundation models in JumpStart with two lines of code
• Amazon SageMaker pricing
About The Author
DrJha