All posts
#rag#embeddings#local-first#on-device-ai

Best Local Embedding Models for RAG in 2026

The best local embedding models for RAG in 2026: nomic-embed, BGE-M3, Qwen3-Embedding, jina-v3 and more, compared on context, license and honest trade-offs.

The recal team7 min read

A calm deep-teal surface with several small glowing tiles of different sizes arranged in a grid, each tile mapping a short phrase to a cluster of points, a quiet metaphor for turning text into local vectors

If you are building retrieval-augmented generation on your own hardware, the embedding model is the quiet decision that sets your ceiling. It is the thing that turns each chunk of text into the vector your search runs over, so if it maps the wrong things close together, no amount of prompt work or reranking downstream can fully recover. The good news in 2026 is that the best local embedding models are genuinely strong, small enough to run on a laptop, and free to use. The catch is that "best" depends on your language mix, your document length, your hardware, and your license constraints, and the honest ranking changes with each of those. This guide walks the real options with their trade-offs stated plainly.

We run local embeddings on-device every day building recal, a local-first assistant, so this comes from living with these models rather than a leaderboard screenshot. None of the picks below is recal; it is not an embedding model. Where our layer sits comes at the end. The comparison is on the merits.

Key takeaways

  • For most local RAG in 2026, start with nomic-embed-text (long 8k context, fast on CPU, permissive license) or BGE-M3 if your corpus is multilingual or you want hybrid dense-plus-sparse retrieval.
  • If you want the highest accuracy and can spare the memory, Qwen3-Embedding (4B or 8B, quantized) is the open-source high-water mark, with flexible vector sizes.
  • Match the model's context length to your chunk size. A 512-token model silently truncates long chunks, which quietly drops recall.
  • Check the license before you ship. Some top-accuracy models are released for non-commercial use only, which matters the moment you sell something.
  • English-only lightweight models (mxbai, bge-large-en) score near zero on cross-lingual queries, so language mix is a real selection axis, not a footnote.

What is the best local embedding model for RAG?

There is no single winner, but there is a sensible default. For a general-purpose local RAG stack in 2026, nomic-embed-text is the model most people should reach for first: it handles long documents with an 8,192-token context, runs quickly on CPU, and ships under a permissive license, so it is safe to build on. If your content spans multiple languages, or you want to combine dense and keyword-style matching in one model, BGE-M3 is the stronger default. If accuracy is the only thing that matters and you have the memory budget, Qwen3-Embedding at 4B or 8B with 4-bit quantization is the open-source top of the pack. Everything else on this list earns its place by being smaller, faster, or better at one specific job.

The best local embedding models in 2026

nomic-embed-text (the sensible default)

The model to start with for general local RAG. It offers an 8,192-token context, which means you can embed a full section without chopping it into fragments, and it is one of the fastest options on CPU-only machines, so it works on hardware without a discrete GPU. It ships under a permissive open license, so there are no commercial-use surprises. The honest catch is that it is English-centric: like most lightweight English models, it performs poorly on cross-lingual retrieval, where a query in one language needs to match a document in another. For English or single-language corpora on modest hardware, it is hard to beat as a starting point.

BGE-M3 (best for multilingual and hybrid)

BGE-M3 is the model many production stacks default to when the corpus is not purely English. It is multilingual across a wide range of languages, handles long context, and uniquely produces dense, sparse, and multi-vector representations from one model, so you can run hybrid retrieval (semantic plus keyword) without bolting on a second system. That flexibility is its whole point. The catch is size and speed: it is heavier than the tiny English models, so on CPU-only hardware it is noticeably slower per chunk. If your users search in more than one language, or you already know you want hybrid search, the extra weight is worth it.

Qwen3-Embedding (highest open-source accuracy)

When accuracy is the priority and memory is available, Qwen3-Embedding is the strongest open option in 2026. It comes in several sizes (roughly 0.6B up to 8B), is strongly multilingual, and supports flexible vector dimensions so you can trade a little accuracy for smaller, faster vectors. The 8B model with 4-bit quantization runs in around 5 GB of memory and delivers state-of-the-art retrieval quality. The catch is exactly that footprint: the large sizes want a capable GPU or a lot of unified memory to stay fast, so this is the pick for a well-specced machine, not a thin laptop. The smaller sizes are a reasonable middle ground.

jina-embeddings-v3 (top accuracy, watch the license)

jina-embeddings-v3 posts some of the best retrieval accuracy of any model in this class, is multilingual out of the box, handles long context, and supports Matryoshka truncation so you can shorten vectors without re-embedding. On paper it is a default-beating pick. The important catch is licensing: it is released under a non-commercial license, so it is excellent for research, personal projects, and evaluation, but you need to check the terms (or an appropriate commercial arrangement) before you ship it inside something you sell. Judge it on merit for prototypes; confirm the license before production.

mxbai-embed-large and bge-large-en-v1.5 (strong English, small)

Two lightweight English specialists worth knowing. Both produce 1,024-dimension vectors, run fast, and punch above their weight on English retrieval, with bge-large-en-v1.5 in particular strong on dense English content like legal and research text. The shared catch is a short context window (around 512 tokens), which means long chunks get truncated unless you keep chunks small, and near-zero cross-lingual ability. If your corpus is English and your chunks are short, either is a lean, accurate choice; if you feed them long passages, you will lose the tail of each one without noticing.

all-MiniLM-L6-v2 (the tiny baseline that still works)

The classic small model, and still a legitimate baseline in 2026. At roughly 22M parameters and 384 dimensions, it is tiny, embeds thousands of chunks per second on a CPU, and runs anywhere. It is the right call for a first prototype, an edge device, or a case where speed and footprint beat every other concern. The catch is a very short context (around 256 tokens) and a lower quality ceiling than anything else here, so it is a starting line, not a finish line. Measure your retrieval quality with it, then upgrade if the numbers ask for it.

Local embedding models compared

ModelParams (approx)DimensionsContextBest forHonest catch
nomic-embed-text~140M7688,192General local RAG, long docs, CPUEnglish-centric
BGE-M3~560M1,0248,192Multilingual, hybrid dense+sparseHeavier, slower on CPU
Qwen3-Embedding (4B/8B)4B / 8BflexiblelongHighest open accuracyNeeds real memory/GPU
jina-embeddings-v3~570Mup to 1,0248,192Top accuracy, multilingualNon-commercial license
mxbai-embed-large~335M1,024~512English, small and fastShort context, English-only
bge-large-en-v1.5~335M1,024~512Dense English (legal, research)Short context, English-only
all-MiniLM-L6-v2~22M384~256Baseline, edge, max speedLow ceiling, very short context

Specifications move as models are updated; treat this as a starting map and confirm the current numbers on each model's card before you commit.

How to choose a local embedding model for RAG

Four questions settle it faster than any leaderboard:

  1. What is your chunk size? Pick a context window comfortably larger than your chunks. If you chunk at 1,000 tokens, a 512-token model truncates every chunk and you lose recall you cannot see. Long-context models (nomic, BGE-M3, jina, Qwen3) remove that failure mode.
  2. How many languages? English-only content lets you use the small, fast English models. Any multilingual requirement points at BGE-M3, jina-v3, or Qwen3, because the lightweight English models score near zero across languages.
  3. What is your hardware? CPU-only or thin laptop favors nomic-embed-text or a MiniLM-class baseline. A GPU or lots of unified memory unlocks Qwen3 at its larger sizes.
  4. Can you ship it commercially? Confirm the license before production. Permissive licenses (nomic, Qwen3, the BGE family, MiniLM) are safe to build on; some top-accuracy models are non-commercial.

One more thing that is easy to skip: the embedding model sets your retrieval ceiling, but a small reranker (for example a BGE reranker) run over the top-k results often buys more accuracy than swapping to a bigger embedder. If you are optimizing, measure retrieval with a reranker in the loop before you conclude the embedder is the bottleneck.

Are local embedding models good enough versus cloud APIs?

For most workloads in 2026, yes. The gap between the best open local models and hosted embedding APIs has narrowed to the point where language coverage, context length, and your own evaluation matter more than provider prestige. Local wins on three things that are hard to give back once you have them: your text never leaves the machine, there is no per-token bill on a large corpus, and re-embedding a growing store costs compute you already own rather than an invoice that scales with your data. The honest counterpoint is that a hosted frontier embedding model can still edge out the local field on the hardest multilingual retrieval, and it saves you from managing the model yourself. If privacy or cost is a real constraint, local is not a compromise anymore; it is the sensible default.

FAQ

What is the best embedding model for local RAG? For a general English or single-language corpus, nomic-embed-text is the best starting point thanks to its long context and CPU speed. For multilingual or hybrid retrieval, BGE-M3. For maximum accuracy with the memory to spare, Qwen3-Embedding at 4B or 8B.

Which embedding model works with Ollama? Several of these run directly in local runners like Ollama, including nomic-embed-text, mxbai-embed-large, and BGE-M3. Check the runner's model library for the exact tags, then point your RAG pipeline at the local endpoint.

What is the best local embedding model for code? Code retrieval benefits from models trained or tuned on code and from larger, more capable embedders. Qwen3-Embedding handles code well at its larger sizes; for a lighter option, test a code-tuned embedding model against your own repository queries rather than trusting a general benchmark.

Do I need a bigger embedding model or a reranker? Often a reranker. Adding a small reranker over your top-k results frequently improves answer quality more, and more cheaply, than upgrading to a larger embedding model. Measure both against your own documents before deciding.

How big are these models? They range from around 22M parameters (all-MiniLM-L6-v2) to 8B (Qwen3-Embedding-8B). The small ones run on any CPU; the largest want a GPU or generous unified memory, though 4-bit quantization brings an 8B model down to roughly 5 GB.


Written with AI assistance and reviewed by the recal team. We build recal, a local-first assistant for macOS that keeps your data on your machine, so retrieval that runs fully on-device is something we use and care about. The model comparisons above are on the merits and independent of recal; specifications change as models are updated, so verify current numbers on each model's card before committing.