RAG Chunking & Embedding Cost Calculator

Enter how many tokens your corpus holds and how many documents they are spread across, then the chunk size and overlap your splitter uses, the size of your embeddings and how many chunks each query retrieves. The calculator counts the chunks document by document, sizes the vector index at four precisions, prices embedding the corpus on every listed model that produces vectors of that size, and shows how many tokens retrieval adds to each prompt. If you know your corpus in words or characters rather than tokens, convert it first with the LLM token calculator.

How the chunks are counted

A splitter slides a window of C tokens along each document and moves it on by the stride, the chunk size less the overlap O, until the window reaches the end. The overlap is your percentage of the chunk size rounded down to whole tokens, so the window always moves. A document no longer than one chunk stays whole, and a longer one takes as many more windows as it needs to cover what the first leaves over:

chunks per document = 1 + ⌈(L − C) ÷ (C − O)⌉

L is the average document length, the corpus divided by the number of documents. Every chunk after a document's first repeats O tokens of the one before it, so the embedding model reads the whole corpus plus one overlap for each of those chunks.

The defaults describe 100 million tokens in 50,000 documents of 2,000 tokens each, cut into 512-token chunks with 25% overlap. The overlap is 128 tokens and the stride 384, so each document takes 1 + ⌈1,488 ÷ 384⌉ = 5 chunks: four full ones and a fifth holding the last 464 tokens. That makes 250,000 chunks. The four repeated overlaps in each document add 25.6 million tokens, so 125.6 million reach the embedding model. Read as one continuous text, the same corpus would make 260,417 chunks, 4% too many, and with 1,000-token documents and 10% overlap the error runs the other way, 28% too few. Chunks stop where documents stop, which is why the calculator asks how many there are.

Where chunks came from

Cutting a corpus into equal pieces is older than the vector database. For Dense Passage Retrieval, published in 2020, Vladimir Karpukhin and colleagues took the English Wikipedia dump of 20 December 2018 and split every article into disjoint blocks of 100 words, 21,015,324 passages, each prefixed with its article's title and embedded as a 768-dimension vector. Building the FAISS index over them took 8.5 hours on a single server. Patrick Lewis and co-authors reused those passages in the 2020 paper that named retrieval-augmented generation: "Each Wikipedia article is split into disjoint 100-word chunks, to make a total of 21M documents." They retrieved five or ten per query in training, and the index needed about 100 GB of memory until compression brought it down to 36 GB.

Overlap arrived with the frameworks that made retrieval routine, and their defaults still disagree. LangChain's text splitters cut 4,000-character chunks with 200 characters of overlap, LlamaIndex's sentence splitter 1,024 tokens with 200, and OpenAI's file search 800 tokens with 400, the most its API allows, since overlap may not exceed half a chunk. Microsoft measured the trade-off for Azure AI Search in 2023. On its own benchmark of customer queries, using ada-002 embeddings, 512-token chunks recalled more than 1,024-, 4,096- or 8,191-token ones, and 25% overlap edged out 10%. Its documentation now recommends starting at 512 tokens with 25% overlap, 128 tokens, which are this calculator's defaults.

Embedding has become cheap along the way. OpenAI's first-generation embedding models, shut down on 4 January 2024, cost $4 to $200 per million tokens. The replacement its deprecations page names, text-embedding-3-small, costs $0.02. The third generation also takes a dimensions parameter that shortens its vectors, and OpenAI reports that text-embedding-3-large cut to 256 dimensions still outscores the 1,536-dimension text-embedding-ada-002 on the MTEB benchmark.

How much memory the index needs

HNSW, the graph index most vector databases search by default, keeps every vector in memory together with links to its nearest neighbours. At FP32 each dimension takes four bytes, so a 1,536-dimension vector takes 6,144. The links depend on M, the number of neighbours each vector keeps. Malkov and Yashunin's HNSW paper found twice M a good limit on the bottom layer, hnswlib allows exactly that, and M defaults to 16 in hnswlib, Qdrant and pgvector, so each vector carries 32 neighbour IDs of four bytes: 128 bytes. hnswlib's documentation puts the graph at roughly M × 8 to 10 bytes per stored element, and Qdrant's capacity guide sizes it as m × 2 × 4 bytes plus 20%. The calculator counts the bare 128 bytes and leaves out the upper layers, IDs and headroom.

index RAM = chunks × (dimensions × bits ÷ 8 + 2 × M × 4 bytes)

Quantization shrinks only the vectors. FP16 halves them, int8 scalar quantization cuts them by a factor of 4, and binary quantization, which keeps one bit per dimension, by a factor of 32. The links stay the same size, so at 1,536 dimensions a binary vector is 192 bytes of data and 128 of links, and the index shrinks 19.6 times rather than 32: 1.46 GiB at FP32 against 76.29 MiB at the defaults. The quantized rows assume the full-precision vectors stay on disk to rescore the best candidates, the layout Qdrant recommends for saving memory. In Hugging Face's 2024 tests across 15 MTEB retrieval benchmarks, a 1,024-dimension model kept 92.53% of its performance in binary and 96.45% with rescoring, and about 97% in int8 without it. Qdrant warns that one bit per dimension loses too much below about a thousand dimensions. In pgvector the FP16 row matters for large embeddings: its indexes take vector columns of up to 2,000 dimensions but halfvec columns of up to 4,000, so 3,072-dimension vectors are indexed at half precision or as binary-quantized bits.

What indexing costs, and what each query costs

The rates below are standard prices per million input tokens from OpenAI's and Google's pricing pages, checked in October 2026, and the table reads the same data file as the calculator. OpenAI's batch rates apply the 50% discount of its Batch API, which takes up to 50,000 embedding inputs per batch, so the default corpus would go in five batches. Google lists the batch price of gemini-embedding-2 directly.

At the defaults, text-embedding-3-small embeds the 125.6 million tokens for $2.51, or $1.26 in batches, and gemini-embedding-2 charges $25.12. The cost that keeps growing is the context each answer reads. Five chunks averaging 502.4 tokens add 2,512 tokens to every prompt, half a cent at $2 per million input tokens, so 500 queries cost as much as embedding the whole corpus once with text-embedding-3-small. Enter the prompt tokens in the LLM API cost calculator for a monthly bill on current models.

Chunk size pulls the two apart. At 256 tokens the defaults make 550,000 chunks and a 3.21 GiB FP32 index, but five chunks add only 1,200 tokens to a prompt. At 1,024 tokens there are 150,000 chunks in 897.22 MiB, and the prompt grows to 4,187 tokens.

What the estimate leaves out

Every document is treated as the average length. A corpus of many short documents and a few long ones usually makes more chunks than the average suggests, because each short document is still a chunk of its own. Token counts differ between providers, since each tokenizer splits text its own way, and the calculator applies one count to every model. Many pipelines prepend a title or heading path to each chunk before embedding it, which adds tokens to every chunk and every prompt. The RAM covers one copy of the vectors and the bottom layer of the graph; replicas multiply it, and IDs, payloads and filter indexes add to it. To price hosting the same vectors on a managed service, use the vector database cost calculator.

Prices change without notice and figures here are estimates, not quotes; this site is not affiliated with any provider named above. See the site disclaimer.