Embedding Models Compared: OpenAI, Cohere, and Open-Source Alternatives

Choosing an embedding model for production vector search is one of those decisions that looks simple until you deploy. The MTEB leaderboard changes monthly, new models drop every quarter, and benchmark rankings don't always predict real-world retrieval quality on your specific documents. After running embedding pipelines across three different production systems — a legal document search engine, an e-commerce product discovery platform, and a customer support knowledge base — here's what actually matters when picking a model.

The Landscape in 2026

The embedding model market has split into three tiers. Commercial APIs from OpenAI (text-embedding-3-small/large) and Cohere (embed-v3) offer the easiest integration path with consistently strong performance. Mid-range open-source models like BGE, E5, and GTE run on commodity GPUs and match commercial APIs on many benchmarks. Large instruction-tuned models like E5-mistral-7b-instruct push state-of-the-art accuracy but demand serious compute. Understanding where each tier shines — and where it falls short — saves months of production debugging. For background on how these embeddings feed into retrieval pipelines, see our RAG architecture guide.

OpenAI text-embedding-3: The Default Choice

OpenAI's text-embedding-3 family replaced ada-002 in early 2024 and remains the most widely deployed commercial embedding API. The -large variant produces 3072-dimensional vectors by default, achieving 64.6 on the MTEB retrieval benchmark. The -small variant outputs 1536 dimensions at roughly half the cost per token.

What makes text-embedding-3 particularly interesting is native Matryoshka dimensionality reduction. You can request any dimension from 256 to 3072 and the model returns truncated embeddings that retain most of their retrieval quality. In our testing, 1024-dimensional truncations lost less than 1.5% nDCG compared to full 3072-dimensional vectors, while cutting storage costs by 3x. This matters when your vector database index holds millions of documents.

from openai import OpenAI
client = OpenAI()

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="Distributed gradient accumulation across data-parallel ranks",
    dimensions=1024  # Matryoshka truncation
)
embedding = response.data[0].embedding
# len(embedding) == 1024

The downsides are real. Latency depends on OpenAI's infrastructure — we've measured p99 latencies ranging from 80ms to 400ms during peak hours. You're also sending your documents to a third-party API, which creates compliance complications for regulated industries. And the per-token pricing adds up: embedding a million 512-token documents costs roughly $13 with text-embedding-3-large. That's cheap for a one-time indexing job, but continuous re-embedding for a dynamic corpus gets expensive fast. For techniques to manage embedding costs in production, see our guide on model serving optimization.

Cohere embed-v3: Multilingual and Compressed

Cohere's embed-v3 is the strongest commercial option for multilingual workloads. It supports over 100 languages with a single model — no language detection or model routing required. On the MIRACL benchmark (multilingual information retrieval), embed-v3 outperforms text-embedding-3 by 4-6 nDCG points across most language pairs.

The standout feature is built-in binary and int8 quantization. Cohere returns embeddings in multiple precision formats in a single API call. Binary embeddings (1 bit per dimension) compress a 1024-dimensional vector from 4096 bytes to 128 bytes — a 32x reduction. In our benchmarks, binary Cohere embeddings retained 90-92% of full-precision retrieval quality, which is remarkable compression for initial candidate retrieval.

Model	Dimensions	MTEB Retrieval	MIRACL Avg	Latency (p50)	Cost/1M tokens
text-embedding-3-large	3072	64.6	54.9	45ms	$0.13
text-embedding-3-small	1536	62.3	51.2	30ms	$0.02
Cohere embed-v3	1024	64.1	59.7	40ms	$0.10
BGE-large-en-v1.5	1024	63.5	—	12ms*	Self-hosted
E5-mistral-7b-instruct	4096	66.6	55.8	85ms*	Self-hosted
GTE-large-en-v1.5	1024	63.1	—	14ms*	Self-hosted

* Self-hosted latency on A10G GPU, batch size 1

The practical workflow for Cohere in production uses a two-pass strategy: store binary embeddings for fast initial search across your full index, then re-rank the top candidates using full-precision float32 embeddings. This pattern cuts vector storage by 30x while keeping retrieval quality within 2% of full-precision search. We detailed similar two-pass strategies in document chunking for vector search.

Open-Source Tier 1: BGE, E5, and GTE

The open-source embedding landscape consolidated around three model families that consistently top MTEB benchmarks: BGE (BAAI General Embedding), E5 (Embeddings from Bidirectional Encoder Representations), and GTE (General Text Embeddings). Each offers models from 33M to 7B parameters, covering the full spectrum from CPU-friendly inference to GPU-demanding state-of-the-art.

BGE-large-en-v1.5

BGE-large-en-v1.5 remains the workhorse for English-only deployments. At 335M parameters with 1024-dimensional output, it fits comfortably on a single A10G GPU and delivers 12ms inference latency per query. The model uses instruction prefixes — prepend "Represent this sentence for searching relevant passages:" for retrieval queries — which improves nDCG@10 by 2-3 points compared to raw embedding.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-large-en-v1.5")

queries = ["How does gradient accumulation work?"]
passages = [
    "Gradient accumulation simulates larger batch sizes...",
    "Learning rate warmup prevents early divergence...",
]

q_embeddings = model.encode(
    [f"Represent this sentence for searching relevant passages: {q}" for q in queries],
    normalize_embeddings=True
)
p_embeddings = model.encode(passages, normalize_embeddings=True)

similarities = q_embeddings @ p_embeddings.T

For teams evaluating embedding space quality, BGE models provide consistent geometric properties — uniform distribution across dimensions, stable nearest-neighbor rankings across random seeds — that make debugging retrieval issues more tractable than some commercial APIs where the embedding space characteristics aren't documented.

E5-mistral-7b-instruct

E5-mistral-7b-instruct deserves special attention because it represents a fundamentally different approach: take a pre-trained LLM (Mistral-7B), fine-tune it for embedding tasks with instruction-following capability, and use the last token's hidden state as the embedding. The result is a 4096-dimensional embedding that outperforms text-embedding-3-large on multiple MTEB retrieval tasks.

The cost is inference speed. A 7B parameter model requires an A100 or equivalent GPU, and single-query latency sits around 85ms — comparable to API latency but with your own hardware costs. Batch inference helps: on an A100-80GB, throughput reaches 200 embeddings per second with batch size 32. If you're processing a large data pipeline and can batch your embedding requests, the cost per embedding drops below commercial APIs. For one-off queries in a real-time search application, the GPU cost per query often exceeds API pricing.

Practical Benchmarking: Beyond MTEB

MTEB benchmarks test general-purpose embedding quality across dozens of tasks, but production retrieval quality depends heavily on domain-specific evaluation. We ran our own benchmark suite across three production workloads and the results diverged significantly from MTEB rankings.

Three findings stand out from our domain-specific evaluation:

• Legal documents: text-embedding-3-large wins, likely because its training data includes more legal text. E5-mistral-7b closes the gap when using instruction prefixes that specify legal terminology.
• E-commerce product search: Cohere embed-v3 dominates because product queries are often multilingual and short. Its training includes substantial e-commerce data, which matters more than raw model size.
• Support knowledge bases: BGE-large-en-v1.5 outperforms larger models. Support queries use colloquial language that's well-represented in BGE's training mix. The smaller model also allows us to re-embed the entire corpus hourly as articles get updated.

The takeaway: run your own experiments on a domain-specific evaluation set. General benchmarks predict relative ordering, but absolute accuracy on your data can shift model rankings by 5-10 nDCG points.

Fine-Tuning: When Generic Embeddings Aren't Enough

For domains with specialized vocabulary — biomedical, legal, financial — fine-tuning an open-source embedding model on in-domain data consistently improves retrieval quality by 5-15%. The approach that works best for us: contrastive fine-tuning with hard negatives mined from our existing search logs.

from sentence_transformers import SentenceTransformer, losses, InputExample
from torch.utils.data import DataLoader

model = SentenceTransformer("BAAI/bge-large-en-v1.5")

train_examples = [
    InputExample(texts=["gradient accumulation batch size",
                        "Gradient accumulation simulates larger batches by summing gradients across multiple forward passes before updating weights."],
                 label=1.0),
    InputExample(texts=["gradient accumulation batch size",
                        "Batch normalization computes running statistics across the batch dimension."],
                 label=0.0),
]

train_dataloader = DataLoader(train_examples, shuffle=True, batch_size=16)
train_loss = losses.CosineSimilarityLoss(model)

model.fit(
    train_objectives=[(train_dataloader, train_loss)],
    epochs=3,
    warmup_steps=100,
    output_path="./bge-legal-finetuned"
)

The critical detail is hard negative mining. Random negatives are too easy — the model learns to distinguish topically different documents but fails on the hard cases where two documents discuss similar topics but only one answers the query. We mine hard negatives by running inference with the base model, collecting the top-50 non-relevant results for each query, and using those as negative training examples. This technique shares principles with LoRA fine-tuning strategies — both depend on targeting the model's specific weaknesses rather than general training.

Production Architecture Patterns

The embedding model choice cascades into your entire retrieval architecture. Here are three patterns we've deployed:

Pattern 1: API-Only (Startup / Low Volume)

Use text-embedding-3 or Cohere embed-v3 through their APIs. Store vectors in a managed service like Pinecone or Weaviate Cloud. Total infrastructure: zero GPU servers. This works until you hit 10M+ documents or need sub-50ms latency, at which point API variability becomes a bottleneck. Experiment tracking with tools covered in our MLflow and W&B guide helps you monitor embedding quality as your corpus grows.

Pattern 2: Self-Hosted Small Model (High Volume / Latency-Sensitive)

Deploy BGE-base or BGE-small on CPU instances behind a load balancer. These models run at 2-5ms per embedding on modern CPUs, handling 200-500 QPS per instance. Store vectors in self-managed Milvus or Qdrant. This pattern optimizes for latency and cost at scale. The tradeoff: 3-5 nDCG points below the best commercial APIs. Understanding feature store patterns helps structure the embedding cache layer.

Pattern 3: Hybrid (Best Accuracy / Complex)

Use a small model for initial candidate retrieval from the full index, then re-embed the top candidates with a larger model for re-ranking. This gets you E5-mistral-7b accuracy with BGE-small latency on 95% of the pipeline. The complexity cost is real — you're maintaining two models, two embedding caches, and a re-ranking service. But for applications where retrieval quality directly impacts revenue, the engineering complexity pays for itself. For monitoring this kind of multi-model pipeline, see our model monitoring guide.

Cost Analysis at Scale

At 10 million documents with 512 tokens average length, here's how the costs break down for initial indexing plus ongoing query embedding at 100 QPS:

Approach	Index Cost	Monthly Query Cost	GPU/Infra	Total Year 1
OpenAI text-emb-3-large	$650	$340	$0	$4,730
Cohere embed-v3	$500	$260	$0	$3,620
BGE-large (2x A10G)	$0	$0	$2,400/mo	$28,800
BGE-small (4x CPU)	$0	$0	$800/mo	$9,600
E5-mistral-7b (A100)	$0	$0	$3,200/mo	$38,400

Commercial APIs are cheaper until you hit high query volumes or need to re-embed frequently. Self-hosted becomes cost-effective when your query volume exceeds roughly 50 QPS sustained, or when compliance requirements prohibit sending data to external APIs. For teams managing shared GPU clusters, the self-hosted models can share infrastructure with training workloads, amortizing the cost further.

Choosing the Right Model

After running these models across multiple production deployments, the decision tree is straightforward:

• If you need multilingual support: Cohere embed-v3. Nothing else comes close on non-English retrieval.
• If you're English-only and want maximum accuracy with minimal ops: text-embedding-3-large with Matryoshka truncation to 1024 dimensions.
• If latency matters more than the last 2% of accuracy: BGE-base-en-v1.5 self-hosted on CPU.
• If you need state-of-the-art accuracy and own your infrastructure: E5-mistral-7b-instruct fine-tuned on your domain data.
• If you're budget-constrained and just getting started: text-embedding-3-small at $0.02 per million tokens.

The model you pick today isn't permanent. Design your pipeline with a clean embedding interface — swap the model behind it — and plan to re-evaluate every 6 months as new models release. The embedding landscape moves fast, and the best choice today might not be the best choice next quarter. What doesn't change is the need for domain-specific evaluation and production monitoring. Get those right, and model migrations become routine rather than risky. For a deeper look at the vector storage layer that sits beneath these models, see our vector database comparison.

FAQ

Which embedding model is best for production vector search?

It depends on your constraints. OpenAI text-embedding-3-large leads MTEB benchmarks on English retrieval tasks. Cohere embed-v3 offers the best multilingual support and built-in compression. For self-hosted deployments, BGE-large-en-v1.5 and E5-mistral-7b-instruct deliver competitive accuracy without API dependency.

How much does embedding model dimensionality affect retrieval quality?

Going from 384 to 1024 dimensions typically improves nDCG@10 by 3-5% on standard benchmarks. Beyond 1536 dimensions the gains plateau for most workloads. Higher dimensions increase storage costs linearly and slow approximate nearest neighbor search.

Can open-source embedding models match commercial APIs?

Yes, on specific tasks. E5-mistral-7b-instruct matches or exceeds text-embedding-3-large on several MTEB retrieval benchmarks. The tradeoff is inference cost — a 7B parameter model requires a GPU, whereas smaller models like BGE-small run on CPU with 5ms per embedding.

Should I use Matryoshka embeddings for my vector database?

Matryoshka Representation Learning lets you truncate embeddings to any prefix length while retaining most retrieval quality. Store 256-dimensional prefixes for initial retrieval and re-rank with full 1536-dimensional vectors, reducing index size by 6x with under 2% accuracy loss.

How do I evaluate embedding models for my specific domain?

Build a domain-specific evaluation set with 200-500 query-document pairs where human annotators mark relevant documents. Measure nDCG@10 and Recall@20. MTEB benchmarks test general-purpose performance, but domain-specific accuracy can diverge by 10-15 points from benchmark rankings.