Two open weight embedding models with 8K context, built for different retrieval problems.
| BGE-M3 | nomic-embed-v1.5 | |
|---|---|---|
| Parameters | 568M, XLM-RoBERTa backbone | About 0.1B, roughly a quarter of BGE-M3 |
| Dense dimensions | 1,024 | 768, resizable to 512, 256, 128, or 64 (Matryoshka) |
| Max input length | 8,192 tokens | 8,192 tokens |
| License | MIT | Apache 2.0 |
| Language coverage | More than 100 languages | English focused |
| Retrieval modes | Dense, sparse, and multi-vector (ColBERT) in one pass | Dense only |
| English MTEB score | Not its headline benchmark; card evals focus on multilingual retrieval | 62.28 at 768 dims; 61.04 at 256; 56.10 at 64 |
| Multilingual evals | Strong MIRACL and MKQA results on the model card | Not a design goal |
| Task prefixes | Not required | Required: search_query, search_document, clustering, classification |
| Multimodal pairing | None | Aligned with nomic-embed-vision-v1.5 for text and image search |
Neither model has a license fee. MIT and Apache 2.0 both allow commercial use, self hosting, and fine tuning, so the real costs come from three places: inference compute, vector storage, and the retrieval stack you build around the model.
Compute first. BGE-M3 carries roughly four times the parameters, so embedding the same corpus takes on the order of four times the work. nomic-embed-text-v1.5 is small enough to run acceptably on CPU or a modest GPU, which is why it shows up so often in local and self hosted deployments.
Storage is the quieter cost, and it is permanent. Every vector you store keeps its dimension count forever. BGE-M3's 1,024 dimensions cost a third more per vector than nomic's 768, and Matryoshka goes further: storing nomic vectors at 256 dimensions cuts storage to a third of full size while the measured MTEB score only drops from 62.28 to 61.04. On an index of tens of millions of chunks, that difference is a visible line on the vector database bill. BGE-M3's ColBERT mode points the other way; multi-vector output can improve precision but multiplies index size, so turn it on deliberately, not by default.
Both models are also served by third party inference APIs, with per token prices that vary by provider and change often, so I will not quote numbers that would be stale in a quarter. The structural point holds either way: with open weights your floor price is your own hardware, and you can move between hosted and self hosted serving without re-embedding, as long as you stay on the same model.
Pick BGE-M3 when your corpus is not purely English. Support tickets, product docs across markets, or any retrieval task that mixes languages plays to its training across more than 100 languages, and its published evaluations on MIRACL and MKQA are about exactly that setting.
It is also the practical choice when you want hybrid retrieval without running two systems. Its sparse output covers the exact keyword matching you would otherwise get from BM25, and the dense output covers semantics, from one model in one pass. If you are currently gluing a keyword index to a separate dense model, BGE-M3 can collapse that stack.
The cost is that everything about it is bigger: more parameters to serve, larger vectors to store, and heavier optional modes. It earns that weight on multilingual and hybrid workloads, and it does not on simple English ones.
Pick nomic-embed-text-v1.5 for English retrieval where cost and latency matter, which in my experience covers most RAG systems that small teams actually ship. Its 62.28 MTEB score at full size is competitive for a model this small, and the Matryoshka dimensions give you a storage dial that fixed size models do not offer.
It is also the easier operational choice. The small footprint runs on modest hardware, it is packaged widely in local tooling, and the vision aligned variant adds text to image search in the same embedding space if you need it later.
One warning from the integration side: the task prefixes are mandatory. Queries must be embedded with search_query and documents with search_document, and skipping them silently degrades retrieval quality rather than throwing an error. It is the single most common mistake I see with this model.
Head to head score tables mislead here, because the two models publish results on different benchmarks. Nomic's headline number is the English MTEB suite; BGE-M3's card leads with multilingual retrieval evals. A single ranking that ignores that is comparing answers to different questions. Second, embedding choices are sticky: switching models later means re-embedding every chunk in your index, which on a large corpus is a real compute bill and a migration project, so the dimension and language decisions you make now follow you. Third, neither of these tops the current MTEB leaderboard, and for production that matters less than it seems; language coverage, dimension budget, tooling maturity, and a license your lawyers accept decide more than a point of average score.
My rule is simple. English corpus, cost sensitive, standard RAG: nomic-embed-text-v1.5, stored at 256 dimensions unless testing on your own data says otherwise. Multilingual corpus, or a real need for hybrid dense plus sparse retrieval: BGE-M3, accepting the heavier serving cost as the price of coverage. Both are permissively licensed open weights, so the honest tiebreaker is a retrieval evaluation on a few hundred of your own queries, which costs an afternoon and beats every leaderboard argument.