Q4_K_M、INT4、FP8 — 使用されるビット数やそのパッキング方法で、量子化の解説で詳しく説明されている）。もう一つは量子化フォーマット（GGUF、AWQ、NVFP4 — ファイルフォーマットや実行時に利用されるカーネルで、どのハードウェアで読み込めるかを決定する）。本ページでは後者の要素に焦点を当てており、下記の表から任意の行を選ぶだけで必要なハードウェアが分かる。
対応表
† vLLMが公開しているハードウェア対応表では、AWQは別途用意されたコードパスを通じてx86やArm CPUでも利用可能と記載されているがGPTQについてはそうではない。実際には両者ともGPU向けフォーマットとして扱うべきだ。 ‡ vLLMの互換性表では、特にvLLM上でAWQおよびGPTQがAMD GPUでは非対応と記載されている。これはvLLMランタイム側の制限であり、すべてのAWQ/GPTQカーネルがどこでも利用不可であることを意味しない。 § ブラックウェル以前のNVIDIA GPUにはNVFP4に必要なTensor Core機能が備わっておらず、これはドライバーのみの問題ではない。 ** MLXの主要なPyPIパッケージはApple SiliconおよびmacOS向けだが、プロジェクト側ではフレームワーク自体用の実験的なLinux向けCUDAバックエンドも提供している。ただしHugging Faceで入手可能なMLX量子化済みモデルファイルはApple Metal用に構築されている。
上記の各記述の出典は以下の注釈欄に記載されている。
各フォーマットに関する補足説明
GGUF — 汎用性に優れた標準フォーマット
GGUFはllama.cppが採用するモデルフォーマットであり、OllamaやLM Studioでも内部で使用されている。このフォーマットはCPU、Apple Metal、NVIDIA CUDA、AMD ROCm（HIP経由）、Vulkanでも動作する。llama.cppの公式ビルドドキュメントにはこれらすべてのバックエンド向けのビルドターゲットが記載されており、そのためGGUFは一般向けハードウェアにおいて最も汎用性の高いフォーマットだ。ご自身の利用環境がどのバックエンドをサポートしているか不明な場合は、GGUFが安全な選択肢となる。詳細は llama.cpp および GGUF仕様 を参照されたい。
bf16 / FP16 — ベースラインとなる形式
bf16 and FP16 store each parameter in 2 bytes with no compression. This is the precision quantization compresses from — every Q4, AWQ, or NVFP4 file is a smaller, lossier version of a bf16/FP16 original. Treat support as framework-dependent: CUDA and ROCm serving stacks commonly support these precisions when you have enough memory, while CPU, Metal, and Vulkan paths depend on the runtime and are often impractical for large models. At roughly 4x the footprint of a 4-bit quantization, bf16/FP16 is rarely what you run locally on consumer hardware. See GPU-to-model fit for the memory math.
AWQおよびGPTQ — GPU向けでvLLMが採用する形式
AWQとGPTQはGPU推論向けに設計された4ビット量子化形式であり、vLLMは両形式のサポートを文書化し維持している実行環境です。vLLMのハードウェア互換性表によれば、両形式はNVIDIA製GPU（Volta世代からHopper世代まで、GPTQはVoltaでも利用可能）で動作しますが、AMD製GPUではいずれもサポート対象外です。特定の実行環境で別の対応が確認されていない限り、これらはNVIDIA/CUDA向けの形式と見なすべきです。vLLMの量子化関連ドキュメントも参照してください。
MXFP4 — gpt-ossのネイティブ形式
MXFP4はOpen Compute Projectが定めるマイクロスケーリング方式の4ビット浮動小数点形式であり、OpenAIがgpt-ossを配布する際に採用したネイティブ形式です。gpt-oss-120bおよびgpt-oss-20bモデルはHugging Face上でMXFP4形式に事前量子化された状態で配布されており、これにより120bは約80GB、20bは約16GBのメモリ消費量で実行可能となっています。llama.cppもgpt-oss向けにMXFP4形式のネイティブサポートを実装しており、vLLMも同様にサポートしています。OpenAI — gpt-ossの紹介および llama.cppのgpt-oss対応情報もご覧ください。
NVFP4 — Blackwell専用形式
NVFP4 is NVIDIA’s own 4-bit floating-point format, purpose-built for the fifth-generation Tensor Cores in the Blackwell architecture (RTX 50 series consumer cards and Blackwell-generation datacenter GPUs). NVIDIA’s own technical blog describes NVFP4 as a Blackwell Tensor Core format using a two-level scaling scheme, and positions it alongside MXFP4 and FP4 as the three 4-bit formats Blackwell’s Tensor Cores support natively. If your GPU predates Blackwell, NVFP4 isn’t the format for you — look for a GGUF, AWQ, or GPTQ build of the same model instead. See NVIDIA — Introducing NVFP4.
Hugging Face上の多くの
NVFP4関連リポジトリは nvidia/ 組織名下に存在します（例えば...-NVFP4接尾辞を持つモデルなど）。この命名規則は、ネイティブな高速処理を得るにはBlackwell世代のハードウェアが必要であることを示唆しています。古い世代のGPUをお使いの場合は、モデルをダウンロードする前に必ずモデル説明ページを確認してください。MLX — Apple Silicon向けフレームワーク
MLXはApple製の配列処理フレームワークで、CPUとGPU間で共有される統合メモリモデルを基盤としています。MLXビット量子化版モデルは、LM Studioや他のMac向けツールがGGUF形式と並んで提供しているもので、macOS 14以降で動作するApple Silicon向けです。このプロジェクトのインストールガイドではApple Silicon＋macOSが主要なサポート対象環境とされています（モデルファイルはMLX形式で配布されますが、フレームワーク自体にはLinux/CUDA向けの実験的バックエンドも存在します）。Macをお使いでない場合、MLXは選択肢になりません。代わりにGGUFをご利用ください。GitHub上のMLXおよび MLXインストールガイドも参照してください。
どの形式を選ぶべきか？
まずは既にお持ちのハードウェアに合った形式を選び、その逆ではない。- NVIDIA製の一般向けグラフィックカード（RTX 40/30シリーズまたはブラックウェル世代以前のカード） — 最も簡単な選択肢としては
GGUFを利用すべきだ（OllamaやLM Studio向け）。GPUネイティブカーネルによる高い処理能力を求める場合はAWQやGPTQも選択可能。 - NVIDIAブラックウェル世代製品（RTX 50シリーズまたはブラックウェルデータセンター向けGPU） — 上記の形式もすべて利用可能だが、アップストリームモデルIDごとに公開されている
NVFP4形式を選ぶのが望ましい。これがTensorコア向けに最適化された形式だからだ。 - Apple Silicon —
GGUF（Metal経由）が最も簡単かつ一般的な選択肢だ。またMLXはMac専用の代替形式であり、LM StudioなどのツールではGGUFと並行して利用できる。 - AMD GPU —
GGUFを通じてROCmまたはVulkanを利用可能。ただしAMDにおけるAWQ/GPTQのサポートは実行環境ごとに一貫性がないため、これを前提とした計画は立てない方が良い。 - CPUのみ —
GGUFが該当する。この形式のみが実際にCPUでの推論をサポートしており、llama.cppやOllama、LM Studioもこの形式を基盤としている。
Q4_K_M vs Q8_0, for example), see Quantization explained. For sizing a specific model against your VRAM, see GPU-to-model fit.
安定したエンドポイントとして利用可能にする
量子化済みモデルがローカル環境で問題なく動作すれば、その形式が何であれTokiosは動作方法を変更しない。どこからでも同じローカルデプロイにアクセスできる、認証機能付きの安定したAPIエンドポイントを提供するのだ。