Quick answer: if you want a safe default API, use Voyage voyage-3.5 or OpenAI text-embedding-3-small. If you need the highest retrieval quality and can pay for it, look at voyage-3-large, Cohere embed-v4, or Google's gemini-embedding-001. If you want open source, Qwen3-Embedding-0.6B is the best quality-per-GPU-dollar right now, and BGE-M3 is still the multilingual workhorse.
That's the short version. The longer version matters, because "best" depends entirely on whether you're optimizing for retrieval quality, cost per million tokens, or latency, and the model that wins one usually loses another.
How to Read MTEB Without Fooling Yourself
Every embedding comparison starts with MTEB, the Massive Text Embedding Benchmark. It's genuinely useful. It's also gamed.
Two caveats before you trust any leaderboard number:
Leaderboard position rewards benchmark overfitting. Several top-10 models train on data suspiciously close to MTEB's test distributions. A model two points "worse" on MTEB routinely beats a leaderboard darling on your actual documents.
The retrieval subset is what matters for RAG. MTEB averages classification, clustering, reranking, and retrieval tasks. If you're building search or a RAG pipeline, ignore the overall average and look at the retrieval column specifically.
In my experience, the only benchmark that predicts production performance is a small eval set built from your own corpus: 50 to 100 real queries with labeled relevant documents. It takes an afternoon and saves weeks.
The API Models Worth Considering
| Model | Dims | Price / M tokens | Best for |
|---|---|---|---|
| OpenAI text-embedding-3-small | 1536 | $0.02 | Cheap default, huge ecosystem |
| OpenAI text-embedding-3-large | 3072 | $0.13 | Better quality, same ecosystem |
| Voyage voyage-3.5 | 1024 | $0.06 | Best quality-per-dollar API |
| Voyage voyage-3.5-lite | 512 | $0.02 | Budget with surprising quality |
| Cohere embed-v4 | up to 1536 | ~$0.12 | Multimodal, 128k context, enterprise |
| Google gemini-embedding-001 | 3072 | $0.15 | Top-tier multilingual quality |
A few opinions the table can't hold:
OpenAI's models are fine, not great. text-embedding-3-small at $0.02 per million tokens is the default for a reason: every vector database tutorial assumes it, and it's rarely the bottleneck. But it hasn't been the quality leader for a while, and OpenAI has not shipped a new embedding model since early 2024. You're buying ecosystem, not state of the art.
Voyage is the quiet winner. Since MongoDB acquired Voyage AI, voyage-3.5 has been the model I recommend most. It beats text-embedding-3-large on most retrieval evals at half the price, and the domain-specific variants (voyage-code, voyage-finance, voyage-law) are meaningfully better in their niches, not just marketing.
Cohere embed-v4 is the enterprise pick. Multimodal (it embeds images and mixed PDFs), 128k token context, Matryoshka dimensions, and deployable inside your own VPC. If your documents are messy scanned PDFs with tables and charts, embedding the page as an image with embed-v4 often beats OCR-then-embed pipelines.
Gemini's embedding model tops multilingual leaderboards and supports 100+ languages, but it's the most expensive per token and ties you to Google's rate limits.
The Open-Source Models Worth Considering
| Model | Params | Dims | Best for |
|---|---|---|---|
| Qwen3-Embedding-0.6B | 0.6B | 1024 | Best small open model, Apache 2.0 |
| Qwen3-Embedding-8B | 8B | 4096 | Top open-source retrieval quality |
| BGE-M3 | 568M | 1024 | Multilingual, dense + sparse hybrid |
| Nomic embed-text-v2 | 475M (MoE) | 768 | Fast, permissive, long context |
| EmbeddingGemma | 308M | 768 | On-device and edge deployment |
| all-MiniLM-L6-v2 | 22M | 384 | Prototyping baseline only |
The Qwen3-Embedding family changed the open-source calculus in 2025. The 8B version sits at or near the top of MTEB's multilingual leaderboard, and the 0.6B version gets close enough that most teams should just run the small one. Apache 2.0 license, so no legal review headaches.
BGE-M3 remains underrated because it does dense, sparse, and multi-vector retrieval from one model. If you want hybrid search without running two systems, it's the pragmatic choice.
And a word on all-MiniLM-L6-v2: it's in every tutorial because it's tiny and fast, but it's a 2021-era model. Fine for prototyping. If it's still in production a year later, you're leaving real retrieval quality on the table.
API vs Open Source: The Actual Decision
The honest framing is not "which is better" but "who runs the GPU."
Choose an API when: your corpus is under ~100M tokens, your team doesn't want to operate inference infrastructure, or you re-embed rarely. At $0.02 to $0.06 per million tokens, embedding 10 million tokens costs less than a coffee. The API premium is trivial until you're embedding continuously.
Choose open source when: you embed at high volume (re-embedding a large corpus monthly adds up), you have data residency requirements, or you need sub-10ms latency without network round trips. A single L4 GPU running Qwen3-Embedding-0.6B comfortably handles thousands of embeddings per second.
There's a hidden cost people miss on the API side: rate limits. Bulk-embedding a 50M token corpus through an API means batching, retry logic, and hours of wall-clock time. Self-hosted, it's an overnight job you control.
And a hidden cost on the open-source side: model migrations. When you switch embedding models, every vector in your database is invalid. You re-embed everything. Factor that into how eagerly you chase leaderboard updates.
Dimensions, Matryoshka, and Speed
Almost every 2026-era model supports Matryoshka representation learning, meaning you can truncate a 3072-dim vector to 1024 or 512 dims and lose only a little quality. Use it. Vector search cost scales with dimensions: storage, RAM, and query latency all drop when you truncate.
A practical recipe: embed at full dimension, store a truncated 512-dim copy for fast first-stage retrieval, then rerank the top 100 candidates with the full vectors or a dedicated reranker. You get most of the quality at a fraction of the query cost.
What Actually Moves Retrieval Quality
Here's the insight most model comparisons skip: the gap between a mediocre and a great embedding model is usually smaller than the gap between clean and dirty input text.
Embedding a web page with navigation menus, cookie banners, and footer links pollutes the vector. The model faithfully encodes "Accept all cookies" right alongside your actual content. We covered this in our guide to HTML-to-Markdown conversion: stripping boilerplate before embedding improves retrieval more than a model upgrade in most pipelines we've seen.
The same goes for chunking. A top-tier model fed badly split chunks loses to a mid-tier model fed coherent, well-bounded chunks.
So the order of operations for better retrieval: clean your text extraction first, fix your chunking second, upgrade your model third. If your pipeline embeds live web content, a fetch API that returns clean Markdown, like link.sc, handles the first step for you, and the RAG pipeline walkthrough shows the full flow end to end.
My Recommendations by Situation
- Just starting, want simple: OpenAI text-embedding-3-small. Boring, cheap, everywhere.
- Best quality-per-dollar API: Voyage voyage-3.5.
- Maximum retrieval quality, budget flexible: voyage-3-large or Cohere embed-v4, validated on your own eval set.
- Multilingual first: gemini-embedding-001 (API) or Qwen3-Embedding (open source).
- Self-hosted at scale: Qwen3-Embedding-0.6B on a small GPU; step up to 4B or 8B only if your evals justify it.
- Edge or on-device: EmbeddingGemma.
Whatever you pick, build that 50-query eval set before committing. The leaderboard doesn't know your data. You do.
Feeding web content into your embedding pipeline? Get a free link.sc API key and fetch any page as clean, embedding-ready Markdown.