How Embeddings Pricing Works

Generating an embedding is almost free

アン embedding is a list of numbers — a vector — that represents the meaning of a piece of text, so a search or RAG system can compare meanings by comparing numbers instead of words. Providers bill embedding generation per 入力トークン, the same unit used for LLM prompts, and the rates are the cheapest in the entire AI pricing stack:

Embed 1 million documents averaging 500 tokens each — 500 million tokens — on the cheapest model above, and the generation bill is about $10. Once. That number is so small it barely shows up on an invoice, which is exactly why most cost estimates for a RAG or search feature stop there.

The real cost starts after generation: storing the vectors

Each embedding call doesn't just cost tokens — it produces something: a vector of floating-point numbers that has to live somewhere a database can search it, for as long as the feature exists. That's a 繰り返しの cost, billed by the gigabyte-month, and it's driven by a different variable entirely: dimension count.

A 1,536-dimension vector stored as float32 is 1,536 × 4 bytes ≈ 6 KB. Multiply by 1 million vectors and the raw payload is about 6 GB — before any indexing structure is added on top. A 3,072-dimension model doubles that to ~12 GB for the identical 1 million documents, for no change in token cost at generation time.

Raw vector size before index overhead. The generation cost for any of these rows was a one-time, low double-digit dollar amount; the storage row is what repeats every month the feature stays live.

Index overhead and the "up to 4×" multiplier

Raw vector bytes are the floor, not the bill. Vector databases wrap vectors in an approximate-nearest-neighbor index (commonly HNSW), which adds graph edges and metadata — typically 20–50% more storage on top of the raw payload just to make search fast. Then production reality adds more: a replica for high availability roughly doubles it again, and snapshots or backups add another slice. Stack those together and the realistic multiplier on raw vector bytes commonly lands in the 2–4× range before a single query has been served.

That's the gap between "1 million vectors is 6 GB" and what actually shows up on a managed vector database invoice. It's not a hidden fee — it's the normal cost of making a vector store fast and durable — but it's rarely included when a feature's AI cost is estimated from the embedding API's rate card alone.

The lever most teams never touch: fewer dimensions, on purpose

Storage cost is linear in dimension count — a 1,024-dimension vector costs exactly two-thirds of a 1,536-dimension one to store, dollar for dollar, with no change to the token price of generating it. Newer embedding models expose this as a setting: OpenAI's text-embedding-3 models accept a dimensions parameter that truncates the output vector, and by OpenAI's own published benchmark, text-embedding-3-large truncated to 256 dimensions still scores higher than the older ada-002 model at its full 1,536 dimensions — roughly six times less storage for better retrieval quality, not worse.

Quantizing the stored vector from 32-bit floats to 8-bit integers (or further, to binary) is a second, independent lever that stacks on top — a 4× or larger reduction in bytes per dimension. Neither change touches the generation cost; both change the recurring one, which is the one that actually compounds with corpus size.

Worked example: the two bills side by side

Take a support knowledge base: 2 million chunks, embedded once on text-embedding-3-small (1,536 dims, $0.02/1M tokens), averaging 400 tokens per chunk.

The $16 happens once. The storage line repeats for as long as the knowledge base is live — a year of hosting can cost many times more than embedding the entire corpus did in the first place, and nobody budgeted for it because the quote everyone remembers is the token price.

When the token cost comes back: switching models

Every embedding model produces its own, incompatible vector space — a vector from one model can't be compared against a vector from another. That means switching embedding models later, for better quality or lower storage, isn't a config change: it requires re-embedding the entire corpus from scratch, at full generation cost, all over again. A pipeline that embeds 2 million chunks every time a better model ships pays that $16 (or whatever the current volume costs) on every migration, indefinitely — the one part of this stack where the token price actually matters twice.

よくある間違い

• Pricing the feature from the embeddings API rate card alone. Generation is usually under 5% of an embedding-based feature's lifetime cost once storage is included.
• Defaulting to a model's maximum dimension count. Higher dimensions aren't automatically better retrieval — test a truncated or smaller-dimension model before paying to store numbers you don't need.
• Forgetting replicas and backups when estimating storage. The raw vector-bytes math is the floor; production infrastructure typically runs 2–4× above it.
• Re-embedding more often than necessary. Each full re-embed of a large corpus repeats the one-time generation cost at full volume — batch model migrations rather than chasing every point release.

学び続ける

よくある質問

Are embeddings expensive to generate?

No — generation is one of the cheapest things you can do with an AI API. The lowest-cost models run about $0.02 per 1 million tokens, so embedding 500 million tokens of text (roughly 1 million documents) costs around $10, one time. The recurring cost that actually matters shows up later, in storage.

Why is vector storage more expensive than generating the embeddings?

Generation is billed once, by the token, at a fraction of a cent per thousand words. Storage is billed every month, by the gigabyte, for as long as the vectors exist. A million 1,536-dimension vectors are about 6 GB of raw float32 data — add 20–50% index overhead and that recurring bill can exceed the one-time generation cost within a few months.

How do I calculate how much storage my embeddings will need?

Multiply the embedding's dimension count by 4 bytes (float32), multiply that by how many vectors you'll store, then add index overhead — typically 20–50% for an HNSW-style graph, more once replicas and backups are counted. Divide by a billion for gigabytes, then multiply by your vector database's per-GB-month rate.

Can I reduce embedding storage cost without losing accuracy?

Yes. Newer embedding models let you truncate the output to fewer dimensions — OpenAI's text-embedding-3-large at 256 dimensions still outperforms the older ada-002 model at its full 1,536 dimensions on OpenAI's own benchmark, while using roughly 6× less storage. Quantizing float32 vectors to int8 or binary is a second, stackable saving.