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 |
| Scale | Batch embeddings for large indexes; re-embed only on model version change |
| Cost model | Embeddings are available on platform plans; see the live pricing page |
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.
- Keep model and chunking in configuration so tuning skips a redeploy.
- Instrument relevance signals early and measure on your own content.
- 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.
- Ship one retrieval feature on a narrow corpus with acceptance instrumentation.
- Record model version and dimension with every vector.
- Schedule re-embedding as a migration with validation before cutover.
Original data
Try it yourself
Open the embedding API tester →
Embeddings for SaaS teams: what changes
SaaS teams add embeddings to ship search, recommendations, deduplication and in-product assistants. The engineering goal is a pipeline that scales with tenants and content without turning every model change into a migration crisis.
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
Keep tenant isolation explicit in collection design, batch indexing to control load, and record model version and dimension with each vector so migrations are auditable. Pin tenants to the regions their contracts require.
Integration pattern and rollout
Ship one retrieval feature on a narrow corpus first, instrument relevance with click or acceptance signals, then generalise the pipeline. Keep the model and chunking strategy in configuration so tuning does not require a redeploy.
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
Model changes require re-embedding, and re-embedding large corpora costs storage and compute; schedule it like a data migration. Retrieval quality must be measured on your content, because generic comparisons rarely predict production relevance.
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 |
| Ship speed | One OpenAI-compatible API for chat and embeddings | Usually compatible | Weeks of infrastructure |
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.
How do we scale embedding jobs?
Batch indexing, process incrementally as content changes, and re-embed only when the model version changes rather than on every deploy.
How do we keep tenant data separate?
Make isolation explicit in collection design, and pin each tenant to the region its contract requires.
How do we evaluate retrieval?
Instrument acceptance signals and maintain a labelled query set, then tune chunking and reranking based on your own data.