大模型文件格式完整指南

原

GrissomFI2025年05月27日约 10 分钟

大语言模型（LLM）部署中涉及多种模型文件格式，格式的选择直接影响模型的加载速度、推理性能、内存占用与跨平台兼容性。理解各类格式的技术特性与适用场景，有助于构建高效、可扩展、安全的部署方案。

广告时间：好书推荐

大模型时代为什么需要一本深度学习教科书？揭秘《深度学习：基础与概念》的独特价值

混合专家系统（MoE）图解指南之好书推荐：《图解大模型：生成式AI原理与实践》

《百面大模型》打通大模型求职与实战的关键一书

广告结束

一、原生训练框架格式

1.1 PyTorch 系列格式

`.pt` / `.pth`

• 格式类型：基于 Python pickle 协议的序列化格式，支持完整的 Python 对象图序列化。
• 内容结构：通常包含 state_dict（模型权重）、优化器状态、训练超参数、模型配置等。
• 加载方式：需结合模型定义代码使用 torch.load() 加载，支持 map_location 参数进行设备映射。
• 安全风险：由于使用 pickle，加载时会执行任意 Python 代码，存在代码注入风险。
• 典型用途：研究实验、模型断点恢复、本地训练存档、完整训练状态保存。

`.bin`

• 实质说明：Hugging Face 生态中的 .bin 文件（如 pytorch_model.bin）本质上是 .pt 格式的重命名版本，内容格式完全相同。
• 生态集成：通过 Transformers 库的 from_pretrained() 方法自动识别和加载，支持自动分片加载。
• 命名约定：遵循 pytorch_model.bin、training_args.bin 等标准命名规范。

1.2 TensorFlow 系列格式

`.ckpt`

• 组成结构：

• .ckpt.index：张量名称与数据文件分片的映射索引表。
• .ckpt.data-*：保存模型权重的二进制数据文件（可能多个分片）。
• .ckpt.meta（TF 1.x）：计算图的 Protocol Buffer 定义。

• 版本差异：TF 1.x 和 2.x 在检查点格式上存在兼容性差异。
• 加载方式：需配合模型构图代码或通过 tf.train.Checkpoint API 加载。

`.pb`（SavedModel 格式）

• 格式特性：TensorFlow 的标准部署格式，包含完整的计算图结构与变量值。

• 目录结构：

saved_model/
├── saved_model.pb        # 图定义
├── variables/           # 权重目录
│   ├── variables.index
│   └── variables.data-*
└── assets/             # 附加资源（可选）

• 推理独立性：无需模型源码，可直接在 TensorFlow Serving、TensorFlow Lite 中使用。
• 签名机制：支持多个 serving_default 签名，用于版本管理与接口绑定。

二、安全与现代格式

`.safetensors`

• 设计初衷：解决传统 pickle 格式的安全风险与加载性能问题，提供确定性的模型存储方案。
• 技术特点：

• 零拷贝加载：支持内存映射（mmap），大模型可实现秒级加载，避免完整解序列化。
• 纯数据格式：不包含任何可执行代码，从根本上消除代码注入风险。
• 确定性存储：相同模型始终产生相同的文件哈希值，便于完整性验证和缓存。
• 跨语言支持：提供 Python、Rust、JavaScript、C++ 等多语言绑定。

• 文件结构：Header（JSON 元数据）+ 对齐的张量数据块。
• 生态应用：已成为 Hugging Face 的默认推荐格式，正逐步取代 .bin 格式。
• 性能优势：加载速度比 pickle 格式提升 10-100 倍，特别适合大模型部署。

三、跨框架与中间表示格式

`.onnx`（Open Neural Network Exchange）

• 定位：框架无关的神经网络中间表示，用于模型标准化和跨平台部署。
• 图结构：基于 Protocol Buffer 的有向无环图（DAG）表示，支持静态计算图。
• 兼容性控制：

• Opset 版本：通过 opset_version 管理算子版本与兼容性（当前主流为 opset 11-17）。
• 算子支持：支持 200+ 标准算子，覆盖主流深度学习操作。

• 优化与量化：

• 原生支持 INT8、FP16、BF16 等量化格式。
• 支持动态量化和静态量化工作流。

• 应用限制：

• 不支持动态控制流（if/while 等）。
• 对自定义算子支持有限。
• 转换复杂模型时可能出现精度损失。

• 兼容部署平台：ONNX Runtime、TensorRT、OpenVINO、DirectML 等主流推理引擎。

四、推理优化格式

4.1 CPU 优化：`.gguf`（GPT-Generated Unified Format）

• 格式演进：由 GGML 格式演化而来，解决了元信息表达能力不足和扩展性问题。
• 量化策略：

• K-means 量化：Q2_K、Q3_K、Q4_K、Q5_K、Q6_K（2-6 bit 非均匀量化）。
• 传统量化：Q4_0、Q4_1、Q5_0、Q5_1、Q8_0（4-8 bit 均匀量化）。
• 浮点格式：F16（半精度）、F32（单精度）。

• 内存管理：

• 支持内存映射（mmap），10B+ 参数模型可在秒级时间内加载。
• 按需加载机制，减少内存峰值占用。

• 硬件适配：针对 x86-64、ARM64、Apple Silicon 等架构的 SIMD 指令集优化。
• 推理引擎：llama.cpp、Ollama、LM Studio、GPT4All 等。
• 性能特点：在 CPU 上可达到接近 GPU 的推理速度（特别是量化模型）。

4.2 GPU 加速：`.trt` / `.engine`（TensorRT 格式）

• 编译特性：

• 将 ONNX/TensorFlow 模型编译为针对特定 GPU 架构优化的执行引擎。
• 支持 Volta、Turing、Ampere、Hopper 等 GPU 架构。

• 精度支持：

• FP32/FP16：标准浮点精度。
• INT8：需要校准数据集进行量化。
• INT4：Ampere 架构及以上支持，需 TensorRT 8.5+。

• 图优化技术：

• 层融合：将多个算子融合为单个 kernel。
• 内存优化：自动优化内存布局和重用策略。
• Kernel 调优：为特定输入尺寸选择最优 CUDA kernel。

• 硬件绑定：编译后的 .engine 文件与生成时的 GPU 型号、CUDA 版本、TensorRT 版本强绑定。
• 动态支持：

• 支持动态 batch size、序列长度（需编译时指定 min/opt/max 范围）。
• 支持多 profile 以适应不同输入尺寸。

4.3 移动端部署格式

`.tflite`（TensorFlow Lite）

• 目标平台：Android、iOS、Raspberry Pi、Coral Edge TPU 等边缘设备。
• 模型优化：

• 算子融合：自动合并相邻算子减少计算开销。
• 量化支持：动态量化、静态量化、QAT（量化感知训练）。
• 稀疏化：支持结构化和非结构化稀疏模型。

• 硬件加速：

• GPU Delegate：OpenGL ES、Vulkan 加速。
• NNAPI Delegate：Android 神经网络 API。
• Core ML Delegate：iOS 平台加速。
• Edge TPU：Google Coral 专用加速器。

• 后端框架：XNNPACK、Eigen、gemmlowp 等优化库。

`.mlmodel` / `.mlpackage`（Apple Core ML）

• 格式演进：.mlmodel（单文件）→ .mlpackage（目录结构，支持大模型）。
• 平台优化：专为 iOS/macOS/watchOS/tvOS 生态设计，深度集成系统框架。
• 硬件加速：

• Neural Engine：Apple 自研神经网络处理器。
• GPU 加速：Metal 框架支持。
• CPU 优化：针对 Apple Silicon 的向量化指令。

• 隐私特性：所有推理在设备本地完成，数据不上传云端。
• 开发集成：与 Xcode、Swift、Objective-C 无缝对接，支持实时预览。

五、分布式部署格式与机制

5.1 模型分片机制

对于超过单文件系统限制或网络传输限制的大模型（通常 > 2GB），采用分片存储机制：

• 分片命名规范：

pytorch_model-00001-of-00005.bin
pytorch_model-00002-of-00005.bin
pytorch_model-00003-of-00005.bin
pytorch_model-00004-of-00005.bin
pytorch_model-00005-of-00005.bin

• 索引文件结构（pytorch_model.bin.index.json）：

{
"metadata":{
"total_size":13231323136,
"format":"pt"
},
"weight_map":{
"model.embed_tokens.weight":"pytorch_model-00001-of-00005.bin",
"model.layers.0.self_attn.q_proj.weight":"pytorch_model-00001-of-00005.bin",
"model.layers.0.self_attn.k_proj.weight":"pytorch_model-00002-of-00005.bin",
    ...
}
}

• Safetensors 分片：

{
"metadata":{"total_size":13231323136},
"weight_map":{
"model.embed_tokens.weight":"model-00001-of-00005.safetensors",
    ...
}
}

5.2 分布式推理策略

• 张量并行（Tensor Parallelism, TP）：

• 横向切分单层权重矩阵，分配到多个 GPU 并行计算。
• 适用于注意力层、MLP 层的权重切分。
• 需要设备间高带宽通信（如 NVLink）。

• 流水线并行（Pipeline Parallelism, PP）：

• 纵向切分模型层次，不同设备处理不同 Transformer 层。
• 通过微批次（micro-batch）流水线减少设备空闲时间。
• 适合层数较多的大模型。

• 数据并行（Data Parallelism, DP）：

• 多个设备分别处理不同输入批次，通过 AllReduce 同步梯度。
• 推理时可直接并行处理多个请求。

• 专家混合（Mixture of Experts, MoE）：

• 将部分专家网络分布到不同设备。
• 根据输入动态路由到相应专家，减少单次推理的计算量。

六、格式转换工具链与实践

6.1 主要转换工具

Hugging Face 生态工具

• 基础 API：

• model.save_pretrained(path, safe_serialization=True)：保存为 safetensors 格式。
• AutoModel.from_pretrained(path, torch_dtype=torch.float16)：自动识别格式加载。

• 转换脚本：

• convert_tf_checkpoint_to_pytorch.py：TensorFlow → PyTorch。
• convert_pytorch_checkpoint_to_tf2.py：PyTorch → TensorFlow 2.x。
• convert_slow_tokenizer.py：慢速分词器 → 快速分词器。

ONNX 工具链

• 导出工具：

• torch.onnx.export()：PyTorch 模型导出 ONNX。
• tf2onnx：TensorFlow 模型转换 ONNX。
• sklearn-onnx：Scikit-learn 模型转换。

• 优化工具：

• onnx-simplifier：简化 ONNX 图结构，去除冗余算子。
• onnxoptimizer：应用图优化 pass。
• onnx-tools：模型验证、可视化、量化。

量化与优化工具

• GGUF 转换：

• llama.cpp/convert.py：HF 模型 → GGUF 格式。
• ggml-quantize：GGUF 模型量化工具。

• 量化库：

• AutoGPTQ：基于 GPTQ 算法的 4bit 量化。
• BitsAndBytes：动态 4bit/8bit 量化，支持 QLoRA。
• Intel Neural Compressor：英特尔 CPU 优化量化。
• NVIDIA TensorRT-LLM：GPU 大模型推理优化。

6.2 转换最佳实践

转换前准备

1. 环境一致性：确保转换环境与目标部署环境的依赖版本一致。
2. 模型验证：检查源模型的完整性和可加载性。
3. 基准建立：记录原始模型的推理结果作为转换后的对比基准。

转换过程控制

1. 精度验证：

# 数值一致性检查示例
import torch
import numpy as np

defcompare_outputs(output1, output2, rtol=1e-3, atol=1e-5):
return np.allclose(output1.numpy(), output2.numpy(), rtol=rtol, atol=atol)

2. 性能基准测试：

• 吞吐量测试：测量单位时间内处理的 token 数。
• 延迟测试：测量单次推理的端到端时间。
• 内存占用：监控推理时的峰值内存使用。

3. 资源评估：

• 加载时间：不同格式的模型加载速度对比。
• 存储空间：文件大小对比（考虑压缩效果）。
• 兼容性测试：在目标平台上的实际运行验证。

常见问题处理

1. 精度损失：

• 检查量化配置是否过于激进。
• 验证转换过程中的数值截断问题。
• 考虑使用校准数据集进行更精确的量化。

2. 性能不达预期：

• 检查是否启用了硬件加速（GPU、专用芯片）。
• 验证batch size 和序列长度设置。
• 考虑模型结构是否适合目标平台优化。

3. 兼容性问题：

• 确认目标运行时版本支持所需算子。
• 检查动态形状支持情况。
• 验证自定义算子的转换情况。

七、格式选择决策框架

7.1 应用场景导向选择

应用场景	首选格式	备选格式	关键考量因素
研究与实验	`.pt` / `.ckpt`	`.safetensors`	保留完整训练上下文，便于调试与继续训练
生产 Web 服务	`.safetensors` / `.onnx`	`.bin` → `.safetensors`	安全性、加载速度、推理引擎兼容性
CPU 本地部署	`.gguf`	`.onnx`	内存效率、量化支持、跨平台兼容性
GPU 高性能推理	`.engine` / `.safetensors`	`.onnx`	推理性能、硬件优化、动态输入支持
移动端/边缘设备	`.tflite` / `.mlmodel`	`.onnx`	模型大小、功耗、硬件加速支持
跨平台分发	`.onnx`	`.safetensors`	标准化程度、运行时支持广度
模型微调	`.pt` / `.safetensors`	`.ckpt`	梯度计算支持、优化器状态保存
模型服务化	`.safetensors` / `.onnx`	`.pb`	服务稳定性、版本管理、API 兼容性

7.2 技术特性对比

特性维度	`.pt/.bin`	`.safetensors`	`.onnx`	`.gguf`	`.trt`	`.tflite`
加载速度	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
推理性能	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
内存效率	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
跨平台兼容性	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐
安全性	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
生态成熟度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
开发调试友好性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐	⭐⭐	⭐⭐

7.3 决策流程图

开始选择模型格式
        ↓
    是否需要训练/微调？
    ┌─── 是 ──→ .pt/.safetensors
    └─── 否
        ↓
    目标部署平台？
    ├─── GPU服务器 ──→ .safetensors/.engine
    ├─── CPU服务器 ──→ .gguf/.onnx
    ├─── 移动设备   ──→ .tflite/.mlmodel
    └─── 跨平台    ──→ .onnx
        ↓
    性能要求级别？
    ├─── 极致性能 ──→ 专用优化格式(.engine/.gguf)
    ├─── 平衡性能 ──→ 通用格式(.safetensors/.onnx)
    └─── 兼容优先 ──→ 标准格式(.onnx)
        ↓
    确定最终格式

八、未来发展趋势与展望

8.1 标准化趋势

• 统一中间表示：ONNX、MLIR、OpenXLA 等项目推动跨框架标准化。
• 安全格式普及：safetensors 等安全格式逐渐成为默认选择。
• 量化标准化：INT4、FP8 等新精度格式的标准化推进。

8.2 性能优化方向

• 零拷贝技术：内存映射、共享内存等技术减少数据拷贝开销。
• 异构计算支持：CPU、GPU、NPU 等多种处理器的协同优化。
• 动态优化：运行时根据输入特征动态选择最优执行策略。

8.3 新兴技术格式

• Apple MLX：针对 Apple Silicon 优化的统一机器学习框架格式。
• IREE-MLIR：Google 开源的端到端编译器中间表示。
• FasterTransformer：NVIDIA 针对 Transformer 架构的专用优化格式。
• DeepSpeed-Inference：Microsoft 的大模型推理优化框架专用格式。

8.4 行业发展预测

1. 格式收敛：预计未来 2-3 年内，主流格式将收敛为 3-5 种核心标准。
2. 自动化工具链：模型格式转换和优化将更加自动化和智能化。
3. 硬件感知优化：格式选择将更多地考虑目标硬件的特性和限制。
4. 安全性强化：模型文件的完整性验证和防篡改机制将成为标配。

通过深入理解各种模型文件格式的技术特性、适用场景和转换策略，开发者可以在 LLM 系统的全生命周期中做出最优的技术决策，从而构建高效、安全、可扩展的大模型应用系统。建议在实际项目中建立格式选择的标准化流程，结合自动化工具链实现最佳的工程实践。