Eliminate models that cannot serve the task

Learning objective

Shortlist FMs including Amazon Titan by capability, modality, context length, Region availability, and known limits. Turn the requirements from 1.1.1 into an eligibility decision before benchmarking candidates.

Core idea

A foundation model (FM) belongs on your shortlist only if it can perform the required operation inside the application’s operating boundaries. A strong general reputation cannot compensate for a missing input modality, an unsuitable output type, an inaccessible deployment Region, or a context budget that excludes essential evidence.

Treat selection as two passes. First, eliminate candidates that violate hard constraints. Then compare the remaining candidates with representative measurements; see 1.2.2. Keep generation, embedding, and other specialized model roles separate. A model suitable for one stage of a retrieval-augmented generation pipeline is not automatically suitable for another.

How it works

Define the model’s job

Write down the transformation the model must perform. A summarizer consumes text and produces text. A document assistant might need image understanding as well as text generation. An embedding stage produces vectors for downstream retrieval. Required tool use, streaming, and response format also belong in the capability contract.

Use Amazon Bedrock’s Models at a glance and the linked model details as the starting inventory. AWS has moved the model IDs, supported Regions, modalities, and inference parameters from the former supported-models table into these model pages. Record the exact model identity and the capabilities you checked. A provider name or product family is too broad to serve as a deployment specification.

Amazon Titan illustrates why roles matter. Titan Text Embeddings V2, identified as amazon.titan-embed-text-v2:0, converts text to vectors; it does not generate the cited answer. Its documented input limit is 8,192 tokens or 50,000 characters. Its vector output supports 1,024 dimensions by default, with 512 and 256 as alternatives. Those facts make it an embedding candidate, not an interchangeable conversational model.

The same Titan documentation warns that cross-language retrieval can produce suboptimal results. If your corpus and queries use different languages, include that workload in the eligibility experiment rather than inferring success from a language list. An advertised modality or language establishes a supported input, while a benchmark establishes useful performance on your task.

Budget the actual request

Context capacity must fit everything the model receives, including instructions, conversation history, retrieved evidence, and any tool definitions. Reserve room for the required response under the selected model’s documented accounting rules. A document’s character count alone does not establish its token consumption, and different models can tokenize the same text differently.

For supported Bedrock models, CountTokens counts the input for a supplied Converse or InvokeModel request. Use the same request shape you expect to send, not an isolated document stripped of its wrapper. Counting is an input-budget mechanism; it does not generate an answer or demonstrate that the model uses a long context accurately.

Test examples near the intended operating boundary. Include the longest permitted conversation and the largest useful evidence set. If a candidate fits only after removing material necessary for a correct answer, it fails the task as specified. You can redesign the evidence path, but make that an explicit architecture decision rather than silent truncation.

Check the deployment path

Record the caller Region, model identifier, inference mode, and processing-location constraints together. Availability of Amazon Bedrock in a Region does not mean every model or feature is available there. Use the model-specific AWS documentation to establish whether the intended path is regional or uses an inference profile. Cross-Region implications belong to 1.2.4.

Inspect capacity through Amazon Bedrock endpoints and quotas and the account’s Service Quotas settings. Separate requests-per-minute capacity from token capacity where the selected model uses both. Titan embedding models use requests-per-minute throttling rather than tokens-per-minute throttling. A quota suitable for short generation requests therefore cannot be copied into an embedding-ingestion estimate.

Finally, inspect lifecycle eligibility. GetFoundationModel and ListFoundationModels expose modelLifecycle; the model’s AWS lifecycle documentation supplies retirement conditions. A model that your existing production account can still invoke might be unavailable to a new account because it is Legacy. Capture that distinction before committing a disaster-recovery design to it.

The following evidence makes a shortlist reviewable:

Key distinctions and trade-offs

Capability versus quality: Support for image input is an eligibility fact. Correct interpretation of your images is an evaluation result. Neither substitutes for the other.

Context limit versus useful context: A request can fit within a documented limit while the model fails to use a crucial passage. Include evidence-position and long-input cases in the benchmark.

Model family versus exact version: Versions can differ in limits, availability, and lifecycle. Freeze the exact identity in your candidate record so the comparison is reproducible.

Broader modality support can simplify an application but still require a more expensive or slower generation path. A specialized embedding model can serve retrieval efficiently while requiring a separate generator. Choose the combination that satisfies the application contract, rather than demanding one model do every job.

Architecture / decision scenario

A maintenance assistant must retrieve English manuals, accept photographs of damaged equipment, and draft a cited explanation. You initially receive a recommendation to use Amazon Titan throughout the pipeline.

You separate retrieval from generation. Titan Text Embeddings V2 remains a candidate for the text index. The generator needs documented image-input support and an adequate request budget for the photograph, selected passages, and instructions. Any text-only candidate fails that gate regardless of its summary quality.

You also require processing inside an approved geography. Candidates available only through an incompatible routing path are removed before cost comparisons. The remaining generator and embedding combinations move to the benchmark, with multilingual manuals reserved for a separate evaluated expansion.

Common exam traps

• Choosing a model family without checking the exact version and inference path.
• Treating an embedding model as the response generator.
• Equating service availability with model and feature availability.
• Treating the advertised context limit as measured long-context accuracy.
• Applying a generation token quota to Titan embedding throughput.
• Assuming existing access proves eligibility for a new recovery account.

What to remember

• Apply hard capability and location gates before comparing quality or price.
• Record model identity, inference mode, and caller Region together.
• Use CountTokens where supported to budget representative requests.
• Match capacity estimates to the model’s documented quota mechanism.
• Include lifecycle eligibility in the shortlist, then benchmark the survivors.

Knowledge check

References

• AWS, Models at a glance
• AWS, Amazon Titan Text Embeddings models
• AWS, CountTokens
• AWS, Amazon Bedrock endpoints and quotas
• AWS, Model lifecycle