Intfloat: Multilingual-E5-Large

Intfloat: Multilingual-E5-Large is an embedding model from Intfloat, listed on api14 under the embeddings category. It takes text as input and returns embeddings as output, so it is not a chat or text generation model. Its purpose is to turn language into vectors that you can store, compare and search with. The provider describes it as encoding sentences, paragraphs and documents across more than 90 languages into a 1024-dimensional dense vector space, with semantic embeddings tuned for multilingual retrieval and cross-language similarity.

The context window is 512 tokens and the maximum output is 460. Because the input is text and the output is a vector rather than generated words, there is no sampling behaviour to tune: the model does not accept supported parameters, so requests carry your input and nothing else in the way of generation settings. The 512 token limit means each call should be scoped to a sentence, a short paragraph or a similarly sized chunk, rather than a long document passed in whole.

The practical uses follow from that shape. Multilingual retrieval is the main one: index documents in one or several languages and search them with queries in another. Cross-language similarity lets you compare or cluster text written in different languages in the same vector space. Related work includes semantic search over a mixed-language corpus, deduplication of near-identical passages, routing or classification based on how close a piece of text sits to reference examples, and building retrieval layers that feed a separate generation model.

You call it through api14's OpenAI-compatible API using the model id "intfloat/multilingual-e5-large". Because the endpoint follows the OpenAI embeddings shape, existing client libraries and code that already point at an OpenAI-compatible base URL should work with only the model id changed. Send your text as input and read the vector back from the response. No extra request parameters are supported, so keep the request minimal and let the model return the embedding.

The 512 token context is the main constraint to plan around. Long documents need to be split into chunks before embedding, and any pipeline that assumes a larger window, or that expects generated text back, will need a different model. If your task is generation, summarisation or conversation rather than representation, an instruct or chat model on api14 is the better fit; this model is for turning text into vectors.