烟台网站建设学校,河北做wap网站,jsp网站开发书籍,做电影网站需要多打了服务器GGUF格式介绍
GGUF#xff08;GPT-Generated Unified Format#xff09;是推理框架llama.cpp 中使用的一种专为大语言模型设计的二进制文件格式#xff0c;旨在实现模型的快速加载和保存#xff0c;同时易于读取。GGUF格式的特点#xff1a;
单文件部署#xff1a;模型…GGUF格式介绍
GGUFGPT-Generated Unified Format是推理框架llama.cpp 中使用的一种专为大语言模型设计的二进制文件格式旨在实现模型的快速加载和保存同时易于读取。GGUF格式的特点
单文件部署模型可以轻松分发和加载不需要任何外部文件来提供额外信息。可扩展性可以在不破坏与现有模型的兼容性的情况下向基于GGML的执行器添加新功能或向GGUF模型添加新信息。mmap兼容性可以使用mmap加载模型以实现快速加载和保存。易于使用可以使用少量代码轻松加载和保存模型无论使用何种语言无需外部库。完整信息加载模型所需的所有信息都包含在模型文件中用户无需提供任何额外信息。
GGUF文件的结构如下图所示 主要包括以下几个部分
文件头Header标识文件类型GGUF、版本号、张量数量。元数据段MetadataJSON-like键值对存储模型信息。张量数据段Tensors按量化类型存储模型权重。
它们使用general.alignment元数据字段中指定的全局对齐如果需要文件将用0x00字节填充到general.alignment的下一个倍数。除非另有说明字段包括数组将按顺序连续写入不进行对齐。模型默认为小端序当然它们也可以是大端序以供大端序计算机使用在这种情况下所有值包括元数据值和张量也将是大端序。
GGUF命名约定
GGUF遵循BaseNameSizeLabelFineTuneVersionEncodingTypeShard.gguf的命名约定其中每个组件由-分隔如果存在,这种命名方式的最终目的是为了让人们能够快速了解模型的关键信息。
每个组件的含义如下 BaseName模型基础类型或架构的描述性名称。 可以从gguf元数据general.basename派生将空格替换为连字符。 SizeLabel参数权重类别在排行榜中有用表示为专家数量x数量量级前缀。 如果可用可以从gguf元数据general.size_label派生如果缺失则进行计算。支持带有单个字母量级前缀的十进制点的四舍五入以帮助显示浮点指数如下所示 Q千万亿参数。T万亿参数。B十亿参数。M百万参数。K千参数。 可以根据需要附加额外的-属性数量量级前缀以指示其他感兴趣的属性。 FineTune模型微调目标的描述性名称例如Chat、Instruct等。 可以从gguf元数据general.finetune派生将空格替换为连字符。 Version表示模型版本号格式为v主版本.次版本。 如果模型缺少版本号则假设为v1.0首次公开发布。可以从gguf元数据general.version派生。 Encoding指示应用于模型的权重编码方案。内容、类型混合和排列由用户代码决定可以根据项目需求而有所不同。 Type指示gguf文件的类型及其预期用途。 如果缺失则文件默认为典型的gguf张量模型文件。LoRAGGUF文件是LoRA适配器。vocab仅包含词汇数据和元数据的GGUF文件。 Shard可选指示模型已被拆分为多个分片格式为分片编号-of-总分片数。 分片编号此模型中的分片位置。必须用零填充为5位数字。 分片编号始终从00001开始例如第一个分片总是从00001-of-XXXXX开始而不是00000-of-XXXXX。 总分片数此模型中的总分片数。必须用零填充为5位数字。
下面是对几个GGUF模型文件名的解释
Mixtral-8x7B-v0.1-KQ2.gguf 模型名称Mixtral专家数量8参数数量7B版本号v0.1权重编码方案KQ2 Hermes-2-Pro-Llama-3-8B-F16.gguf 模型名称Hermes 2 Pro Llama 3专家数量0参数数量8B版本号v1.0权重编码方案F16分片不适用 Grok-100B-v1.0-Q4_0-00003-of-00009.gguf 模型名称Grok专家数量0参数数量100B版本号v1.0权重编码方案Q4_0分片3 out of 9 total shards
GGUF命名规则约定所有模型文件都应该有基本名称、大小标签和版本以便能够轻松验证其是否符合GGUF命名约定。例如如果省略版本号那么编码很容易被误认为是微调。
GGUF与其他格式对比
格式特点典型场景GGUF专为 CPU 推理优化支持量化元数据丰富本地部署llama.cppPyTorch .pt原生训练格式未量化依赖 GPU 和 PyTorch 环境模型训练/微调HuggingFace .safetensors安全序列化格式未量化需加载完整模型到内存云端推理GPU 加速ONNX跨框架通用格式支持硬件加速但量化功能有限跨平台部署
GGUF格式转换
GGUF格式是推理框架llama.cpp使用的格式但是通常模型是使用PyTorch之类的训练框架训练的保存的格式一般使用HuggingFace的safetensors格式因此使用llama.cpp进行推理之前需要把其他格式的模型转换为GGUF格式。
下面以DeepSeek R1的蒸馏模型DeepSeek-R1-Distill-Qwen-7B为例介绍如何将模型转换为GGUF格式。
首先从魔搭社区或HuggingFace下载模型
pip install modelscope
modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B --local_dir DeepSeek-R1-Distill-Qwen-7B下载好的模型是以safetensors格式存放的可以调用llama.cpp的转换脚本把模型转换为GGUF格式
# 安装python依赖库
pip install -r requirements.txt
# 转换模型
python convert_hf_to_gguf.py DeepSeek-R1-Distill-Qwen-7B/转换成功后在该目录下会生成一个FP16精度、GGUF格式的模型文件DeepSeek-R1-Distill-Qwen-7B-F16.gguf。
如果不想自己转模型也可以在魔搭社区或HuggingFace上找带gguf后缀的模型或者使用HuggingFace的gguf-my-repo进行转换网址如下
https://huggingface.co/spaces/ggml-org/gguf-my-repo在该界面的Hub Modeil ID框中查找你想转的模型然后Quantization Method中选择你想要的模型量化方式关于GGUF模型的各种量化参数将在下文进行介绍最后点击Submit就可以开始模型转换了。 GGUF量化参数介绍
llama.cpp的模型量化方法主要采用了分块量化Block-wise Quantization和K-Quantization算法来实现模型压缩与加速其核心策略包括以下关键技术 分块量化Block-wise Quantization 该方法将权重矩阵划分为固定大小的子块如32或64元素为一组每个子块独立进行量化。通过为每个子块分配独立的缩放因子Scale和零点Zero Point有效减少量化误差。例如Q4_K_M表示每个权重用4比特存储且子块内采用动态范围调整。 K-Quantization混合精度量化 在子块内部进一步划分更小的单元称为“超块”根据数值分布动态选择量化参数。例如Q4_K_M将超块拆分为多个子单元每个子单元使用不同位数的缩放因子如6bit的缩放因子和4bit的量化值通过混合精度平衡精度与压缩率。 重要性矩阵Imatrix优化 通过分析模型推理过程中各层激活值的重要性动态调整量化策略。高重要性区域保留更高精度如FP16低重要性区域采用激进量化如Q2_K从而在整体模型性能损失可控的前提下实现高效压缩。 量化类型分级策略 提供Q2_K至Q8_K等多种量化级别其中字母后缀如_M、_S表示优化级别 Q4_K_M中等优化级别平衡推理速度与精度常用推荐。Q5_K_S轻量化级别侧重减少内存占用
在GGUF的量化类型命名如 Q4_K_M中Q4表示模型的主量化精度为4比特K 和 M 分别代表量化过程中的分块策略Block-wise Quantization和混合精度优化级别。以下是详细解释
K 的含义分块量化Block-wise Quantization
核心思想将权重矩阵划分为多个小块Block对每个块单独进行量化以降低整体误差。技术细节 每个块Block的大小通常为32/64/128个权重值具体数值由量化算法决定。块内共享量化参数如缩放因子和零点减少存储开销。 优势 相比全矩阵量化分块量化能保留更多局部细节降低信息损失。提高量化后模型的生成质量和数学能力。
M 的含义混合精度优化级别 GGUF在分块量化的基础上进一步通过混合不同精度来提升效果M 表示混合策略的强度等级为中等另外还有S和L两个等级
后缀全称说明SSmall/Simple轻度混合仅对关键块使用更高精度如 6-bit其他块用低精度如 4-bitMMedium中等混合更多块使用高精度平衡速度和精度推荐默认选择LLarge高度混合最大化高精度块比例接近原始模型精度速度最慢
以下是关于 GGUF 量化方法选择策略的详细解析包含不同场景下的量化建议和性能对比
GGUF量化方法分类与特性
量化类型比特数内存占用以7B模型为例推理速度精度保持适用场景Q2_K2-bit~2.8GB最快低极低资源设备手机Q3_K_M3-bit~3.3GB快中低快速测试/简单问答Q4_04-bit~3.8GB快中等平衡型通用场景Q4_K_M4-bit~4.0GB中等中高推荐默认选择Q5_05-bit~4.5GB中等高复杂任务代码生成Q5_K_M5-bit~4.7GB中等很高高质量生成推荐首选Q6_K6-bit~5.5GB较慢接近原始学术研究/最小精度损失Q8_08-bit~7.0GB最慢无损基准测试/对比实验
选择建议
优先选择 _K_M 后缀在相同比特数下质量和速度平衡最佳。极端资源场景可用 _K_S 牺牲少量质量换取更快速度。研究用途使用 _K_L 或非混合量化如 Q6_K作为基准。
按硬件资源选择
手机/嵌入式设备 首选 Q4_0 或 Q3_K_M内存 4GB示例在 iPhone 14 上运行 Q4_K_M 的 7B 模型推理速度约 20 tokens/s 低配 PC8GB 内存 选择 Q4_K_M 或 Q5_K_M7B 模型占用约4-5GB 高性能 CPU服务器/工作站 使用 Q5_K_M 或 Q6_K 以获得最佳质量
只要理解了 K 和 M 的含义我们就可以更精准地根据硬件和任务类型选择合适的量化模型了。
参考资料
https://github.com/ggml-org/ggml/blob/master/docs/gguf.mdhttps://huggingface.co/docs/hub/ggufDeepSeek关于GGUF的介绍
