据MarkTechPost 2026年9月19日报道，LLM模型格式讨论中的多数混淆，源于把“容器”和“量化方法”混在一起。该文称，容器决定张量如何存放在磁盘上，量化方法决定权重如何压缩到更少比特。容器包括safetensors、GGUF、PyTorch pickle（.bin/.pt）；方法包括GPTQ、AWQ、bitsandbytes NF4、llama.cpp K-quants和I-quants；EXL2和EXL3则同时是方法与绑定某一推理库的存储布局。权重内存估算公式为参数×每权重比特÷8。按该文示例，16位权重下8B模型约16GB，70B约140GB；约4.5比特每权重时，8B约4.5GB，70B约39GB。这仅是权重算术估算，KV缓存和运行时开销另计。
未量化模型通常以16位权重发布为pytorch_model.bin或model.safetensors。较旧.bin/.pt使用Python pickle，加载可能执行任意代码，不可信检查点有安全风险。Safetensors由Hugging Face创建，文件由小型JSON头和原始张量缓冲组成，内部没有可执行内容，张量可内存映射并逐个加载。Safetensors现列为PyTorch Foundation项目。该文强调，多数GPTQ、AWQ、EXL2、EXL3和MLX模型也存储在.safetensors中，量化信息在张量内容和配置文件，而非新容器。
GGUF是用于GGML及llama.cpp等基于GGML执行器的二进制格式，由Georgi Gerganov创建，他同时领导llama.cpp。GGUF于2023年8月21日推出，替代旧GGML格式。旧GGML、GGMF和GGJT无法说明模型架构，新增超参数会破坏现有文件；GGUF改用类型化键值元数据，新字段可在不破坏旧文件的情况下加入。其设计目标包括单文件部署、可扩展性、mmap兼容、易于加载和文件内包含完整信息。GGUF可把分词器、特殊token和Jinja聊天模板与权重放在一起。
读取GGUF量化名时，Q4_K_M.gguf这样的后缀可说明方案。按Hugging Face GGUF文档，Q4_0和Q4_1在32权重块中做4位round-to-nearest，Q4_1增加块最小值，每权重约4.5和5.0；Q8_0为32权重块8位round-to-nearest，约8.5；Q2_K、Q3_K、Q4_K、Q5_K、Q6_K等K-quants每权重约2.625、3.4375、4.5、5.5和6.5625；IQ4_XS、IQ3_XXS、IQ2_XXS、IQ1_S使用重要性矩阵，约4.25、3.06、2.06和1.56。名称中的_S、_M、_L是混合而非新类型。例如llama.cpp描述Q4_K_M对一半attention.wv和feed_forward.w2张量使用Q6_K，其余用Q4_K，因此平均高于4.5比特。Hugging Face表还列出三元权重类型TQ1_0、TQ2_0，以及4位微缩放浮点类型MXFP4。Q8_0虽被归入“legacy”，仍是标准近无损GGUF选择。
质量与体积方面，该文引用Hugging Face针对Llama-2-7B类模型的参考表：FP16困惑度5.9565、体积13.0GB；Q8_0为5.9584、变化+0.03%、7.0GB；Q6_K为5.9642、+0.13%、5.5GB；Q5_K_M为5.9796、+0.39%、4.8GB；Q4_K_M为6.0565、+1.68%、4.1GB。这些数字仅作示意，来自2023年时代的7B模型。GGUF量化可用校准数据：llama.cpp的llama-imatrix从文本文件计算重要性矩阵，llama-quantize --imatrix随后用它改进质量；对1比特和2比特混合，若未提供imatrix，llama-quantize会警告。规范定义的文件名包括基础名、大小标签、微调、版本、编码、类型和分片，分片使用00003-of-00009式五位计数器，可选mmproj-和mtp-前缀分别标记视觉投影器和多token预测草稿模块。GGUF原生用于llama.cpp及其生态，Hugging Face文档列出llama.cpp、LM Studio、GPT4All和Ollama等使用方式。