AWS generative AI developer exam prep · Lesson 3 of 17
Choosing, switching and customizing models
There's no best model, only the best fit. Compare candidates on what the task needs: quality on your own examples (not just public benchmarks), the modalities it takes (text, images, documents), the size of its context window, latency, price per input and output token, the languages it handles, and which Regions offer it. A proof of concept in Bedrock on a sample of real data answers most of these in a day.
Smaller models are faster and cheaper; bigger ones reason better. Many apps use both: a small model for routine requests and a larger one only when the request is hard. This is called model cascading or tiered routing. Bedrock's Intelligent Prompt Routing can do a version of it for you, sending each prompt to one of the models in a router (from the same family) based on the quality and cost it predicts.
Don't hard-code a model id in every service. Put the choice in configuration, so it can change without a deploy. A common exam pattern is Amazon API Gateway in front of an AWS Lambda function that reads the model id and settings from AWS AppConfig. Switching models, or rolling a new one out to 10% of traffic, becomes a config change.
Models live in some Regions and not others, and each account has throughput quotas. Cross-Region inference sends requests through an inference profile (you pass its id where the model id would go), and Bedrock routes each request to a Region in that profile's set, which raises how much traffic you can serve and helps when a model isn't in your Region. Check where your data may be processed: a geographic profile keeps requests within its geography.
Plan for failure. Retry throttled calls with exponential backoff and jitter (the AWS SDKs do this). For bigger outages, a circuit breaker stops calling a failing model for a while and uses a fallback: a second model, another Region, a cached answer, or a simpler response. AWS Step Functions can run this logic with retries, catches and choice states, so the app degrades gracefully rather than failing.
Most needs are met with prompts and retrieval. Fine-tuning a model (training it further on your labeled examples) is for a consistent style, format or narrow skill that prompts can't reach. Parameter-efficient methods like LoRA train small adapter weights instead of the whole model, which is cheaper and lets you keep several adapters for one base model. Customized models can be hosted in Bedrock (check the current deployment options for each model) or on Amazon SageMaker AI endpoints, with SageMaker Model Registry tracking versions, approvals and rollbacks.
Practice
A company wants to move 10% of traffic to a new model, watch quality, then switch fully, without redeploying the app. What fits best?
More info
Quick reference
Model cascading
Cheap model first, bigger model only when needed.
Intelligent Prompt Routing
Bedrock routes each prompt between models in a router.
AWS AppConfig
Change settings (like the model id) without a deploy.
Inference profile
Id you call instead of a model id; enables cross-Region inference.
Circuit breaker
Stop calling a failing dependency and use a fallback for a while.
Fine-tuning / LoRA
Train further on your examples / train small adapter weights.
SageMaker Model Registry
Versions, approvals and rollback for custom models.