Qwen3-Embedding-8B is Qwen’s 8B text-embedding model, built from the dense Qwen3 foundation model. It represents text as numerical vectors rather than generating conversational answers. Qwen lists text retrieval, code retrieval, classification, clustering and bitext mining among the supported application areas. A search system can use these vectors to compare a question with relevant passages; a document collection can use them to find semantically related material or organise records into groups.
The exact model supports a 32K-token sequence length and embeddings of up to 4,096 dimensions. It also supports user-defined output dimensions from 32 to 4,096 through Matryoshka Representation Learning. That makes vector length a deliberate design choice: a shorter vector changes the representation’s size, while the full output preserves the model’s maximum dimensionality. Keep the chosen dimension consistent for the documents and queries compared in one index. Qwen3-Embedding-4B is a separate edition with a different maximum dimension, rather than an interchangeable vector source for an existing 8B collection.
The producer describes support for more than 100 languages, including programming languages, and multilingual, cross-language and code retrieval. A practical collection can contain documents in several languages while queries seek the relevant meaning, or source-code passages indexed for a natural-language question. Preserve important identifiers, titles and domain terms in the input. For code, keep the function or module’s surrounding explanation with the excerpt when that context is part of the question. The output remains a vector representation; returning the matched document text is the search application’s next step.
The model is instruction-aware. Qwen recommends a one-sentence instruction tailored to the retrieval task and, for multilingual use, recommends writing that instruction in English. Its direct example formats a query with Instruct: followed by the task description and Query: followed by the question. Retrieval documents do not need the same instruction prefix in that example. A suitable original brief might describe finding technical passages that explain a user’s error, then place the particular error description in the query. The instruction describes what kind of semantic relationship the search should favour.
Qwen’s examples encode queries and documents separately, compare their vectors using cosine similarity, and show a lower-level procedure that pools the final token’s hidden state and normalises the embedding before a dot-product comparison. A useful workflow keeps each passage’s vector attached to its source identifier, compares a prepared query with the stored vectors and returns the corresponding passages in similarity order. The example’s 8,192-token truncation setting is a chosen input-processing setting, distinct from the model’s documented 32K sequence length. Review what is retained when preparing long inputs.
The embedding and reranking models are different components in Qwen’s release. An embedding model represents one text segment and enables an initial similarity search. A separate reranker evaluates the relationship between a query and candidate passages and can refine their order. Qwen describes combining the two modules, but Qwen3-Embedding-8B itself returns embeddings rather than a reranker’s relevance judgement or a written answer. For retrieval followed by an answer, retain the matched source text and pass that evidence to the answering stage. Choose and keep a consistent model, dimension and query instruction for the collection being searched.
", "aboutText": "Qwen3-Embedding-8B is Qwen’s 8B text-embedding model, built from the dense Qwen3 foundation model. It represents text as numerical vectors rather than generating conversational answers. Qwen lists text retrieval, code retrieval, classification, clustering and bitext mining among the supported application areas. A search system can use these vectors to compare a question with relevant passages; a document collection can use them to find semantically related material or organise records into groups.\n\nThe exact model supports a 32K-token sequence length and embeddings of up to 4,096 dimensions. It also supports user-defined output dimensions from 32 to 4,096 through Matryoshka Representation Learning. That makes vector length a deliberate design choice: a shorter vector changes the representation’s size, while the full output preserves the model’s maximum dimensionality. Keep the chosen dimension consistent for the documents and queries compared in one index. Qwen3-Embedding-4B is a separate edition with a different maximum dimension, rather than an interchangeable vector source for an existing 8B collection.\n\nThe producer describes support for more than 100 languages, including programming languages, and multilingual, cross-language and code retrieval. A practical collection can contain documents in several languages while queries seek the relevant meaning, or source-code passages indexed for a natural-language question. Preserve important identifiers, titles and domain terms in the input. For code, keep the function or module’s surrounding explanation with the excerpt when that context is part of the question. The output remains a vector representation; returning the matched document text is the search application’s next step.\n\nThe model is instruction-aware. Qwen recommends a one-sentence instruction tailored to the retrieval task and, for multilingual use, recommends writing that instruction in English. Its direct example formats a query with Instruct: followed by the task description and Query: followed by the question. Retrieval documents do not need the same instruction prefix in that example. A suitable original brief might describe finding technical passages that explain a user’s error, then place the particular error description in the query. The instruction describes what kind of semantic relationship the search should favour.\n\nQwen’s examples encode queries and documents separately, compare their vectors using cosine similarity, and show a lower-level procedure that pools the final token’s hidden state and normalises the embedding before a dot-product comparison. A useful workflow keeps each passage’s vector attached to its source identifier, compares a prepared query with the stored vectors and returns the corresponding passages in similarity order. The example’s 8,192-token truncation setting is a chosen input-processing setting, distinct from the model’s documented 32K sequence length. Review what is retained when preparing long inputs.\n\nThe embedding and reranking models are different components in Qwen’s release. An embedding model represents one text segment and enables an initial similarity search. A separate reranker evaluates the relationship between a query and candidate passages and can refine their order. Qwen describes combining the two modules, but Qwen3-Embedding-8B itself returns embeddings rather than a reranker’s relevance judgement or a written answer. For retrieval followed by an answer, retain the matched source text and pass that evidence to the answering stage. Choose and keep a consistent model, dimension and query instruction for the collection being searched.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "d84cd9bce962400c2c1c71e4020e7ad9a8bd2d80427ab1b3cf6c429bfb016f66", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "qwen/qwen3-embedding-8bQwen3-Embedding-8B turns text into semantic vectors for multilingual search, code retrieval, classification and clustering. It supports a 32K-token sequence length and custom embedding dimensions from 32 to 4,096.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Qwen3-Embedding-8B is Qwen’s 8B text-embedding model, built from the dense Qwen3 foundation model. It represents text as numerical vectors rather than generating conversational answers. Qwen lists text retrieval, code retrieval, classification, clustering and bitext mining among the supported application areas. A search system can use these vectors to compare a question with relevant passages; a document collection can use them to find semantically related material or organise records into groups.
The exact model supports a 32K-token sequence length and embeddings of up to 4,096 dimensions. It also supports user-defined output dimensions from 32 to 4,096 through Matryoshka Representation Learning. That makes vector length a deliberate design choice: a shorter vector changes the representation’s size, while the full output preserves the model’s maximum dimensionality. Keep the chosen dimension consistent for the documents and queries compared in one index. Qwen3-Embedding-4B is a separate edition with a different maximum dimension, rather than an interchangeable vector source for an existing 8B collection.
The producer describes support for more than 100 languages, including programming languages, and multilingual, cross-language and code retrieval. A practical collection can contain documents in several languages while queries seek the relevant meaning, or source-code passages indexed for a natural-language question. Preserve important identifiers, titles and domain terms in the input. For code, keep the function or module’s surrounding explanation with the excerpt when that context is part of the question. The output remains a vector representation; returning the matched document text is the search application’s next step.
The model is instruction-aware. Qwen recommends a one-sentence instruction tailored to the retrieval task and, for multilingual use, recommends writing that instruction in English. Its direct example formats a query with Instruct: followed by the task description and Query: followed by the question. Retrieval documents do not need the same instruction prefix in that example. A suitable original brief might describe finding technical passages that explain a user’s error, then place the particular error description in the query. The instruction describes what kind of semantic relationship the search should favour.
Qwen’s examples encode queries and documents separately, compare their vectors using cosine similarity, and show a lower-level procedure that pools the final token’s hidden state and normalises the embedding before a dot-product comparison. A useful workflow keeps each passage’s vector attached to its source identifier, compares a prepared query with the stored vectors and returns the corresponding passages in similarity order. The example’s 8,192-token truncation setting is a chosen input-processing setting, distinct from the model’s documented 32K sequence length. Review what is retained when preparing long inputs.
The embedding and reranking models are different components in Qwen’s release. An embedding model represents one text segment and enables an initial similarity search. A separate reranker evaluates the relationship between a query and candidate passages and can refine their order. Qwen describes combining the two modules, but Qwen3-Embedding-8B itself returns embeddings rather than a reranker’s relevance judgement or a written answer. For retrieval followed by an answer, retain the matched source text and pass that evidence to the answering stage. Choose and keep a consistent model, dimension and query instruction for the collection being searched.
POST /v1/embeddingstext, token_idsembedding| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits qwen/qwen3-embedding-8b | 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,768 · 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 | Contract32768 |
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.00002 / 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": "qwen/qwen3-embedding-8b", "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='qwen/qwen3-embedding-8b',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 qwen/qwen3-embedding-8b
Use the method paths shown above.