Perplexity: Embed V1 4B

Perplexity: Embed V1 4B is a text embedding model from Perplexity, released by the provider on 16 March 2026. It belongs to the embeddings category rather than the chat category, which means it does not generate conversational answers. Instead it turns text into vector representations that you store and search against. The 4B in the name refers to the parameter count of this variant, and Perplexity positions the pplx-embed-v1 family as state of the art for real world, web scale retrieval, with the 4B model maximizing retrieval quality within that family.

The model accepts text as its only input modality and returns embeddings as its only output modality. It supports a context length of 32000 tokens, so a single request can cover a long document rather than a short snippet. The reported maximum output is 28800. Because the output is a vector rather than prose, there is no text generation step and no sampling behaviour to tune. You send text in, you get numeric representations back, and those representations are what carry the semantic meaning of the input.

The practical uses follow directly from dense retrieval. You can embed a corpus of documents or web pages and store the vectors in a vector database, then embed a user query and search for the nearest neighbours. That pattern covers semantic search, retrieval augmented generation pipelines where a language model needs relevant passages before it answers, deduplication and near duplicate detection, clustering and topic grouping, classification by comparing vectors against labelled examples, and recommendation or similarity features. The 32000 token context is useful when the units you want to index are long: full articles, documentation pages, or long support threads rather than single sentences.

Calling the model through api14 works the same way as any other model on the gateway, because api14 exposes an OpenAI-compatible API. You set the model id to perplexity/pplx-embed-v1-4b in your request and send your text as input. Because the endpoint is OpenAI-compatible, existing OpenAI client libraries and code paths generally work with only the base URL, key and model id changed. The model reports no supported parameters, so there are no extra knobs such as temperature or top_p to configure; the request is essentially text in and embeddings out.

One thing to plan for is the absence of supported parameters. If your workflow depends on tuning generation behaviour, this is not the right model, since it produces embeddings and nothing else. It is also a single modality model, so it cannot handle images or audio. If your task is generation, summarisation, or dialogue rather than retrieval, a chat or completion model is the appropriate choice, and this embedding model fits best as the retrieval layer alongside one.