Key facts
| Endpoint | POST /v1/embeddings (OpenAI-compatible) |
| Models | plugsky-embed, plugsky-embed-multilingual and plugsky-embed-nim in a 30+ model catalogue |
| Input limit | 8K-class text per request; live limits published per model |
| Vector dimension | Published per model on /models — read it before creating a collection |
| Use cases | RAG, semantic search, clustering and recommendations |
| Indexing | Batch embeddings for large corpora; re-embed when the model version changes |
| API compatibility | OpenAI-compatible /v1/embeddings; change base URL, keep your code |
| Pipeline design | Chunk by structure; read dimension from /models before indexing |
TL;DR
- OpenAI-compatible /v1/embeddings with the plugsky-embed family in a 30+ model catalogue.
- Dimension is published per model — read it before creating the collection.
- One OpenAI-compatible endpoint for chat and embeddings keeps integration simple.
- Dimension is a schema contract; record it with every vector.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Read the model's live vector dimension from the catalogue and create the collection with it.
- Chunk by document structure, embed in batches, and store metadata for citations.
- Validate retrieval on a labelled question set before moving to production traffic.
- Read the model's live dimension and create the collection with it.
- Batch-index with structure-aware chunks and citation metadata.
- Evaluate retrieval on your own queries before adding a reranker.
Original data
Try it yourself
Open the embedding API tester →
Embeddings for developers: what changes
Developers adopt embeddings to power search, recommendations, deduplication and RAG. The work is familiar: call an endpoint, store vectors, query by similarity. What matters is picking a model, respecting the dimension contract, and keeping the pipeline maintainable when models change.
Embeddings run on an OpenAI-compatible /v1/embeddings endpoint, so existing vector pipelines keep their request shape. The plugsky-embed family — plugsky-embed, plugsky-embed-multilingual and plugsky-embed-nim — sits alongside chat models in a 30+ model catalogue, each with an 8K-class input limit and a published vector dimension you can read from the catalogue before indexing.
Architecture and controls
Call /v1/embeddings with the same authentication and workspace model used for chat, batch indexing jobs, and read the live vector dimension from the model catalogue before creating a collection. Validate inputs against the model's input limit.
Integration pattern and rollout
Build the smallest useful loop first: chunk documents, embed, store with metadata, retrieve top-k, then add hybrid keyword search and a reranker if precision needs it. Keep model choice in configuration so switching is a config diff.
The pipeline is straightforward: chunk, embed in batches, store vectors with source metadata, retrieve top-k. What needs discipline is versioning — record the model and dimension with every vector, keep model choice in configuration, and treat a model swap as a data migration with dual-write and a validation phase before cutover.
Limits, evidence and cost
Switching embedding models invalidates stored vectors; budget for dual-write and backfill rather than an in-place migration. Quality varies by corpus and language, so evaluate on your own data instead of relying on generic comparisons.
Self-serve plans are flat monthly with unlimited fair-use usage, so embedding volume does not introduce per-token billing — check the live pricing page. The free plan includes plugsky-micro and plugsky-lite with no card, and the 14-day full-access trial lets you test before committing to an index.
Honest comparison
| Concern | Plugsky embeddings | Typical API provider | Self-hosted embedder |
|---|---|---|---|
| API shape | OpenAI-compatible /v1/embeddings | Usually compatible, varies | Custom serving stack |
| Model choice | plugsky-embed family inside a 30+ model catalogue | Provider catalogue only | You package each model |
| Residency | Region-locked planes; VPC, on-prem and air-gapped | Limited region choices | Wherever you deploy |
| Dimension changes | Read live dimension from /models; plan new collections | Varies by provider | You manage every migration |
| Operational load | Managed endpoint with batching | Managed endpoint | GPU capacity, patching and autoscaling |
| API shape | OpenAI-compatible /v1/embeddings | Usually compatible | Custom serving layer |
Frequently asked questions
Do we need to re-embed when we change models?
Yes. Vectors depend on the model and dimensions can change. Plan a new collection, backfill, validate, then cut over — re-embedding is a data migration, not a config flip.
Are embeddings region-locked?
Yes, when the workload is pinned to a region-locked plane. Keep the vector store, backups and logs in the same jurisdiction as the source data.
Which embedding model should we start with?
plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages, and plugsky-embed-nim for NVIDIA-style profiles. Evaluate on your own content.
Can we keep our OpenAI embedding code?
Yes. Point the base URL at Plugsky and keep the request shape; read the live dimension from the model catalogue before creating the collection.
How do we handle long documents?
Chunk by structure to fit the 8K-class input limit, keep metadata for citations, and batch indexing jobs to control load.
Should we add a reranker?
If top-k precision matters, combine vector search with keyword matching and a reranker. Evaluate on your own queries rather than assuming a gain.