How These Options Were Compared
This comparison uses official model documentation, model cards, published pricing, and lifecycle information checked on October 20, 2026. The shortlist is organized by workload and deployment requirements, not an independently measured performance ranking. Published limits describe the cited model or checkpoint; hosting platforms may impose different limits. No private accuracy, latency, or successful-task measurements are claimed.
Embedding Model Comparison: Context, Dimensions, and Cost
| Model |
Direct-provider text input / 1M tokens |
Published input limit |
Dimensions |
Primary fit |
| text-embedding-3-large |
$0.13 |
8,192 |
3,072 default; reducible |
Hosted semantic-search baseline |
| Gemini Embedding 2 |
$0.20 for text |
8,192 |
128–3,072; 768/1,536/3,072 recommended |
Cross-modal retrieval |
| Voyage 4 — voyage-4 |
$0.06 |
32,000 |
1,024 default; 256/512/2,048 optional |
General-purpose multilingual retrieval |
| Embed 5 Pro — embed-v5.0-pro |
$0.12 for text |
128K |
2,048 default; multiple reduced sizes |
Long-document and text-plus-image search |
| Qwen3-Embedding-8B |
Hosting- and deployment-specific |
32K |
32–4,096 |
Open-weight multilingual retrieval |
| BGE-M3 |
Hosting- and deployment-specific |
8,192 |
1,024 dense; sparse/multi-vector outputs separate |
Self-hosted multilingual and hybrid retrieval |
| Jina Embeddings v5 text small |
Model- and deployment-specific |
32,768 |
1,024 full size; reducible |
Compact text retrieval with task adapters |
| text-embedding-3-small |
$0.02 |
8,192 |
1,536 default; reducible |
Cost-sensitive hosted text retrieval |
| Nemotron-3-Embed-1B |
Hosting- and deployment-specific |
32,768 |
2,048 |
Compact retrieval-model evaluation |
The quoted OpenAI, Google, Voyage, and Cohere amounts are standard text-input rates, not GPT Proto prices. Image, audio, video, batch, and trial terms differ. Google rates, Voyage rates, and OpenAI embedding dimensions and limits document those distinctions. Rates and limits were checked October 20, 2026.
The 9 Embedding Models, by Retrieval Requirement
1. text-embedding-3-large — Hosted semantic-search baseline
OpenAI provides this model through a hosted embedding API; retrieval quality should be evaluated on labeled queries from the intended corpus. Its larger default vectors increase raw index storage compared with the small model. Choose it when labeled corpus tests show a worthwhile retrieval gain, not merely because its name says large. OpenAI documents dimension reduction; both stored vectors and query vectors must use the same model and dimension settings. (Source: OpenAI text-embedding-3-large specifications).
2. Gemini Embedding 2 — Cross-modal retrieval
Google documents text, image, audio, video, and PDF inputs in one embedding space. This makes it relevant to product catalogs and document collections where a text query must locate non-text assets. Its text rate cannot be applied to audio or video: those inputs have separate prices. PDF ingestion and cross-modal retrieval also require suitable preprocessing and evaluation; multimodal support does not guarantee correct field extraction. (Source: Gemini Embedding 2 model specifications).
3. Voyage 4 — voyage-4 — General-purpose multilingual retrieval
Voyage 4 is a general-purpose multilingual embedding model, not a legal-, finance-, or code-specialized checkpoint. Voyage publishes separate domain models, with separate prices. Its documented 4-series shared vector space is an important exception to the usual migration rule: supported combinations can reuse an index when the required settings match. That compatibility should not be generalized to unrelated models or older Voyage generations. (Source: Voyage 4 model specifications).
4. Embed 5 Pro — embed-v5.0-pro — Long-document and text-plus-image search
Cohere documents text and image inputs, more than 100 languages, and a 128K context window. The model therefore belongs alongside Gemini in a multimodal shortlist, rather than behind a claim that only one model supports cross-modal retrieval. A large input window allows larger units but does not remove chunking trade-offs. Embed 5 Pro and Fast share a vector space under Cohere’s documented compatibility conditions; governance depends on the chosen deployment and contract. (Source: Embed 5 Pro model specifications).
5. Qwen3-Embedding-8B — Open-weight multilingual retrieval
This open-weight model supports instruction-aware retrieval and more than 100 languages. The 8B size affects GPU memory, batch throughput, and operating costs. Query instructions, normalization, output dimensions, and document preprocessing must remain consistent. Sharing the Qwen brand with a generation model does not create a special vector-to-language-model interface: retrieved text, not embedding-space alignment, is what the generator receives. (Source: Qwen3-Embedding-8B model specifications).
6. BGE-M3 — Self-hosted multilingual and hybrid retrieval
BGE-M3 provides dense, sparse, and multi-vector representations from one checkpoint. Dense vectors alone do not activate all three retrieval modes; the index and scoring implementation must support the selected representation. Its multilingual design and downloadable weights make it relevant to on-premises search. Local deployment adds compute, storage, maintenance, and access-control work; it is not free production inference. (Source: BGE-M3 model specifications).
7. Jina Embeddings v5 text small — Compact text retrieval with task adapters
The exact checkpoint is jina-embeddings-v5-text-small, not the entire v5 family. Other small, nano, text, and omni variants have different capabilities. Task adapters distinguish retrieval roles. Moving from an API to local inference preserves vectors only when checkpoint, adapter, preprocessing, dimensions, normalization, and version match. The downloadable weights use CC BY-NC 4.0, so commercial users need to arrange licensing with Jina. Hosted API access has separate service terms. (Source: Jina Embeddings v5 text small model specifications).
8. text-embedding-3-small — Cost-sensitive hosted text retrieval
At the published default dimensions, text-embedding-3-small returns 1,536-dimensional vectors, compared with 3,072 for text-embedding-3-large. It reduces default vector size and published token cost relative to 3-large. A reranker can improve the ordering of candidates returned by the retriever, but cannot recover documents absent from that candidate set. Measure first-stage recall before assuming a cheaper embedding model plus reranking will match a more expensive setup. (Source: OpenAI text-embedding-3-small specifications).
9. Nemotron-3-Embed-1B — Compact retrieval-model evaluation
NVIDIA documents this model separately from any third-party free endpoint. Its model card reports evaluation across 34 languages; that is not equivalent to a guarantee of equal accuracy in each language. A provider may offer limited free access, but a free route is neither a universal model tariff nor a production availability commitment. Compare retrieval quality and throughput alongside the endpoint’s limits. (Source: Nemotron-3-Embed-1B model specifications).
What to Measure Before Choosing an Embedding Model
Build a labeled query-document set from the intended workload. Measure recall@k for candidate retrieval and a ranking metric such as nDCG@k for ordering. Include short queries, ambiguous terms, multilingual queries, and relevant documents with distracting neighbors. A general MTEB score is useful context, not a substitute for these tests.
Keep chunking and the vector database configuration fixed when comparing models. Then evaluate chunking separately: larger chunks can preserve context but dilute relevance, while very small chunks can remove facts needed to answer the question. A longer model input limit is a capacity allowance, not an optimal chunk size.
Dimensions, Reranking, and Migration
The index must accept the output vector size. Dimension reduction saves storage but its quality impact depends on the model and dataset. Sparse and multi-vector representations need different indexes or scoring paths from a conventional dense-vector index.
Changing an embedding model generally requires re-embedding documents and switching query encoding at the same time. Matching dimensions alone does not make vectors compatible. Voyage 4-series and Cohere Embed 5 Pro/Fast document specific shared-space arrangements; preserve the required model settings when using those exceptions.
A reranker receives a candidate set and reorders it. Increase retrieval depth or improve retrieval before expecting reranking to fix missing evidence. Maintain separate indexes when comparing incompatible embedding spaces.
API Cost Versus Self-Hosting Cost
Total retrieval cost includes initial indexing, document updates, query embeddings, vector storage, search, and any reranking. Query volume does not always dominate: large or frequently changing corpora can make indexing the larger expense. Self-hosting adds hardware, utilization, software maintenance, and operational capacity.
For a concrete API-only illustration, 100 million text tokens at the published $0.02 rate cost $2 with text-embedding-3-small; at $0.13 they cost $13 with text-embedding-3-large. These arithmetic examples exclude storage, search, retries, discounts, and taxes; they do not predict retrieval quality.
Embedding Access Through GPT Proto
GPT Proto lists text-embedding-3-small and text-embedding-3-large as model-specific entry points. These listings are a starting point for comparing model access; the embedding endpoint and supported parameters depend on the route documentation. They do not establish availability for every model in this nine-model shortlist. GPT Proto acts as an intermediary for third-party models rather than developing the embedding models itself.
Supported routes use one account, one API key, and a shared prepaid balance. For a RAG project, that account structure can accommodate supported embedding and generation usage without requiring a separate prepaid balance for each provider. It does not make their interfaces interchangeable: embedding requests produce vectors, while generation requests produce answers from supplied context.
Before integrating a model, check its API Usage panel for the embedding endpoint, model identifier, accepted inputs, and available settings. Use the documented embedding interface rather than copying a Chat Completions example. Where dimension controls are exposed, confirm the returned vector length and configure the index accordingly. A model publisher’s native feature list does not establish that every setting is available through the selected GPT Proto route.
For evaluation, keep the document sample, chunking, query set, and search configuration consistent. Compare retrieval recall and ranking quality before considering downstream answer quality. If testing incompatible embedding spaces, use separate indexes and encode each query with the matching model and settings. These are application-level evaluation steps, not results of an independent GPT Proto endpoint benchmark.
Billing is prepaid, with no required monthly subscription and no expiry for unused credits under the published pricing terms. The pricing page lists a $15 entry top-up; this adds usage balance rather than unlimited inference. Use the selected model’s current rate when estimating initial indexing, document updates, and query embeddings. Vector storage, search, reranking, and answer generation remain separate cost components rather than benefits included in an embedding token rate.
GPT Proto is therefore an access option within a retrieval pipeline, not a replacement for the vector database or retrieval implementation. The application still owns document preparation, access controls, indexing, relevance evaluation, and error handling. Its practical fit depends on the documented route, observed retrieval results, and total operating requirements—not the presence of a model name in the catalog alone.