Key facts
| Model class | General-purpose embedding model with a NIM-style profile |
| Best for | RAG, semantic search, clustering and recommendations on text |
| Endpoint | POST /v1/embeddings (OpenAI-compatible) |
| Input limit | 8K-class text per request; live limits published per model |
| Vector dimension | Published per model on /models — use it to size your index |
| 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
- A NIM-profile embedding model for teams that name models the NVIDIA way.
- Same OpenAI-compatible embeddings endpoint as the rest of the family.
- Interchangeable with plugsky-embed at the API level — pick per pipeline standard.
- Dimension lives on /models; set it once when you create the collection.
- Peer fallback inside the embed family keeps indexing jobs alive.
How it works, step by step
- Read the live card at /models for dimension, input limit and status.
- Create your vector collection with exactly that dimension.
- Chunk documents to fit the 8K-class input limit, preserving section boundaries.
- Embed a sample corpus and test known queries to sanity-check neighbours.
- Benchmark retrieval quality against your current embedding model.
- Switch the model name in your embeddings call and re-index.
- Keep model and dimension recorded with the collection for future migrations.
Try it yourself
Open the LLM cost calculator →
What plugsky-embed-nim is
plugsky-embed-nim is an embedding model for converting text into vectors used by search, RAG and clustering systems. Its distinguishing feature is its NIM-style profile: teams that already standardise on NVIDIA-style naming and tooling can adopt it without renaming models in their codebase or documentation. It serves the same OpenAI-compatible /v1/embeddings endpoint as the rest of the Plugsky catalogue.
Dimension, input limit and status are published per model at /models. Read the live value there before creating an index — the collection dimension is the one field that must match exactly.
When to choose it
Choose plugsky-embed-nim when your organisation already speaks the NIM naming convention, or when a migration plan lists NIM-style models explicitly. It is also a reasonable general-purpose choice for RAG and semantic search when you do not need multilingual behaviour.
If your corpus is English-only and naming is not a constraint, plugsky-embed is the simpler default. For mixed-language and Arabic content, use plugsky-embed-multilingual. All three live in the same family and fall back to one another automatically, but you should still pick one deliberately per collection.
Dimensions, indexing and trade-offs
Embedding models are cheap to call and expensive to migrate, so the important decisions happen at index time.
- Fix the dimension from the live model card before you create the collection.
- Never mix vectors from different models in one collection.
- Chunk by structure, keep titles with passages, and store source metadata for citations.
- Re-embed the corpus whenever you change embedding models — plan for it as a batch job.
- Combine embeddings with keyword search for codes, names and rare tokens.
How to switch to plugsky-embed-nim
Switching is one model name: {"model": "plugsky-embed-nim", "input": ["first passage", "second passage"]} posted to https://api.plugsky.com/v1/embeddings.
Index into a fresh collection, run your labelled retrieval checks, then flip the application. Because the whole family shares one endpoint and request shape, you can A/B two embedding models against the same query set without touching application code.
Honest comparison
| Dimension | plugsky-embed-nim | plugsky-embed | Managed vector database embeddings |
|---|---|---|---|
| Best fit | NIM-standardised pipelines and general RAG | Default general-purpose embeddings | Teams that want embeddings inside their vector store |
| Naming | NIM-style model profile | Plugsky default name | Varies by vendor |
| Endpoint | OpenAI-compatible /v1/embeddings | OpenAI-compatible /v1/embeddings | Vendor-specific API |
| Dimension | Read the live value at /models | Read the live value at /models | Varies; may not expose a choice |
| Migration | Change the model name, re-index | Change the model name, re-index | Often locked to the store |
| Failover | Automatic peer fallback in the embed family | Automatic peer fallback | Vendor-dependent |
Frequently asked questions
Is plugsky-embed-nim 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 live output dimension is listed per model on the catalogue at /models. Use that exact value when you create the vector collection.
How is it different from plugsky-embed?
Functionally they serve the same embedding role and the same API. plugsky-embed-nim carries a NIM-style profile for teams that standardise on NVIDIA naming; plugsky-embed is the default name.
What is the input limit?
The model accepts an 8K-class text window per request. Check /models for the current live limit and size your chunks accordingly.
Can it generate text?
No. It only produces embeddings. For generation in a RAG pipeline, pair it with a chat model from the same catalogue.
Do I need to re-index when switching from another embedding model?
Yes. Embeddings from different models are not comparable, even at the same dimension. Re-embed the corpus into a new collection before switching traffic.
Does it work with any vector database?
Yes — it returns standard numeric vectors, so pgvector, Qdrant, Pinecone, Weaviate and similar stores work without special integrations.
What happens if embeddings fail mid-job?
Requests fall back to same-profile peers in the embed family, so batch indexing normally completes without intervention. Live health is on the status page.