Rulați modele de embedding local cu Ollama: Am cronometrat GPU rece vs. cald

Rulați modele de embedding local cu Ollama: Am cronometrat GPU rece vs. cald

Puteți rula modele de embedding local cu Ollama și puteți opri plata către OpenAI a sumei de 0,02 $ per milion de tokeni pentru fiecare fragment pe care îl indexați. Compromisul: dețineți GPU-ul, timpii de pornire la rece (cold starts) și operațiunile IT. Ollama le servește pe portul 11434 fără cheie API. Iată fluxul de lucru complet, de la ollama pull până la o căutare vectorială activă care răspunde la interogări.

Principalele concluzii

• Ollama servește embedding-uri local pe http://localhost:11434 prin POST /api/embed, fără cheie API și cu cost 0 $ per token.
• Folosiți /api/embed (actual, array batch); /api/embeddings este legacy și sursa obișnuită a erorilor 404.
• Modele locale populare: nomic-embed-text (768 dim), mxbai-embed-large (1024), bge-m3 (1024), embeddinggemma (768).
• Potrivește dimensiunea embedding-ului cu coloana bazei de date vectoriale și fixează modelul cu keep_alive pentru a evita latența de pornire la rece.

De ce aveți nevoie pentru a rula embedding-uri local cu Ollama?

Tot ceea ce aveți nevoie pentru a rula embedding-uri local se rezumă la trei componente: un model de embedding, serverul Ollama pe portul 11434 și un stocaj vectorial pentru a păstra output-ul. Ollama descarcă și servește modelul; codul dumneavoastră postează text către /api/embed; vectorii ajung într-o bază de date precum pgvector, Qdrant sau Chroma. Fără dus-întors către cloud, fără facturare per token.

Două comenzi vă oferă un embedding funcțional în mai puțin de un minut:

ollama pull nomic-embed-text
curl http://localhost:11434/api/embed -d '{
  "model": "nomic-embed-text",
  "input": "The quick brown fox"
}'

Acesta este întregul ghid de start rapid. Restul acestui tutorial completează alegerea modelului, stocarea și cele două capcane care îi prind pe toți: confuzia endpoint-urilor și penalizarea de pornire la rece.

Pasul 1: Instalați Ollama și descărcați un model de embedding

Instalați Ollama, confirmați că serverul ascultă pe portul 11434, apoi descărcați un model de embedding. Ollama rulează ca un serviciu în background, astfel încât ollama pull nomic-embed-text descarcă ponderile, iar următorul apel /api/embed le va servi. Modelele de embedding sunt minuscule comparativ cu modelele de chat, deci procesul este rapid.

# macOS / Linux install
curl -fsSL https://ollama.com/install.sh | sh

# Make sure the server is up (background service on :11434)
ollama serve            # only if it isn't already running

# Pull an embedding model and health-check the server
ollama pull nomic-embed-text
curl http://localhost:11434            # should return "Ollama is running"

Partea interesantă: un model de embedding precum nomic-embed-text are doar 137M parametri, aproximativ o descărcare de 274 MB, față de modelele de chat de câțiva gigabytes. Se încarcă în VRAM în aproximativ o secundă. Dacă doriți configurarea completă LLM locală pentru ca un model de chat să stea alături de embedder-ul dumneavoastră, ghidul nostru despre configurarea Ollama pentru LLM-uri locale acoperă această cale, precum și o interfață UI pentru modelele locale Ollama dacă preferați click-uri în locul comenzilor curl.

Sfat pro: serverul trebuie să ruleze înainte de orice cerere. O conexiune refuzată pe :11434 înseamnă aproape întotdeauna că ollama serve nu este activ.

Ce model local de embedding ar trebui să descărcați?

Pentru majoritatea sistemelor RAG locale, nomic-embed-text la 768 de dimensiuni este implicitul sigur. Depășește vechiul ada-002 de la OpenAI și rulează pe aproape orice hardware. Alegeți bge-m3 sau qwen3-embedding când aveți nevoie de recuperare multilingvă sau cu context lung, all-minilm pentru viteză pe hardware modest și embeddinggemma ca opțiune Google mai nouă. Tabelul de mai jos acoperă actuala bibliotecă de modele de embedding Ollama ca decizie de servire, nu ca clasament al calității.

În firele de discuție „best ollama embedding model reddit”, consensul recurent este nomic-embed-text pentru RAG general și bge-m3 când treceți la multilingv, ceea corespunde cu ceea ce livrăm noi. Dacă doriți vizualizarea ierarhizată, între provideri, cu scoruri, aceasta este sarcina hub-ului: ce model de embedding să alegeți pentru RAG. Omitem deliberat numerele MTEB aici; articolul nostru companion despre cum funcționează scorurile MTEB pentru RAG explică de ce clasamentul alone vă poate induce în eroare.

Pasul 2: Generați embedding-uri prin /api/embed

Trimiteți text către POST /api/embed și Ollama returnează vectori normalizați L2, ceea ce înseamnă că fiecare are lungimea unitară, astfel încât similaritatea cosinus funcționează direct. Conform documentației Ollama embeddings, endpoint-ul actual acceptă un câmp input care primește fie un singur șir de caractere, fie un array pentru batching, și returnează {"embeddings": [[...]]}.

Apelul HTTP brut:

curl http://localhost:11434/api/embed -d '{
  "model": "nomic-embed-text",
  "input": ["first chunk", "second chunk", "third chunk"]
}'

În Python, clientul oficial necesită o linie per batch:

import ollama

resp = ollama.embed(
    model="nomic-embed-text",
    input=["first chunk", "second chunk", "third chunk"],
    options={"num_ctx": 8192},  # raise context for long chunks
)
vectors = resp["embeddings"]   # list of 768-float lists, L2-normalized

Batching-ul prin array-ul input este pârghia principală de throughput. O cerere cu 64 de fragmente bate 64 de cereri individuale cu o marjă largă, deoarece plătiți overhead-ul per apel o singură dată. Rețineți creșterea num_ctx: nomic-embed-text are implicit o fereastră de 2048 de tokeni, deși suportă nativ 8192, astfel încât fragmentele lungi sunt trunchiate silențios dacă nu o creșteți. Embedding-ul este o etapă din pipeline-ul RAG complet către care alimentează acest proces; logica de chunking și retrieval trăiește acolo, nu aici.

/api/embed vs /api/embeddings vs /v1/embeddings: Care este diferența?

/api/embed este endpoint-ul curent; /api/embeddings este cel depreciat, din spatele majorității postărilor „Ollama embeddings not working”. Ruta legacy folosește un câmp singular prompt și returnează embedding (fără s), în timp ce ruta curentă folosește input, acceptă batch-uri și returnează embeddings. O a treia rută, /v1/embeddings, este compatibilă OpenAI și acceptă un parametru dimensions.

Primiți o eroare 404 sau o formă ciudată a răspunsului? Probabil sunteți pe /api/embeddings (legacy). Treceți la /api/embed și citiți cheia embeddings în loc de embedding. Acest singur caracter îi derutează pe mulți care copiază tutoriale vechi.

Ruta /v1/embeddings contează pentru un caz specific: migrarea de la OpenAI. Deoarece acceptă un parametru dimensions, puteți trunchia un model capabil Matryoshka la o dimensiune țintă, ceea ce reprezintă soluția pentru nepotrivirea de 1536 de dimensiuni pe care o abordăm mai departe.

Pasul 3: Stocați și căutați vectorii (pgvector, Qdrant sau Chroma)

Stocați vectorii de 768 de float-uri într-o bază de date care efectuează căutarea nearest-neighbor, apoi interogați cu distanța cosinus. În construcțiile noastre RAG, folosim implicit Postgres plus pgvector pentru echipele deja pe Postgres, deoarece păstrează embedding-urile lângă datele relaționale. Activați extensia, declarați o coloană VECTOR(768) care se potrivește cu dimensiunea modelului, inserați și interogați cu operatorul cosinus <=>.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id     bigserial PRIMARY KEY,
  body   text,
  embedding vector(768)          -- must match nomic-embed-text
);

-- Insert a row (embedding comes from ollama.embed)
INSERT INTO chunks (body, embedding) VALUES ('first chunk', '[0.01, -0.02, ...]');

-- Top-5 nearest chunks by cosine distance
SELECT body, 1 - (embedding <=> '[0.01, -0.02, ...]') AS score
FROM chunks
ORDER BY embedding <=> '[0.01, -0.02, ...]'
LIMIT 5;

Qdrant și Chroma funcționează conceptual la fel: creați o colecție cu o dimensiune vectorială fixă care se potrivește cu modelul, apoi faceți upsert și search. Regula este valabilă peste tot: alegerea unei baze de date vectoriale contează mai puțin decât obținerea dimensiunii corecte, deoarece Qdrant, Chroma și pgvector resping toate un vector whose size doesn't match the collection. Consultați comparația noastră Qdrant vs Chroma vs pgvector dacă încă decideți.

Capcana migrației: niciun model Ollama nu este nativ 1536-dim, astfel încât o coloană pgvector existentă VECTOR(1536) le va respinge. Trei soluții: (1) alegeți un model a cărui dimensiune se potrivește cu coloana, (2) folosiți /v1/embeddings cu un parametru dimensions pe un model Matryoshka precum qwen3-embedding sau embeddinggemma pentru a trunchia la 1536, sau (3) redeclarați coloana la dimensiunea nativă a modelului, cum ar fi VECTOR(768).

Am cronometrat nomic-embed-text pe un RTX 4090: Pornire la rece vs. GPU cald

Am măsurat. Pe configurația noastră (Ubuntu 22.04, RTX 4090 24 GB, Ollama 0.5.x, nomic-embed-text la 768-dim), primul /api/embed după o perioadă de inactivitate a durat aproximativ 1,3 secunde în timp ce ponderile se încărcau în VRAM. Odată încălzit, am observat p50 aproape de 9 ms și p95 aproape de 22 ms per embedding. La batch de 64, am menținut aproximativ 600 embedding-uri/sec.

Iată capcana care răspunde la întrebarea „de ce sunt lente sau expiră timeout-ul embedding-urile Ollama”. Implicit, Ollama descarcă un model din VRAM după aproximativ 5 minute de inactivitate. Astfel, următoarea cerere plătește din nou acea pornire la rece de ~1,3 s, ceea ce pare un vârf aleatoriu în producție. Soluția este keep_alive:

curl http://localhost:11434/api/embed -d '{
  "model": "nomic-embed-text",
  "input": "keep me warm",
  "keep_alive": -1
}'

Setarea keep_alive: -1 fixează modelul în VRAM indefinit, astfel încât fiecare cerere rămâne pe calea „caldă”. Cald, nomic-embed-text pe un RTX 4090 a menținut p95 aproape de 22 ms. Lăsați-l inactiv 5 minute și următoarea cerere va plăti din nou o pornire la rece de ~1,3 s. Pentru un serviciu sensibil la latență, fixați-l.

Merită self-hosting-ul pentru embedding-uri? Cost vs. un API

Embedding-urile locale costă aproximativ 0 $ per milion de tokeni la margine, plus electricitatea, față de aproximativ 0,02 $ per milion de tokeni pentru OpenAI text-embedding-3-small. Dar răspunsul onest este: self-hosting-ul câștigă doar peste un prag de volum de tokeni. Sub câteva sute de milioane de tokeni pe lună, plătiți în timp de operațiuni IT și GPU inactiv, nu în dolari economisiți. Conveniența API-ului câștigă pentru volume mici.

Self-hosting-ul embedding-urilor bate API-ul doar peste aproximativ câteva sute de milioane de tokeni pe lună. Sub acest nivel, plătiți în timp de operațiuni IT, nu în dolari economisiți. Unde local nu se potrivește bine: volum scăzut de interogări, lipsa unui GPU sau o echipă fără capacitatea operațională de a menține un server sănătos. În aceste cazuri, un API gestionat este apelul pragmatic, iar o comparație a API-urilor de embedding Voyage, OpenAI și Cohere este următorul lucru de citit. Nu sunteți sigur dacă doriți să dețineți GPU-ul și operațiunile deloc? Multe echipe păstrează embedding-urile local pentru confidențialitate, dar aduc ajutor pentru configurare și mentenanța zilnică, ceea ce reprezintă tipul de construcție pe care serviciul nostru de integrare AI îl gestionează. Dacă doriți să comparați runtime-urile, vedeți alte instrumente pentru rularea modelelor local.

Despre autor

Mert Batur Gurbuz este Co-fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voice/SDR pentru clienți B2B. Studiază la Universitatea din Birmingham și scrie despre stack-ul de tooling LLM pe care echipa Techsy îl folosește efectiv în producție.

Credenziale: Co-fondator, Techsy.io, Universitatea din Birmingham. Conectați-vă pe LinkedIn.

Întrebări frecvente

Este rularea embedding-urilor local cu Ollama realmente mai ieftină decât API-ul OpenAI?

Doar peste un prag de volum de tokeni. Costul marginal local este aproximativ 0 $ per milion de tokeni plus electricitatea, față de aproximativ 0,02 $ pentru OpenAI text-embedding-3-small. Sub câteva sute de milioane de tokeni pe lună, API-ul câștigă la conveniență și zero operațiuni IT. Un alt motiv pentru self-hosting este confidențialitatea: datele dumneavoastră nu părăsesc niciodată mașina.

Care este diferența dintre /api/embed și /api/embeddings?

/api/embed este endpoint-ul curent. Acceptă un câmp input (un șir sau un array pentru batching) și returnează embeddings. /api/embeddings este ruta legacy, depreciată, cu un câmp singular prompt care returnează embedding. Dacă întâmpinați o eroare 404 sau o formă neașteptată a răspunsului, aproape sigur sunteți pe cea veche.

Sunt embedding-urile Ollama gratuite?

Da, în sensul că nu există taxă per token și nu este necesară o cheie API. Plătiți pentru hardware și electricitatea necesară rulării acestuia. Nu există facturare contorizată ca la un API cloud, deci odată ce GPU-ul rulează, generarea unui alt milion de embedding-uri nu costă practic nimic la margine.

Care este modelul de embedding Ollama implicit sau cel mai bun pentru RAG?

nomic-embed-text la 768 de dimensiuni este implicitul popular pentru RAG local; depășește vechiul ada-002 de la OpenAI și rulează pe hardware modest. Pentru lucrări multilingve sau cu context lung, bge-m3 sau qwen3-embedding sunt mai puternice. Pentru comparația ierarhizată, cu scoruri, între provideri, consultați hub-ul nostru de modele de embedding.

De ce sunt lente sau expiră timeout-ul embedding-urile mele Ollama?

Prima cerere după inactivitate plătește o pornire la rece în timp ce modelul se încarcă în VRAM, aproximativ 1,3 secunde pe RTX 4090-ul nostru. Ollama descarcă, de asemenea, modelul după aproximativ 5 minute de inactivitate implicit, astfel încât lentoarea intermitentă este de obicei o pornire la rece repetată. Setati keep_alive: -1 pentru a fixa modelul în VRAM.

Poate Ollama să egaleze embedding-urile OpenAI de 1536 de dimensiuni?

Niciun model Ollama nu este nativ 1536-dim, astfel încât migrarea unei coloane existente VECTOR(1536) eșuează din cauza nepotrivirii de dimensiuni. Remediați acest lucru apelând /v1/embeddings cu un parametru dimensions pe un model Matryoshka precum qwen3-embedding sau embeddinggemma, sau redeclarați coloana la dimensiunea nativă a modelului, cum ar fi VECTOR(768).

Am nevoie de un GPU pentru a rula modele de embedding local?

Nu. Modelele mici precum nomic-embed-text (137M) și all-minilm (22M) rulează bine pe CPU pentru volume mici. Un GPU reduce latența per embedding la milisecunde cu o singură cifră și crește throughput-ul batch la sute de embedding-uri pe secundă, ceea ce contează când indexați mii de fragmente simultan.

Cum folosesc embedding-urile Ollama în Python sau LangChain?

Apelul clientului oficial este ollama.embed(model="nomic-embed-text", input=["fragment a", "fragment b"]), care returnează o listă embeddings. În LangChain, utilizați clasa OllamaEmbeddings pointată către http://localhost:11434, apoi transmiteți-o metodei from_documents sau add_texts a stocajului vectorial, ca orice alt provider de embedding.

Ce lungime de context pot gestiona modelele de embedding Ollama?

Variază în funcție de model. nomic-embed-text suportă nativ 8192 de tokeni, dar are implicit o fereastră de 2048 de tokeni când este servit, deci creșteți num_ctx la 8192 pentru fragmente lungi, altfel vor fi trunchiate silențios. bge-m3 gestionează 8192, iar qwen3-embedding merge până la 32K; all-minilm este limitat la 256 de tokeni.