The number that should bother you

The most-downloaded model on HuggingFace right now is a 33-million-parameter BERT variant from March 2022. It has 254 million downloads. The second is a cross-encoder from the same month. The third is a 33M-parameter model from 2023. The fourth and fifth are BERTs from 2022.

Every single one of the top five is a sentence-transformer or BERT-derivative. None of them were released this year. The field has moved on — 0.6B, 4B, 8B embedding models with instruction-tuned retrieval heads and 1024 to 3072 dimensions — and the download counter has not caught up.

What a download counter actually measures

A download counter on a model hub measures cumulative pulls over the model’s entire lifetime. A model released in 2022 has had four and a half years to accumulate downloads. A model released last month has had one. The counter is not a vote. It is a sum of every pip install, every Docker pull, every CI cache warm-up, every “just gonna try this in a weekend project” that happened since the model shipped.

MiniLM is not the most-downloaded model because it is the best embedding model people are running today. It is the most-downloaded because it is the default in the most tutorials, the default in the most RAG boilerplate, the default in the most “how to do semantic search” blog posts that were written between 2022 and 2024 and never updated.

The boilerplate problem

Here is the uncomfortable part. When a developer reads a 2023 tutorial on semantic search, they copy the code. The code pulls all-MiniLM-L6-v2. The code works. The developer ships the project. The project runs for three years. Every time the project’s CI runs, MiniLM gets a download.

The download counter is therefore a measure of how much of the current internet is built on 2022-era code. It is a fossil record of the tutorial era. Every RAG stack that was bolted onto an application between 2023 and 2025 and never revisited is still pulling that 33M-parameter BERT from a hub server in the cloud.

This is not an indictment of MiniLM. It is an indictment of the update rate. A 33M-parameter model with 384-dimensional vectors, fine-tuned on SNLI and MS MARCO, is a perfectly competent sentence encoder for in-memory similarity over a few thousand documents. It is not what you want for a local retrieval system indexing thousands of markdown files with a 0.6B model doing 1024-dimensional vectors and instruction-aware retrieval. The task moved. The boilerplate did not.

What I actually run

Two weeks ago I swapped the 12-billion-parameter embedding model that powers local note retrieval for a 0.6B one. The vectors shrank 3.7x. The memory peak dropped from 12.3 gigabytes to about 185 megabytes. The search quality did not regress in any way I could measure. That post is still the most practical thing I have written about embedding models, and the model I picked is not in the top five by downloads. It is not in the top fifty. It is a 0.6B model that does the job.

The point is not that MiniLM is bad. The point is that the most-downloaded model on the hub and the model I actually run for a real retrieval workload are separated by four years of research and a factor of twenty in parameter count. The download counter does not tell you what is good enough today. It tells you what was good enough when the tutorial was written.

The graveyard effect

Every model category on the hub has this problem. The LLM download counter is dominated by 7B and 13B models from 2023 and early 2024. The image model counter is dominated by SD 1.5 and SDXL from 2022 and 2023. The top-downloaded list in any category is a graveyard of the current defaults.

This has a practical consequence for anyone evaluating models. If you sort by downloads, you are seeing the inertia of the field. If you sort by last modified, you are seeing noise — every model that gets a config file updated floats to the top. The signal is somewhere in between, and the only way to find it is to know what the current task actually needs and check the benchmark, not the counter.

What to do instead

If you are building a retrieval system today, skip the download counter entirely. Decide the task: how many documents, what dimensionality is acceptable for your vector store, do you need instruction-aware queries, do you need multilingual coverage. Then look at models released in the last two years that match those constraints. The 0.6B to 8B range has several strong options with published benchmarks. The 33M BERTs are there for legacy compatibility and quick prototypes. They are not where the field is.

The download counter will keep telling you that MiniLM is the most popular embedding model on the hub. It will keep telling you that SD 1.5 is the most popular image model. It will keep telling you that the 7B LLMs from 2023 are the most popular language models. And it will be correct. The counter measures cumulative pulls. The field measures what works today. Those are not the same number.

The most-downloaded model on HuggingFace is sentence-transformers/all-MiniLM-L6-v2, a 33M-parameter BERT variant released 2022-03-02. 254,035,929 cumulative downloads. The model I run for local note retrieval is Qwen3-Embedding-0.6B, released in the 0.6B class with 1024-dimensional vectors. It is not in the top fifty by downloads. The gap between the two is four years of embedding research that the counter has not caught up to.

Sources

[1] sentence-transformers/all-MiniLM-L6-v2 — the most-downloaded model on the hub [2] Qwen3-Embedding-0.6B — the 0.6B embedding model in use on this stack [3] Shrink the Embedder, Not the Idea — the 12B to 0.6B swap on this stack