社区供稿 | 源大模型的快速部署与高效推理——GGUF格式模型介绍与使用教程

简介: 在人工智能领域,大型语言模型的发展日新月异,它们在自然语言处理、机器翻译、智能助手等多个领域展现出了前所未有的能力。

GGUF简介

在人工智能领域,大型语言模型的发展日新月异,它们在自然语言处理、机器翻译、智能助手等多个领域展现出了前所未有的能力。然而,随着模型规模的不断扩大,这些庞大的神经网络模型在存储、传输和加载上面临着一系列挑战。传统的文件格式在处理这些庞大的数据集时显得力不从心,不仅效率低下,而且兼容性和扩展性也难以满足日益增长的需求。

在这样的背景下,GGUF(GPT-Generated Unified Format)应运而生。由开发者Georgi Gerganov提出,GGUF格式是专为大型语言模型设计的二进制文件格式,旨在解决当前大模型在实际应用中遇到的存储效率、加载速度、兼容性和扩展性等问题。GGUF通过优化数据结构和编码方式,显著提升了模型文件的存储效率,同时保证了快速的加载性能。此外,它的设计考虑了跨平台和跨框架的兼容性,使得模型能够无缝地在不同的硬件和软件环境中运行,极大地促进了大型模型的广泛应用和进一步发展。

当前,GGUF格式广泛应用于各类大模型的部署和分享,特别是在Hugging Face等开源社区中广受欢迎。GGUF格式模型在实际使用中体现出的主要特点和优势包括:

  1. 高效存储:GGUF格式优化了数据的存储方式,减少了存储空间的占用,这对于大型模型尤为重要,因为它们通常包含大量的参数。
  2. 快速加载:GGUF格式支持快速加载模型数据,这对于需要即时响应的应用场景非常有用,比如在线聊天机器人或实时翻译系统。
  3. 兼容性:作为一种统一的格式,GGUF旨在提高不同平台和框架之间的兼容性,使得模型可以在不同的环境和硬件上无缝运行。
  4. 可扩展性:随着模型规模的不断扩大,GGUF格式设计时考虑到了未来的扩展性,以适应更大规模的模型和更复杂的数据结构。

本文以下部分将着重介绍当下源大模型对于GGUF格式的支持情况以及开发者在实际使用体验过程中如何使用GGUF格式的模型进行部署、推理、量化等技术细节。

Yuan2.0-2B模型的GGUF应用

Yuan2.0模型简介

源2.0 是浪潮信息发布的新一代基础语言大模型。我们开源了全部的3个模型源2.0-102B,源2.0-51B和源2.0-2B。并且我们提供了预训练,微调,推理服务的相关脚本,以供研发人员做进一步的开发。源2.0是在源1.0的基础上,利用更多样的高质量预训练数据和指令微调数据集,令模型在语义、数学、推理、代码、知识等不同方面具备更强的理解能力。

更多详情请参考Yuan2.0模型

  • 技术报告

https://arxiv.org/ftp/arxiv/papers/2311/2311.15786.pdf

  • Github

https://github.com/IEIT-Yuan/Yuan-2.0

 

本项目基于llama.cpp(version:b1742)在Windows系统(CPU Only)上对源2.0-2B模型的适配。本项目的Github地址为:

llamacpp for Yuan

https://github.com/IEIT-Yuan/3rd_party/

由于源2.0模型结构与llama结构存在差异,针对源2.0模型(Yuan2.0-2B)模型LFA结构,进行如下修改:

  • llama计算图中添加LFA结构,修改ggml_conv_1d逻辑,以适配源2.0,保证前后序列长度不变;
  • llama计算图中添加q、k混合相关的逻辑;
  • 修改IM2COL算子,修改数组的读取方式;
  • 修改ADD算子,将卷积模块的输出进行转置,以适配后面的计算;
  • 修改concat算子,以适配q、k混合的逻辑;
  • 支持多线程推理,加速生成速率;

目前支持fp16精度模型的gguf文件转换,后续会持续进行其他精度的工作。

Yuan2.0-2B模型的GGUF应用

实现对Yuan2.0-2B模型的GGUF格式转换需要克隆llamacpp for Yuan项目到本地并进入工作目录。

格式转化

对已有的hf格式模型转化为GGUF格式

python convert.py --model yuan2b-hf\yuan2-2B --outfile zh-models/Yuan2-2B-Februa-hf-GGUF.gguf

image.gif

编译

下一步为了使用对GGUF格式模型调用并部署推理,我们需要编译该项目,同样在该项目的工作目录执行编译。

对于Linux和MacOS系统,可以使用make工具,在工作目录下执行

make

image.gif

对于Windows系统,可以使用cmake工具,在工作目录下执行

mkdir build
cd build
cmake ..
cmake --build . --config Release

image.gif

模型测试

成功完成上述编译后,工作目录会生成编译好的可执行文件 main.exe,下一步我们就使用该文件进行GGUF格式模型的调用和推理测试。

我们使用的测试环境配置如下:

  • python3.9
  • 11th Gen Intel(R) Core(TM) i5-1145G7 @2.60GHz 2.61GHz
  • 8.00GB RAM
  • Windows 10专业版(21H1)

我们以”北京简介“为prompt对先前转化出来的GGUF格式Yuan2.0-2B模型进行测试,记得将下方代码中的模型路径替换为您设备上GGUF格式模型存储的路径。

main.exe -m D:\\llama-cpp\\llama.cpp\\zh-models\\Yuan2-2B-Februa-hf-GGUF.gguf -p "北京简介" -n 400  --top-k  5 --threads 4

image.gif

在我们的测试环境下得到的终端输出如下所示

llama_new_context_with_model: n_ctx      = 512
llama_new_context_with_model: freq_base  = 10000.0
llama_new_context_with_model: freq_scale = 1
llama_new_context_with_model: KV self size  =   96.00 MiB, K (f16):   48.00 MiB, V (f16):   48.00 MiB
llama_build_graph: non-view tensors processed: 628/820
llama_build_graph: ****************************************************************
llama_build_graph: not all non-view tensors have been processed with a callback
llama_build_graph: this can indicate an inefficiency in the graph implementation
llama_build_graph: build with LLAMA_OFFLOAD_DEBUG for more info
llama_build_graph: ref: https://github.com/ggerganov/llama.cpp/pull/3837
llama_build_graph: ****************************************************************
llama_new_context_with_model: compute buffer total size = 270.94 MiB
Model metadata: {'tokenizer.ggml.add_eos_token': 'true', 'tokenizer.ggml.padding_token_id': '77185', 'tokenizer.ggml.seperator_token_id': '77185', 'tokenizer.ggml.eos_token_id': '77185', 'general.architecture': 'llama', 'llama.context_length': '8192', 'general.name': 'E:\\ckpts\\yuan2b-hf', 'tokenizer.ggml.add_bos_token': 'true', 'llama.embedding_length': '2048', 'llama.feed_forward_length': '8192', 'llama.attention.layer_norm_rms_epsilon': '0.000001', 'llama.rope.dimension_count': '64', 'llama.attention.head_count': '32', 'tokenizer.ggml.bos_token_id': '77185', 'llama.block_count': '24', 'llama.attention.head_count_kv': '32', 'tokenizer.ggml.model': 'llama', 'general.file_type': '1'}
北京是中国的首都,是华北地区的中心城市。它是中国政治、文化和经济的中心,也是中国最大的城市之一。北京具有悠久的历史和丰富的文化遗产,包括长城、故宫、天坛等世界闻名的古迹,以及现代化的摩天大楼和购物中心。
北京也是中国的教育和科研中心,拥有众多高等院校和科研机构,为中国培养了许多杰出人才。此外,北京还是中国重要的商业和交通中心,拥有众多的商业区和购物中心。
北京还是一个旅游胜地,吸引着大量的国内外游客前来参观和旅游。著名的景点包括故宫博物院、颐和园、天坛公园、八达岭长城等。这些景点都有着独特的历史文化背景和壮观的自然风光,给人们带来了不同的体验。
总的来说,北京是一个历史悠久、文化底蕴丰富、旅游胜地众多的城市,值得一游。无论是对于艺术爱好者、历史文化爱好者还是自然探索者,北京都有着不可多得的体验。
llama_print_timings:        load time =     579.04 ms
llama_print_timings:      sample time =     126.74 ms /   193 runs   (    0.66 ms per token,  1522.81 tokens per second)
llama_print_timings: prompt eval time =     578.98 ms /     4 tokens (  144.74 ms per token,     6.91 tokens per second)
llama_print_timings:        eval time =   20562.87 ms /   192 runs   (  107.10 ms per token,     9.34 tokens per second)
llama_print_timings:       total time =   22961.55 ms

image.gif

此外,我们还对比了在相同任务下GGUF格式和原始hf格式模型的推理性能和内存占用情况,结果如下表格所示:

推理性能

GGUF格式(C++)

HF格式(Python)

加速比

9.16 tokens/s

1.21 tokens/s

7.57

内存占用

GGUF格式(C++)

HF格式(Python)

内存占比(GGUF/HF)

~0.4 GB

~8.6 GB

4.65%

从上方表格的结果我们不难看出使用GGUF格式模型可以显著提升模型部署后的推理速度,同时可以有效降低模型使用时对于内存的占用。

结论

本文深入探讨了GGUF(GPT-Generated Unified Format)格式在大型语言模型领域的应用,及其在提高模型存储效率、加载速度、兼容性和可扩展性方面的重要性。通过对Yuan2.0-2B模型的适配和测试,我们验证了GGUF格式在实际应用中的高效性和稳定性。测试结果表明,使用GGUF格式的模型在推理速度和内存占用方面均优于传统的HF格式,这不仅提高了模型的运行效率,也降低了资源消耗。

最后,GGUF格式的可扩展性为未来更大规模模型的发展提供了支持,确保了格式能够适应不断进步的技术需求。随着开源社区和开发者的不断贡献,GGUF格式有望成为大型语言模型部署和分享的新标准,进一步推动人工智能技术的创新和发展。Yuan2.0系列模型也将持续支持GGUF格式,为开发者带来更好的使用体验。

关于源大模型的更多信息

更多信息,请访问以下页面

YuanChat Github 项目主页:

GitHub - IEIT-Yuan/YuanChat

Yuan 2.0 Github 项目主页:

GitHub - IEIT-Yuan/Yuan-2.0: Yuan 2.0 Large Language Model

Yuan 2.0-M32 Github 项目主页:

Github Yuan2.0-M32

Yuan 2.0 系列模型Hugging Face 主页:

https://huggingface.co/IEITYuan

Yuan 2.0 系列模型Modelscope 主页:

https://modelscope.cn/organization/IEITYuan

相关文章
|
2月前
|
消息中间件 人工智能 资源调度
云上AI推理平台全掌握 (5):大模型异步推理服务
针对大模型推理服务中“高计算量、长时延”场景下同步推理的弊端,阿里云人工智能平台 PAI 推出了一套基于独立的队列服务异步推理框架,解决了异步推理的负载均衡、实例异常时任务重分配等问题,确保请求不丢失、实例不过载。
|
2月前
|
存储 机器学习/深度学习 缓存
阿里云AirCache技术实现多模态大模型高效推理加速,入选国际顶会ICCV2025
阿里云研发的AirCache技术被计算机视觉顶会ICCV2025收录,该技术通过激活跨模态关联、优化KV缓存压缩策略,显著提升视觉语言模型(VLMs)的推理效率与存储性能。实验表明,在保留仅10%视觉缓存的情况下,模型性能下降小于1%,解码延迟最高降低66%,吞吐量提升达192%。AirCache无需修改模型结构,兼容主流VLMs,已在教育、医疗、政务等多个行业落地应用,助力多模态大模型高效赋能产业智能化升级。
270 1
|
2月前
|
人工智能 运维 Serverless
0 代码,一键部署 Qwen3
依托于阿里云函数计算 FC 算力,Serverless + AI 开发平台 FunctionAI 现已提供模型服务、应用模版两种部署方式辅助您部署 Qwen3 系列模型。完成模型部署后,您即可与模型进行对话体验;或以 API 形式进行调用,接入 AI 应用中,欢迎您立即体验。
|
2月前
|
人工智能 缓存 资源调度
云上AI推理平台全掌握 (4):大模型分发加速
为应对大模型服务突发流量场景,阿里云人工智能平台 PAI 推理服务 PAI-EAS 提供本地目录内存缓存(Memory Cache)的大模型分发加速功能,有效解决大量请求接入情况下的推理延迟。PAI-EAS 大模型分发加速功能,零代码即可轻松完成配置。
|
7天前
|
机器学习/深度学习 算法 数据可视化
从零开始训练推理模型:GRPO+Unsloth改造Qwen实战指南
推理型大语言模型兴起,通过先思考再作答提升性能。本文介绍GRPO等强化学习算法,详解其原理并动手用Qwen2.5-3B训练推理模型,展示训练前后效果对比,揭示思维链生成的实现路径。
109 1
从零开始训练推理模型:GRPO+Unsloth改造Qwen实战指南
|
25天前
|
机器学习/深度学习 人工智能 JSON
微软rStar2-Agent:新的GRPO-RoC算法让14B模型在复杂推理时超越了前沿大模型
Microsoft Research最新推出的rStar2-Agent在AIME24数学基准测试中以80.6%的准确率超越超大规模模型DeepSeek-R1,展现“思考更聪明”而非“更长”的AI推理新方向。
103 8
微软rStar2-Agent:新的GRPO-RoC算法让14B模型在复杂推理时超越了前沿大模型
|
19天前
|
人工智能 云栖大会
2025云栖大会大模型应用开发与部署|门票申领
2025云栖大会大模型应用开发与部署门票申领
|
19天前
|
存储 缓存 负载均衡
LLM推理成本直降60%:PD分离在大模型商业化中的关键价值
在LLM推理中,Prefill(计算密集)与Decode(访存密集)阶段特性不同,分离计算可提升资源利用率。本文详解vLLM框架中的PD分离实现及局限,并分析Dynamo、Mooncake、SGLang等主流方案,探讨KV缓存、传输机制与调度策略,助力LLM推理优化。建议点赞收藏,便于后续查阅。
404 1
|
20天前
|
算法 安全 开发者
大模型部署指南:从个人玩转到企业级应用,这4款工具必看!
本文介绍了五款主流大语言模型部署工具,帮助用户根据需求选择合适的方案。包括适合个人使用的 Ollama 和 LM Studio、优化低配设备运行的 llama.cpp、企业级部署的 vLLM,以及 Hugging Face 推出的 TGI 框架,覆盖从本地体验到高性能服务的多种场景。

热门文章

最新文章