voyage-4-large is Voyage AI's flagship text embedding model in the Voyage 4 family. It represents source passages and queries as numerical vectors for general-purpose and multilingual retrieval. Its two distinguishing features are a mixture-of-experts model design and the shared embedding space used by voyage-4-large, voyage-4, voyage-4-lite and voyage-4-nano.
The manufacturer describes asymmetric retrieval: documents can be embedded with voyage-4-large while a different Voyage 4 family model prepares the query vectors. For example, a corpus represented by Large can be searched with voyage-4 queries. This lets the two sides of search have different model choices while remaining in the documented compatible space.
A practical collection can therefore use Large to prepare stable document passages and choose the query-side model independently. Documents are embedded when the corpus is created or updated, while queries are vectorized as users search. The family announcement describes changing the query model within the compatible family without re-vectorizing the document corpus solely for that change. Keep compared vectors at matching dimensions and in representations the search system can interpret together.
A dense feed-forward layer processes every token through its full parameter set. The MoE approach described for voyage-4-large uses a router and expert feed-forward networks, selecting the experts that process each token. This separates total model capacity from the parameters active for a particular token. Voyage reports an activation ratio of 1/10 for the model's MoE design, using top-k routing.
The maker's technical explanation also describes two development choices. Expert capacity affects whether excess tokens bypass an expert layer through a residual path; the team chose the largest feasible capacity factor to avoid retrieval-quality loss. In the final training stage, router parameters are frozen before model merging so interpolation of the source models does not change the learned expert-selection routing. These are characteristics of model preparation, distinct from the text-length or truncation settings used when preparing an input.
The official model table specifies a 32,000-token context window and selectable 256-, 512-, 1024- and 2048-dimensional embeddings, with 1024 as the default. The family uses Matryoshka learning for nested representation sizes and supports quantization choices: 32-bit floating point, signed or unsigned 8-bit integers, and packed binary output.
With binary output, the returned byte-list length is one eighth of the selected dimension because each byte contains eight embedding bits. Preserve the dimension and data-type choices with the index, and use a comparison method that supports that representation. A smaller or compressed vector changes the representation used for search; assess the relevant passages returned on actual questions before choosing it for a collection.
Voyage recommends using the document role for corpus passages and the query role for search wording. Its role option adds the corresponding retrieval instruction before embedding. Preserve the passage's useful heading, conditions and source location, then store the returned vector with the original text and a stable identifier.
For a technical knowledge collection, a question about a failure mode should lead to the passage describing that mode and its relevant conditions. For a document collection spanning languages, retain the source language and evaluate the questions and terminology users will search with. The release covers retrieval material including technical documents, conversations, long documents, code, law, finance and web text. The embedding locates candidate material; a later reranker or answer stage uses the original text.
The maker's current guide allows up to 1,000 strings and 120,000 total input tokens in a voyage-4-large request. This differs from the batch allowance listed for voyage-4, while both have a 32,000-token per-text window. Default truncation shortens an over-length input to fit; disabling truncation returns an error for an over-length text.
Choose answer-bearing passage boundaries deliberately so a long source does not lose a relevant qualification at a truncated tail. Keep the source association when returning search results, and inspect the actual candidate text rather than treating vector proximity as verification of its contents. Shared-space compatibility applies to the documented Voyage 4 text family; contextualized chunk processing, image/video embeddings and later model editions remain their own model-specific workflows.
", "aboutText": "voyage-4-large is Voyage AI's flagship text embedding model in the Voyage 4 family. It represents source passages and queries as numerical vectors for general-purpose and multilingual retrieval. Its two distinguishing features are a mixture-of-experts model design and the shared embedding space used by voyage-4-large, voyage-4, voyage-4-lite and voyage-4-nano.\n\n### Shared space: separate corpus and query choices\n\nThe manufacturer describes asymmetric retrieval: documents can be embedded with voyage-4-large while a different Voyage 4 family model prepares the query vectors. For example, a corpus represented by Large can be searched with voyage-4 queries. This lets the two sides of search have different model choices while remaining in the documented compatible space.\n\nA practical collection can therefore use Large to prepare stable document passages and choose the query-side model independently. Documents are embedded when the corpus is created or updated, while queries are vectorized as users search. The family announcement describes changing the query model within the compatible family without re-vectorizing the document corpus solely for that change. Keep compared vectors at matching dimensions and in representations the search system can interpret together.\n\n### Mixture-of-experts embedding design\n\nA dense feed-forward layer processes every token through its full parameter set. The MoE approach described for voyage-4-large uses a router and expert feed-forward networks, selecting the experts that process each token. This separates total model capacity from the parameters active for a particular token. Voyage reports an activation ratio of 1/10 for the model's MoE design, using top-k routing.\n\nThe maker's technical explanation also describes two development choices. Expert capacity affects whether excess tokens bypass an expert layer through a residual path; the team chose the largest feasible capacity factor to avoid retrieval-quality loss. In the final training stage, router parameters are frozen before model merging so interpolation of the source models does not change the learned expert-selection routing. These are characteristics of model preparation, distinct from the text-length or truncation settings used when preparing an input.\n\n### Dimensions and output representation\n\nThe official model table specifies a 32,000-token context window and selectable 256-, 512-, 1024- and 2048-dimensional embeddings, with 1024 as the default. The family uses Matryoshka learning for nested representation sizes and supports quantization choices: 32-bit floating point, signed or unsigned 8-bit integers, and packed binary output.\n\nWith binary output, the returned byte-list length is one eighth of the selected dimension because each byte contains eight embedding bits. Preserve the dimension and data-type choices with the index, and use a comparison method that supports that representation. A smaller or compressed vector changes the representation used for search; assess the relevant passages returned on actual questions before choosing it for a collection.\n\n### Prepare document and query inputs\n\nVoyage recommends using the document role for corpus passages and the query role for search wording. Its role option adds the corresponding retrieval instruction before embedding. Preserve the passage's useful heading, conditions and source location, then store the returned vector with the original text and a stable identifier.\n\nFor a technical knowledge collection, a question about a failure mode should lead to the passage describing that mode and its relevant conditions. For a document collection spanning languages, retain the source language and evaluate the questions and terminology users will search with. The release covers retrieval material including technical documents, conversations, long documents, code, law, finance and web text. The embedding locates candidate material; a later reranker or answer stage uses the original text.\n\n### Context, batching and truncation limits\n\nThe maker's current guide allows up to 1,000 strings and 120,000 total input tokens in a voyage-4-large request. This differs from the batch allowance listed for voyage-4, while both have a 32,000-token per-text window. Default truncation shortens an over-length input to fit; disabling truncation returns an error for an over-length text.\n\nChoose answer-bearing passage boundaries deliberately so a long source does not lose a relevant qualification at a truncated tail. Keep the source association when returning search results, and inspect the actual candidate text rather than treating vector proximity as verification of its contents. Shared-space compatibility applies to the documented Voyage 4 text family; contextualized chunk processing, image/video embeddings and later model editions remain their own model-specific workflows.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "a00566c3cf5888e90d237c7cde958531545448ecf067c8e35f337635090c644b", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "voyageai/voyage-4-largevoyage-4-large is Voyage AI’s mixture-of-experts text embedding model for general-purpose and multilingual retrieval. Its vectors share the Voyage 4 family space, allowing corpus embeddings from Large to be searched with compatible query embeddings from other family models.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
voyage-4-large is Voyage AI's flagship text embedding model in the Voyage 4 family. It represents source passages and queries as numerical vectors for general-purpose and multilingual retrieval. Its two distinguishing features are a mixture-of-experts model design and the shared embedding space used by voyage-4-large, voyage-4, voyage-4-lite and voyage-4-nano.
The manufacturer describes asymmetric retrieval: documents can be embedded with voyage-4-large while a different Voyage 4 family model prepares the query vectors. For example, a corpus represented by Large can be searched with voyage-4 queries. This lets the two sides of search have different model choices while remaining in the documented compatible space.
A practical collection can therefore use Large to prepare stable document passages and choose the query-side model independently. Documents are embedded when the corpus is created or updated, while queries are vectorized as users search. The family announcement describes changing the query model within the compatible family without re-vectorizing the document corpus solely for that change. Keep compared vectors at matching dimensions and in representations the search system can interpret together.
A dense feed-forward layer processes every token through its full parameter set. The MoE approach described for voyage-4-large uses a router and expert feed-forward networks, selecting the experts that process each token. This separates total model capacity from the parameters active for a particular token. Voyage reports an activation ratio of 1/10 for the model's MoE design, using top-k routing.
The maker's technical explanation also describes two development choices. Expert capacity affects whether excess tokens bypass an expert layer through a residual path; the team chose the largest feasible capacity factor to avoid retrieval-quality loss. In the final training stage, router parameters are frozen before model merging so interpolation of the source models does not change the learned expert-selection routing. These are characteristics of model preparation, distinct from the text-length or truncation settings used when preparing an input.
The official model table specifies a 32,000-token context window and selectable 256-, 512-, 1024- and 2048-dimensional embeddings, with 1024 as the default. The family uses Matryoshka learning for nested representation sizes and supports quantization choices: 32-bit floating point, signed or unsigned 8-bit integers, and packed binary output.
With binary output, the returned byte-list length is one eighth of the selected dimension because each byte contains eight embedding bits. Preserve the dimension and data-type choices with the index, and use a comparison method that supports that representation. A smaller or compressed vector changes the representation used for search; assess the relevant passages returned on actual questions before choosing it for a collection.
Voyage recommends using the document role for corpus passages and the query role for search wording. Its role option adds the corresponding retrieval instruction before embedding. Preserve the passage's useful heading, conditions and source location, then store the returned vector with the original text and a stable identifier.
For a technical knowledge collection, a question about a failure mode should lead to the passage describing that mode and its relevant conditions. For a document collection spanning languages, retain the source language and evaluate the questions and terminology users will search with. The release covers retrieval material including technical documents, conversations, long documents, code, law, finance and web text. The embedding locates candidate material; a later reranker or answer stage uses the original text.
The maker's current guide allows up to 1,000 strings and 120,000 total input tokens in a voyage-4-large request. This differs from the batch allowance listed for voyage-4, while both have a 32,000-token per-text window. Default truncation shortens an over-length input to fit; disabling truncation returns an error for an over-length text.
Choose answer-bearing passage boundaries deliberately so a long source does not lose a relevant qualification at a truncated tail. Keep the source association when returning search results, and inspect the actual candidate text rather than treating vector proximity as verification of its contents. Shared-space compatibility applies to the documented Voyage 4 text family; contextualized chunk processing, image/video embeddings and later model editions remain their own model-specific workflows.
POST /v1/embeddingstext, token_idsembedding| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits voyageai/voyage-4-large | Default— |
Fieldinput | Typestring|string[]|integer[]|integer[][] | RequirementRequired | Values & limits Minimum items: 1 Conditions: Nonempty homogeneous batch. Token IDs are nonnegative integers. Input budget: Maximum: 32,000 · Text unit: UTF8 bytes · Token unit: token-array elements | Default— |
Fieldencoding_format | Typestring | RequirementOptional | Values & limits float | Defaultfloat |
Fielddimensions | Typeinteger | RequirementNot supported | Values & limits Minimum: 1 | Default— |
Fielduser | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldsession_id | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldtrace | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits Conditions: provider.options rejected | Default— |
text_to_embedding
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, input |
Parameterinput_shapes | Contractstring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parameterencoding_format | Contractfloat |
Parameterdimensions_override | Contractfalse |
Parametermax_input_budget_units | Contract32000 |
Parametermultimodal_objects | Contractfalse |
Parametermaterial_types | Contracttext, token_ids |
Lifecycle: synchronous_json
Keep every vector index and dimension.
Multimodal model name does not admit image objects on this exact path.
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0.00024 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "voyageai/voyage-4-large", "input": ["First document", "Second document"]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/embeddings \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("data",[]): print(json.dumps({"index":x.get("index"),"embedding":x.get("embedding")}))\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.embeddings.create(model='voyageai/voyage-4-large',input=["First document","Second document"])\nprint(result)\nfor item in result.data:print(item.index,item.embedding)\njson
Keep every complete returned response, file and content part.
Keep every vector with its index. Vector count must equal input count; dimensions must be consistent.
No embedding job endpoint is introduced.
| Field | Type |
|---|---|
Fieldobject | Typestring |
Fieldmodel | Typestring |
Fielddata[].index | Typeinteger |
Fielddata[].embedding | Typefinite float[] |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra voyageai/voyage-4-large
Use the method paths shown above.