---
title: "all-MiniLM-L6-v2: the complete reference (dimensions, specs, self-hosting)"
description: all-MiniLM-L6-v2 outputs 384-dimensional embeddings, truncates at 256 tokens, and costs $0.0040 per million tokens to self-host. Full spec sheet, benchmarks, and honest alternatives.
canonical_url: https://superlinked.com/glossary/what-is-all-minilm-l6-v2
last_updated: 2026-08-13
---

<!--
target_queries:
- sentence-transformers all-minilm-l6-v2 384 dimensions model card
- sentence-transformers/all-minilm-l6-v2
- all-minilm-l6-v2 384 dimensions
- all-minilm-l6-v2 dimension 384
catalog_page: https://superlinked.com/models/sentence-transformers-all-minilm-l6-v2
-->

# all-MiniLM-L6-v2: the complete reference

all-MiniLM-L6-v2 outputs 384-dimensional sentence embeddings from a 22.7M parameter encoder. It is the most downloaded embedding model on Hugging Face, at well over 200 million downloads a month, and it is five years old. Both facts matter when you decide whether to use it.

## Spec sheet

| Spec | Value |
|---|---|
| Embedding dimensions | 384 |
| Parameters | 22.7M |
| Max input length | 256 word pieces (truncated beyond that) |
| Architecture | 6-layer MiniLM, fine-tuned from nreimers/MiniLM-L6-H384-uncased |
| Training data | 1.17 billion sentence pairs |
| Language | English |
| License | Apache 2.0 |
| Released | August 2021 |

Two of these rows cause most of the confusion that brings people to this page.

The dimension count is 384. Not configurable, no Matryoshka truncation, no smaller variants. If your vector database collection is set to anything else, inserts fail; this is the single most common integration error we see with this model.

The input limit is 256 word pieces, and here is the gotcha: the underlying tokenizer config says 512, so some frameworks happily accept longer inputs and silently truncate at 256. The model card is explicit that text beyond 256 word pieces is cut. Chunk accordingly.

One more footgun for anyone using raw transformers instead of the sentence-transformers library: the model does not pool for you. You have to apply mean pooling over token embeddings, then normalize. Skip that and you get garbage similarities that look plausible.

## What it is good at, and where it loses

MiniLM's appeal is speed and size. 22.7M parameters fits anywhere; it embeds a corpus faster than anything of comparable quality and runs acceptably on CPU.

Quality is where its age shows. On our benchmark suite (NDCG@10, measured on the same suite as every model in the catalog):

| Benchmark | all-MiniLM-L6-v2 | e5-base-v2 (109M) | stella_en_400M_v5 (435M) |
|---|---|---|---|
| FiQA2018 (finance) | 0.150 | 0.351 | 0.559 |
| NFCorpus (medical) | 0.232 | 0.354 | 0.413 |
| SciFact | 0.611 | 0.684 | 0.784 |
| StackOverflowQA | 0.840 | 0.878 | 0.867 |
| SCIDOCS | 0.065 | 0.118 | 0.250 |

Read the FiQA row again. On domain-specific retrieval, MiniLM scores less than half of what a 2024-era model manages. On StackOverflowQA it is within a few points of models 20x its size. The pattern: MiniLM holds up on general short-text similarity and collapses on specialized domains.

Our take: it is still a fine default for prototypes, semantic deduplication, and clustering where volume is huge and precision tolerance is loose. For production RAG over domain documents, the quality gap to e5-base-v2 or stella_en_400M_v5 is too large to ignore, and both are cheap.

## Self-hosting numbers

Measured on an L4 GPU, as published on the [catalog page](https://superlinked.com/models/sentence-transformers-all-minilm-l6-v2):

| Metric | Value |
|---|---|
| Latency (p50) | 53 ms |
| Throughput | 55,300 tokens/sec |
| Cost | \$0.0040 per 1M tokens |

At \$0.0040 per million tokens, embedding a 10-billion-token corpus costs about \$40 of GPU time. This is the model's real remaining argument; nothing hosted comes close on price.

Running it on SIE takes one model reference in the config; the /encode endpoint handles batching across concurrent callers, which is where the 55K tokens/sec figure comes from. Setup is in the [encode docs](https://superlinked.com/docs/encode).

## Alternatives, honestly

Upgrade to **e5-base-v2** (109M, 768 dims, \$0.0042/1M tokens) if you want a meaningful quality lift at essentially the same serving cost; it beats MiniLM on all nine of our retrieval benchmarks. Mind the "query:" / "passage:" prefixes it requires.

Upgrade to **stella_en_400M_v5** (435M, 1,024 dims, \$0.0082/1M tokens) if retrieval quality is the point. It roughly doubles MiniLM's NDCG@10 on half our benchmark suite and still costs under a cent per million tokens.

Stay on MiniLM if you are dimension-locked to 384 in an existing index, or if you are embedding at a scale where the difference between \$0.0040 and \$0.0082 per million actually shows up on a bill. e5-small-v2 (33M, also 384 dims, \$0.0038/1M) is the drop-in-shaped upgrade in that case, though re-embedding is still required; embeddings from different models are never comparable, even at the same dimension count.

All three alternatives are in the [model catalog](https://superlinked.com/models) with the same benchmark and cost columns, measured the same way.
