Models
The API serves the four models below. Other models in the KURE family can be downloaded from Hugging Face and run yourself (compare models).
| Model ID (alias) | Snapshot | Endpoint | Use |
|---|---|---|---|
kure-v3 | kure-v3-20261016 | /embeddings | Dense embeddings (semantic search) |
kure-sparse-nano | kure-sparse-nano-20261016 | /sparse-embeddings | Sparse embeddings (inverted index, hybrid search) |
kure-sparse-base | kure-sparse-base-20261016 | /sparse-embeddings | Sparse embeddings (more accurate than nano, larger vocabulary) |
kure-reranker-nano | kure-reranker-nano-20261016 | /rerank | Reranking (cross-encoder) |
Sending a model to the wrong endpoint returns 404 with the endpoint to use.
Model IDs and versions
A model ID is either a snapshot or an alias.
| Kind | Example | Points to |
|---|---|---|
| Snapshot | kure-v3-20261016 | The weights deployed on that date. Never changes |
| Alias | kure-v3-latest | The model's latest snapshot |
| Alias | kure-v3 | Same as kure-v3-latest |
- The
modelfield of a response is the snapshot ID that served the request.alias_forinGET /modelsshows which snapshot an alias points to now. - When we update the weights, we add a snapshot with a new date and move the aliases. We announce it before moving an alias.
- If you store vectors for search, use a snapshot ID. When an alias moves, the same text gets a different vector, and new query vectors no longer match your stored document vectors. A snapshot keeps results the same until you switch.
- Reranker and sparse embedding models follow the same rules (
kure-reranker-nano-20261016,kure-sparse-nano-latest,kure-sparse-base, and so on).
KURE-v3
| Item | Value |
|---|---|
| Model ID | kure-v3-20261016 (aliases kure-v3, kure-v3-latest) |
| Type | Dense single-vector embedding |
| Parameters | 1.1B |
| Output dimensions | 2048 (MRL: 256, 512, 768, 1024, 2048) |
| Maximum input length | 8,192 tokens |
| Normalization | L2 (dot product = cosine similarity) |
| Languages | Korean-first, Korean↔English cross-lingual retrieval |
Queries vs. documents (input_type)
KURE-v3 was trained with different prompts in front of queries and documents. With input_type, the server adds the right one for you.
input_type | Prompt added | Use for |
|---|---|---|
query | query: | Search queries and questions from users |
document | passage: | Documents, paragraphs, and chunks being searched |
| omitted | none | Embedding the text as-is |
For retrieval, always distinguish queries from documents. When comparing texts of the same kind (deduplication, clustering), use the same input_type on both sides.
If your text already starts with the prompt and you also set input_type, the prompt is added twice. Use one or the other.
MRL dimensions
KURE-v3 is trained with Matryoshka Representation Learning (MRL), so keeping only the leading part of a vector costs little accuracy. With dimensions, the server truncates the vector from the front and re-normalizes it.
dimensions | Size of one float32 vector | Storage vs. 2048 |
|---|---|---|
| 2048 (default) | 8 KB | 100% |
| 1024 | 4 KB | 50% |
| 768 | 3 KB | 38% |
| 512 | 2 KB | 25% |
| 256 | 1 KB | 13% |
- Queries and documents must use the same dimensions to be comparable.
- If you already stored 2048-dim vectors, truncating them and re-normalizing gives the same result as calling the API again.
- Compare how rankings change across dimensions on the Playground.
Long documents
Each text can be up to 8,192 tokens; longer texts return 400 context_length_exceeded. Typical Korean prose is around 600 tokens per 1,000 characters, so 8,192 tokens is roughly 13,000 characters. This varies by text, so we recommend splitting long documents by paragraph. The actual count is in usage.prompt_tokens of each response.
KURE-Sparse
kure-sparse-nano | kure-sparse-base | |
|---|---|---|
| Type | Learned sparse vectors (SPLADE family) | Learned sparse vectors (English + multilingual vocabulary) |
| Parameters | 149M | 593M |
Vocabulary (dimension) | 36,282 | 280,524 |
| Max input length | 8,192 tokens (longer input is truncated) | 8,192 tokens |
| MTEB(kor) Retrieval nDCG@10 | 0.7716 | 0.7984 |
| Hugging Face | KURE-Sparse-nano | KURE-Sparse-base |
Queries and documents are encoded differently, so input_type is required. See the Sparse Embeddings API.
KURE-Reranker-nano
| Type | Cross-encoder reranker |
| Parameters | 149M |
| Max input length | 8,192 tokens for query + document (longer pairs are truncated, longest part first) |
| Reranking nDCG@10 (9 Korean benchmarks, BM25 top 50) | 0.8757 (the 1.7B base model: 0.8800) |
| Score | Relevance probability 0–1 (relevance_score) |
| Hugging Face | KURE-Reranker-nano |
See the Rerank API.
Model lifecycle
GPU capacity is limited, so when a new model ships, older models are retired after a notice period. Retirement goes through the stages below, with at least 30 days between the announcement and retirement.
| Status | Served | What the API shows |
|---|---|---|
active | Yes | Business as usual |
deprecated | Yes | Deprecation and Sunset (earliest retirement date) response headers. status, sunset, replacement in GET /models |
| retired | No | 410 model_retired, with the replacement in the message |
- Accounts that used a deprecated model in the last 30 days see a notice at the top of the dashboard We also email them when we have an email address for the account.
- The lifecycle applies to snapshots. Aliases are moved off a snapshot before it is retired.
- Vectors from different snapshots are not comparable, so you need to re-embed your stored documents with the new snapshot.
- Log a warning when you see a
Sunsetheader or a non-activestatusinGET /models, so you don't miss the notice.
Weight release
The KURE-v3 weights are available on Hugging Face. kure-v3-20261016 has the same weights as revision 9e799c2 of nlpai-lab/KURE-v3, so you can mix vectors you make with sentence-transformers and vectors from the API.