Nomic Embed Text: The Most-Pulled Ollama Embedding Model, Explained

Why an embedding model has 81 million pulls

Because every RAG pipeline needs exactly one embedding model, and for two years the default answer has been this one. As of August 2026 the Ollama library ranks nomic-embed-text third overall at 81.2M pulls — behind llama3.1 (118.1M) and deepseek-r1 (90.9M), ahead of llama3.2 (79M). Chat models churn with every release wave; the embedding slot barely moves, because switching means re-embedding your entire document store.

When it shipped in February 2024, nomic-embed-text-v1 was the first fully open embedding model — open weights, open training code, public training data — to claim wins over OpenAI's then-standard ada-002 on both short and long context (Nomic's paper, arXiv 2402.01613). It landed right as Ollama adoption exploded, got written into essentially every "local RAG in 10 minutes" tutorial, and the installed base has compounded since. Model quality started the flywheel; ecosystem inertia keeps it spinning.

That inertia is rational. An embedding model is infrastructure, not a chat companion — you want it boring, small, and identical between the day you index and the day you query. If you're still deciding whether local embeddings fit your project at all, start with our local embeddings guide for the wider model landscape.

Specs at a glance

A 137M-parameter BERT-style encoder that reads up to 8,192 tokens and outputs one 768-float vector per input. Sources: Ollama library tag metadata and the nomic-ai/nomic-embed-text-v1.5 model card.

One quirk worth knowing: this is an embedding-only model. ollama run nomic-embed-text is not a thing — it only answers on the embeddings endpoints.

v1 vs v1.5 vs v2 MoE — which tag to pull

Pull the default. nomic-embed-text resolves to v1.5, which is the right choice for English documents. Only reach for nomic-embed-text-v2-moe if you need multilingual retrieval — and accept its 512-token input limit.

v1.5's upgrade over v1 was Matryoshka training — the ability to truncate vectors below 768 dims with graceful quality loss (details in the Matryoshka section). v2 MoE is a different animal entirely: a mixture-of-experts model (8 experts, top-2 routing) trained on ~1.6B pairs across roughly 100 languages. On multilingual benchmarks it earns its keep — 65.8 on MIRACL vs 62.3 for mE5-Base per Nomic's model card — though BGE-M3 still leads that particular benchmark at 69.2.

The spec almost nobody reads before upgrading: v2 MoE's max sequence length is 512 tokens, against v1.5's 8,192. If your chunker produces 1,000-character chunks you're fine either way, but long-chunk or whole-section embedding strategies break silently on v2. For English content there is no retrieval-quality reason to move — v2's pull count (642K vs 81.2M) says most of Ollama agrees.

Nomic Embed vs OpenAI embeddings

Nomic's published comparison has v1 beating both ada-002 and text-embedding-3-small on MTEB and LoCo, while both OpenAI models win on the Jina Long Context benchmark. Numbers below are from the nomic-embed-text-v1 model card — Nomic's own evaluation, so read it as a vendor benchmark, though MTEB scores are independently reproducible.

Benchmarks aside, the structural differences decide it for most local-first builders: your documents never leave the machine, embedding a million chunks costs electricity instead of API credits, and no provider can deprecate the model your entire vector store depends on — re-embedding a corpus because an API model was sunset is a real migration people have had to do. We break down the cost math and privacy trade-offs in local vs OpenAI embeddings.

Setup: Ollama, Python, LangChain, ChromaDB

One pull, one endpoint. Current Ollama versions expose /api/embed (batched); the older /api/embeddings endpoint still works but is officially superseded (Ollama API docs). The examples below are the exact wiring we use in our production RAG pipeline guide.

Raw API — batch embedding

import requests

r = requests.post("http://localhost:11434/api/embed", json={
    "model": "nomic-embed-text",
    "input": [
        "search_document: Chunk one of your document...",
        "search_document: Chunk two of your document...",
    ],
})
vectors = r.json()["embeddings"]
print(len(vectors), len(vectors[0]))   # 2 768

Batching through input as a list is dramatically faster than one request per chunk when indexing. Watch out: truncate defaults to true, so input longer than the active context gets clipped silently — if you rely on long chunks, set "options": {"num_ctx": 8192} explicitly rather than trusting defaults.

LangChain

# pip install langchain-ollama
from langchain_ollama import OllamaEmbeddings

emb = OllamaEmbeddings(model="nomic-embed-text")

doc_vecs = emb.embed_documents([
    "search_document: Rotate API keys from the dashboard settings page.",
])
query_vec = emb.embed_query("search_query: how do I rotate an API key?")

Note that we prepend the prefixes ourselves — LangChain doesn't know this model wants them. Full LangChain wiring (retrievers, chains, streaming) is covered in our Ollama + LangChain integration guide.

ChromaDB

import chromadb
from chromadb.utils.embedding_functions import OllamaEmbeddingFunction

client = chromadb.PersistentClient(path="./chroma_db")

embed_fn = OllamaEmbeddingFunction(
    url="http://localhost:11434/api/embeddings",
    model_name="nomic-embed-text",
)

collection = client.get_or_create_collection(
    name="kb",
    embedding_function=embed_fn,
    metadata={"hnsw:space": "cosine"},
)

Once a collection is created at 768 dims, every future write and query must use the same model at the same dimensionality. Changing embedding models means re-indexing from scratch — there's no shortcut. If you'd rather start from a working end-to-end template than assemble pieces, our local RAG setup guide is the from-zero version.

Measure your own throughput

Embedding speed varies so much across CPUs, batch sizes, and chunk lengths that any single tok/s claim would mislead you. It takes 30 seconds to get the number that actually matters — yours:

import requests, time

chunks = [f"search_document: test paragraph {i} " + "lorem ipsum " * 80
          for i in range(256)]

t0 = time.time()
requests.post("http://localhost:11434/api/embed",
              json={"model": "nomic-embed-text", "input": chunks})
dt = time.time() - t0
print(f"{len(chunks)/dt:.0f} chunks/sec")

Run it twice and keep the second number — the first request includes model load time.

The prefix gotcha: search_document and search_query

Nomic Embed was trained with task prefixes, and the model card lists them as required: prepend search_document: to text you store and search_query: to questions you search with. Ollama hands your input to the model exactly as you send it — no template, no automatic prefix — so if you didn't add them, you've been running the model outside its training distribution this whole time.

This is the single most common nomic-embed-text mistake we see, and it's invisible: everything still returns vectors, cosine similarity still produces rankings, and retrieval quality is just quietly worse than it should be. The asymmetry is the point — queries and documents are phrased differently ("how do I rotate a key" vs "keys can be rotated from settings"), and the prefixes tell the model which side of that gap it's embedding.

Two more prefixes exist for non-search tasks: clustering: for grouping similar texts and classification: for feature extraction (nomic-ai model card). If you're building semantic search specifically, our Ollama semantic search guide shows prefixed indexing and querying in a complete working example.

Matryoshka: paying storage only for the quality you need

v1.5 lets you truncate 768-dim vectors down to 512, 256, 128, or 64 dims and re-normalize, trading a measured amount of quality for a proportional storage cut. Nomic's model card publishes the trade-off:

MTEB scores: nomic-ai/nomic-embed-text-v1.5 model card. Storage column is our arithmetic (dims × 4 bytes × 1M).

The 512-dim cut costs 0.32 MTEB points for a third less storage — close to free. 256 dims costs about 1.2 points for a 3× reduction, which Nomic themselves highlight as the sweet spot. Below that, quality falls off fast. For a typical personal knowledge base (tens of thousands of chunks) storage is a rounding error and you should just use 768; Matryoshka starts mattering at millions of vectors or on memory-constrained devices. Recent Ollama versions expose a dimensions parameter on /api/embed (Ollama API docs), so you can request truncated vectors without post-processing.

Honest limitations

• –It no longer tops leaderboards. An MTEB of ~62 was frontier in early 2024; plenty of newer, larger embedding models score meaningfully higher today. nomic-embed-text wins on size, speed, and ecosystem defaults — not raw retrieval ceiling. If maximum quality matters more than a 274MB footprint, benchmark alternatives on your own corpus.
• –English-first. v1.5 was not built for multilingual retrieval. Non-English corpora should use v2 MoE or BGE-M3 — and note BGE-M3 still beats v2 MoE on MIRACL (69.2 vs 65.8, Nomic's own table).
• –Long-context wins are benchmark-dependent. The LoCo blowout (85.53 vs ada's 52.7) is real, but on Jina Long Context both OpenAI models score higher. 8,192 tokens of input capacity does not mean 8,192 tokens embed as well as focused 500-token chunks — good chunking still beats long-context embedding for most RAG.
• –The prefix requirement is a footgun. No error, no warning, just silently degraded retrieval. Frameworks won't add prefixes for you.
• –Embedding-only. It cannot generate, rerank, or chat. A full RAG stack still needs a generator — on an 8GB GPU it pairs cleanly with a small chat model; see the best Ollama models for 8GB VRAM for what fits alongside it.

Frequently asked questions