Gitlon
LLM模型格式Hugging Face

模型格式说明 ​

这篇文章解决什么问题 ​

很多人第一次接触开源模型时，会把下面几件事混在一起：

  • 模型架构，比如 Transformer
  • 工具库，比如 transformers
  • 文件命名，比如 model.safetensors
  • 输入格式，比如 chat template
  • 模型格式，比如 safetensors、ONNX、GGUF

真正容易卡住的地方通常是这些：

  • 模型格式到底在说什么
  • 为什么会同时看到这么多格式
  • 它们分别适合什么场景
  • 哪些能继续训练，哪些更适合部署
  • 哪些只是“能存”，哪些是“能直接跑”

这篇文章只讲“模型格式”这一层，不讲模型架构，也不讲输入消息格式。

如果你要找的是：

先说结论 ​

  • 模型格式，本质上是在说：模型权重、配置和相关 metadata 用什么方式保存、交换和加载。
  • 它不等于模型架构，也不等于推理时的消息格式。
  • 之所以会有很多格式，是因为“继续训练”“跨平台部署”“本地量化推理”“只发微调增量”这几件事，需求完全不同。
  • 在大模型语境里，最常见的几类是：
    • PyTorch checkpoint
    • safetensors
    • ONNX
    • GGUF
    • PEFT adapter
    • MLX 生态里的转换模型

模型格式到底是什么 ​

最简单的说法是：

模型格式 = 你怎么把模型保存下来，并让另一个框架或运行时重新把它装起来。

它通常会涉及这些内容：

  • 权重张量怎么存
  • 配置怎么存
  • metadata 怎么存
  • 能不能分片
  • 能不能量化
  • 谁能直接加载

所以“模型格式”真正回答的是：

  • 这个模型存在磁盘上时长什么样
  • 谁能读它
  • 读出来以后更适合训练、转换、还是直接推理

为什么会有这么多格式 ​

因为大家想解决的问题根本不是同一个。

需求更常见的格式方向
继续训练、继续微调PyTorch checkpoint / safetensors
安全分发和分享权重safetensors
跨框架、跨平台部署ONNX
本地 CPU / 轻量 GPU 推理GGUF
只分享微调增量adapter_model.safetensors + adapter_config.json
Apple Silicon 本地运行或微调MLX 转换模型

所以你看到格式多，不代表行业混乱到不可用；更常见的情况是：

同一个模型，为了不同目标，会被保存成不止一种格式。

先分清：你看到的是哪一类格式 ​

类别常见例子它主要解决什么问题
训练/研究格式.pt、.pth、.bin方便训练、保存 checkpoint
安全权重格式model.safetensors更安全地分发和加载张量
交换/部署格式.onnx跨框架、跨平台部署
本地推理格式.gguf本地量化推理、轻量运行
增量微调格式adapter_model.safetensors只发 LoRA / PEFT 增量参数
特定生态转换结果mlx_model/ 一类目录给 Apple Silicon 的 MLX 生态使用

下面按这几类逐个拆。

1. PyTorch checkpoint ​

常见文件名：

text
model.bin
model.pt
model.pth
checkpoint.pt

起源 ​

它来自 PyTorch 自己的保存和加载体系。
PyTorch 官方文档明确写到，torch.save / torch.load 底层使用的是 Python pickle 序列化。

用途 ​

它最常见的用途是：

  • 训练中间 checkpoint
  • 研究实验保存
  • 继续训练
  • 保存 optimizer / scheduler / trainer state

能做什么 ​

  • 保存模型权重
  • 保存完整训练状态
  • 直接回到 PyTorch 环境继续训练
  • 方便研究和实验阶段快速迭代

不能做什么 ​

  • 不能默认认为它适合跨框架部署
  • 不能默认认为它适合直接发给不可信环境
  • 不能默认认为它比 safetensors 更安全

优势 ​

  • 原生
  • 灵活
  • 训练链路里最直接

劣势 ​

  • 安全性差于 safetensors
  • 和具体 Python / PyTorch 环境绑定更紧
  • 不适合作为“长期通用交换格式”

2. safetensors ​

常见文件名：

text
model.safetensors
model-00001-of-00004.safetensors
adapter_model.safetensors

起源 ​

它来自 Hugging Face 推出的 safetensors 项目。
官方文档对它的定义很直接：这是一个“安全保存 tensors”的简单格式，用来替代 pickle 类方式。

用途 ​

它最常见的用途是：

  • 保存主模型权重
  • 在 Hugging Face Hub 上安全分享
  • 作为 transformers / peft 体系里的主流权重格式

能做什么 ​

  • 安全保存张量
  • 快速加载
  • 支持分片
  • 适合模型分发和服务加载

不能做什么 ​

  • 它本身不负责定义执行图
  • 它不等于模型架构说明
  • 只有 safetensors 文件本身，通常还不够；一般还需要 config.json、tokenizer 等文件配套

优势 ​

  • 比 pickle 类格式更安全
  • 加载快
  • 现在生态支持非常广
  • 很适合作为主模型权重分发格式

劣势 ​

  • 它只管 tensor，不替你解决部署兼容性
  • 它不是“跨运行时一把通吃”的部署格式

3. ONNX ​

常见文件名：

text
model.onnx
encoder_model.onnx
decoder_model.onnx

起源 ​

ONNX 是 Open Neural Network Exchange。
它在 2017 年由 Microsoft 和 Facebook 推动早期发布，目标就是减少框架之间来回迁移模型的成本。
ONNX 官方现在也把它定义成一种可扩展的计算图模型标准。

用途 ​

它最常见的用途是：

  • 跨框架模型交换
  • 推理部署
  • 服务端、移动端、浏览器等环境的统一运行

能做什么 ​

  • 把模型导出成更标准化的图表示
  • 让不同 runtime 在不同硬件上执行
  • 方便做部署优化

不能做什么 ​

  • 不能保证所有模型都能无痛导出
  • 不能保证自定义算子、动态行为都完美支持
  • 通常不是大模型微调时最自然的中间格式

优势 ​

  • 互操作性强
  • 部署友好
  • 适合跨平台推理

劣势 ​

  • 导出链路可能麻烦
  • 调试成本比原生框架高
  • 一旦碰到不兼容算子，排查成本会上来

4. GGUF ​

常见文件名：

text
Qwen2.5-7B-Instruct-Q4_K_M.gguf
Llama-3-8B-Instruct-Q5_K_M.gguf

起源 ​

GGUF 来自 GGML / llama.cpp 生态。
Hugging Face 官方文档明确写到，它是为快速加载和保存优化的二进制格式，由 @ggerganov 开发，主要给 GGML 以及相关执行器使用。

用途 ​

它最常见的用途是：

  • 本地推理
  • 边缘设备推理
  • 量化后分发
  • 给 llama.cpp、Ollama、LM Studio、GPT4All 这类工具使用

能做什么 ​

  • 把权重和标准化 metadata 打包在一起
  • 支持多种量化类型
  • 显著降低本地运行内存压力
  • 让消费级设备跑大模型变得更现实

不能做什么 ​

  • 它不是默认的训练主格式
  • 它不是通用跨框架部署标准
  • 不能把“能用 GGUF 跑起来”理解成“适合继续做常规微调”

这里有个细节要分清：

根据 Hugging Face transformers 文档，GGUF 现在可以重新载入到 Transformers 里，再解量化成 fp32 做进一步训练或微调。
但这不代表 GGUF 已经变成主流训练中间格式。更常见的工作流仍然是：

  • 原始训练 / 微调用 Hugging Face / PyTorch 权重
  • 本地分发或运行再转成 GGUF

优势 ​

  • 本地运行友好
  • 单文件或接近单文件分发很方便
  • 量化支持成熟
  • 很适合 CPU、本地 GPU、边缘设备推理

劣势 ​

  • 更偏推理，不是最自然的训练格式
  • 依赖特定生态
  • 量化后质量通常会有取舍

5. PEFT adapter ​

常见文件：

text
adapter_model.safetensors
adapter_config.json

起源 ​

它来自参数高效微调这条路线，比如 LoRA、IA3 这类方法。
Hugging Face PEFT 文档把这套 checkpoint 结构定义得比较明确：adapter 只保存新增那一小部分参数，而不是整模。

用途 ​

它最常见的用途是：

  • 分享 LoRA / PEFT 微调结果
  • 在不复制整模的情况下分发增量改动
  • 在同一个底座模型上切换多个 adapter

能做什么 ​

  • 大幅缩小微调结果体积
  • 让同一个底座挂多个不同任务 adapter
  • 更便于分享和版本管理

不能做什么 ​

  • 通常不能单独跑
  • 没有底座模型时，adapter 本身不够恢复完整能力
  • 不能把它当成完整整模文件

优势 ​

  • 小很多
  • 分享成本低
  • 适合团队内部或社区发微调结果

劣势 ​

  • 强依赖底座模型
  • 加载链路比“整模即插即用”多一步
  • 底座不匹配时会直接出问题

6. MLX 转换模型 ​

常见形态：

text
mlx_model/

或者某个给 mlx-lm 直接加载的模型目录。

起源 ​

MLX 是 Apple 在 2023 年公开的机器学习框架，目标是服务 Apple Silicon。
mlx-lm 则是它在大语言模型上的常用配套工具，可以把 Hugging Face 模型转换到 MLX 生态里使用。

用途 ​

它最常见的用途是：

  • 在 Mac 本地跑大模型
  • 在 Apple Silicon 上做推理
  • 在 MLX 生态里做微调和量化

能做什么 ​

  • 把 Hugging Face 模型转成 MLX 可加载格式
  • 在 Apple Silicon 上高效跑推理
  • 做量化、LoRA、部分训练和上传

不能做什么 ​

  • 不能把 MLX 简单理解成像 ONNX 那样的跨平台交换标准
  • 不能默认认为 Linux / Windows 上的常见推理引擎都能直接吃它
  • 它更像“Apple 生态下的运行和转换结果”，不是通用行业标准格式

优势 ​

  • 对 Apple Silicon 很友好
  • 本地开发体验好
  • Mac 上跑大模型的门槛较低

劣势 ​

  • 生态范围更窄
  • 可移植性不如 ONNX
  • 通常需要从 Hugging Face 模型再做一次转换

一张表看清它们的分工 ​

格式更适合什么不适合什么
PyTorch checkpoint训练、实验、恢复训练状态不可信来源直接加载、长期通用分发
safetensors安全分享主权重、Hub 分发直接解决跨平台部署
ONNX跨框架部署、服务端/移动端推理任意模型无痛导出、常规继续微调
GGUF本地量化推理、llama.cpp 生态作为主流训练中间格式
PEFT adapter分享微调增量单独当完整模型运行
MLX 转换模型Mac 本地运行与微调当成通用跨平台格式

怎么选 ​

如果你的目标是：

  • 继续训练或继续微调：优先 Hugging Face / PyTorch 主权重，通常是 safetensors
  • 分享微调结果，但不想发整模：优先 PEFT adapter
  • 做跨平台部署：优先 ONNX
  • 在本地 CPU 或轻量 GPU 上跑：优先 GGUF
  • 在 Apple Silicon 上本地跑：优先 MLX
  • 只是拿到一个老 checkpoint 继续实验：.pt / .bin 也能用，但对外分发更建议转成 safetensors

最容易搞混的几组概念 ​

1. 模型格式 != 模型骨架 ​

Transformer 说的是模型结构。
safetensors、ONNX、GGUF 说的是“怎么保存和加载”。

2. 模型格式 != 输入格式 ​

chat template 说的是消息怎么排。
ONNX、GGUF 说的是模型文件怎么存。

3. 模型格式 != 文件命名 ​

Qwen2.5-7B-Instruct-Q4_K_M.gguf 这个字符串里：

  • Qwen2.5-7B-Instruct 是模型名
  • Q4_K_M 是量化标签
  • .gguf 才是文件格式

4. adapter != 整模 ​

adapter_model.safetensors 通常不是完整模型，只是增量补丁。
没有底座，它往往不能单独用。

一个最短记忆法 ​

如果你只想记一句话，可以记这个：

模型格式不是在回答“模型聪不聪明”，而是在回答“它怎么存、谁来读、适合拿去干什么”。

参考资料 ​

基于 VitePress 的个人知识库骨架

Copyright © 2026 GitLon