LFM2.5-Embedding-350M is LiquidAI’s dense bi-encoder for multilingual and cross-language retrieval. It produces one 1024-dimensional vector for each text and targets short-context search across eleven languages. The named 350M model family uses a bidirectional adaptation of LFM2.5-350M-Base; the detailed model table gives approximately 354 million parameters for this embedding edition.
The manufacturer adapts the backbone so attention and local convolutions can use context on both sides of a token. CLS-style pooling turns the processed text into one dense vector. Its model table describes seventeen layers: ten convolution blocks, six attention blocks and a pooling stage. This is a retrieval encoder, with its own preparation and output, rather than the text-generation task of the base model.
The separately named LFM2.5-ColBERT-350M retains per-token vectors for late interaction. That representation requires a different index and comparison method. The Embedding model here supplies one vector per document or query, with cosine similarity as the documented comparison.
Prepare search queries with “query:” and source passages with “document:”. The manufacturer stores these prompts in its configuration and its reference workflow applies the matching prompt name. It specifically recommends using the corresponding role on each side because the model was trained with these prefixes. This document prefix is different from the “passage:” convention of E5 models.
A practical product-search collection can hold descriptions in the supported languages. Prepare the user’s search wording as a query and each product description as a document. Store the original text, product identifier and language with the vector so a search result can return the corresponding record. For a support collection, retain the question’s relevant policy or instruction instead of replacing it with an unrelated short label.
The documented language set is English, Spanish, German, French, Italian, Portuguese, Arabic, Swedish, Norwegian, Japanese and Korean. The manufacturer explicitly targets both retrieval within a language and retrieval across language boundaries. Prepare real questions from the intended audience and inspect the returned document text in those languages.
The document-length specification is 512 tokens. Divide a long source into coherent passages which preserve the heading, definitions and conditions needed by a retrieved result. The role prefix and added context belong to the prepared input. A FAQ answer, a product explanation or a focused section of a technical document is a more suitable unit than a whole oversized manual.
The maker describes three training stages: English contrastive pretraining, multilingual and cross-language distillation, then fine-tuning with hard-mined negatives. The resulting model is intended for product catalogues, FAQ and support collections, file or note search, and enterprise knowledge retrieval. Those are tasks for the text representations, not claims of a particular application’s deployment.
The producer’s example normalises query and document vectors and ranks them with a dot product, equivalent to cosine similarity. Precompute the corpus representations when the source material is prepared, then embed a search query and return candidate documents with their text and identifiers. Keep the selected model and role convention with the index so the numerical comparison uses compatible representations.
The useful result is a compact dense search index or a query vector that retrieves source material across the documented language set. This exact LFM2.5 Embedding edition remains separate from its ColBERT companion, older LFM2 retrievers and externally quantised implementations. The selected passage text is the evidence used by a reader or a later RAG answer stage.
", "aboutText": "LFM2.5-Embedding-350M is LiquidAI’s dense bi-encoder for multilingual and cross-language retrieval. It produces one 1024-dimensional vector for each text and targets short-context search across eleven languages. The named 350M model family uses a bidirectional adaptation of LFM2.5-350M-Base; the detailed model table gives approximately 354 million parameters for this embedding edition.\n\n### A bidirectional retrieval representation\n\nThe manufacturer adapts the backbone so attention and local convolutions can use context on both sides of a token. CLS-style pooling turns the processed text into one dense vector. Its model table describes seventeen layers: ten convolution blocks, six attention blocks and a pooling stage. This is a retrieval encoder, with its own preparation and output, rather than the text-generation task of the base model.\n\nThe separately named LFM2.5-ColBERT-350M retains per-token vectors for late interaction. That representation requires a different index and comparison method. The Embedding model here supplies one vector per document or query, with cosine similarity as the documented comparison.\n\n### Use the correct asymmetric prompts\n\nPrepare search queries with “query:” and source passages with “document:”. The manufacturer stores these prompts in its configuration and its reference workflow applies the matching prompt name. It specifically recommends using the corresponding role on each side because the model was trained with these prefixes. This document prefix is different from the “passage:” convention of E5 models.\n\nA practical product-search collection can hold descriptions in the supported languages. Prepare the user’s search wording as a query and each product description as a document. Store the original text, product identifier and language with the vector so a search result can return the corresponding record. For a support collection, retain the question’s relevant policy or instruction instead of replacing it with an unrelated short label.\n\n### Languages and passage size\n\nThe documented language set is English, Spanish, German, French, Italian, Portuguese, Arabic, Swedish, Norwegian, Japanese and Korean. The manufacturer explicitly targets both retrieval within a language and retrieval across language boundaries. Prepare real questions from the intended audience and inspect the returned document text in those languages.\n\nThe document-length specification is 512 tokens. Divide a long source into coherent passages which preserve the heading, definitions and conditions needed by a retrieved result. The role prefix and added context belong to the prepared input. A FAQ answer, a product explanation or a focused section of a technical document is a more suitable unit than a whole oversized manual.\n\n### Training and matching\n\nThe maker describes three training stages: English contrastive pretraining, multilingual and cross-language distillation, then fine-tuning with hard-mined negatives. The resulting model is intended for product catalogues, FAQ and support collections, file or note search, and enterprise knowledge retrieval. Those are tasks for the text representations, not claims of a particular application’s deployment.\n\nThe producer’s example normalises query and document vectors and ranks them with a dot product, equivalent to cosine similarity. Precompute the corpus representations when the source material is prepared, then embed a search query and return candidate documents with their text and identifiers. Keep the selected model and role convention with the index so the numerical comparison uses compatible representations.\n\nThe useful result is a compact dense search index or a query vector that retrieves source material across the documented language set. This exact LFM2.5 Embedding edition remains separate from its ColBERT companion, older LFM2 retrievers and externally quantised implementations. The selected passage text is the evidence used by a reader or a later RAG answer stage.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "b75458db86aaa9ab5b99426206250f02874e41239016c83a6fe2f647688e5796", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "liquid/lfm-2.5-embedding-350m:freeLiquidAI LFM2.5-Embedding-350M produces one 1024-dimensional vector per text for multilingual and cross-language retrieval. It targets 11 languages and short, 512-token inputs, with distinct query/document prefixes.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
LFM2.5-Embedding-350M is LiquidAI’s dense bi-encoder for multilingual and cross-language retrieval. It produces one 1024-dimensional vector for each text and targets short-context search across eleven languages. The named 350M model family uses a bidirectional adaptation of LFM2.5-350M-Base; the detailed model table gives approximately 354 million parameters for this embedding edition.
The manufacturer adapts the backbone so attention and local convolutions can use context on both sides of a token. CLS-style pooling turns the processed text into one dense vector. Its model table describes seventeen layers: ten convolution blocks, six attention blocks and a pooling stage. This is a retrieval encoder, with its own preparation and output, rather than the text-generation task of the base model.
The separately named LFM2.5-ColBERT-350M retains per-token vectors for late interaction. That representation requires a different index and comparison method. The Embedding model here supplies one vector per document or query, with cosine similarity as the documented comparison.
Prepare search queries with “query:” and source passages with “document:”. The manufacturer stores these prompts in its configuration and its reference workflow applies the matching prompt name. It specifically recommends using the corresponding role on each side because the model was trained with these prefixes. This document prefix is different from the “passage:” convention of E5 models.
A practical product-search collection can hold descriptions in the supported languages. Prepare the user’s search wording as a query and each product description as a document. Store the original text, product identifier and language with the vector so a search result can return the corresponding record. For a support collection, retain the question’s relevant policy or instruction instead of replacing it with an unrelated short label.
The documented language set is English, Spanish, German, French, Italian, Portuguese, Arabic, Swedish, Norwegian, Japanese and Korean. The manufacturer explicitly targets both retrieval within a language and retrieval across language boundaries. Prepare real questions from the intended audience and inspect the returned document text in those languages.
The document-length specification is 512 tokens. Divide a long source into coherent passages which preserve the heading, definitions and conditions needed by a retrieved result. The role prefix and added context belong to the prepared input. A FAQ answer, a product explanation or a focused section of a technical document is a more suitable unit than a whole oversized manual.
The maker describes three training stages: English contrastive pretraining, multilingual and cross-language distillation, then fine-tuning with hard-mined negatives. The resulting model is intended for product catalogues, FAQ and support collections, file or note search, and enterprise knowledge retrieval. Those are tasks for the text representations, not claims of a particular application’s deployment.
The producer’s example normalises query and document vectors and ranks them with a dot product, equivalent to cosine similarity. Precompute the corpus representations when the source material is prepared, then embed a search query and return candidate documents with their text and identifiers. Keep the selected model and role convention with the index so the numerical comparison uses compatible representations.
The useful result is a compact dense search index or a query vector that retrieves source material across the documented language set. This exact LFM2.5 Embedding edition remains separate from its ColBERT companion, older LFM2 retrievers and externally quantised implementations. The selected passage text is the evidence used by a reader or a later RAG answer stage.
POST /v1/embeddingstext, token_idsembedding| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits liquid/lfm-2.5-embedding-350m:free | Default— |
Fieldinput | Typestring|string[]|integer[]|integer[][] | RequirementRequired | Values & limits Minimum items: 1 Conditions: Nonempty homogeneous batch. Token IDs are nonnegative integers. Input budget: Maximum: 512 · 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 | Contract512 |
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 / 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": "liquid/lfm-2.5-embedding-350m:free", "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='liquid/lfm-2.5-embedding-350m:free',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 liquid/lfm-2.5-embedding-350m:free
Use the method paths shown above.