メインコンテンツへスキップ

​
モデル名が重要な理由

Hugging Face や Ollama のモデルライブラリを閲覧すると、Qwen/Qwen3-235B-A22B-Instruct や bartowski/Llama-3.3-70B-Instruct-GGUF のような名前を目にします。これらはランダムな文字列ではなく、各セグメントはダウンロード前に判断が必要な情報をエンコードしています。 モデル名は以下のことを教えてくれます：
  • モデルの規模 — つまり、必要な VRAM やシステムメモリの量。
  • 学習目的 — 一般的なチャット、コーディング、推論、ビジョン、または生のテキスト補完。
  • 圧縮方法 — サイズに対してどのような品質のトレードオフがあるか。
  • 製作者 — 重みがオリジナルか、サードパーティによる再パッケージ化か。
これらの慣習を読む方法を5分で学ぶことで、GPU に収まらない 70B モデルをダウンロードしたり、指示に従えないベースモデルで VRAM を無駄にしたりするのを防げます。

​
モデル名の構造

ほとんどのオープンウェイトモデルの名前は以下のパターンに従います：
すべての名前がすべてのセグメントを含むわけではありませんし、公開者は区切り文字を変化させることがあります — 一部はハイフンを使用し、他はスラッシュや何も使用しません。しかし、通常はこれらの部分を識別できます： セグメントごとに解析された実際の例： Qwen/Qwen3-235B-A22B-Instruct mistralai/Mistral-7B-Instruct-v0.3 TheBloke/Llama-2-7B-Chat-GGUF — TheBloke（サードパーティ量子化者）、Llama 2、7B パラメータ、チャットチューニング済み、GGUF 形式。
組織が TheBloke、bartowski、unsloth などのサードパーティ量子化者の場合、モデル自体は他の誰かによって学習されています — リポジトリには、元の重みの再パッケージ化または量子化されたバージョンが含まれています。

​
サイズラベルの解読

モデル名の B の前にある数字は、十億単位のパラメータ数です。これは、能力とメモリ要件の両方の最大の決定要因です。

​
MoE モデル：二つの数字

MoE（mixture-of-experts）モデルは、合計パラメータとアクティブパラメータの両方をリストし、235B-A22B や 30B-A3B のように記述されます：
  • 最初の数字は合計パラメータ数 — メモリまたはディスクに格納するために必要な量。
  • 二番目の数字（A の後）はアクティブパラメータ数 — トークンごとに実行されるパラメータ数。
この 235B-A22B モデルは 235B パラメータを保持するのに十分なメモリが必要ですが、一度に 22B しか計算しないため、デンスな 235B モデルよりもはるかに高速にトークンを生成します。トレードオフ：MoE モデルは、同じアクティブサイズのデンスモデルよりもディスク上およびメモリ上で大きくなりますが、推論は高速です。
この 235B-A22B MoE モデルは、トークンあたりの速度でデンスな 22B モデルに概して匹敵しますが、依然としてすべての 235B パラメータを格納するために VRAM またはシステム RAM が必要です。Q4_K_M では、これは概算 120 GB — デンスな 22B モデルの 13 GB よりもはるかに多いです。

​
パラメータ数が能力にどのようにマッピングされるか

より多くのパラメータは一般的により多くの能力を意味しますが、関係は線形ではありません。70B モデルは 10x 優れているわけではありません（7B モデル比）— 推論、ニュアンス、複雑なタスクで明らかに優れていますが、適切にチューニングされた 7B モデルは依然として日常のチャットや単純なコーディングタスクを適切に処理できます。適切なサイズは、より大きい方が良いというルールだけでなく、ハードウェアとタスクに依存します。

​
アーキテクチャサフィックス

公開者は、ベースモデルを超えたアーキテクチャのバリアントを示すためにサフィックスを付加します。これらは、モデルが何ができるか、およびどのようなハードウェアが必要かに影響します。
つまり、デンスモデルは、すべてのトークンですべてのパラメータを使用します。MoE（mixture-of-experts）モデルは、各トークンを「エキスパート」サブネットワークのサブセットルーティングします。MoE モデルは合計パラメータ数は大きくなりますが、アクティブなパラメータのみが計算するため、トークンあたり高速です。モデル名に二つのサイズ数字（235B-A22B のような）が含まれている場合、それは MoE です。
モデル名の -VL とラベル付けされたモデルは、テキストに加えて画像またはビデオを受け入れます。例：Qwen3-VL-32B-Instruct、gemma-4-12b-it。VL モデルは、言語モデルの重みの上にビジョンエンコーダのために追加の VRAM が必要です。
モデル名が -Coder とラベル付けされたモデルは、主にコードでファインチューニングまたは学習されています。それらは、同じサイズの一般的なモデルよりもプログラミングタスクで通常優れていますが、オープンエンドの会話では弱い場合があります。例：Qwen3-Coder-480B-A35B-Instruct。
モデル名に -Math または推論固有のラベルを持つモデルは、数学的問題解決と思考連鎖データで学習されています。それらは、同じサイズの一般的なモデルよりもステップバイステップの論理で強力ですが、範囲は狭いです。
一部の公開者は、実験的なリリースを next、preview、または experimental とタグ付けします。これらは、不完全な学習または未テストのチャットテンプレートを持つ可能性があります — 評価には有用ですが、本番環境には適していません。

​
学習ステージラベル

学習ステージは、モデルが会話を維持できるか、それともテキストを補完するだけかを示します。これは、モデルが箱から出して使えるかどうかを決定するための最も重要なセグメントです。 Instruct と Chat は、ほとんどの目的で交換可能です — どちらも、モデルがユーザープロンプトに応答するようにファインチューニングされたことを意味します。Chat はより古いラベルです（Llama 2 が使用）；Instruct は新しいファミリーでより一般的です。Mistral のような一部の公開者は、どちらかを使用せず、代わりにベース名と一緒にバージョンタグ（v0.3）に依存します。
ローカル使用の場合、ほぼ常に Instruct または Chat が望ましいです。Base モデルは指示に従えません — テキストを補完するのみ — チャットボットのようにプロンプトを与えると、混乱する出力になります。
学習ステージラベルがなく、Base タグもないモデルを見つけた場合、指示チューニング済みであると仮定する前にモデルカードを確認してください。一部の公開者は、ラベルなしでファインチューニング済みモデルをリリースしますが、他の公開者は、ラベルなしでベースモデルをリリースします。

​
量子化ラベル（GGUF の世界）

GGUF 量子化ラベルは、llama.cpp quantize README で文書化されている命名スキームに従います。Q 数字は、重みあたりのビット数の概算です；高いほど、ファイルが大きく、品質が高くなります。K-クアントは混合精度を追加します — 異なるテンソルが感度に応じて異なるビット幅を取得 — 末尾の S/M/L は、そのレベル内の小/中/大バリアントを示します。 以下は、実践的なガイダンス付きで遭遇する完全な範囲です：

​
実践的なスイートスポット

  • Q4_K_M — ここから始めます。良い品質、コンシューマーハードウェアに収まる。
  • Q5_K_M — VRAM に余裕がある場合にステップアップ。ほとんどのタスクでほぼロスレス。
  • Q8_0 — 最小の損失。品質が重要でメモリが利用可能な場合使用。
  • Q3_K_M — Q4_K_M ではロードできない大きなモデルを収めるためにのみこれを落とします。品質の低下を期待してください。

​
サイズ比較：各量子化での 7B モデル

GGUF クアントのファイルサイズは、重みのための 真の VRAM 数です。その上に KV キャッシュを追加（KV cache and context を参照）して、合計メモリ要件を取得します。

​
I-quants（imatrix）vs K-quants

他にも IQ で始まる量子化名、例えば IQ4_XS や IQ3_XXS も見かけるかもしれません。これらはimatrix クアントで、重要度行列を使用して構築されます：量子化器にどの重みが最も重要かを知らせるキャリブレーションデータ、それによりそれらをより慎重に保存できます。I-クアントは、同じビット幅で、特に非常に低いビット幅で、K-クアントよりも良い品質を生成できますが、量子化プロセスが遅くなるコストがかかります。リポジトリが Q4_K_M と IQ4_M の両方を提供する場合、I-クアントはわずかに良いかもしれませんが、違いは通常どちらでも機能するのに十分小さいです。 量子化がどのように機能し、なぜ K-クアントが単純なクアントよりも優れているかのより深い説明については、Quantization を参照してください。

​
その他の一般的なサフィックス

量子化ラベルを超えて、モデル名には、どのバックエンドがファイルをロードできるかを示す形式と精度タグが含まれます。
この形式は llama.cpp ベースのバックエンド — Ollama、LM Studio、および任意の llama.cpp サーバー — で使用されます。GGUF ファイルは、重み、トークナイザ、チャットテンプレートを 1 つのファイルにバンドルします。ほとんどのコンシューマーハードウェアは GGUF を実行します。
GPU 量子化形式（通常 4 ビットまたは 8 ビット）で、AutoGPTQ または vLLM を通じて NVIDIA GPU で実行されます。GPU で GGUF より高速ですが、NVIDIA 専用で llama.cpp バックエンドと互換性がありません。
アクティベーション認識重み量子化 — GPTQ に似た別の GPU 形式ですが、アクティベーション統計を使用してキャリブレーションされます。vLLM および他の一部の推論エンジンによってサポートされます。NVIDIA GPU。
ExLlamaV2 形式 — 異なるレイヤーが異なるビット幅を使用する混合比率量子化をサポートします。NVIDIA GPU および ExLlamaV2 推論エンジン用に最適化されています。
完全な 16 ビット精度。FP16（float16）と BF16（bfloat16）は、どちらもパラメータあたり 2 バイトです。BF16 はより広い指数範囲を持ち、学習中に数値的に安定しています；推論では、両方とも同様に動作します。vLLM または同様のエンジンが必要です。
8 ビット浮動小数点 — FP16 の半分サイズで最小の品質損失。FP8 をサポートする GPU（NVIDIA Ada Lovelace 以降、AMD MI300）で vLLM および SGLang のような推論エンジンによって使用されます。
NVIDIA の 4 ビット浮動小数点形式、DGX Spark を含む Blackwell GPU で利用可能です。ハードウェアネイティブサポート付きの積極的なサイズ削減を提供 — DGX Spark model compatibility を参照。

​
公開者による量子化 vs サードパーティ

複数の当事者が、同じモデルの量子化バージョンを公開することがよくあります：
  • 公開者クアント — Qwen、Mistral、Google、および他は、ますます完全精度の重みと一緒に独自の GGUF ファイルを提供しています。これらは通常、公開者が元の重みとチャットテンプレートを制御するため、最も安全な選択肢です。
  • Unsloth — 最適化されたチャットテンプレートと動的量子化付きの GGUF クアントを提供します。また、非常に小さい 1.58 ビット（unsloth/...-1.58bit）バリアントも提供します。一般的に信頼性が高く、広く使用されています。
  • TheBloke — GGUF 配布エコシステムを定義するのに役立ったリポジトリを持つ多作な初期量子化者。整理されていますが、最新のモデルに遅れたり、最近のリリースのチャットテンプレート更新を見逃したりする場合があります。
  • bartowski — 一貫した命名と新しいリリースの良いカバレッジを持つアクティブなコミュニティ量子化者。新しいモデルがドロップしたときに、GGUF バリアントを最初に公開するものの一つであることが多いです。

​
サードパーティクアントの確認方法

  1. リポジトリが元のモデルにリンクバックすることを確認します。
  2. ファイルサイズを、その量子化レベルで期待されるものと比較します（上記の表が参照です）。
  3. チャットテンプレートのメタデータを探します — 欠落または誤ったテンプレートは、出力を静かに劣化させます。
  4. 量子化のパープレキシティベンチマークが公開されている場合、それらを公開者自身の数字と比較します。

​
クイック決定ガイド

ハードウェアをモデルサイズと量子化レベルに一致させます：

8 GB VRAM

7B Q4_K_M または 14B Q3_K_M。快適な量子化でより小さなモデルに固執します — 7B の Q4_K_M は 14B の Q2_K より優れています。

16 GB VRAM

14B Q5_K_M または 32B Q4_K_M。14B の Q5 はほぼロスレスです；32B の Q4 は、いくつかの品質を大幅に多くの能力と交換します。

24 GB VRAM

32B Q5_K_M または 70B Q4_K_M。32B の Q5 は、単一 GPU 品質のスイートスポットです。70B の Q4 は能力を高く押し上げますが、VRAM のほとんどを埋めます。

48 GB+

70B Q5_K_M またはオフロード付きの 235B-A22B Q4_K_M のような MoE モデル。最大のモデルの高品質クアントのためのスペースがあります。

128 GB (DGX Spark)

120B+ の MoE モデルを FP8 または NVFP4 で。フロンティアスケールモデルの完全精度またはほぼ完全精度。DGX Spark model compatibility を参照。

CPU only

3B Q4_K_M または 7B Q3_K_M。CPU 推論は遅いです — モデルを小さく保ちます。1–5 トークン毎秒を期待してください。
これらは開始点です。あなたの実際の VRAM 使用量は、コンテキスト長（KV キャッシュはコンテキストとともに成長）、バッチサイズ、およびバックエンドがレイヤーをシステム RAM にオフロードするかどうかにも依存します。正確なサイジングには model fit guide を使用します。

​
命名の赤旗

すべてのモデル名が慣習に従うわけではありませんし、一部のパターンは注意を要します：
  • サイズラベルなし — パラメータ数なしのモデル名は、何でもあり得ます。ダウンロード前にモデルカードを確認します。
  • “Uncensored” バリアント — 通常、安全性学習が削除されただけで、能力の向上ではありません。ベースモデルの品質は、変更されていないか、削除が整列を壊した場合により悪い場合があります。
  • マージモデル — 2 つ以上のモデルの重みを結合（例えば、コーディングモデルをチャットモデルとマージ）。品質は大きく変動し、名前だけでは予測が難しいです。マージ方法（SLERP、DARE、TIES）と、評価結果が公開されているかを探します。
  • 極めて低いクアント — Q2_K は、モデルがロードするかどうかのテストを超えて、ほぼ常に損失が大きすぎます。推論の低下、フォーマットの破損、ハルシネーションを期待してください。モデルが Q2 クアントのみを提供する場合、同じパラメータ数の別のモデルを探します。
  • 変更ログなしのバージョン番号 — バージョン間で何が変わったかの明確な説明なしの v0.1 から v0.9。特定の理由がない限り、最新を使用します。
  • “AWSD” または同様のハイプタグ — 一部のリポジトリは、標準的な技術に対応しない注目を集めるサフィックスを追加します。用語を他の場所で見つけられない場合、懐疑的に扱います。

​
すべてをまとめる

例として unsloth/Qwen3-30B-A3B-Instruct-GGUF を取り上げます。左から右に読んで：
  1. unsloth — Unsloth によって量子化（サードパーティ量子化者）。
  2. Qwen3 — Qwen3 アーキテクチャ、Alibaba からの現在の世代。
  3. 30B-A3B — MoE モデル：合計 30B パラメータ、トークンあたり 3B アクティブ。
  4. Instruct — 指示チューニング済み、チャット準備完了。
  5. GGUF — llama.cpp 形式、Ollama、LM Studio、または任意の llama.cpp バックエンドで実行。
名前だけで、これは高速に実行され、Q4_K_M で 8 GB の VRAM に収まり、指示に従える小さな MoE モデルであることがわかります。試すかどうかを決定するためにモデルカードを開く必要はありません。 次に meta-llama/Llama-3.3-70B-Instruct を比較します。これは Meta の Llama 3.3、70B デンスパラメータ、指示チューニング済み — GGUF タグがないことは、vLLM または同様のエンジンが必要な完全精度の重みを見ていることを意味します。名前は、それは深刻なハードウェアを必要とする大きな、高品質なモデルであることを教えてくれます。

​
次：モデルカードを読む

名前を解読できるようになった今、モデルカード は、名前が省略するすべてを教えてくれます — コンテキスト長、ライセンス、チャットテンプレート、および意図された使用。

Read a model card

ダウンロード前に、重要なパラメータ、アーキテクチャ、コンテキスト長、ライセンスを見つけます。

Quantization

量子化がどのように機能し、なぜ K-クアントが単純なクアントよりも優れているか。

Model fit guide

モデルと量子化の組み合わせがあなたのハードウェアに収まるか確認します。