VoyageAI by MongoDB: voyage-4-large

VoyageAI by MongoDB: voyage-4-large is an embedding model from Voyage AI, a provider whose models are distributed under the VoyageAI by MongoDB name. It sits in the embeddings category, which means it is built to turn text into vectors rather than to generate chat responses. If you are choosing a model for a retrieval or similarity pipeline, this is the kind of model you evaluate on embedding quality rather than on conversational ability.

The model accepts text as its only input modality and returns embeddings as its only output. It has a context length of 32,000 tokens, so a single request can cover a fairly long document or a batch of shorter passages. The provider describes it as a state-of-the-art general-purpose and multilingual embedding optimized for retrieval quality. It uses Matryoshka learning and quantization-aware training, and it supports embeddings at 2048, 1024, 512, and 256 dimensions. The maximum output is listed as 28,800, which is the ceiling on the embedding output side of a request.

Those capabilities point to a specific set of use cases. Semantic search and retrieval over a document collection is the most direct fit, since the model is tuned for retrieval quality and can embed long passages within the 32,000 token context. Multilingual corpora are also a reasonable target, given the multilingual training. Because the embeddings can be truncated to 2048, 1024, 512, or 256 dimensions, you can trade vector size against storage and search speed depending on how much precision your index needs. Clustering, deduplication, and similarity scoring over text are other natural applications, as is building a vector index that feeds a separate generation model.

You call the model through api14's OpenAI-compatible API using the model id "voyageai/voyage-4-large". Because the endpoint follows the OpenAI format, you can point an existing OpenAI client at api14 and send embedding requests without rewriting your integration. The model's supported parameters list is empty, so there are no extra request parameters to configure beyond what the standard embedding call requires. Treat the model id as the only model-specific value you need to set.

One practical constraint to keep in mind is that this model only handles text input and only produces embeddings. It cannot generate text, answer questions, or follow instructions, so any application that needs a written response requires a separate generation model alongside it. The 32,000 token context is generous for embedding work but still finite, so very large documents need to be chunked before embedding. If your task is generation rather than retrieval, a chat or completion model is the better fit.