Key facts
| Model class | Multilingual embedding model in the Plugsky catalogue |
| Best for | Cross-language semantic search, Arabic plus English RAG, clustering |
| Endpoint | POST /v1/embeddings (OpenAI-compatible) |
| Input limit | 8K-class text per request; live limits are published per model |
| Vector dimension | Published per model on /models — match it in your index schema |
| Pricing tier | Available on platform plans; see the live pricing page |
| Capabilities | Batch embeddings, similarity search, clustering — no chat completions |
| Product status | Live |
TL;DR
- Purpose-built for mixed-language corpora, including Arabic and English.
- OpenAI-compatible embeddings endpoint, so existing RAG code works unchanged.
- Read the live dimension from /models and match it to your vector store schema.
- Chunk input to the 8K-class limit and re-embed only when the model version changes.
- Pair with a reranker and keyword search for production-grade retrieval quality.
How it works, step by step
- Check the live model card at /models for the current dimension, input limit and status.
- Create the vector collection with that exact dimension — dimensions must match the index.
- Chunk documents into passages that fit the 8K-class input limit with room for headers.
- Embed a sample of real documents and run a few known queries to inspect nearest neighbours.
- Compare cross-language retrieval against your current embedding model on the same query set.
- Switch the embeddings call to plugsky-embed-multilingual and re-index the corpus.
- Monitor retrieval quality and re-embed only when the model version or dimension changes.
Try it yourself
Open the LLM token calculator →
What plugsky-embed-multilingual is
plugsky-embed-multilingual is an embedding model: it maps text to vectors that capture meaning, so similar passages sit close together in vector space. It is aimed at corpora that mix languages — product catalogues, support tickets, policy documents — and at Arabic content in particular. It serves the OpenAI-compatible /v1/embeddings endpoint, so an existing RAG pipeline swaps model names without changing its client code.
The vector dimension and input limit are published on the live catalogue at /models. Always read them there: the dimension defines your index schema, and a mismatch is the most common cause of silent retrieval failures.
When to choose it
Choose plugsky-embed-multilingual when queries and documents are not in the same language, or when the corpus itself is mixed. Cross-language retrieval is the key benefit: an English question can retrieve an Arabic passage and vice versa. It is also a sensible default for GCC-focused products with Arabic content alongside English.
For English-only corpora, the default plugsky-embed model is usually the simpler choice. Whichever you pick, keep the embedding model fixed once you have indexed: mixing vectors from two models in one collection produces meaningless similarity scores.
Dimensions, chunking and retrieval quality
Embedding quality depends as much on your pipeline as on the model. Dimension is a schema decision, chunking is a retrieval decision, and both must be consistent.
- Set the index dimension from the live model card before creating the collection.
- Chunk by meaning (sections, paragraphs) rather than fixed character counts.
- Store metadata beside each vector so you can filter and cite sources.
- Use hybrid retrieval — embeddings plus keyword search — for names, codes and rare terms.
- Add a reranker when result order matters more than latency.
How to switch to plugsky-embed-multilingual
Switching is a model-name change on the embeddings endpoint, for example {"model": "plugsky-embed-multilingual", "input": ["passage one", "passage two"]} against https://api.plugsky.com/v1/embeddings.
Re-index in a new collection, verify retrieval with a labelled query set, then cut over the application. Keep the old collection until the new one passes your quality checks, and document the model and dimension in your schema so future migrations are predictable.
Honest comparison
| Dimension | plugsky-embed-multilingual | Default English embed model | Self-hosted embedding model |
|---|---|---|---|
| Best fit | Mixed-language and Arabic plus English corpora | English-dominant corpora | Full control and offline indexing |
| Endpoint | OpenAI-compatible /v1/embeddings | OpenAI-compatible /v1/embeddings | You run the inference server |
| Dimension | Read the live value at /models | Read the live value at /models | Chosen from the weights |
| Ops overhead | None — one API call | None — one API call | GPU capacity, updates, scaling |
| Switching cost | Re-index once, then swap the model name | Re-index once | Re-train or re-tune if the corpus shifts |
| Failover | Automatic peer fallback in the embed family | Automatic peer fallback | You design redundancy |
Frequently asked questions
Is plugsky-embed-multilingual free?
Embeddings are part of platform plans; the free plan includes two free chat models, plugsky-micro and plugsky-lite. See the live pricing page for plan details and trial access.
What dimension does it output?
The output dimension is published per model on the live catalogue at /models. Read it there before creating your index, because the collection dimension must match exactly.
Can it handle Arabic?
Yes — multilingual and cross-language retrieval, including Arabic content alongside English, is the model's purpose.
What is the maximum input size?
The model accepts an 8K-class window of text. Chunk documents to fit, and check /models for the current live limit before designing chunk sizes.
Does it replace a chat model?
No. It is an embedding model for search, clustering and recommendations. Pair it with a chat model such as plugsky-pro for answer generation in RAG.
Can I mix embeddings from two models in one collection?
No. Vectors from different models are not comparable. Re-embed the whole corpus when you change embedding models, even if the dimension is the same.
How does it fit into an existing OpenAI-compatible RAG stack?
Point your client at the Plugsky base URL, call /v1/embeddings with the model name, and keep your vector store and retrieval code unchanged.
What happens if the embedding model is unavailable?
The embed family has automatic peer fallback within the same profile, so indexing jobs keep running. Check the status page for live health.