Embedding Models Compared — Which One Should You Actually Use?

Five embedding options developers use#

Embeddings sit behind most search bars, recommendation engines and RAG pipelines. If you have built anything with AI retrieval, you have had to pick one, and the list of options keeps growing. At the time of recording (April 2026), five families stood out in production use:

• OpenAI text-embedding-3-small and -large. Still the default for most teams. Small produces 1,536-dimension vectors and large up to 3,072. Fast, well documented and inexpensive: at the time of recording, small cost about $0.02 per million tokens and large about$0.13.
• Cohere embed-v4. Supports more than 100 languages natively, covers search and classification, and performs strongly on multilingual benchmarks.
• Google Gemini embedding. Part of the Gemini API with 768-dimension vectors by default; the natural fit if you already use Vertex AI or BigQuery vector search.
• Voyage AI voyage-3. The specialist choice, frequently near the top of MTEB for code search and technical documentation.
• Open-source BGE-M3 and Nomic Embed. Run locally with no per-query fee and, for many use cases, perform within about five to ten percent of commercial options, at the cost of managing your own infrastructure.

Retrieval quality on your own data#

Generic benchmarks such as MTEB are useful as a direction, but they do not predict performance in your domain. Teams regularly find that a model ranked lower on public leaderboards wins on their own documents.

The fix is cheap: build an evaluation set of fifty to a hundred real query-document pairs and measure recall at ten for each candidate. That small, domain-specific test is worth more than any leaderboard position. Keep it around: every time you consider a new model or a new chunking approach, rerun the same set so you compare like with like.

Dimensions, storage and latency#

Storage is where teams get surprised. A million documents embedded at 3,072 dimensions in float32 take roughly 12 GB for the vectors alone. Moving to 1,536 dimensions halves that. Matryoshka dimensionality reduction, supported by OpenAI and several other providers, lets you go lower still with minimal quality loss. At scale, your vector database bill can exceed your embedding API bill.

Latency matters most when you embed user queries at search time, where every millisecond is felt. OpenAI's small model is quick, typically returning in roughly 20 to 50 milliseconds in the episode's experience; Voyage was somewhat slower, and self-hosted models vary widely with your GPU. For batch indexing, latency is much less important.

Do the storage math before you index rather than after. Dimension count is a cost you pay on every stored vector for as long as it lives in your database, so a model with smaller vectors can be the cheaper choice even if its per-token price is slightly higher.

Multilingual support#

For English-only content, most of these models work fine. As soon as you add Chinese, Japanese, Korean, Arabic or mixed-language text, the field narrows. Cohere embed-v4 and BGE-M3 lead for multilingual retrieval, while OpenAI's models handle other languages reasonably well but are not optimized for them. If your users search in one language for documents written in another, include those mixed-language cases in your evaluation set from the start.

A practical recommendation#

For most developers, start with OpenAI's text-embedding-3-small: it is cheap, fast and good enough for the large majority of use cases. Then specialize only where you need to:

• Multilingual content: Cohere embed-v4.
• Code search: Voyage.
• On-premise data or zero per-query cost: BGE-M3 deployed locally.

Keep the model swappable. If you call embeddings through an OpenAI-compatible endpoint such as Crazyrouter, trying another embedding model it offers is a change to the model parameter, so you can benchmark candidates without touching application code. Re-embed a sample of your corpus with each candidate and run it through the same evaluation set. That makes it practical to compare OpenAI, Cohere, Voyage and Gemini embeddings side by side on your own eval set.

Chunking matters more than the model#

The insight most teams miss is that chunking strategy often has a bigger effect than model choice. Teams have spent weeks A/B testing embedding models, only to find that moving from fixed-size chunks to semantic chunking with overlap improved retrieval more than any model swap.

Embedding models are a solved-enough problem that you should not agonize over the choice. Pick a sensible default, build your eval set, and put your effort into chunking; the model is the easiest part to change later. Measure each chunking change with the same recall-at-ten test you used for model selection, so improvements are real rather than anecdotal.