- Published on
What's Trending on Hugging Face Right Now — A Map of August 2026
- Authors

- Name
- Youngju Kim
- @fjvbn20031
Introduction — Half of Trending Page One Isn't New Models
Open Hugging Face's trending page on August 2, 2026, and the first screen shows a little over thirty repositories. Roughly half of them aren't newly trained models. They're someone else's weights converted to GGUF and uploaded, community fine-tunes that changed the character of the model, and effectively mirrors.
That's not to say this is bad. Without quantized reuploads, you couldn't run a 27B model on a laptop. The issue is that reading this list as "the ranking of what's hot right now" throws off your judgment. Which organization made what, where that model is meant to be used, what the license is — all of it gets flattened away on the list.
This post doesn't just copy out the leaderboard. Instead, it organizes models by purpose that you'd actually put into deployment, noting for each the maker, scale, license, and constraints worth knowing before you use it. It starts with how to tell an original from a derivative — learn this, and the rest of the list reads far more clearly.
Every figure was checked directly against the Hugging Face API and model cards on August 2, 2026, the moment of lookup. Download counts are the trailing-30-days figure Hugging Face shows by default, which differs from cumulative downloads. For example, Qwen3.6-27B is 6.57 million on a 30-day basis and 18.8 million on a cumulative basis. Every table in this post is standardized to the 30-day basis.
Half of Trending Is Reuploads — How to Tell Originals From Derivatives
Hugging Face records the relationship between repositories with a tag. The badge at the top of a model page and the tag list in the API carry the same value.
| Tag form | Meaning | What shows on the page |
|---|---|---|
base_model:quantized:original | Original quantized and reuploaded | Quantized from |
base_model:finetune:original | Original given additional training | Finetuned from |
base_model:adapter:original | Holds only an adapter, like a LoRA | Adapter for |
base_model:merge:original | Multiple models merged | Merge of |
| No tag | Either an original release, or the relationship just isn't marked | None |
The last row is the thing to watch here. No tag doesn't guarantee it's an original — it just doesn't get attached if the uploader didn't fill it in. So in practice, you look at three things together.
First, look at the organization account. Accounts like Qwen, deepseek-ai, moonshotai, google, microsoft, nvidia, upstage, LGAI-EXAONE, and skt carry an organization-verified badge. A frontier-class model uploaded to a personal account is almost always a derivative.
Second, look at the file list. An original release comes with config.json, model.safetensors.index.json, tokenizer.json, and chat_template.jinja together. If there are just a few GGUF files and no config.json, it's a conversion.
Third, look at the naming convention. Suffixes like -GGUF, -AWQ, -GPTQ, -NVFP4, -FP8, -INT4, -MLX, -ONNX are, practically without exception, conversions.
So why does a derivative get downloaded more than the original? Several reasons stack up. An original usually ships as a single BF16 set, which needs multiple GPUs. A GGUF conversion, on the other hand, runs on a laptop, so the number of individual users is overwhelmingly larger. On top of that, a GGUF repository has multiple files per quantization tier, so partial downloads happen often, and a format tied to a specific runtime, like MLX or ONNX, becomes the default path for that ecosystem.
Here's what it looks like in actual numbers — trailing-30-day downloads checked on the same day.
| Original | Original downloads | Derivative | Derivative downloads |
|---|---|---|---|
| Qwen/Qwen3.6-27B | 6,572,759 | prism-ml/Bonsai-27B-gguf | 2,510,237 |
| Qwen/Qwen3.6-27B | 6,572,759 | unsloth/Qwen3.6-27B-MTP-GGUF | 1,181,465 |
| moonshotai/Kimi-K3 | 559,924 | unsloth/Kimi-K3-GGUF | 41,337 |
| poolside/Laguna-S-2.1 | 77,021 | unsloth/Laguna-S-2.1-GGUF | 170,109 |
| upstage/Solar-Open2-250B | 13,426 | nota-ai/Solar-Open2-250B-Nota-NVFP4 | 22,396 |
| nvidia/parakeet-tdt-0.6b-v3 | 207,975 | mlx-community/parakeet-tdt-0.6b-v3 | 1,300,339 |
In the bottom three rows, the derivative outpaces the original. For parakeet, the MLX conversion for Apple silicon gets downloaded more than six times as much as the original. Read the original repository's download count as "this model's popularity," and this structure will throw you badly off.
There are three effects on model selection.
One, a derivative doesn't automatically follow the original's fixes. Even if the original team pushes a fix to the tokenizer or chat template, a conversion stays as it was. For the first few weeks after a release, it's safer to check the original's commit history.
Two, a license doesn't change in a derivative. If the original restricts commercial use, the GGUF conversion is restricted the same way. Sometimes a derivative's card has no license at all, or states it ambiguously — the original is the reference in that case.
Three, there's a big difference between a derivative with verified quality and one without. Accounts like unsloth, mlx-community, ggml-org, and RedHatAI have a published conversion pipeline and leave traces of regression checking. A personal merge with a name stuffed full of adjectives usually has no reproducible evaluation behind it.
General-Purpose and Coding LLMs — Frontier-Class, Wide Open
The top ranks right now are occupied by MoE models north of a trillion parameters. Below is a pull of just the original releases from the top of trending at the time of lookup.
| Model | Maker | Scale | Context | License | 30-day downloads |
|---|---|---|---|---|---|
| moonshotai/Kimi-K3 | Moonshot AI | 2.8T / 104B active MoE | 1,048,576 | Kimi K3 License (custom) | 559,924 |
| deepseek-ai/DeepSeek-V4-Flash | DeepSeek | 284B / 13B active MoE | 1M | MIT | 2,814,414 |
| zai-org/GLM-5.2 | Z.ai | Not stated in card | 1M | MIT | 1,683,442 |
| Qwen/Qwen3.6-27B | Qwen | 27B dense + vision | 262,144 (extends to 1,010,000) | Apache 2.0 | 6,572,759 |
| Qwen/Qwen3.6-35B-A3B | Qwen | 35B / 3B active MoE | 262,144 | Apache 2.0 | 5,939,238 |
| thinkingmachines/Inkling | Thinking Machines | 975B / 41B active MoE | Not stated in card | Apache 2.0 | 59,076 |
| upstage/Solar-Open2-250B | Upstage | 250B / 15B active MoE | 1M | Upstage Solar License | 13,426 |
| skt/A.X-K2 | SK Telecom | 688B / 33B active MoE | 262,144 | Apache 2.0 | 1,218 |
| LGAI-EXAONE/K-EXAONE-2.0-750B-A37B | LG AI Research | 750B / 37B active MoE | See card | Apache 2.0 | 101 |
There are a few constraints worth flagging.
Kimi K3 uses a custom license, not MIT. Read the license text and use, modification, redistribution, and fine-tuning are all free, but there are two thresholds. Running what the card defines as Model as a Service — a business offering model inference or fine-tuning to third parties — requires a separate agreement once trailing 12-month revenue exceeds USD 20 million. Also, using it in a product with over 100 million monthly active users or USD 20 million in monthly revenue requires displaying the model's name in the UI. Neither condition applies to internal-only use. For most companies this is effectively unlimited, but classify it as "open source" without checking the license and it causes trouble later.
Solar Open 2 is similar but pulls in a different direction. The Upstage Solar License carries over most of Apache 2.0's terms as-is, but adds Section 4(e). Build and distribute a derivative AI model from this one, and its name has to start with Solar, and related websites and documentation have to display a branding notice. It doesn't block commercial use itself, but a branding obligation comes attached.
Three models worth watching from a Korean-language standpoint came out around the same time. Upstage's Solar Open 2 explicitly supports Korean and Japanese, and its card lists roughly 12 trillion pretraining tokens and 2 million GPU-hours on B200. SKT's A.X K2 is 688B / 33B active MoE, and per its card is part of a government sovereign-AI foundation model program. LG AI Research's K-EXAONE 2.0 is 750B / 37B active, released under Apache 2.0. All three still have low download counts as of the lookup time — 101 for K-EXAONE 2.0, 1,218 for A.X K2. That's because they'd been public for only a few days, and these numbers can't be used to judge quality.
Inkling's downloads are low relative to its scale (59,076), because 975B / 41B active isn't a size an individual can run. The same account also has Inkling-Small and its NVFP4 variant up alongside it, and interestingly, the NVFP4 variant (25,352) gets downloaded more than six times as much as the original BF16 (3,998). It means people who actually put it into serving reach for the low-precision side.
The coding side has a narrower purpose.
| Model | Maker | Scale | License | 30-day downloads | Constraint |
|---|---|---|---|---|---|
| poolside/Laguna-S-2.1 | poolside | 118B / 8B active | OpenMDW-1.1 | 77,021 | BF16 weights alone run about 236GB |
| Kwaipilot/KAT-Coder-V2.5-Dev | Kwaipilot | 35B / 3B active | Apache 2.0 | 10,771 | The public release is text-only, vision module excluded |
| moonshotai/Kimi-K2.7-Code | Moonshot AI | ~1T class | Custom | 665,880 | Needs a check against the Kimi family license |
Laguna S 2.1's license, OpenMDW-1.1, states it freely permits commercial use and modification. That said, this license only recently became established, so there's a good chance it's not on your legal team's review list yet. As the card states, only 12 of its 48 layers use global attention, with the remaining 36 as sliding-window with a window of 512, and this structure is what handles the 1M context.
For KAT-Coder-V2.5-Dev, the constraint stated directly by the card matters. The weights that were released are only the language-model portion — the vision and multimodal components aren't included, so it runs text-only. This is the type of case where you absolutely have to check whether the benchmark table is based on the full model.
Embeddings and Rerankers — A Two-Year-Old Model Still Holds First
This space moves on a completely different rhythm from LLMs. New models keep coming out, but the top spot in actual usage still belongs to an old one.
| Model | Maker | Size | License | 30-day downloads | Release date |
|---|---|---|---|---|---|
| sentence-transformers/all-MiniLM-L6-v2 | SBERT | ~22M | Apache 2.0 | 251,140,343 | 2022-03 |
| BAAI/bge-m3 | BAAI | See card | MIT | 34,621,449 | 2024-01 |
| Qwen/Qwen3-Embedding-0.6B | Qwen | 0.6B | Apache 2.0 | 9,801,487 | 2025-06 |
| google/embeddinggemma-300m | 0.3B | Gemma License | 1,911,651 | 2025-07 | |
| Qwen/Qwen3-Reranker-0.6B | Qwen | 0.6B | Apache 2.0 | 2,725,199 | 2025-05 |
| Alibaba-NLP/gte-reranker-modernbert-base | Alibaba NLP | 0.1B | Apache 2.0 | 2,386,616 | 2025-01 |
| microsoft/harrier-oss-v1-0.6b | Microsoft | 0.6B | MIT | 214,363 | 2026-03 |
| jinaai/jina-reranker-v3.5 | Jina AI | 0.6B | CC BY-NC 4.0 | 1,866 | 2026-07 |
MiniLM-L6-v2's figure of 251 million isn't about performance. It's baked in as the default in countless libraries and gets downloaded every time CI runs. In the embedding space, download count can't be used as a quality metric.
Two constraints come up often in practice.
First, google/embeddinggemma-300m is a gated repository. At lookup time, the gated value was manual, so trying to pull the card without logging in returns only an access-restriction notice. You have to agree to the Gemma license. This is the classic spot where a Docker image build fails trying to pull without a token.
Second, Jina AI's latest models are CC BY-NC 4.0. A non-commercial condition comes attached. That goes for jina-reranker-v3.5 and for jina-embeddings-v5-text-small alike. Make an adoption decision based on the performance table alone, and you get blocked right before deployment. For a commercial service, it's better to narrow candidates toward the Apache 2.0 side, like the Qwen3-Reranker family or the GTE family.
Microsoft's harrier-oss-v1 is a multilingual embedding family released under MIT. The MTEB v2 scores stated by the card are 66.5 for 270M, 69.0 for 0.6B, and 74.3 for 27B, and it's explicitly noted that these are self-reported figures as of release time. Swapping an embedding model means rebuilding your index, so the right move is to reproduce it on your own data and decide, rather than going by the card's score. How to reproduce it was covered separately in how to debug RAG retrieval quality and the practical guide to embedding models and vector search.
Vision and Documents — OCR and Computer-Use Agents
This space splits into two branches right now. One is OCR that turns documents into text; the other is an agent that looks at a screen and operates it.
| Model | Maker | Size | License | 30-day downloads | Purpose |
|---|---|---|---|---|---|
| baidu/Unlimited-OCR | Baidu | 3.3B | MIT | 2,457,387 | Document OCR |
| nvidia/LocateAnything-3B | NVIDIA | 3.8B | Custom | 716,448 | Open-vocabulary localization |
| ATH-MaaS/OvisOCR2 | ATH | 0.9B | Apache 2.0 | 68,429 | Lightweight OCR |
| microsoft/Mage-VL | Microsoft | 4.7B | Apache 2.0 | 10,525 | General-purpose vision-language |
| microsoft/Fara1.5-27B | Microsoft | 27B | MIT | 2,775 | Browser-operating agent |
Unlimited-OCR's own card states it pushes DeepSeek-OCR one step further, and a paper is published alongside it. MIT plus 3.3B makes it a good combination to plug into a document pipeline.
Fara1.5-27B has an unusual character. It's a computer-use agent supervised-fine-tuned from Qwen3.5-27B, and it judges from screenshots alone, without looking at the DOM or the accessibility tree, to click pixel coordinates. There's a part the card warns about in bold: use it only inside the harness Microsoft built. Integrate it directly, and the responsibility for implementing sandboxing, a domain allowlist, a monitoring mode, and an emergency stop falls onto you. It explicitly states not to run it with open browser permissions on a machine with anything sensitive on it. For this class of model, read this paragraph before the performance table.
LocateAnything-3B is a fine-tuned derivative of Qwen2.5-3B-Instruct. Its 710,000 downloads are an example of how, even without being an original-family release, a model gets widely used if it fits a specific task well. That said, its license is other, so the text needs checking before commercial adoption.
Speech — STT Has Settled, TTS Is Still Split
The speech-recognition side has a fairly stable distribution of actual usage.
| Model | Maker | Size | License | 30-day downloads |
|---|---|---|---|---|
| openai/whisper-large-v3-turbo | OpenAI | 0.8B | MIT | 8,503,879 |
| Qwen/Qwen3-ASR-0.6B | Qwen | 0.9B | Apache 2.0 | 3,548,123 |
| mistralai/Voxtral-Mini-4B-Realtime-2602 | Mistral AI | 4.4B | Apache 2.0 | 2,097,354 |
| CohereLabs/cohere-transcribe-03-2026 | Cohere Labs | 2.1B | Apache 2.0 | 1,029,521 |
| microsoft/VibeVoice-ASR | Microsoft | 8.7B | MIT | 678,655 |
| nvidia/parakeet-tdt-0.6b-v3 | NVIDIA | 0.6B | CC BY 4.0 | 207,975 |
Whisper large-v3-turbo is still in first place, even though it's an October 2024 model. When you bring in a new model, the reason for replacing it should be clear. If you need real-time streaming, look at Voxtral's realtime family or NVIDIA's streaming family; if you need broad multilingual coverage, look at Qwen3-ASR or VibeVoice-ASR. VibeVoice-ASR's card lists Korean among its languages.
The parakeet family is CC BY 4.0, which comes with an attribution obligation — a clause that's frequently missed in practice. And as seen earlier, actual usage is far larger on the mlx-community mirror side.
Speech synthesis is even more scattered.
| Model | Maker | License | 30-day downloads | Notes |
|---|---|---|---|---|
| hexgrad/Kokoro-82M | hexgrad | Apache 2.0 | 11,282,032 | 82M, card explicitly welcomes commercial deployment |
| Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice | Qwen | Apache 2.0 | 2,400,018 | Voice customization |
| openbmb/VoxCPM2 | OpenBMB | Apache 2.0 | 963,360 | |
| k2-fsa/OmniVoice | k2-fsa | No license in tags | 849,526 | Derivative based on Qwen3-0.6B |
| Supertone/supertonic-3 | Supertone | OpenRAIL | 28,838 | 30-odd languages including Korean |
Kokoro-82M racks up 11 million downloads at 82M parameters. It's an example showing that in this space, size and adoption run inversely. Its card also carries a warning about fake sites impersonating this name.
OmniVoice's license tag was empty at lookup time, even though it's a model with 850,000 downloads. No license is closer to "the rights situation is unclear" than "use it freely." Internal use might be fine, but putting it into a product needs a check with the uploader. The OpenRAIL family is a different story — clauses prohibiting specific uses come attached in the body. Not a license to wave through without legal review.
Image and Video — Check the License First, Before Anything Else
The generative image/video space has more license variance than any other space here. Look at this before performance comparisons.
| Model | Maker | License | Gated access | 30-day downloads |
|---|---|---|---|---|
| Tongyi-MAI/Z-Image-Turbo | Tongyi MAI | Apache 2.0 | Not required | 1,102,053 |
| Lightricks/LTX-2.3 | Lightricks | LTX-2 Community License | Not required | 2,128,047 |
| black-forest-labs/FLUX.1-dev | Black Forest Labs | Non-commercial license | Required | 537,643 |
| krea/Krea-2-Turbo | Krea | Krea 2 Community License | Required | 144,966 |
| Wan-AI/Wan2.2-TI2V-5B | Wan AI | Apache 2.0 | Not required | 16,094 |
FLUX.1-dev is the overwhelming leader on this list with 13,887 likes, yet the license's name itself is non-commercial. It also requires gated access. Like count has no relationship whatsoever to commercial usability.
Per its card, Z-Image-Turbo is a 6B-parameter distilled model that generates an image in 8 function evaluations and fits on a 16GB-VRAM consumer device. It has the fewest constraints since it's Apache 2.0. That said, this performance figure is the maker's own self-measurement.
The Krea 2 and LTX-2 families have "community" in the name, but they're custom licenses with conditions attached. On the Krea side, the license text is linked as a PDF, and gated access is set automatically. This space sees an unusually large number of derivative LoRAs and GGUF conversions hit trending, and the license reference for all those derivatives is the original.
Small and On-Device — 3B and Under, and Extreme Low-Bit
The on-device side splits into two branches: models built small from the start, and large models squeezed down to the extreme.
| Model | Maker | Scale | License | 30-day downloads | Notes |
|---|---|---|---|---|---|
| Nanbeige/Nanbeige4.2-3B | Nanbeige | 4B total, 3B non-embedding | Apache 2.0 | 27,892 | Looped transformer |
| LiquidAI/LFM2.5-350M | Liquid AI | 350M | LFM custom license | 89,888 | 28T-token training budget |
| microsoft/harrier-oss-v1-270m | Microsoft | 270M | MIT | 221,855 | Multilingual embedding |
| fdtn-ai/antares-1b | fdtn-ai | ~1B | Apache 2.0 | 11,297 | Derivative of granite-4.0-1b, gated access required |
| prism-ml/Bonsai-27B-gguf | Prism ML | 1-bit conversion of Qwen3.6-27B | Apache 2.0 | 2,510,237 | ~3.9GB deployed size |
Bonsai-27B is where this post's two axes meet. It's near the top of trending with 2.51 million downloads, yet it's not an original — it's a quantized reupload of Qwen3.6-27B. The card's stated figure is an effective 1.125 bits per weight, a sign-bit representation where every 128 weights share one FP16 scale. It states about a 14.2x reduction versus FP16, and an average of 76.11 across 15 thinking-mode benchmarks, retaining 89.5 percent of FP16.
All these numbers are the maker's own self-measurement. And there's an interesting point the card raises about itself: a typical low-bit build's actual average bit width runs higher than its label. It cites the example of a widely used "2-bit" build of Qwen3.6-27B that's actually 9.4GB at 2.8 bits per weight. The point is: don't take a quantization tier's name at face value — divide the file size by the parameter count instead. The differences across quantization formats are laid out in the GPTQ, AWQ, GGUF quantization comparison.
LFM2.5-350M's card shows what an on-device model card should look like: 350M parameters, 16 layers, a 28-trillion-token training budget, a context of 32,768, a knowledge cutoff of mid-2024, and crucially, a sentence stating "not recommended for knowledge-intensive tasks and programming." When the maker states its limits up front, the adoption decision goes much faster.
If your goal is fitting a small model to your own work, the criteria for picking a size are laid out in the local LLM VRAM math, and the training procedure in production QLoRA fine-tuning.
Closing — Look at Coordinates, Not the Leaderboard
The trending list is the rate of change over the last few days. It shows what's newly appeared, not what's good. So a freshly uploaded GGUF conversion and a 750B model nobody's run yet sit side by side at the top of the list.
What practice needs is coordinates. Who made this model, is it an original or a derivative, what does the license prohibit, and what limits did the maker state on the card. None of these four show up on any leaderboard, but all four are on the model card's first screen. The next post takes apart the training pipeline that card holds, and the one after that lays out an order for reading a card in five minutes.