GGUF 简介
当前的大模型的参数规模较大,数以千亿的参数导致了它们的预训练结果文件都在几十GB甚至是几百GB,这不仅导致其使用成本很高,在不同平台进行交换也非常困难。因此,大模型预训练结果文件的保存格式对于模型的使用和生态的发展来说极其重要。
大语言模型的开发通常使用PyTorch等框架,其预训练结果通常也会保存为相应的二进制格式,如pt后缀的文件通常就是PyTorch框架保存的二进制预训练结果。
但是,大模型的存储一个很重要的问题是它的模型文件巨大,而模型的结构、参数等也会影响模型的推理效果和性能。为了让大模型更加高效的存储和交换,就有了不同格式的大模型文件。其中,GGUF就是非常重要的一种大模型文件格式。
GGUF就是一种二进制格式文件的规范,原始的大模型预训练结果经过转换后变成GGUF格式可以更快地被载入使用,也会消耗更低的资源。原因在于GGUF采用了多种技术来保存大模型预训练结果,包括采用紧凑的二进制编码格式、优化的数据结构、内存映射等。
注意:llama.cpp官方提供了转换脚本,可以将pt格式的预训练结果以及safetensors模型文件转换成GGUF格式的文件。转换的时候也可以选择量化参数,降低模型的资源消耗。
GGUF格式的前身是GGML,也是同一个作者开发的,但是GGML格式因为种种限制目前被放弃
GGUF 特性
GGUF 是一种基于现有 GGJT 的格式(这种格式对张量进行对齐,以便能够使用内存映射(mmap)),但对该格式进行了一些更改,使其更具可扩展性且更易于使用。GGUF 具有如下特性:
- 单文件部署:它们可以轻松分发和加载,并且不需要任何外部文件来获取附加信息。
- 可扩展性:可以将新特征添加到基于 GGML 的执行器中/可以将新信息添加到 GGUF 模型中,而不会破坏与现有模型的兼容性。
- mmap兼容性:可以使用mmap加载模型,以实现快速地加载和保存。
- 易于使用:无论使用何种语言,都可以使用少量代码轻松加载和保存模型,无需外部库。
- 信息完整:加载模型所需的所有信息都包含在模型文件中,用户不需要提供任何额外的信息。这大大简化了模型部署和共享的流程。
- GGJT 和 GGUF 之间的主要区别在于:超参数(现称为元数据)使用键值结构,而不是非类型化的值列表。这允许在不破坏与现有模型的兼容性的情况下添加新的元数据,这使得可以添加对推理或识别模型有用的附加信息来注释模型。
GGUF 与 Safetensors 的区别
safetensors是一种由Hugging Face推出的新型的安全的模型存储格式。它特别关注模型的安全性和隐私保护,同时保证了加载速度。safetensors文件仅包含模型的权重参数,不包括执行代码,这有助于减少模型文件的大小并提高加载速度。此外,safetensors支持零拷贝(zero-copy)和懒加载(lazy loading),没有文件大小限制,并且支持bfloat16/fp8数据类型。但safetensors没有重点关注性能和跨平台交换。在大模型高效序列化、数据压缩、量化等方面存在不足,并且它只保存了张量数据,没有任何关于模型的元数据信息。
而gguf格式是一种针对大模型的二进制文件格式。专为GGML及其执行器快速加载和保存模型而设计。它是GGML格式的替代者,旨在解决GGML在灵活性和扩展性方面的限制。它包含加载模型所需的所有信息,无需依赖外部文件,这简化了模型部署和共享的过程,同时有助于跨平台操作。此外,GGUF还支持量化技术,可以降低模型的资源消耗,并且设计为可扩展的,以便在不破坏兼容性的情况下添加新信息。
适用场景
GGUF:
适合需要频繁加载大模型的场景,尤其是在本地设备或边缘计算环境中。
常用于 llama.cpp 等本地推理引擎。
Safetensors:
适合快速部署和对安全性要求较高的场景,特别是在 Hugging Face 生态中。
常用于 Hugging Face Transformers 库和 Stable Diffusion 等模型79。
扩展性与兼容性
GGUF:
设计为可扩展,支持在不破坏兼容性的情况下添加新信息。
跨平台兼容性强,适合多种硬件和操作系统。
Safetensors:
主要用于 PyTorch 和 TensorFlow 框架,跨平台兼容性较弱。
不支持量化技术,文件大小相对较大。
总结
GGUF 更适合需要高效加载和资源优化的场景,尤其是在本地设备上运行大模型。
Safetensors 更适合快速部署和对安全性要求较高的场景,特别是在 Hugging Face 生态中。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。