第4章. モデルファイル形式の基本
この章の目的
この章では、LLM（大規模言語モデル）を扱う上で頻繁に目にする「モデルファイル形式」について、その種類と特徴、そしてそれぞれの使い分けを理解することを目的とします。特に「GGUFって何？ safetensorsって何？」といった疑問を解消し、それぞれのファイル形式がどのような役割を果たしているのかを整理します。
この章で覚えるべきこと
safetensors、PyTorch checkpoint、GGUF、ONNX、TensorRT engine、MLX formatといった主要なモデルファイル形式の概要と特徴- 各ファイル形式がどのような目的で利用されるのか
safetensorsとGGUFの違い、GGUFとモデルアーキテクチャの関係性- 量子化されたモデルファイルがどのように生成され、利用されるのか
導入
LLMをダウンロードしたり推論を実行したりする際、様々な拡張子を持つファイルに遭遇します。.safetensors、.bin、.gguf、.onnxなど、これらはすべてモデルの「重み（weights）」や「構造（architecture）」、あるいはその両方を保存するためのファイル形式です。しかし、それぞれの形式がどのような特徴を持ち、どのような場面で使われるのか、初心者にとっては混乱しやすいポイントです。
例えば、Hugging Face Hubでモデルを探すと、同じモデル名でも複数のファイル形式が提供されていることがあります。どのファイルを選べば良いのか、なぜ複数の形式が存在するのか、といった疑問が生じます。この章では、これらの疑問に答え、各ファイル形式の役割と利用シーンを明確にしていきます。
モデルファイル形式の選択フロー
LLMのモデルファイル形式は、その利用目的や実行環境によって最適なものが異なります。以下のフローチャートは、一般的な選択プロセスを示しています。
graph TD
A[LLMモデルの利用目的は？] --> B{"学習済みモデルの配布/推論？"}
B -- はい --> C{セキュリティと高速ロードが最優先？}
C -- はい --> D[safetensors]
C -- いいえ --> E{"PyTorchで学習再開/開発？"}
E -- はい --> F[PyTorch checkpoint]
E -- いいえ --> G{"CPU/統合GPUで効率的な推論？"}
G -- はい --> H[GGUF]
G -- いいえ --> I{"異なるフレームワーク間で交換/汎用推論？"}
I -- はい --> J[ONNX]
I -- いいえ --> K{NVIDIA GPUで最高速推論？}
K -- はい --> L[TensorRT engine]
K -- いいえ --> M{Apple Siliconで最適化推論？}
M -- はい --> N[MLX format]
M -- いいえ --> O[その他/特殊な要件]
基本概念
LLMのモデルファイルは、主に以下の要素を保存しています。
- モデルの重み（Weights）: ニューラルネットワークの各層における数値パラメータ。これがモデルの学習済み知識を構成します。
- モデルのアーキテクチャ（Architecture）: モデルの層の構成、接続方法、活性化関数など、ネットワークの構造を定義する情報。
- メタデータ（Metadata）: モデルに関する追加情報（例えば、学習時の設定、トークナイザの情報、ライセンスなど）。
これらの要素をどのように保存するかによって、様々なファイル形式が生まれます。
モデルの構成要素
モデルファイルは、これらの要素をどのようにパッケージ化するかによって異なります。
graph TD
A[LLMモデル] --> B(モデルの重み)
A --> C(モデルのアーキテクチャ)
A --> D(メタデータ)
subgraph "ファイル形式の例"
B
safetensors
B
C
D
GGUF
B
C
ONNX
end
safetensors
ひとことで言うと: 安全かつ高速にモデルの重みを読み込むためのファイル形式。
何のカテゴリか: モデルの重み保存形式
何に使うのか: PyTorchなどのフレームワークで学習されたモデルの重みを、セキュリティリスクなく効率的にロードするために使用。
代表例: Hugging Face Hubで提供される多くのLLMモデルの重みファイル（例: model.safetensors）
よく混同される用語: GGUF, PyTorch checkpoint
初心者向け注意点: safetensorsファイル自体にはモデルのアーキテクチャ情報は含まれていません。通常、設定ファイル（例: config.json）やモデル定義コード（例: modeling_*.py）と組み合わせて使用します。
safetensorsは、悪意のあるコードの実行リスクを排除しつつ、高速にテンソル（重み）を読み込むことを目的として開発されました。従来のPyTorchのpickleベースの保存形式（.binや.pt）は、柔軟性がある一方で、任意のPythonコードを実行できるためセキュリティ上の懸念がありました。safetensorsは、テンソルデータとシンプルなメタデータのみを保存するように設計されており、この問題を解決します。
PyTorch checkpoint
ひとことで言うと: PyTorchモデルの重みや学習状態を保存する標準的な形式。
何のカテゴリか: PyTorchフレームワーク固有のモデル保存形式
何に使うのか: PyTorchで学習したモデルの重み、オプティマイザの状態、学習の進行状況などを保存し、学習の再開や推論に利用。
代表例: pytorch_model.bin, model.pt
よく混同される用語: safetensors
初心者向け注意点: pickle形式を使用しているため、信頼できないソースからのファイルをロードする際にはセキュリティリスクが伴います。Hugging Faceはsafetensorsへの移行を推奨しています。
PyTorch checkpointは、Pythonのpickleモジュールを使用してモデルのstate_dict（重みの辞書）やその他のオブジェクトをシリアライズします。これにより、モデルの重みだけでなく、オプティマイザの状態や学習率スケジューラなど、学習に必要なあらゆる情報を保存できます。
safetensors と PyTorch checkpoint の比較
| 特徴 | safetensors | PyTorch checkpoint (.bin, .pt) |
|---|---|---|
| セキュリティ | 安全 (任意のコード実行リスクなし) | リスクあり (pickleによる任意のコード実行) |
| 柔軟性 | 低い (テンソルとメタデータのみ) | 高い (Pythonオブジェクト全般を保存可能) |
| ロード速度 | 高速 | やや遅い (pickleのデシリアライズ) |
| 用途 | 主に推論時のモデル重み配布 | 学習状態の保存、学習の再開 |
| 推奨 | モデルの公開・配布にはこちらが推奨される | 信頼できる環境での学習・開発向け |
GGUF
ひとことで言うと: CPUでの効率的な推論に特化した、モデルの重みとアーキテクチャ、トークナイザを統合したファイル形式。
何のカテゴリか: CPU推論向けモデルファイル形式
何に使うのか: 量子化されたLLMを、CPUや統合GPUなど限られたリソースの環境で高速に推論するために使用。
代表例: llama-2-7b-chat.Q4_K_M.gguf
よく混同される用語: safetensors, model architecture, quantization
初心者向け注意点: GGUFファイルは、特定の推論エンジン（例: llama.cpp）で使用されることを前提としています。Hugging Face Transformersライブラリのような汎用的なフレームワークで直接ロードすることはできません。
GGUFは、llama.cppプロジェクトによって開発されたファイル形式で、主にCPUでのLLM推論を最適化するために設計されています。モデルの重みだけでなく、モデルのアーキテクチャ情報、トークナイザ、そして量子化に関するメタデータも単一ファイルに統合されています。これにより、推論時に必要なすべての情報が揃い、効率的なロードと実行が可能になります。特に、量子化されたモデルの重みを効率的に格納し、CPUでのメモリ効率と計算速度を最大化するよう設計されています。
GGUF と safetensors の比較
| 特徴 | GGUF | safetensors |
|---|---|---|
| 目的 | CPU/統合GPUでの効率的な推論 (llama.cpp向け) | 安全かつ高速なモデル重みロード (汎用) |
| 内容 | 重み、アーキテクチャ、トークナイザ、メタデータ | 重み、シンプルなメタデータ |
| 汎用性 | 低い (llama.cppエコシステムに特化) | 高い (PyTorchなどのフレームワークで利用可能) |
| 量子化 | 量子化されたモデルの格納に最適化 | 量子化された重みも格納可能だが、形式自体は量子化に特化していない |
| ファイル数 | 通常1ファイルで完結 | 重みファイルと設定ファイル（config.jsonなど）が別途必要 |
ONNX (Open Neural Network Exchange)
ひとことで言うと: 異なるフレームワーク間でモデルを交換するためのオープンな標準形式。
何のカテゴリか: モデル交換フォーマット
何に使うのか: PyTorchやTensorFlowなどで学習したモデルを、ONNX Runtimeなどの推論エンジンや、他のフレームワークに変換して利用するために使用。
代表例: model.onnx
よく混同される用語: 特定のフレームワーク固有の形式（PyTorch checkpoint, TensorFlow SavedModel）
初心者向け注意点: ONNXはモデルのグラフ構造と重みを保存しますが、元のフレームワークのすべての操作をサポートしているわけではありません。複雑なモデルでは変換に工夫が必要な場合があります。
ONNXは、ニューラルネットワークモデルを表現するためのオープンソース形式です。これにより、開発者は任意のフレームワークでモデルを学習し、ONNX形式にエクスポートすることで、別のフレームワークや推論エンジンで利用できるようになります。特に、エッジデバイスや組み込みシステムでの推論最適化において重要な役割を果たします。
TensorRT engine
ひとことで言うと: NVIDIA GPU上での推論を最大限に高速化するために最適化されたモデル形式。
何のカテゴリか: NVIDIA GPU向け推論最適化形式
何に使うのか: NVIDIA GPU環境で、LLMを含む深層学習モデルの推論レイテンシとスループットを極限まで高めるために使用。
代表例: model.engine
よく混同される用語: ONNX (ONNXからTensorRT engineを生成することが多い)
初心者向け注意点: 特定のGPUアーキテクチャとCUDAバージョンに強く依存するため、異なる環境間での互換性はありません。再生成が必要です。
TensorRTは、NVIDIAが提供する高性能な深層学習推論最適化SDKです。TensorRT engineファイルは、特定のNVIDIA GPU上で動作するように、モデルのグラフ構造を最適化し、量子化やカーネル融合などの技術を適用した結果生成されます。これにより、GPUの性能を最大限に引き出し、推論速度を大幅に向上させることができます。
MLX format
ひとことで言うと: Apple Silicon（Mシリーズチップ）に最適化されたモデル形式。
何のカテゴリか: Apple Silicon向けモデル形式
何に使うのか: Apple Silicon搭載Macで、LLMを効率的に推論するために使用。
代表例: model.mlx
よく混同される用語: GGUF (どちらも特定のハードウェアに最適化されている点)
初心者向け注意点: Apple Silicon以外の環境では利用できません。
MLXは、Appleが開発した機械学習フレームワークであり、Apple Siliconの高性能なニューラルエンジンを最大限に活用するように設計されています。MLX formatは、このフレームワークで利用されるモデルの保存形式で、Apple Silicon上での推論性能を最適化します。具体的には、Apple Siliconの統合メモリアーキテクチャを最大限に活用し、CPUとGPU間でデータ転送のオーバーヘッドを最小限に抑えることで、メモリ効率と推論速度を向上させています。
quantized model file (量子化されたモデルファイル)
ひとことで言うと: モデルの重みを低精度（例: 16ビット浮動小数点数から4ビット整数）に変換し、ファイルサイズとメモリ使用量を削減したファイル。
何のカテゴリか: モデルの重み表現形式
何に使うのか: メモリや計算リソースが限られた環境（例: CPU、エッジデバイス）で、LLMを動作させるために使用。
代表例: model.Q4_K_M.gguf, model_quantized.safetensors
よく混同される用語: 量子化されていない通常のモデルファイル
初心者向け注意点: 量子化はモデルの精度をわずかに低下させる可能性があります。どの量子化レベルが自分の用途に最適か、試行錯誤が必要です。
量子化は、モデルの重みを表現するのに必要なビット数を減らす技術です。例えば、通常32ビット浮動小数点数で表現される重みを、16ビット浮動小数点数や8ビット整数、さらには4ビット整数に変換します。これにより、モデルのファイルサイズが大幅に削減され、メモリ使用量も減るため、限られたリソースの環境でもLLMを動作させることが可能になります。GGUFファイルは、量子化されたモデルを保存するための主要な形式の一つです。
量子化によるメモリ削減の例
モデルの重みが$N$個あり、それぞれが$B_{original}$ビットで表現されている場合、元のモデルのメモリサイズは$N \times B_{original}$です。 量子化により、各重みが$B_{quantized}$ビットで表現されるようになると、量子化後のモデルのメモリサイズは$N \times B_{quantized}$となります。 このとき、メモリ削減率は以下の式で表せます。
$$ \text{Memory Reduction Ratio} = \frac{N \times B_{original} - N \times B_{quantized}}{N \times B_{original}} = 1 - \frac{B_{quantized}}{B_{original}} $$
例えば、32ビット浮動小数点数（FP32）から4ビット整数（INT4）に量子化する場合、$B_{original}=32$, $B_{quantized}=4$なので、メモリ削減率は$1 - \frac{4}{32} = 1 - \frac{1}{8} = \frac{7}{8} = 87.5%$となります。これは、モデルのメモリ使用量が元の1/8になることを意味します。
具体例
Hugging Face Hubでmistralai/Mistral-7B-Instruct-v0.2モデルを見てみましょう。
| ファイル名 | 形式 | 説明