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 |
| Schema contract | Dimension, model version and chunking strategy versioned per collection |
| Topology | Vector store can run in your VPC, on-prem or air-gapped |
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.
- Treat model, dimension and chunking as a versioned interface.
- Embeddings extend your data surface and governance scope — document it.
- 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.
- Define the embedding contract and record model version with each vector.
- Design hybrid retrieval with metadata and citation fields from the start.
- Plan re-embedding as a migration with backfill and validation stages.
Original data
Try it yourself
Open the RAG chunk size calculator →
Embeddings for enterprise architects: what changes
For enterprise architects, embeddings are a data product with a schema: model, dimension, chunking strategy, store topology and refresh policy. Getting the contract right early avoids a painful migration later, when millions of vectors and downstream features depend on it.
Plugsky exposes an OpenAI-compatible /v1/embeddings endpoint with the plugsky-embed family inside a 30+ model catalogue: plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages such as Arabic and English, and plugsky-embed-nim for teams standardised on NVIDIA-style profiles. Inputs are 8K-class per request, and each model's vector dimension is published on the model catalogue — read it before you create the collection.
Architecture and controls
Record which model produced each vector and when, keep the vector store in the same deployment boundary as the source data, and version the embedding pipeline like any other interface. Define who can trigger a re-embed and how the cutover is validated.
Integration pattern and rollout
Choose the model per corpus — English default, multilingual for mixed content — then design collections, indexes and metadata for hybrid retrieval. Where residency demands it, run the store in your VPC, on-prem or air-gapped using the same APIs.
Treat the dimension as a schema contract. When you change embedding models the vectors change, so plan a new collection and a backfill rather than an in-place swap. Chunk by document structure, store metadata alongside vectors, and combine vector similarity with keyword search and a reranker for production retrieval. Batch indexing jobs and re-embed only when the model version or chunking strategy changes.
Limits, evidence and cost
Dimension and similarity behaviour are model-specific, so a model swap is a data migration, not a config flip. Plan storage and compute for backfills, and be explicit that embeddings extend your data surface and therefore your governance scope.
Embeddings are available on platform plans — see the live pricing page for current tiers. Start free with plugsky-micro and plugsky-lite and no card to build the application layer, then add the indexing workload when retrieval is on the roadmap. The 14-day full-access trial covers larger models.
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 |
| Schema contract | Dimension and model version recorded per vector | Provider-managed | You version every index |
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.
What belongs in the embedding contract?
Model name, vector dimension, chunking strategy, store topology and refresh policy — versioned like any interface.
How do we plan for model changes?
Budget re-embedding as a data migration: new collection, backfill, validation, cutover, then retire the old index.
Can the vector store stay inside our boundary?
Yes. Run the store in your VPC, on-prem or air-gapped, and keep it in the same jurisdiction as the source data.