GGUF、GPTQ、AWQ与EXL2：主流大模型量化格式详解

容器 vs. 量化：两个不可混淆的层次

多数误解源于将模型‘容器’（如何在磁盘存储张量）与‘量化方法’（如何将权重压缩为更少比特）混为一谈。容器包括safetensors、GGUF、PyTorch的.bin/.pt；量化方法则涵盖GPTQ、AWQ、bitsandbytes NF4、llama.cpp的K-quants与I-quants。EXL2和EXL3属于特例——它们既是量化方法，也绑定了专属推理库（如exllamav2）的存储布局。

内存占用估算：基础算术法则

模型权重内存 ≈ 参数量 × 每权重比特数 ÷ 8。以16位精度为基准：8B模型约16GB，70B模型约140GB；而典型4.5-bit量化后，对应分别降至约4.5GB与39GB。该计算仅覆盖权重，不包含KV缓存与运行时开销。

全精度格式：safetensors与PyTorch .bin

未量化模型通常以16位权重发布，格式为pytorch_model.bin或model.safetensors。旧式.bin/.pt依赖Python pickle，存在任意代码执行风险；safetensors由Hugging Face开发，采用JSON头+原始张量缓冲区结构，无可执行内容，支持内存映射与按需加载。值得注意的是，绝大多数GPTQ、AWQ、EXL2/EXL3及MLX量化模型，其权重文件本身仍是.safetensors格式——量化信息体现在张量内容与配置文件中，而非新容器。

GGUF：llama.cpp原生二进制格式

GGUF由Georgi Gerganov（llama.cpp项目负责人）于2023年8月21日推出，取代老旧的GGML/GGMF/GGJT格式。旧格式无法标识模型架构，新增超参即导致所有文件失效；GGUF采用类型化键值对元数据，实现向后兼容。其设计目标明确：单文件部署、可扩展性、内存映射兼容、易加载、元数据自包含。不同于纯张量格式，GGUF可内嵌分词器、特殊token及Jinja聊天模板。

GGUF量化命名解析

后缀如Q4_K_M.gguf揭示量化方案。以Q4_K为例：每个超块含256个权重，4-bit量化占1024比特；叠加8个区块的12-bit缩放因子与最小值（96比特），以及16-bit超缩放与超最小值（32比特），总计1152比特 → 平均4.5比特/权重。_S/_M/_L后缀表示混合精度策略（如Q4_K_M对部分attention与FFN层使用Q6_K，其余用Q4_K），故实际平均比特数略高于标称值。最新类型还包括TQ1_0/TQ2_0（三值权重）与MXFP4（4-bit微缩放浮点）。

质量-尺寸权衡实证

以Llama-2-7B类模型为基准，Hugging Face参考数据显示：FP16基准困惑度5.9565（13.0GB）；Q8_0仅增0.03%困惑度但体积减至7.0GB；Q4_K_M困惑度上升1.68%，体积压缩至4.1GB。需注意，该数据基于2023年模型，新架构响应可能不同。

校准增强：重要性矩阵（imatrix）

GGUF量化可引入校准数据。llama.cpp工具llama-imatrix从文本生成重要性矩阵，llama-quantize --imatrix据此优化量化质量。对于1-bit/2-bit混合量化，若未提供imatrix，工具将发出警告。

文件命名与部署生态

GGUF规范定义了完整命名结构：基础名、尺寸标签、微调标识、版本、编码、类型与分片序号（如00003-of-00009）。mmproj-与mtp-前缀分别标记视觉投影器与多token预测草稿模块。GGUF原生运行于llama.cpp及其衍生引擎（如llama-cpp-python、Ollama），是当前轻量级本地推理事实标准。