モデルファイルフォーマット

モデルのリリースは1つのファイルではない。エンジンごとに再パッケージされるチェックポイントだ。このページはローカルで実際に出会うフォーマットの地図。llama.cpp界隈のGGUF、PyTorch/HFスタックのsafetensors、エンジン固有のGPU量子化、エッジランタイムのONNX。先にエンジンを選べ。フォーマットは後から付いてくる。

GGUF:1ファイルにすべて

.ggufファイルは、モデル重み、トークナイザ語彙、チャットテンプレート、テンソルごとのメタデータを1つのバイナリに詰める。ダウンロード1回、設定ゼロで、GGUFを話すすべてのアプリが同じファイルを動かす。llama.cppとllama-server、Ollama、LM Studio、Jan、KoboldCpp。フォーマットはメモリマップ可能なので、重みはディスクからページごとにストリームされる——起動は速く、OSのページキャッシュが無料でキャッシュを引き受ける。

Qwen3-8B-Q4_K_M.ggufのファイル名解剖、フィールドごと。

ロードせずにGGUFを検査。

python gguf-py/gguf/scripts/gguf_dump.py model.gguf

general.architecture     : qwen3
general.name             : Qwen3 8B
qwen3.context_length     : 32768
tokenizer.ggml.model     : gpt2 (BPE)
tokenizer.chat_template  : {%- ... a Jinja template ... %}

このメタデータブロックがあるから、GGUFは5つの異なるアプリで「そのまま動く」。エンジンはアーキテクチャを読み、グラフを構築し、トークナイザをロードし、チャットフロントエンドは埋め込みテンプレートを適用する。設定探索なし、語彙の不一致なし、トークナイザの別ダウンロードなし。

safetensors:Hugging Faceの標準

safetensorsは意図的に退屈なコンテナ。テンソル名、形状、dtypeのJSONヘッダに生バイトが続く。格納するのはテンソルだけ——盲目的にロードするには危険なpickle風味の.binチェックポイントと違って実行コードなし——で、ゼロコピーmmapをサポートする。PyTorchの起動が速い理由。Transformers、vLLM、SGLang、TRL、ファインチューニングのエコシステム全体がネイティブで話す。

テンソルしか格納しないので、動くモデルはリポジトリディレクトリ全体。

model-00001-of-00004.safetensors   ← 重みシャード(各約5 GB)
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors
model.safetensors.index.json        ← シャードマップ: テンソル名 → シャードファイル
config.json                         ← アーキテクチャ+ハイパーパラメータ
generation_config.json              ← デフォルトのサンプリング設定
tokenizer.json                      ← トークナイザ本体
tokenizer_config.json               ← チャットテンプレートはここ

シャーディングが存在するのは、70B FP16チェックポイントが約140 GBだから。1ファイルでは管理不能。vLLMでサーブするなら全シャードをダウンロードする。safetensorsリリースに「4ビットファイルだけ」の近道はない。量子化サービングは別リポジトリ(同じモデルのAWQまたはGPTQ派生)。

エンジン固有のGPU量子化:AWQ、GPTQ、EXL2

これらのフォーマットはGPU推論サーバのために存在する。そこではファイルの利便性よりスループットが重要。

• AWQ——活性化を考慮した量子化。キャリブレーションプロンプトで、活性化が最も依存する重みチャネルの約1%を見つけ、それには保護されたスケーリングを、残りは4ビットへ。高速カーネルで4ビットのほぼ元通り品質。vLLMのデフォルト4ビット選択。
• GPTQ——古典的GPU量子化。optimal brain量子化の子孫。レイヤーごとに量子化し、各レイヤーの誤差を未量子化重みに対して補償する。4ビット、GPU専用カーネル、サービング構成のあらゆる場所に今も存在。
• EXL2——exllamav2の、重みあたりビット数が可変のフォーマット。2〜8ビットテンソルを混ぜて、合計がVRAM上限のちょうど下に着地するよう、1つのリポジトリをたとえば4.65 bpwに置ける。Q4が収まらずQ3では痛いときの道具。

3つすべてにキャリブレーションデータと一回の変換実行が必要で、どれもCPUでは動かない。

ONNX、MLX、生FP16/BF16

ONNXはポータブルな計算グラフフォーマット。transformersモデルを一度エクスポートすれば、onnxruntimeが動くどこでも実行できる——CUDAなしのWindowsマシン、スマホ、ブラウザのWebGPUデモ。onnxruntimeはグラフをCPU用にINT8へ量子化もできる。支払うのはセットアップの摩擦としばしばピーク速度。得るのはPyTorchスタックのないマシンへの移植性。エッジと組み込みが主戦場で、デスクトップチャットではない。

MLXはApple Silicon向けのAppleの配列フレームワーク。mlx-community orgが主要リリースの大半をMLXフォーマットに再パッケージする。4ビットと8ビットを含む。mlx-lmを動かすMシリーズMacでは、それがあなたのフォーマット——Apple Siliconを参照。

生FP16/BF16チェックポイントが重要なのは、無劣化の参照、ファインチューニングのベース、変換ソースが欲しいとき。BF16はFP32の8ビット指数範囲を保ち、その代わりに仮数ビットを差し出す——学習ではFP16よりはるかに安定、重みあたり2バイトは同じ。FP16/BF16の7〜8Bモデルは、コンテキストを数える前に重みだけで約16 GB。

どのエンジンにどのフォーマット

フォーマットの混在が典型的な初心者の過ち。vLLMに.ggufを、llama.cppにsafetensorsシャードを向けること。どちらも動かない——エンジンはエラーを出すか、先に変換ステップを必要とする。

変換パス

Hugging Faceリポジトリからローカルファイルへの標準経路は2ステップ。チェックポイントを16ビットGGUFに変換し、それから量子化して下げる。

git clone https://github.com/ggerganov/llama.cpp
pip install -r llama.cpp/requirements.txt

# 1. HFチェックポイント(safetensors)をGGUFに変換
python llama.cpp/convert_hf_to_gguf.py ./Qwen3-8B --outtype bf16 --outfile qwen3-8b-bf16.gguf

# 2. 目標サイズへ量子化
llama-quantize qwen3-8b-bf16.gguf qwen3-8b-Q4_K_M.gguf Q4_K_M

実践では自分で変換することはまれ。bartowskiやmradermacherのような量子化者が、注目リリースのすべてのサイズを数時間で公開する。自分で変換するのは、プライベートなファインチューニングがある、imatrixキャリブレーション済みI-quantが欲しい、非標準のビット目標が必要なとき——詳細は量子化。

エンベディングモデル——RAGの検索側の半分——は同じフォーマットで出荷される。llama.cppのエンベディングエンドポイントにはGGUF、sentence-transformersにはsafetensors。上のすべてと同じルール。実際に動かすエンジンにフォーマットを合わせること。

関連: 量子化 · モデルファミリー · エンジン · RAG