LLM Model Structure & Model Files

大语言模型的结构和文件可以分为四个层次：

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 随上下文长度增长，占用更多内存。

一般不缓存 Q，因为后续生成只需要新的 Query 与历史 Key/Value 计算 Attention。

3. MHA、MQA、GQA

三者主要区别是 Query Head 与 KV Head 的数量关系。

GQA 是现代 LLM 中常见的折中方案。

优点：

• 减少 KV Cache 占用。
• 降低 KV 数据读取量。
• 通常能以相对较小的质量代价改善推理效率。

例如 32 个 Q Heads、8 个 KV Heads，相比相同 Head 维度的 MHA，KV Cache 理论上可以降低到原来的四分之一。

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 参数模型：

以上使用十进制 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              → 另一种常见推理模型文件格式

理解这些内容后，就能进一步研究显存占用、模型加载、推理引擎和部署性能。

---

参考文档

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