LLM Model Structure & Model Files

大規模な言語モデルの構造とファイルは、次の 4 つのレベルに分類できます。

Model Architecture
├── Transformer
├── Attention / MLP
├── Position Encoding
└── KV Cache

Model Weights
├── FP32 / FP16 / BF16
└── INT8 / INT4 Quantization

Model Files
├── config.json
├── *.safetensors
├── tokenizer.json
├── tokenizer_config.json
└── generation_config.json

Model Formats
├── Hugging Face Model Directory
└── GGUF

1. Transformer アーキテクチャ

現代の主流の生成テキスト LLM は主に Decoder-only Transformer を使用します。

Input Text
    ↓
Tokenizer → Token IDs
    ↓
Token Embedding
    ↓
Transformer Blocks × N
    ├── RMSNorm / LayerNorm
    ├── Causal Self-Attention
    │   ├── Q / K / V
    │   ├── RoPE
    │   └── KV Cache（推理段階）
    ├── Residual Connection
    ├── MLP / FFN
    └── Residual Connection
    ↓
Final Normalization
    ↓
LM Head
    ↓
Logits
    ↓
Sampling / Decoding Strategy
    ↓
Next Token

アーキテクチャが異なると、正規化位置、MLP 構造、Attention 設計などに違いがあります。

Attention

Attention を使用すると、Token は相関関係に基づいて他の Token に関する情報を取得できます。

• Query (Q): Token が現在探している情報は何ですか?
• Key (K): 現在の Token はどのようなクエリに一致しますか?
• Value (V): Token は現在何を提供していますか?

コアフォーミュラ:

$$\operatorname{Attention}(Q,K,V) =\operatorname{softmax}\left(QK^T d_k^{-1/2}+M\right)V$$

その中には:

• (d_k): Key ベクトル次元。
• (M)：Attention Mask。
• Causal Mask: Token をブロックし、今後の Token に焦点を当てます。

MLP / FFN

Attention は主に Token 間の情報交換を担当します。

MLP は主に各 Token の特徴の非線形変換を担当します。

最新の LLM 一般的な MLP 構造には、SwiGLU などのゲート形式が含まれます。

Residual Connection

残留接続はモジュール入力をモジュール出力に追加し、深いネットワークのトレーニングと情報転送を改善します。

RoPE: 回転位置エンコーディング

Transformer の Attention 自体は Token の位置を直接知りません。

RoPE (Rotary Position Embedding) は位置情報を Q/K にエンコードし、Attention が相対的な位置関係を認識できるようにします。

RoPE は次の概念と密接に関連しています。

• Context Window。
• 長い文脈推論。
• RoPE Scaling。
• KV CacheにおけるKeyの位置。

RoPE は独立したモデル重みファイルではなく、モデル アーキテクチャで定義された位置エンコード メカニズムです。具体的な実装とパラメーターはモデルの構成によって決まります。

2. KV Cache

KV Cache は、自己回帰生成中のコンテキスト全体の再計算を避けるために、Token より前に計算された Key および Value を再利用するために使用されます。

Prefill

Input Prompt
    ↓
Process Prompt Tokens
    ↓
Calculate Attention
    ↓
Generate K / V for Each Layer
    ↓
Store KV Cache
    ↓
Produce Next-token Logits

Prefill は通常、入力 Prompt 全体を処理するため、より多くの並列行列計算が含まれます。

Decode

Current Token
    ↓
Calculate New Q / K / V
    ↓
Read Historical KV Cache
    ↓
Calculate Attention
    ↓
Append New K / V
    ↓
Generate Next Token

Decode は通常、ラウンドごとに新しい Token のみを処理しますが、K/V に対応する履歴コンテキストへのアクセスが必要です。

したがって:

• Prefill は通常、非常に多くの計算を要します。
• Decode は、メモリ帯域幅、KV Cache アクセス、バッチ処理条件の影響を受けることがよくあります。
• KV Cache は、コンテキストの長さが大きくなるにつれて、より多くのメモリを消費します。

後続の世代では Attention を計算するために新しい Query と過去の Key/Value のみが必要となるため、Q は通常キャッシュされません。

3. MHA、MQA、GQA

3 つの主な違いは、Query Head と KV Head の量的な関係です。

GQA は、最新の LLM に見られる一般的な妥協案です。

利点:

• KV Cache の占有率を減らします。
• KV のデータ読み出し量を減らしてください。
• 多くの場合、比較的少ない品質コストで推論効率を改善できます。

たとえば、32 Q Heads と 8 KV Heads です。同じHead寸法のMHAと比較すると、KV Cacheは理論上4分の1に小型化できます。

4. モデルの精度と重み

一般的な数値形式:

浮動小数点構造:

FP32  1 sign + 8 exponent + 23 fraction
FP16  1 sign + 5 exponent + 10 fraction
BF16  1 sign + 8 exponent + 7 fraction

BF16 は FP16 よりもダイナミック レンジが大きくなりますが、仮数精度が低くなります。

モデルの重み推定

理論的には:

$$\text{Weight Memory} \approx \text{Parameter Count}\times \text{Bytes per Parameter}$$

たとえば、7B パラメータ モデル:

上記では 10 進数の GB が使用されていますが、これは理論上の重みのサイズにすぎません。

実際の推論メモリも考慮する必要があります。

Total Memory
≈ Model Weights
+ KV Cache
+ Temporary Activations
+ Runtime Buffers
+ Framework Overhead

したがって、7B INT4 モデルは、3.5 GB のメモリだけで正常に動作するとは限りません。

5. Quantization: 量子化

量子化とは、モデルのメモリ使用量とデータ送信コストを削減するために、高精度の値を低精度の表現にマッピングすることです。

たとえば:

Weights:       INT4
Activations:   FP16 / BF16
KV Cache:      FP16 / BF16
Accumulation:  FP16 / FP32 待ってください

量子化は、モデル内のすべての計算で INT4 が使用されることを意味するわけではありません。

実際の演算精度は推論エンジンGPU Kernelと量子化方式に依存します。

Scale および Zero Point

一般的な線形量子化は次のように表現できます。

$$x \approx s(q-z)$$

その中には:

• (x): 生の浮動小数点数。
• (q): 量子化された整数。
• (s)：Scale。
• (z)：Zero Point。

これらの補助パラメータも保存する必要があるため、実際の低ビット モデルのサイズは、通常、理論上のパラメータ数 × ビット幅よりも大きくなります。

量子化の粒度

Per-group Quantization は、他の重みに対する極端な値の影響を軽減できますが、メタデータと実装の複雑さは増加します。

PTQ および QAT

PTQ（Post-Training Quantization）

モデルのトレーニングが完了した後に量子化するため、モデル全体を再トレーニングする必要はありません。

QAT（Quantization-Aware Training）

量子化エラーはトレーニング中にシミュレートされ、モデルが低精度の表現に適応できるようになります。通常、トレーニング更新プロセスでは高精度のパラメーターと勾配が維持されます。

一般的な量子化アルゴリズム

GPTQ、AWQ、および SmoothQuant はすべて、典型的な PTQ 技術ルートに属しますが、適用可能な量子化スキームはまったく同じではありません。

以下を区別することも必要です。

• Weight-only Quantization: 主に数値化された重み。
• Weight + Activation Quantization: 重みと活性化値の両方が量子化されます。
• KV Cache Quantization：KV Cache単体の記憶精度を下げます。

6. Hugging Face モデルディレクトリ

代表的なモデルカタログ：

model/
├── config.json
├── model.safetensors
├── model.safetensors.index.json
├── tokenizer.json
├── tokenizer_config.json
├── special_tokens_map.json
└── generation_config.json

実際のモデルにはすべてのファイルが含まれていない可能性があります。大規模なモデルでは、ウェイトが複数の .safetensors ファイルに分割されることがよくあります。

config.json

モデルのアーキテクチャと構造パラメータについて説明します。

例 (説明のみを目的としており、実際のフィールドはモデルによって異なります):

{
  "architectures": ["LlamaForCausalLM"],
  "hidden_size": 4096,
  "intermediate_size": 14336,
  "num_hidden_layers": 32,
  "num_attention_heads": 32,
  "num_key_value_heads": 8,
  "vocab_size": 128256,
  "max_position_embeddings": 131072,
  "torch_dtype": "bfloat16"
}

重要なフィールド:

max_position_embeddings は、モデルが実際にデプロイされるときに確実に使用できるコンテキスト長と必ずしも一致するわけではなく、モデルのトレーニングと推論エンジンの構成にも影響されます。

*.safetensors

モデルの Tensor 重みを保存します。例:

model.embed_tokens.weight
model.layers.0.self_attn.q_proj.weight
model.layers.0.self_attn.k_proj.weight
model.layers.0.self_attn.v_proj.weight
model.layers.0.self_attn.o_proj.weight
model.layers.0.mlp.gate_proj.weight
model.norm.weight
lm_head.weight

safetensors は、モデル アーキテクチャ全体を定義するのではなく、主に Tensor を安全かつ効率的に保存するために使用されます。

model.safetensors.index.json

大きなモデルの重みはシャードに保存できます。

model-00001-of-00004.safetensors
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors

Index ファイルには、各重み Tensor に対応するシャードが記録されます。

{
  "metadata": {
    "total_size": 14000000000
  },
  "weight_map": {
    "model.layers.0.self_attn.q_proj.weight": "model-00001-of-00004.safetensors"
  }
}

7. Tokenizer

Tokenizer は、テキストを Token ID に変換し、Token ID をテキストにデコードする役割を果たします。

Text
  ↓
Tokenizer
  ↓
Token IDs
  ↓
Embedding
  ↓
Transformer

一般的な単語分割アルゴリズム:

• BPE。
• Unigram。
• WordPiece。

tokenizer.json には次のものを含めることができます。

Vocabulary
Normalizer
Pre-tokenizer
Tokenization Model
Post-processor
Decoder

Tokenizer はモデル語彙および Embedding と強く関連しており、自由に置き換えることはできません。

tokenizer_config.json

Tokenizer の使用構成について説明します。Chat Template が含まれる場合があります。

{
  "model_max_length": 131072,
  "padding_side": "left",
  "chat_template": "..."
}

Chat Template

Chat Template メッセージの役割とコンテンツを、モデルのトレーニング時に使用される入力形式に変換します。

たとえば:

<|im_start|>system
You are a helpful assistant.
<|im_end|>
<|im_start|>user
Hello
<|im_end|>
<|im_start|>assistant

実際のテンプレートはモデルによって異なります。

Chat Template は非常に重要です。重みと Tokenizer が正しい場合でも、入力メッセージの形式が一致しない場合、モデルの出力品質が低下する可能性があります。

8. Special Tokens

共通 Special Tokens:

たとえば:

<s>
</s>
<|im_start|>
<|im_end|>
<|eot_id|>

モデルごとに異なる Special Token システムが使用されており、これらのマーカーがモデル間で共通であるとは想定できません。

9. generation_config.json

モデルがテキストを生成するときにデフォルトのパラメーターを構成するために使用されます。

たとえば:

{
  "do_sample": true,
  "temperature": 0.7,
  "top_p": 0.9,
  "eos_token_id": 2
}

共通パラメータ:

基本的なプロセス:

LM Head
    ↓
Logits
    ↓
Logits Processing
    ↓
Sampling / Greedy Decoding
    ↓
Next Token ID

生成されたパラメータはモデルの重みを変更しませんが、Token の選択戦略にのみ影響します。

10. GGUFとSafetensors

GGUF は、llama.cpp / ggml エコシステムで使用されるモデル ファイル形式であり、ローカルの量子化推論によく使用されます。

GGUF 量子化タイプ

llama.cpp エコシステムには次のものが表示されます。

F16
Q8_0
Q4_0
Q4_K_M
Q5_K_M

これらの名前は、さまざまなストレージおよび量子化スキームを表します。

たとえば、Q4_K_M は、すべてのパラメータが厳密に 4 bit として保存されることを意味するわけではありません。実際の平均ビット幅と量子化グループ化方法はフォーマット定義によって異なります。

Ollama

Ollama のローカル推論機能は主に llama.cpp 関連テクノロジー エコシステムに基づいて構築されており、一般的なモデルは GGUF または互換モデルのリソースを使用します。

しかし、それは区別する必要があります。

Model Architecture
        ↓
Model Weights
        ↓
Model File Format
        ↓
Inference Engine
        ↓
Model Serving API

たとえば:

Llama Architecture
        ↓
Quantized Weights
        ↓
GGUF
        ↓
llama.cpp / Ollama
        ↓
HTTP API

GGUF はファイル形式、llama.cpp は推論実装、Ollama はモデル管理およびサービス機能を提供します。

概要

モデルの構造とファイルを理解します。主に以下をマスターします。

最も重要な関係:

config.json       → モデル構造
*.safetensors     → モデルの重み
tokenizer.json    → テキストと Token ID 変換
tokenizer_config  → Tokenizer 行動と Chat Template
generation_config → デフォルトのビルドパラメータ
GGUF              → もう 1 つの一般的な推論モデル ファイル形式

これらを理解すると、メモリ使用量、モデルの読み込み、推論エンジン、デプロイメントのパフォーマンスをさらに調査できるようになります。

---

参考資料

• Hugging Face Transformers
• Hugging Face KV Cache
• Hugging Face Quantization
• Safetensors
• GGUF Format
• llama.cpp