Embedding Model Comparison: text-embedding-3 vs Voyage 4 vs GLM — Dimensions, Cost, and Recall

An embedding model comparison usually starts with three numbers: dimensions, context length, and price per million tokens. Those three values decide how much memory your vector database eats, how long each document chunk can be, and how much you pay at scale. But they do not tell you which model retrieves better — that requires actually running a recall test on your own data. This article compares the OpenAI text-embedding-3 family, the Voyage 4 family, and the GLM embedding situation as of mid-2026, so you can choose with both the spec sheet and the retrieval reality in view.

If you are building a RAG pipeline or a semantic search system, the embedding model you pick at the start is expensive to change later. Every document you index is stored as a vector of that model dimension count, and swapping models means re-embedding everything. A careful embedding model comparison up front saves weeks of rework.

Verification status: Specs were checked against official docs on 2026-08-25. Prices are per 1 million tokens. Where a vendor does not publish an embedding model, that is stated explicitly rather than estimated.

Three Numbers That Matter

Before diving into individual models, here is what each number actually means for your system:

Dimensions — the length of the vector each model outputs. A 3072-dimensional vector takes twice the storage of a 1536-dimensional one. If you are embedding 10 million documents, the difference between 1024 and 3072 dimensions is roughly 20 GB vs 60 GB of raw vector storage in float32 format. Most modern vector databases support both, but your memory bill scales linearly.

Context length — the maximum number of input tokens the model can embed in a single call. A 32,000-token context means you can embed a full short article in one request. An 8,192-token context means you need to chunk first. This matters less for RAG (you almost always chunk before embedding anyway) but more for long-document search and batch throughput.

Price per million tokens — what you actually pay. At 10 million tokens per month, the difference between $0.02 and $0.13 per million is $200/month vs $1,300/month. For a startup processing user queries in real time, the small model is often enough.

OpenAI text-embedding-3 Family

OpenAI text-embedding-3 family replaced the older text-embedding-ada-002 and introduced two tiers: small and large. Both support the dimensions parameter, which lets you request a shorter vector than the default without retraining — a feature that most competitors matched only later.

The specs below come from OpenAI text-embedding-3-small model card and the text-embedding-3-large model card.

text-embedding-3-small

This is the default choice for most RAG systems. It outputs 1536-dimensional vectors by default, accepts up to 8,192 input tokens, and costs $0.02 per million tokens. You can also request shorter vectors — 256, 512, or 1024 dimensions — by passing the dimensions parameter in the API call. Shorter vectors trade a small amount of retrieval quality for lower storage cost.

At $0.02 per million tokens, embedding a 50,000-document corpus of roughly 500 tokens each (25 million tokens total) costs $0.50. That is essentially free for most projects. The model performs well on standard retrieval benchmarks — not the best, but consistently above the older ada-002 baseline.

text-embedding-3-large

The large variant outputs 3,072-dimensional vectors by default, accepts the same 8,192 input tokens, and costs $0.13 per million tokens — 6.5x the small model. It also supports the dimensions parameter, so you can request 256, 512, 1024, or 1536 dimensions if the full 3,072 is too much for your storage budget.

The retrieval quality improvement over the small model is real but modest — typically 1 to 3 percentage points on standard benchmarks like MTEB, depending on the task. For most RAG use cases, that difference does not justify a 6.5x cost increase unless your corpus is small and quality is critical.

Voyage 4 Family

Voyage AI embedding models have gained traction in 2025 and 2026, particularly for teams that need longer context windows or specialized domain embeddings. The Voyage 4 family includes four variants, all sharing a 32,000-token context length and a default dimension count of 1024.

The specs below come from the Voyage AI embeddings documentation and the Voyage AI pricing page.

The Four Voyage Variants

voyage-4-large — the flagship, $0.12 per million tokens. Best retrieval quality in the family, designed for general-purpose text.

voyage-4 — the base model, $0.06 per million tokens. A balanced option for teams that want better-than-OpenAI-small retrieval at a mid-range price.

voyage-4-lite — the budget option, $0.02 per million tokens. Same price as OpenAI small model but with a 32,000-token context and 1024 default dimensions (vs OpenAI 1536). The lower dimension count means about 33% less storage.

voyage-code-4 — specialized for code and technical content, $0.12 per million tokens. If your RAG pipeline indexes code repositories, API documentation, or technical specs, this is the variant to benchmark.

All four variants support 256, 512, 1024, and 2048 dimensions via the output_dimension parameter. Voyage also offers 200 million free tokens per account, which is enough to embed a medium-sized corpus for evaluation.

Choosing the Right Voyage Variant

The decision tree is straightforward:

• If you are embedding general text and want the best retrieval, use voyage-4-large.
• If you are cost-sensitive but still want the 32k context, use voyage-4-lite.
• If you are embedding code or technical documentation, benchmark voyage-code-4 against voyage-4-large on your own data — code embeddings are a different beast, and a specialized model can outperform a generalist one.
• If you want a middle ground, voyage-4 at $0.06 is a reasonable default.

The 32,000-token context is the main structural advantage over OpenAI 8,192. In practice, most RAG pipelines chunk documents to 256 to 512 tokens before embedding, so the context limit rarely matters for retrieval quality. It does matter for throughput: fewer API calls when embedding long documents, which means lower latency on batch jobs.

The GLM Embedding Question

GLM (from Z.AI) has a strong lineup of chat models — GLM-5.3, 5.2, 5.1, and others — but as of August 2026, there is no publicly documented GLM embedding model. The Z.AI documentation lists only chat and vision models. The OurToken models page and the GLM 5.2 model page confirm the same: GLM chat models are available, but no embedding endpoint is exposed.

This is worth stating plainly rather than burying: if your stack already uses GLM for generation, you still need a separate embedding provider. The good news is that embeddings and generation are decoupled — you can use OpenAI or Voyage for embeddings while routing generation to GLM through the same OurToken gateway. This is a common pattern in production RAG systems.

For more on mixing models this way, see our guide on LLM model routing, which covers sending different request types to different models through a single API endpoint.

Side-by-Side Embedding Model Comparison

The price-per-dimension ratio is worth calculating. text-embedding-3-small gives you 1536 dimensions for $0.02, while voyage-4-lite gives you 1024 for the same price. If storage is your bottleneck, OpenAI small model is more storage-efficient per dollar. If context length matters, Voyage wins.

Minimal Embedding Request in Python

All of these models use a similar API shape. Here is a minimal example using the OpenAI Python SDK against an OpenAI-compatible endpoint:

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://api.ourtoken.ai/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-small",
    input="Your text to embed goes here.",
    dimensions=1024  # optional: shorten the default 1536
)

vector = response.data[0].embedding
print(f"Dimensions: {len(vector)}")

For Voyage models, the request shape is similar but uses the Voyage client or the OpenAI-compatible interface if your gateway supports it:

import voyageai

vo = voyageai.Client(api_key="your-voyage-key")

result = vo.embed(
    texts=["Your text to embed goes here."],
    model="voyage-4-lite",
    output_dimension=1024
)

vector = result.embeddings[0]
print(f"Dimensions: {len(vector)}")

The key point: both APIs follow the same pattern — pass text, get a vector. If you are building a RAG pipeline, abstract the embedding call behind a single interface so you can swap models without touching your indexing code.

For a complete RAG pipeline that uses these embeddings alongside generation, see our guide on RAG evaluation metrics, which covers how to measure whether your retrieval actually works.

Choosing for RAG and Search

The right embedding model depends on three factors specific to your system:

Corpus size. If you are embedding 50,000 documents, even the $0.13 large model costs $3 to $5. If you are embedding 50 million documents, the $0.02 model saves you $5,500/month over the large one. Price scales linearly with tokens, so model your token volume before choosing.

Storage budget. Multiply dimensions times number of vectors times 4 bytes (float32) to get raw storage. One million documents at 3072 dimensions equals 12 GB. One million at 1024 dimensions equals 4 GB. If you are paying for managed vector database storage, this number goes straight to your bill.

Recall requirements. This is the one number the spec sheet cannot tell you. You need to test on your own data. Build a small evaluation set of 50 to 100 queries with known relevant documents, embed them with two or three candidate models, and measure recall@5 or recall@10. The model that wins on your data may not be the one that wins on a public benchmark.

A practical approach: start with text-embedding-3-small or voyage-4-lite (both $0.02/1M tokens), build your full pipeline, then benchmark against the larger variants. If the recall improvement justifies the cost, upgrade. If not, you have saved money without sacrificing quality.

For cost optimization on the generation side of RAG, see our guide on OpenAI prompt caching, which reduces the cost of repeated system prompts — a common pattern in RAG where the same retrieval instructions appear in every request.

Measuring Recall

Recall is the percentage of relevant documents your retrieval system finds. If a query has 10 relevant documents in your corpus and your system returns 5 of them in the top-10 results, recall@10 is 50%.

To run an embedding model comparison that produces actionable numbers:

1. Build an evaluation set. Write 50 to 100 queries that real users would ask. For each query, manually identify the 3 to 5 documents in your corpus that answer it. This is tedious but irreplaceable — you cannot optimize what you cannot measure.
2. Embed and retrieve. For each candidate model, embed your corpus, then embed each query, and retrieve the top-10 documents by cosine similarity.
3. Compute recall@k. For each query, check what fraction of the relevant documents appear in the top-k results. Average across all queries.
4. Compare. If model A has 82% recall@10 and model B has 85% recall@10, the 3-point difference may or may not matter depending on your downstream task. A reranker can often close a small gap more cost-effectively than switching to a more expensive embedding model.

The important thing: do not trust benchmark numbers from the model providers. MTEB scores are averages across many tasks, and your specific domain (legal, medical, code, conversational) may diverge significantly. The only benchmark that matters is the one you run on your own data.

Conclusion

For most teams starting a RAG pipeline in 2026, text-embedding-3-small is the safe default: it is cheap, well-understood, and performs well enough that switching costs usually outweigh the quality gain. If you need longer context or specialized code embeddings, Voyage 4 is a strong alternative with a generous free tier for evaluation. The text-embedding-3-large model is worth it only when retrieval quality is the primary constraint and cost is secondary.

The GLM situation is what it is: a strong generation model with no public embedding endpoint. Use GLM for generation, and pair it with OpenAI or Voyage for embeddings — the OurToken gateway makes this a single configuration change rather than a separate integration.

The most expensive mistake in embedding model selection is choosing without testing. Pick two candidates, run a recall test on 50 queries, and let your own data make the decision.

FAQ

Which embedding model is cheapest?

text-embedding-3-small and voyage-4-lite are tied at $0.02 per million tokens. voyage-4-lite has a lower default dimension count (1024 vs 1536), so it uses less storage. text-embedding-3-small has a larger default dimension count but supports shortening to 256 if storage is a concern.

Can I use GLM for embeddings?

No public GLM embedding model exists as of August 2026. GLM is available for chat and generation through the OurToken gateway, but you need a separate embedding provider. This is a common pattern and does not require a separate API key if your gateway handles routing.

What dimensions should I use?

Start with the model default. If storage is a bottleneck, reduce to 1024 or 512 — most models lose less than 2 points of recall when halving dimensions. If you are storing millions of vectors, the storage savings compound quickly.

How many tokens do I need to embed?

A typical RAG pipeline embeds 500 to 1000 tokens per document chunk. For a 50,000-document corpus, that is 25 to 50 million tokens. At $0.02/1M tokens, the total cost is $0.50 to $1.00. At $0.13/1M tokens, it is $3.25 to $6.50. Embedding is almost never the bottleneck cost in a RAG system — generation is.

Do I need to re-embed everything if I switch models?

Yes. Embeddings from different models are not comparable — you cannot mix vectors from text-embedding-3-small and voyage-4 in the same vector space. If you switch, you re-embed your entire corpus. This is why testing before committing matters.

Should I use a reranker instead of a better embedding model?

Often, yes. A reranker (like a cross-encoder) on top of a cheap embedding model can outperform a more expensive embedding model alone. The trade-off is latency — a reranker adds a model call per retrieved document. For most RAG systems, the pattern is: cheap embeddings for first-pass retrieval, reranker for precision.