필사 모드: 今Hugging Faceで何が伸びているか — 2026年8月トレンディングマップ

はじめに — トレンディング1ページ目の半分は新規モデルではありません

2026年8月2日にHugging Faceのトレンディング一覧の最初の画面を開くと、三十個あまりのリポジトリが見えます。そのうち半分ほどは新しく学習されたモデルではありません。他人が作った重みをGGUFに変換してアップロードしたもの、コミュニティが性格を変えたファインチューン、そして事実上のミラーです。

これは悪いという話ではありません。量子化再アップロードがなければノートパソコンで27Bモデルを動かせません。問題は、この一覧を「今伸びているモデルのランキング」として読むと判断がずれるという点です。どの組織が何を作ったのか、そのモデルがどこで使われるのか、ライセンスは何かが、一覧の上ではすべて潰れて見えます。

この記事はランキング表をそのまま書き写しません。代わりに用途別に分けて、実際にデプロイに載せることになるモデルを整理し、それぞれについて作り手と規模、ライセンス、そして使う前に知っておくべき制約を書きました。まずは原本と派生版を見分ける方法から始めます。これを身につけておけば、残りの一覧がはるかに読みやすくなります。

数値はすべて照会時点である2026年8月2日にHugging Face APIとモデルカードで直接確認した値です。ダウンロード数はHugging Faceが標準で表示する直近30日基準です。累計ダウンロードとは違います。たとえばQwen3.6-27Bは30日基準で657万、累計基準で1,880万です。この記事の表はすべて30日基準に統一しています。

トレンディングの半分は再アップロードです — 原本と派生版の見分け方

Hugging Faceはリポジトリ間の関係をタグで記録します。モデルページ上部のバッジとAPIのタグ一覧は同じ値を使います。

ここで注意すべきなのは最後の行です。タグがないからといって原本である保証はありません。アップロードした人が入力しなければ付きません。だから実務では三つを一緒に見ます。

第一に、組織アカウントを見ます。Qwen、deepseek-ai、moonshotai、google、microsoft、nvidia、upstage、LGAI-EXAONE、sktのようなアカウントには組織認証バッジが付きます。個人アカウントに上がっているフロンティア級モデルはほぼ常に派生版です。

第二に、ファイル一覧を見ます。原本リリースにはconfig.json、model.safetensors.index.json、tokenizer.json、chat_template.jinjaが揃っています。GGUFファイルが数個だけあってconfig.jsonがなければ変換版です。

第三に、命名規則を見ます。-GGUF、-AWQ、-GPTQ、-NVFP4、-FP8、-INT4、-MLX、-ONNXという接尾辞は事実上すべて変換版です。

ところでなぜ派生版が原本より多くダウンロードされるのでしょうか。理由はいくつか重なっています。原本はたいていBF16一式だけがアップロードされ、これはGPUが複数枚必要です。一方GGUF変換版はノートパソコンで動くので個人ユーザーの数が圧倒的に多くなります。さらにGGUFリポジトリは量子化等級ごとにファイルが複数あるため部分ダウンロードが頻繁で、MLXやONNXのように特定のランタイムに紐づいたフォーマットはそのエコシステムの基本経路になります。

実際の数字で見るとこうなります。同じ日に照会した直近30日のダウンロード数です。

下の三行では派生版が原本を上回っています。parakeetの場合、アップル シリコン向けのMLX変換版は原本の六倍以上ダウンロードされています。原本リポジトリのダウンロード数を「このモデルの人気」として読むと、この構造のせいで大きく間違えます。

モデル選定に及ぼす影響は三つです。

一つ目、派生版は原本の修正を自動的には追いません。原本チームがトークナイザやチャットテンプレートを直してアップロードしても、変換版はそのままです。リリース直後の数週間は原本のコミット履歴を確認するほうが安全です。

二つ目、ライセンスは派生版で変わりません。原本が商用利用を制限していれば、GGUF変換版も同じように制限されます。変換版のカードにライセンスがまったくないか曖昧に書かれている場合がありますが、そのときの基準は原本です。

三つ目、品質が検証された派生版とそうでないものの差は大きいです。unsloth、mlx-community、ggml-org、RedHatAIのようなアカウントは変換パイプラインが公開されており、回帰確認の痕跡が残っています。名前に形容詞がたくさん付いた個人のマージ版は、再現可能な評価がないことがほとんどです。

汎用LLMとコーディングモデル — フロンティア級がまるごと開かれました

今の上位は1兆パラメータを超えるMoEモデルが占めています。以下は照会時点のトレンディング上位から原本リリースだけを抜き出したものです。

いくつか触れておくべき制約があります。

Kimi K3はMITではなく自社ライセンスです。ライセンス原文を見ると、使用、修正、再配布、ファインチューンは自由ですが、二つの敷居があります。モデル推論やファインチューンを第三者に提供する事業、つまりカードが定義するModel as a Serviceを運営していて、連続12か月の合算売上が2,000万米ドルを超えると別途契約が必要です。また月間アクティブユーザー1億人または月商2,000万ドルを超える製品に使う場合、UIにモデル名を表示する必要があります。社内限定利用にはどちらの条件も適用されません。ほとんどの企業には事実上無制限ですが、ライセンスを確認せず「オープンソース」に分類しておくと後で困ります。

Solar Open 2も似ていますが方向が違います。Upstage Solar Licenseはアパッチ2.0の条項をほとんどそのまま踏襲しつつ、4条(e)項を追加しています。このモデルから派生AIモデルを作って配布する場合、名前がSolarで始まる必要があり、関連ウェブサイトと文書にブランド文言を表示する必要があります。商用利用自体は妨げませんが、ブランディング義務が付きます。

韓国語の観点で注目に値する三つのモデルが同じ時期に出ました。UpstageのSolar Open 2は韓国語と日本語を明示的にサポートしており、カードに事前学習トークン約12兆個、B200基準GPU時間200万時間と記載されています。SKTのA.X K2は688B / 活性33B MoEで、カードが明かしたところによると政府のソブリンAI基盤モデル事業の一部です。LG AI ResearchのK-EXAONE 2.0は750B / 活性37Bで、アパッチ2.0で出されています。三つとも照会時点ではダウンロードがまだ少なく、K-EXAONE 2.0は101、A.X K2は1,218です。公開されてから数日しか経っていないためで、この数字で品質を判断することはできません。

Inklingは規模の割にダウンロードが少なく(59,076)、975B / 活性41Bは個人が動かせる大きさではないからです。同じアカウントのInkling-SmallとそのNVFP4変種が一緒に上がっており、興味深いことにNVFP4変種(25,352)が原本BF16(3,998)より六倍以上ダウンロードされています。実際にサービングに載せる人は低精度側を選ぶという意味です。

コーディング側は目的がもう少し狭いです。

Laguna S 2.1のライセンスであるOpenMDW-1.1は、商用利用と修正を自由に許可するとカードが明かしています。ただしこのライセンスは最近確立されたものなので、社内の法務レビューリストにまだ載っていない可能性が高いです。カードに書かれているとおり、48レイヤーのうち12個だけがグローバルアテンションで36個はウィンドウ512のスライディングウィンドウであり、1Mコンテキストをこの構造で処理します。

KAT-Coder-V2.5-Devはカードが直接明かした制約が重要です。公開された重みは言語モデル部分のみで、ビジョンおよびマルチモーダル構成要素は含まれず、テキスト専用として動作します。ベンチマーク表が全体モデル基準ではないか、必ず確認すべき類のものです。

埋め込みとリランカー — 2年前のモデルがまだ1位です

この領域はLLMとまったく違うリズムで動きます。新規モデルは出続けますが、実使用の1位は依然として古いモデルです。

MiniLM-L6-v2の2億5,100万という数字は性能によるものではありません。数多くのライブラリのデフォルト値として組み込まれており、CIが回るたびにダウンロードされるからです。埋め込み領域のダウンロード数は品質指標としては使えません。

実務でよく引っかかる制約が二つあります。

第一に、google/embeddinggemma-300mはアクセス承認が必要なリポジトリです。照会時点でgatedの値がmanualであり、ログインせずにカード原文を取得しようとするとアクセス制限の案内しか出てきません。Gemmaライセンスへの同意が必要です。Dockerイメージのビルド段階でトークンなしに取得しようとして失敗する典型的な地点です。

第二に、Jina AIの最新モデルはCC BY-NC 4.0です。非商用の条件が付きます。jina-reranker-v3.5もjina-embeddings-v5-text-smallも同様です。性能表だけを見て導入を決めると、デプロイ直前で止められます。商用サービスならQwen3-Reranker系列やGTE系列のようなアパッチ2.0側に候補を絞るほうがよいです。

Microsoftのharrier-oss-v1はMITで出ている多言語埋め込み系列です。カードが明かしたMTEB v2スコアは270Mが66.5、0.6Bが69.0、27Bが74.3ですが、これは自己報告の数値であり、リリース時点の基準だと明記されています。埋め込みの入れ替えはインデックスの再構築を伴うので、カードのスコアではなく自分のデータで再現してから決めるのが正しいやり方です。再現方法はRAG検索品質のデバッグ方法と埋め込みモデルとベクトル検索の実践ガイドで別途扱いました。

ビジョンと文書 — OCRとコンピュータ操作エージェント

この領域は今二つの流れに分かれています。ひとつは文書をテキストに変えるOCR、もうひとつは画面を見て操作するエージェントです。

Unlimited-OCRはカード自身がDeepSeek-OCRをもう一歩押し進めたと明かしており、論文も一緒に公開されています。MITで3.3Bなので、文書パイプラインに組み込みやすい組み合わせです。

Fara1.5-27Bは性格が独特です。Qwen3.5-27Bを教師あり微調整したコンピュータ操作エージェントで、DOMやアクセシビリティツリーを見ずスクリーンショットだけで判断してピクセル座標をクリックします。カードが太字で警告している部分があり、マイクロソフトが作ったハーネスの中でのみ使うようにというものです。直接統合すると、サンドボックス化、ドメイン許可リスト、監視モード、緊急停止を自分で実装する責任がユーザーに移ります。機微なものがあるマシンでブラウザ権限を開いたまま動かすなと明示的に書かれています。この種のモデルは性能表よりこの段落を先に読むべきです。

LocateAnything-3BはQwen2.5-3B-Instructをファインチューンした派生版です。ダウンロード71万は、原本系列のリリースでなくても特定の作業にうまく合えば広く使われるという例です。ただしライセンスがotherなので、商用導入前に原文の確認が必要です。

音声 — STTは整理され、TTSはまだ分かれています

音声認識側は実使用の分布がかなり安定しています。

Whisper large-v3-turboが依然として1位です。2024年10月のモデルなのにそうです。新しいモデルを入れるときは置き換える理由が明確でなければなりません。リアルタイムストリーミングが必要ならVoxtralのリアルタイム系列やNVIDIAのストリーミング系列、多言語の幅が必要ならQwen3-ASRやVibeVoice-ASR側です。VibeVoice-ASRのカードの言語一覧には韓国語が含まれています。

parakeet系列はCC BY 4.0なので著作者表示義務が付きます。実務でよく見落とされる条項です。そして先に見たとおり、実使用量はmlx-communityミラー側のほうがはるかに大きいです。

音声合成はさらに分散しています。

Kokoro-82Mは82Mパラメータで1,100万ダウンロードを記録します。この領域でサイズと採用率が反比例することを示す事例です。カードにはこの名前を騙る偽サイトへの警告も一緒に載っています。

OmniVoiceは照会時点でライセンスタグが空でした。ダウンロード85万のモデルなのにそうです。ライセンスがないというのは「自由に使ってよい」ではなく「権利関係が不明確」に近いです。社内利用はともかく、製品に組み込むときはアップロードした人への確認が必要です。OpenRAIL系列はまた別の話で、特定用途を禁じる条項が本文に付いています。法務レビューなしに通せるライセンスではありません。

画像と動画 — ライセンスを何より先に見ます

生成画像・動画領域は他のどの領域よりライセンスのばらつきが大きいです。性能比較よりこれを先に見るべきです。

FLUX.1-devはいいね13,887でこの一覧圧倒的1位ですが、ライセンス名自体が非商用です。アクセス承認も必要です。いいね数と商用利用の可否には何の関係もありません。

Z-Image-Turboはカードによれば6Bパラメータの蒸留モデルで、関数評価8回で画像を生成し、16GB VRAMのコンシューマー機器に収まると書かれています。アパッチ2.0なので制約がもっとも少ないです。ただしこの性能数値は作り手側の自己測定です。

Krea 2系列とLTX-2系列は名前にcommunityが入っていますが、条件付きの自社ライセンスです。Krea側はライセンス本文がPDFでリンクされておりアクセス承認が自動的に掛かっています。この領域は派生LoRAとGGUF変換版がとりわけ多くトレンディングに上がりますが、その派生版のライセンス基準はすべて原本です。

小型・オンデバイス — 3B以下と極低ビット

機器で動かす側は二つの流れに分かれます。最初から小さく作られたモデルと、大きなモデルを極限まで圧縮したものです。

Bonsai-27Bはこの記事の二つの軸が交わる地点です。トレンディング上位でダウンロードが251万ですが、原本ではなくQwen3.6-27Bの量子化再アップロードです。カードが明かした表現は重みあたり実効1.125ビットで、128個の重みごとにFP16スケールをひとつ共有する符号ビット表現です。FP16比で約14.2倍縮小、15個の思考モードベンチマーク平均76.11でFP16比89.5パーセント維持と書かれています。

これらの数字はすべて作り手側の自己測定です。そしてカード自身が指摘している点が興味深いのですが、一般的な低ビットビルドはラベルより実際の平均ビット幅が大きいということです。広く使われているQwen3.6-27Bの「2ビット」ビルドが実際には9.4GBで重みあたり2.8ビットだという例を挙げています。量子化等級の名前をそのまま信じず、ファイルサイズをパラメータ数で割ってみるべきだという話です。量子化形式ごとの違いはGPTQ、AWQ、GGUF量子化の比較に整理してあります。

LFM2.5-350Mのカードは、オンデバイスモデルのカードがどうあるべきかを示しています。パラメータ350M、レイヤー16個、学習予算28兆トークン、コンテキスト32,768、知識カットオフ2024年半ば、そして決定的に「知識集約的な作業とプログラミングには推奨しない」という一文が入っています。作り手が限界を先に書いておくと、導入判断がはるかに速くなります。

小型モデルを自分の作業に合わせることが目的なら、サイズを選ぶ基準はローカルLLM VRAM計算法に、学習手順はQLoRAプロダクションファインチューニングに整理されています。

おわりに — ランキング表ではなく座標を見てください

トレンディング一覧は直近数日の変化率です。何が良いかではなく、何が新しく上がってきたかを示します。だから一覧の上のほうには、上がったばかりのGGUF変換版と、まだ誰も動かしていない750Bモデルが並んで座っています。

実務で必要なのは座標です。このモデルを誰が作ったのか、原本か派生版か、ライセンスが何を禁じているか、そして作り手がカードにどんな限界を書いているか。この四つはどのランキング表にも出てきませんが、すべてモデルカードの最初の画面にあります。次の記事ではそのカードが含む学習パイプラインを解体し、その次の記事ではカードを5分で読む手順を整理します。