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 |
| Sovereign search | On-prem, VPC and air-gapped embedding pipelines for classified corpora |
| Languages | plugsky-embed-multilingual supports mixed-language corpora |
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.
- Vectors inherit the classification of their source — govern them accordingly.
- Test multilingual retrieval with native-speaker question sets.
- 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.
- Pilot on public corpora to validate retrieval and language coverage.
- Move the pipeline in-region, on-prem or air-gapped for restricted content.
- Keep citations and access scoping in the retrieval layer.
Original data
Try it yourself
Open the embedding model comparison →
Embeddings for government teams: what changes
Government semantic search must serve citizens and staff while respecting classification and language diversity. Embeddings make policy, legislation and case archives searchable across languages, but the vectors inherit the sensitivity of their source, so they belong inside the same sovereign boundary.
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
Run embedding pipelines in-region, on-prem or air-gapped depending on classification, and keep vector stores and logs in the same jurisdiction. Use the multilingual model for mixed-language corpora, and restrict retrieval through RBAC scoped to organisational roles.
Integration pattern and rollout
Start with public or unclassified corpora to validate retrieval quality and language coverage, then extend to restricted content once the boundary is proven. Keep citations in metadata so answers can be traced to authoritative sources.
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
Embeddings do not classify documents; source labelling and access control do. Plan re-embedding when models change, and budget storage for vectors as a first-class dataset in your retention schedule.
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 |
| Sovereign search | On-prem and air-gapped embedding pipelines | Limited | You build the estate |
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 search across languages?
Yes — use plugsky-embed-multilingual for mixed-language corpora, and validate retrieval with native-speaker test sets.
How do we protect classified content?
Keep the pipeline in-region, on-prem or air-gapped, and enforce RBAC so retrieval respects the requester's clearance.
Do we need to re-index often?
Re-embed when the model version or chunking strategy changes, and refresh indexes as content is updated. Schedule it as routine maintenance.