Amazon Titan Text Embeddings V2 on Bedrock: Model ID, Dimensions, Pricing, Python Examples, Semantic Search, Binary and Image Embeddings, and Errors Fixed

Amazon Titan Text Embeddings V2 (model ID amazon.titan-embed-text-v2:0) is Amazon's text embedding model on Bedrock: it turns text of up to 8,192 tokens or 50,000 characters into a vector of 1,024, 512 or 256 numbers, normalized by default, as float or binary values, for semantic search, RAG, clustering and classification. It is optimized for English and supports more than 100 other languages in preview, and at about $0.02 per million tokens it is one of the cheapest embedding models on any cloud. You call it with InvokeModel and a body of {"inputText": "...", "dimensions": 512, "normalize": true}, and read the vector from embedding in the response. The older Titan Embeddings G1 - Text outputs 1,536 numbers and has no settings, and Titan Multimodal Embeddings G1 embeds images and short text together. Below: what embeddings are in plain English, every Titan model compared with Cohere and Nova embeddings on Bedrock, working Python, a small semantic search you can run, how to choose dimensions with real storage math, binary vectors, image search, pricing, throttling (by requests, not tokens), vector stores, and the errors you will meet.

After Jake's computer shop tagged eight years of repair notes, Ethan wanted one more thing: when a laptop came in with a strange fault, he wanted to type a description and see the five most similar past repairs, even when the old notes used completely different words. "Fan screams then shuts off" should find "overheats, thermal shutdown, cleaned heatsink." Keyword search could not do that. Embeddings could, and Titan Text Embeddings V2 made it cost less than a coffee for all 18,000 notes. This page is how it works.

New to Bedrock? Our plain-English Bedrock explainer covers the service itself, and the cards below cover the rest.

What a Titan embedding is, in plain English

An embedding is a list of numbers that captures what a piece of text means. Feed the model "my laptop gets very hot and turns itself off" and it returns, say, 512 numbers. Feed it "overheating, thermal shutdown" and it returns 512 different numbers that are close to the first set, because the meanings are close, even though the two sentences share no words. Feed it "the screen has a crack" and the numbers land far away.

That one property, similar meaning means nearby numbers, is what powers:

• Semantic search: find documents by meaning, not exact words.
• RAG (retrieval-augmented generation): find the passages a chatbot should read before it answers.
• Recommendations and duplicates: "customers who asked this also asked..."; spotting near-identical tickets.
• Clustering and classification: group thousands of texts by topic without labeling them first.

Titan embeddings are Amazon's own embedding models, offered through Amazon Bedrock. You send text (or, with the multimodal model, an image) and get the numbers back; storing and searching those numbers is the job of a vector database, not of the model. The model is the translator into "meaning space"; the database is the map.

Jake: "So the computer doesn't understand the note, it just knows which notes sit near each other?"

Ethan: "That's the whole trick. And 'near each other' turns out to be very close to 'means the same thing.'"

Every embedding model on Bedrock, compared

All of these are Active models on Bedrock as of October 2026, and our model IDs list tracks their Regions and lifecycle dates. For most English text projects the decision is quick: start with Titan Text Embeddings V2, and move to Cohere Embed v4 if multilingual quality or very long inputs matter, or to a multimodal model if your content includes images or video.

Titan Text Embeddings V2: every specification

Three of those rows matter more than they look. The 8,192-token limit is a ceiling, not a target: for search, one vector per paragraph or section finds things far more precisely than one vector per whole document, so split long documents before embedding. Normalization on means every vector has length 1, so the simple dot product of two vectors equals their cosine similarity, which keeps comparison code trivial. And throttling by requests means a quota of, say, a few thousand requests per minute is the same whether each request carries ten words or ten pages, so fewer, fuller requests (or a batch job) go further than many tiny ones.

Your first embedding in Python

With boto3 and your normal AWS credentials, in a Region where the model is available:

import json
import boto3

brt = boto3.client("bedrock-runtime", region_name="us-east-1")
encode = json.JSONEncoder().encode

def embed(text: str, dims: int = 512) -> list[float]:
    resp = brt.invoke_model(
        modelId="amazon.titan-embed-text-v2:0",
        body=encode({"inputText": text, "dimensions": dims, "normalize": True}),
        contentType="application/json",
        accept="application/json",
    )
    result = json.loads(resp["body"].read())
    return result["embedding"]

v = embed("Laptop gets very hot and turns itself off")
print(len(v), v[:5])   # 512 [0.031..., -0.012..., ...]

The response also includes inputTextTokenCount, the number of tokens billed, and embeddingsByType, which holds the float and/or binary versions you asked for. One quirk: if you request only binary ("embeddingTypes": ["binary"]), the plain embedding field is absent and the vector is at embeddingsByType["binary"].

Comparing two texts takes one more function. Because the vectors are normalized, cosine similarity is just a dot product:

def similarity(a: list[float], b: list[float]) -> float:
    return sum(x * y for x, y in zip(a, b))

q  = embed("fan screams then shuts off")
n1 = embed("overheats, thermal shutdown, cleaned heatsink and replaced paste")
n2 = embed("cracked screen, replaced LCD panel")
print(round(similarity(q, n1), 3), round(similarity(q, n2), 3))
# the first score is clearly higher than the second

Scores near 1 mean nearly identical meaning; unrelated texts score much lower. The exact numbers depend on the texts, so judge them relative to each other rather than against a fixed threshold, at least until you have tried them on your own data.

From the AWS CLI, handy for a quick test without writing code (CLI version 2):

aws bedrock-runtime invoke-model \
  --region us-east-1 \
  --model-id amazon.titan-embed-text-v2:0 \
  --cli-binary-format raw-in-base64-out \
  --body '{"inputText": "Laptop gets very hot and turns off", "dimensions": 256}' \
  embedding.json

The vector lands in embedding.json. The --cli-binary-format raw-in-base64-out flag lets you pass the body as plain JSON; without it, CLI version 2 expects base64 and rejects the request. On Windows PowerShell, save the body to a file and pass --body fileb://body.json.

From JavaScript (Node.js with the AWS SDK for JavaScript v3):

import { BedrockRuntimeClient, InvokeModelCommand } from "@aws-sdk/client-bedrock-runtime";

const client = new BedrockRuntimeClient({ region: "us-east-1" });

export async function embed(text, dimensions = 512) {
  const res = await client.send(new InvokeModelCommand({
    modelId: "amazon.titan-embed-text-v2:0",
    contentType: "application/json",
    accept: "application/json",
    body: JSON.stringify({ inputText: text, dimensions, normalize: true }),
  }));
  return JSON.parse(new TextDecoder().decode(res.body)).embedding;
}

If you use LangChain, BedrockEmbeddings(model_id="amazon.titan-embed-text-v2:0") wraps the same call; our LangChain with Bedrock guide shows it inside a full RAG app.

Build a small semantic search, step by step

Here is the shop's "find similar repairs" feature at its smallest: no database, just Python and NumPy, which handles tens of thousands of notes comfortably.

1. Prepare the texts. One entry per note (or per paragraph of longer documents), each with an ID.
2. Embed them all once and save the vectors to disk, so this step only repeats for new notes.
3. Embed the query with the same model and the same dimensions.
4. Score every note against the query with a dot product and take the top five.
5. Show the matches with their scores, so a person can judge them.

import csv
import numpy as np

# Steps 1 and 2: embed every note once (reuse embed() from above)
ids, texts = [], []
with open("tagged_notes.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        ids.append(row["note_id"])
        texts.append(row["note"])

vectors = np.array([embed(t) for t in texts], dtype=np.float32)
np.save("note_vectors.npy", vectors)

# Steps 3 to 5: search
def find_similar(query: str, k: int = 5):
    q = np.array(embed(query), dtype=np.float32)
    scores = vectors @ q                       # dot product with every note at once
    best = np.argsort(-scores)[:k]
    return [(ids[i], float(scores[i]), texts[i]) for i in best]

for note_id, score, text in find_similar("fan screams then shuts off"):
    print(f"{score:.3f}  {note_id}  {text}")

Embedding 18,000 notes one call at a time takes a while and spends 18,000 requests of your per-minute quota, so for the first full load either run several calls in parallel (a thread pool of four to eight workers is plenty) or use a batch inference job; our batch inference guide has the JSONL format for Titan embeddings. After that, only new notes need embedding.

When the collection grows past a few hundred thousand vectors, or several people search at once, move the vectors into a proper vector store (covered below). The embedding part of the code does not change.

Jake: "I typed 'smells like burning when charging' and it found the three bad chargers from last spring."

Ethan: "None of those notes say 'smell.' They say 'scorched DC jack' and 'melted connector.' That's the embeddings doing their job."

How to split documents before embedding

Short texts such as repair notes, tickets and product titles can be embedded whole. Longer documents (manuals, policies, contracts) need splitting into chunks first, because one vector for a 40-page manual is a blurry average of everything in it, and a search for one specific clause cannot find it. A routine that works for most documents:

1. Extract clean text from the files, keeping headings. Drop repeated page headers and footers, which otherwise end up in every chunk.
2. Split along the document's own structure first: sections, then paragraphs. A chunk that follows a heading is easier to understand on its own than one cut mid-sentence.
3. Aim for a few hundred tokens per chunk, roughly 200 to 600 words. Combine very short paragraphs; split very long ones at sentence boundaries.
4. Overlap neighboring chunks slightly, by a sentence or two, so an idea that straddles a boundary is fully present in at least one chunk.
5. Prefix each chunk with its context: the document title and section heading ("Warranty policy > Accidental damage"). It costs a few tokens and makes the chunk's meaning, and its vector, much clearer.
6. Keep metadata with each vector: source file, page, section, date. You will want to show it to users and filter by it later.

A simple paragraph-based splitter in plain Python:

def chunk_text(title: str, text: str, max_words: int = 350):
    paragraphs = [p.strip() for p in text.split("\n\n") if p.strip()]
    chunks, current = [], []
    for p in paragraphs:
        if current and len(" ".join(current + [p]).split()) > max_words:
            chunks.append(f"{title}\n" + "\n".join(current))
            current = current[-1:]          # one paragraph of overlap
        current.append(p)
    if current:
        chunks.append(f"{title}\n" + "\n".join(current))
    return chunks

Libraries such as LangChain's RecursiveCharacterTextSplitter do the same with more options. Bedrock Knowledge Bases offer fixed-size, hierarchical and semantic chunking if you let them manage the documents.

Jake: "So you cut the warranty PDF into pieces before the computer reads it?"

Ethan: "Into about forty pieces, each with its heading on top. Then a question about cracked screens lands on the one piece about accidental damage, not on the whole PDF."

Choosing dimensions: 1,024, 512 or 256

Titan Text Embeddings V2 lets you pick how many numbers each vector has. More dimensions keep slightly more detail; fewer make storage and search cheaper and faster. For many retrieval tasks, the drop from 1,024 to 512 is small, while the storage halves.

The storage math for one million vectors, stored as standard 4-byte floats:

Vector databases keep indexes in memory for speed, and memory is what you pay for, so these numbers translate fairly directly into monthly cost. A sensible way to choose:

• 1,024 when accuracy matters most and the collection is modest, or when precise ranking of near-duplicates is the point.
• 512 as the everyday default for RAG and document search: most of the quality at half the size.
• 256 for very large collections, or as a fast first pass before re-ranking.

Whatever you choose, it is permanent for that index: the vector store is created for one size, and vectors of another size cannot be added or compared. Changing dimensions means re-embedding everything, which is cheap with Titan but takes time.

Binary embeddings: 32 times smaller

Ask for "embeddingTypes": ["binary"] and Titan returns each dimension as a single bit (1 or 0) instead of a 32-bit number, so a 1,024-dimension vector shrinks from 4,096 bytes to 128. Similarity between binary vectors is measured by counting matching bits (Hamming distance), which computers do extremely fast.

Binary vectors lose some precision, so the common pattern is a two-stage search: search the full collection with binary vectors to get, say, the top 200 candidates quickly and cheaply, then re-score those 200 with the float vectors (or a re-ranking model) to pick the final top five. You can request both types in one call with ["float", "binary"], store the binary ones in the fast index and keep the float ones on cheaper storage for re-scoring.

Several vector stores, including OpenSearch, support binary vectors directly. For collections under a million or so, plain float vectors are usually simpler and the savings are not worth the extra stage.

Titan embeddings inside a RAG answer

Search finds the right passages; RAG hands them to a language model to write the answer. With the search function from earlier and a chat model on Bedrock, the whole loop fits on one screen:

def answer(question: str) -> str:
    hits = find_similar(question, k=4)                 # (id, score, text) from the search example
    context = "\n\n".join(f"[{note_id}] {text}" for note_id, _, text in hits)
    resp = brt.converse(
        modelId="us.amazon.nova-pro-v1:0",
        system=[{"text": "Answer from the repair notes below and cite note IDs in brackets. "
                         "If the notes do not answer the question, say so.\n\n" + context}],
        messages=[{"role": "user", "content": [{"text": question}]}],
        inferenceConfig={"maxTokens": 400, "temperature": 0},
    )
    return resp["output"]["message"]["content"][0]["text"]

print(answer("What usually fixes a fan that screams and then shuts down?"))

The embeddings decide what the model gets to read, so they decide the quality of the answer more than the chat model does: a strong model given the wrong passages answers confidently and wrongly. When a RAG app gives poor answers, look at the retrieved passages first. If the right one is missing, fix chunking or dimensions; if it is there but ignored, fix the prompt or the model.

Two settings shape what the model reads. How many passages (k): three to five usually beats one (too little context) or twenty (the model drowns in loosely related text and pays for every token). A minimum score: if even the best match scores low compared with what good matches usually score in your data, it is better to tell the model "nothing relevant was found" than to hand it weak passages that invite an invented answer. Find the cut-off by looking at scores for your 30 test questions, described below.

Meaning plus keywords: hybrid search

Embeddings are excellent at meaning and surprisingly weak at exact strings. A search for "T14 Gen 3" may happily return notes about a T14 Gen 2 or a T15, because their meanings are close, while the person searching wanted that exact model. Part numbers, error codes, serial numbers and names behave the same way.

The fix is hybrid search: run a keyword search and a vector search together, and combine their rankings. OpenSearch supports this directly with hybrid queries, and in PostgreSQL you can combine pgvector with full-text search. In a small setup like the shop's, a simple rule goes a long way: if the query contains something that looks like a model or part number, boost results that contain that exact string.

import re

def hybrid_search(query: str, k: int = 5):
    results = find_similar(query, k=50)
    codes = re.findall(r"\b[A-Z]{1,3}\d{2,}[A-Za-z0-9-]*\b", query)   # e.g. T14, X1, 0x8007
    def boosted(item):
        note_id, score, text = item
        bonus = 0.1 * sum(code.lower() in text.lower() for code in codes)
        return score + bonus
    return sorted(results, key=boosted, reverse=True)[:k]

Meaning finds the right kind of note; the keyword boost puts the exact model first. Most production search systems end up hybrid for exactly this reason.

Jake: "Last week it kept showing me T15 notes when I typed T14."

Ethan: "To the embeddings, a T14 and a T15 are basically the same laptop. The keyword boost tells it you meant the exact one."

How to tell whether your search is any good

"It seems to work" is not a test. Twenty minutes of setup gives you a number you can improve:

• Write 30 test questions the way real users ask them, each paired with the note or chunk that should come back.
• Run each question and check whether the right answer appears in the top five results. The share of questions where it does is your "recall at 5."
• Change one thing at a time, such as dimensions (1,024 vs 512), chunk size, or the hybrid boost, and rerun. Keep the change if the number goes up.
• Look at the failures by hand. They usually point at one fix: a missing synonym in the notes, chunks that are too long, or a part-number problem that hybrid search solves.

Ethan's first run found the right repair in the top five for most questions; moving to paragraph chunks for the warranty documents and adding the part-number boost lifted it noticeably. Your numbers will differ, which is the point of measuring them.

Keeping vectors up to date

Documents change, and a search index that quietly drifts out of date is worse than none, because people trust it. Three rules keep it current:

• Re-embed only what changed. Store a hash (a short fingerprint, such as SHA-256) of each chunk's text next to its vector. On each update run, embed only chunks whose hash is new or different, and delete vectors whose chunks no longer exist.
• Record the model and settings with every vector: amazon.titan-embed-text-v2:0, 512 dimensions, normalized. Vectors from different settings must never mix in one index.
• Plan for model upgrades. When you move to a newer embedding model, build a new index alongside the old one, re-embed everything into it, run your 30-question test on both, and switch over only when the new one wins. At Titan's prices, re-embedding is cheap; the care is in not mixing the two.

Languages, and the cross-language trap

Titan Text Embeddings V2 is optimized for English and supports more than 100 other languages in preview, from Arabic, Chinese and Hindi to Spanish, Swahili and Welsh. For a single-language collection in one of those languages, it works well.

The trap is cross-language search: documents in one language and questions in another, such as a knowledge base in Korean queried in German. Titan V2 returns noticeably weaker results in that situation. If your users and documents mix languages, either translate everything into one language before embedding, or use a model built for multilingual retrieval, such as Cohere Embed v4 or Cohere Embed Multilingual v3, and test it on real queries in each language pair you need.

Image search with Titan Multimodal Embeddings G1

Titan Multimodal Embeddings G1 (amazon.titan-embed-image-v1) puts images and text into the same "meaning space," so a text query can find images, and an image can find similar images. For a shop, that means photographing a customer's charger and finding the matching part in the catalog photos.

import base64

def embed_image(path: str, caption: str = "", dims: int = 384) -> list[float]:
    with open(path, "rb") as f:
        img = base64.b64encode(f.read()).decode()
    body = {"inputImage": img, "embeddingConfig": {"outputEmbeddingLength": dims}}
    if caption:
        body["inputText"] = caption
    resp = brt.invoke_model(modelId="amazon.titan-embed-image-v1",
                            body=encode(body),
                            contentType="application/json", accept="application/json")
    return json.loads(resp["body"].read())["embedding"]

def embed_text_for_images(text: str, dims: int = 384) -> list[float]:
    body = {"inputText": text, "embeddingConfig": {"outputEmbeddingLength": dims}}
    resp = brt.invoke_model(modelId="amazon.titan-embed-image-v1",
                            body=encode(body),
                            contentType="application/json", accept="application/json")
    return json.loads(resp["body"].read())["embedding"]

Its limits: images up to 25 MB and 2,048 by 2,048 pixels, text up to 256 tokens, English only, and output of 1,024 (default), 384 or 256 dimensions. Use the multimodal model for both the catalog images and the search queries: its text vectors live in a different space from Titan Text Embeddings V2, so the two cannot be mixed. It can also be fine-tuned on your own image-caption pairs, which helps when your images are specialized, such as circuit boards or medical scans.

For newer projects that mix documents, images, audio and video, Amazon Nova Multimodal Embeddings covers all of them in one space and is worth testing alongside it.

Titan embeddings pricing, with worked examples

Embeddings are billed per input token; there are no output tokens. On-demand list prices in US East (N. Virginia):

• Titan Text Embeddings V2: about $0.02 per million tokens.
• Titan Embeddings G1 - Text: about $0.10 per million tokens, five times V2, one more reason to move to V2.
• Titan Multimodal Embeddings G1: priced per text token and per image.

What that means in practice with V2:

Batch inference roughly halves the indexing cost, though at these prices the saving is pennies; the reason to batch large loads is speed and quotas, not money. The real cost of a search system is almost never the embeddings: it is the vector database that holds them, and the language model that reads the results in a RAG app. Our Bedrock pricing guide covers the model side.

Throttling and throughput

Embedding models on Bedrock are throttled by requests per minute (RPM), not tokens per minute. When you exceed the quota, calls fail with a ThrottlingException ("Too many requests, please wait before trying again"). Three habits avoid it:

• Retry with backoff. boto3 can do it for you: create the client with config=botocore.config.Config(retries={"max_attempts": 10, "mode": "adaptive"}).
• Cap parallel calls. A thread pool of a handful of workers loads data fast without tripping the quota; dozens of workers only produce errors.
• Use batch for big loads. A batch job processes huge volumes without touching your on-demand RPM quota.

If production search traffic needs more, request a quota increase for the model's requests per minute in the Service Quotas console, a week or so before you need it. Our throttling guide covers the details.

Where to store Titan vectors

Titan produces the vectors; something else must store and search them. Common choices on AWS:

• Bedrock Knowledge Bases, if you would rather not handle any of this: they chunk your documents, embed them (Titan Text Embeddings V2 is a standard choice) and manage the vector store for you. Our knowledge base guide covers the setup.
• Amazon OpenSearch Service or OpenSearch Serverless, a full search engine with k-NN vector search, filters and keyword search combined.
• Amazon Aurora PostgreSQL or RDS with pgvector, when your data already lives in PostgreSQL and you want vectors next to it, queryable with SQL.
• Amazon S3 Vectors, vector storage built into S3, for large collections where low storage cost matters more than the lowest latency.
• Local or embedded stores such as FAISS, Chroma or plain NumPy, as in the example above, for small collections and prototypes.

Whichever you use, create the index with the dimension count you chose (1,024, 512 or 256) and the matching distance metric: cosine, or inner product, which gives the same ranking for normalized Titan vectors. The most common setup error, a "dimension mismatch," comes from an index created for one size receiving vectors of another.

Choosing Titan inside a Bedrock knowledge base

If you let a Bedrock knowledge base manage your documents, the embedding choice is a few fields in its setup, but they are the fields you cannot change later:

• Embeddings model: Titan Text Embeddings V2 is the usual choice for English documents; pick a Cohere model for multilingual collections, or a multimodal model if your documents are image-heavy.
• Dimensions: 1,024, 512 or 256 for Titan V2, as discussed above. The vector store is created to match.
• Vector type: float, or binary where the chosen vector store supports it, for a smaller, cheaper index.
• Chunking: default, fixed-size, hierarchical or semantic. Default is a reasonable start; hierarchical helps with long, well-structured documents.

Changing the embeddings model or dimensions afterwards means creating a new knowledge base and syncing the documents again, so test a few real questions against a small sample before loading everything. The embeddings for a knowledge base are billed at the same per-token rates as calling the model yourself, which, for Titan V2, is rarely the part of the bill worth worrying about. Our knowledge base guide covers the rest of the setup and its costs.

Common Titan embeddings errors and fixes

Titan vs a free local embedding model

If your data must never leave your own machines, or you want zero per-token cost, open embedding models run locally with Ollama; our EmbeddingGemma 2 guide shows one in practice. The trade-off is operational rather than financial: at Titan's price, 25 million tokens cost about 50 cents, so the local route saves money only at very large scale, while it adds a machine to run, update and keep available. For a small business on AWS, Titan is usually the simpler choice; for strict on-premises requirements, local is the only one. The same rule applies either way: vectors from one model cannot be searched with another's, so pick before you index.

Frequently asked questions

The "find similar repairs" box now sits at the top of the shop's notes page. Embedding all 18,000 notes cost about three cents; the search itself runs on the shop PC in a fraction of a second. The best test came the following week, when a customer described a fault in words nobody at the shop had ever written down, and the top match was a repair from 2019 with the exact fix. Jake printed that note and pinned it to the wall, under a sign that said "The computer remembered."

Revision note. Written October 19, 2026. An embedding is a model's way of saying "these mean the same thing" in numbers; the rest of a search system is just keeping those numbers tidy.