赞
踩
文章的目标是普及开源大型模型的基础知识,建立对这一领域全面而深入的认知。
通过本文的阅读,我们希望读者能够从对Qwen2的了解开始,逐步扩展到对国内其他优秀开源大型模型的认识。
随着对一个模型的熟悉,我们将引导读者逐步掌握对多个模型的理解,从基础概念到深入分析,循序渐进地深化对整个开源大型模型生态的理解。
此外,国内其他开源大模型也都有不错的表现,我们也期待未来会有更多的版本和规模的开源大型模型问世。
Qwen2作为一个起点,将帮助我们构建起对开源大型模型的基本认识,为进一步探索和应用打下坚实的基础。
通过由浅入深的学习,我们相信读者将能够更好地把握开源大型模型的发展趋势,发掘其在各个领域的应用潜力。
最新版本Qwen2有以下特点:
Qwen2博客:qwenlm.github.io/zh/blog/qwe…
Qwen2文档:qwen.readthedocs.io/zh-cn/lates…
"7B"、"57B"、"72B"等参数通常指的是大型语言模型的参数数量,其中的 "B" 代表 "billion",也就是十亿。参数是机器学习模型中用于存储模型知识的基本单元。每个参数可以看作是一个权重或者偏置,它们在模型训练过程中被优化以更好地适应数据。例如:
参数的数量通常与模型的复杂性和能力有关。具有更多参数的模型理论上可以捕捉更复杂的模式和关系,但同时也需要更多的数据来训练,并且计算资源的需求也会更高。
在英文中,以下是一些常见的数字前缀及其含义:
对比看下商用(非开源)的各代ChatGPT的大致参数规模(以十亿参数为单位):
不过即使GPT-4有万亿的参数量,但是跟人脑相比还是小儿科。作为对比,人脑有约1000亿个神经元,每个神经元平均有1000个突触联接,估计人脑有100T(万亿)个参数,现在GPT-4勉强达到了人脑1%的参数水平。
单纯的参数量并不能直接作为智能程度的判断,但是可以作为很重要的参考条件之一,更详细的大模型能力评估请参考权威的模型评测榜单。
接下来看一下目前最新主流开源大模型提供的一些模型规模:
(部分参数模型开源后续有更新,开源时间仅供参考)
这里只列出了部分通用基础开源大模型的参数,不包含垂直领域和多模态类型,但基本上参数规模都比较类似。随着开源大模型发布节奏越来越快、数量和种类越来越多,我们不难看出一些趋势和特性:
我们以Qwen2-7B为例,根据官方推荐:
训练资源
以下三种训练方式需要的最低GPU显存和卡型配置如下:
- 全量参数微调:80GB(例如A100/A800/H100/H800)
- LoRA微调:24GB(例如A10)
- QLoRA微调:16GB(例如A10)
如果您使用更大的batch_size、num_train_epochs、seq_length等超参数,训练可能消耗更大的显存
模型推理
模型支持单机多卡推理
需要的最低卡型配置:GPU显存16G,单卡P100、单卡T4、单卡V100(gn6v)
推荐部署机型:单卡GU30、单卡A10。
如果您的输入token(包含您设定的历史对话)较长,可能需要更大显存的机器进行支持。
我们先忽略与显存和模型规格无关的名词,显存参数A100\A10\A800等等显卡参数解读我们后续会专门推出一篇“算力参数解读”的文章,还有对微调的方式方法、推理的方式方法进行详细独立篇章讲解,敬请期待。
那要如何根据模型规格计算显存需要多少GB呢?
首先我们来了解一下显存,GPU显存(图形处理器显存)的单位通常以字节(Byte)为基础,使用更大单位来表示其容量。以下是常见的GPU显存单位及其对应关系:
一般在讨论GPU显存时,最常用的单位是GB(吉字节)。例如,常见的消费级GPU显存容量有4GB、8GB、12GB、24GB等。
理解这些单位有助于评估GPU的性能和选择合适的硬件来满足不同应用需求。
在深度学习模型训练时,需要了解模型和数据集对显存的需求,以选择合适的GPU,避免内存不足导致计算效率低下或训练无法进行。
在huggingface上有个显存计算推荐工具:huggingface.co/spaces/hf-a…
输入模型名称Qwen/Qwen2-7B即可测算出训练和推理所需显存
该工具能计算在 Hugging Face Hub 上托管的模型上训练和执行大模型推理所需的 vRAM 量。
目前,该工具支持所有使用 Transformer 和 timm 托管的模型。要使用此工具,传入要计算内存使用量的模型的 URL 或模型名称即可,选择它源自哪个框架(“auto”将尝试从模型元数据中检测它),以及想要的精度使用。
可以根据计算结果看到Qwen2-7B大模型张量类型Tensor type(也叫模型精度Model Precision)float16/bfloat16,推理需要14.92GB的显存,训练需要59.69GB的显存,这与官方推荐的推理16GB和训练80GB是在基本在同一个范围的。
具体计算规则请自行研究,这里不做深入讨论,基本上我们获得一些估算数据就足够了,不需要非常精准。
另外我们也要注意这是基于输入长度为1的情况下计算出来的结果,输入长度对模型的计算需求和性能有重大影响,受篇幅所限这块我们放到下一篇去讲。
再介绍一下常见的Tensor类型供参考
这里有篇技术文章可以参考:《淺談DeepLearning的浮點數精度》
57B-A14B Qwen2 基础语言模型是一种混合专家模型 (Mixture-of-Experts,简称 MoE)
MoE是大模型架构的一种,其核心工作设计思路是术业有专攻 ,即将任务分门别类,然后分给多个"专家"进行解决。
与MoE相对应的概念是稠密(Dense)模型,可以理解为它是一个"通才"模型。
一个通才能够处理多个不同的任务,但一群专家能够更高效、更专业地解决多个问题。与一个"通才"相比,一组术业有专攻的"专家"能够提供更好的模型性能、更好地完成复杂的多种任务;同时,也能够在不显著增加计算成本的情况下大幅增加模型容量。
在海外OpenAI的GPT-4、谷歌的Gemini、Mistral AI的Mistral、xAI的Grok-1等主流大模型都采用了MoE架构。
而在国内,昆仑万维的天工3.0、MiniMax的abab6、DeepSeek的DeepSeekMoE 16B等等也都属于MoE模型,相信接下来还会有更多的MoE大模型出现。
关于MoE架构技术详解:huggingface.co/blog/zh/moe
推荐该模型用法不建议使用该基础语言模型来生成文本。相反,可以在此模型上进行post-training,例如 SFT、RLHF、持续预训练等。
与小于 70 亿个参数的训练模型相比,训练像 32B 这样的中型模型的成本很高,而 14B 模型无法像 72B 模型那样很好地执行复杂的任务。
由于最近MoE模型的成功,57B-A14B 就是采用MoE模型架构,根据之前版本的Qwen1.5-MoE-A2.7B,将其扩展到更大的模型尺寸。
具体来说,Qwen将相同的架构和训练策略(例如升级再造)应用于总共有 57B 个参数的模型,其中只有 14B 的参数在每次前向传递中被激活。
基础模型的评估主要集中在自然语言理解、一般问答、编码、数学、科学知识、推理、多语言能力等方面的模型性能。下面是性能评估内容:
MOE:通过多个专家和门控网络处理数据,提高模型的灵活性和效率。
Dense:通过全连接的方式捕捉输入数据的高层次特征。
在 2张 NVIDIA A100 卡上使用 vLLM 部署的两个模型的推理性能:
Qwen2-57B-A14B | Qwen1.5-32B | |
---|---|---|
QPS | 9.40 | 5.18 |
TPS | 10345.17 | 5698.37 |
QPS和TPS是衡量系统性能的两个重要指标,它们分别代表:
QPS (Queries Per Second) - 每秒查询次数:
- 这个指标用来衡量数据库系统或服务器在一秒钟内能够处理的查询请求的数量。
- QPS 通常用于衡量数据库的读取性能,尤其是在需要快速响应的在线查询场景中。
- 例如,在Web应用中,QPS可以用来衡量服务器在高并发环境下处理用户请求的能力。
TPS (Transactions Per Second) - 每秒事务次数:
- TPS 是衡量数据库系统在一秒钟内能够处理的事务数量的指标。
- 事务通常指的是一系列操作,这些操作作为一个整体被执行,要么全部成功,要么全部失败(符合ACID原则:原子性、一致性、隔离性、持久性)。
- TPS 更多地用于衡量数据库的写入性能,尤其是在需要处理复杂事务的业务场景中。
从效率方面来看,明显可以看到Qwen2-57B-A14B相较于Qwen1.5-32B具有显著优势。此外,根据先前在基准测试上关于模型性能的报告,可以发现Qwen2-57B-A14B相比参数激活更多的Qwen1.5-32B,在模型质量上获得了更优的表现。
Qwen2有:Qwen2-7B、Qwen2-7B-Instruct、Qwen2-72B、Qwen2-72B-Instruct等等多个版本,那有-Instruct与没有-Instruct的区别是什么呢?我们耐心往下看:
首先我们要了解基础语言模型(Base Language Models)、微调模型(Fine-tuned Models)、预训练模型(Pre-trained Models)和指令调优模型(Instruction-tuned Models)在训练方式和应用场景上的不同
Qwen/Qwen2-7B
、Qwen/Qwen2-72B
、Qwen/Qwen1.5-7B
、Qwen/Qwen1.5-72B
、Qwen/Qwen-7B
、Qwen/Qwen-72B
meta-llama/Llama-2-7b-chat
、meta-llama/Llama-2-13b-chat
、meta-llama/Llama-2-70b-chat
google/gemma-2-9b
、google/gemma-2-27b
、google/gemma-2b
、google/gemma-7b
、meta-llama/Meta-Llama-3-8B
、meta-llama/Meta-Llama-3-70B
、meta-llama/Llama-2-7b
、meta-llama/Llama-2-13b
、meta-llama/Llama-2-70b
Qwen/Qwen2-7B-Instruct
、Qwen/Qwen2-72B-Instruct
、google/gemma-2-9b-it
、google/gemma-2-27b-it
、google/gemma-2b-it
、google/gemma-7b-it
、meta-llama/Meta-Llama-3-8B-Instruct
、meta-llama/Meta-Llama-3-70B-Instruct
。另外还有"Aligned Chat Models" 是指那些经过特别训练和调优,以确保其生成的内容与特定的目标或价值观对齐,并能符合用户的需求和预期的聊天模型,例如Qwen/Qwen1.5-7B-Chat
、Qwen/Qwen1.5-72B-Chat
、Qwen/Qwen-7B-Chat
、Qwen/Qwen-72B-Chat
,模型名称后面带-Chat,也是一种指令调优模型或预训练模型。可以看出不同模型具体分类没有很明确的分界线,这里做一个归纳总结供大家参考。
综合对比
类型 | 主要特点 | 训练方式 | 数据类型 | 用途 |
---|---|---|---|---|
基础语言模型 | 建立语言理解和生成基础 | 自监督学习 | 大规模通用文本数据 | 用于后续微调或特定任务训练 |
微调模型 | 优化特定任务性能 | 微调基础语言模型 | 特定任务的标注数据 | 特定任务如情感分析、文本分类 |
预训练模型 | 广泛任务应用的基础 | 大规模预训练 | 通用或特定领域文本数据 | 多种下游任务的初步模型 |
指令调优模型 | 通过指令优化响应能力 | 指令和人类反馈调优 | 指令和反馈数据 | 高度人类指令特定任务 |
我们接着Qwen2-7B-Instruct继续往下看,基于Instruct还有很多模型版本:Qwen/Qwen2-7B-Instruct-AWQ
、Qwen/Qwen2-7B-Instruct-GPTQ-Int8
、Qwen/Qwen2-7B-Instruct-GPTQ-Int4
、Qwen/Qwen2-7B-Instruct-GGUF
、Qwen/Qwen2-7B-Instruct-MLX
,这都是采用不同量化技术的版本。
量化技术专注于用较少的信息来表示数据,同时尽量不损失太多的精度。这通常意味着转换数据类型以用更少的位来表示相同的信息。例如,如果您的模型权重存储为 32 位浮点数,并且它们被量化为 16 位浮点数,则模型大小会减半,从而更易于存储并减少内存使用量。较低的精度也可以加快推理速度,因为用较少的位执行计算所需的时间更少。
每种量化方法都有各自的优缺点。
例如,一些量化方法需要使用数据集校准模型以实现更准确和“极端”的压缩(高达 1-2 位量化),而其他方法则可通过即时量化来实现。
另一个需要考虑的参数是与目标设备的兼容性,到底在 CPU、GPU 还是 Apple 芯片上进行量化?
下面的表格可能帮助你决定使用哪种量化方法:
AWQ(Activation-aware Weight Quantization-激活值感知的权重量化)不会量化模型中的所有权重,而是保留一小部分对 LLM 性能至关重要的权重。
GPTQ是一种post-training量化技术,它基于近似二阶信息进行一次性权重量化。
GGUF是一种文件格式,也是一种量化方法,允许用户在 CPU 上运行 LLM,同时将其部分层次转移到 GPU 上以加速运行
Qwen/Qwen2-7B-Instruct-GPTQ-Int8
、Qwen/Qwen2-7B-Instruct-GPTQ-Int4
是基于Qwen/Qwen2-7B-Instruct-GPTQ的不同版本,类似的npc0/chatglm-4-9b-int8
、npc0/chatglm-4-9b-int4
也是一样。
Qwen2量化模型(包括GPTQ与AWQ量化方案)的效果评估如下,采用数据集:MMLU (准确率)、C-Eval (准确率)、IFEval (提示词级的严格准确率,Strict Prompt-Level Accuracy),所有模型均使用贪心解码。
从这些数据可以看出,对于GPTQ-Int8和GPTQ-Int4,量化精度的降低(从8位到4位)通常会导致模型在各个数据集上的准确率有所下降。
然而,具体到每个模型和数据集,这种下降的程度可能会有所不同。例如,对于Qwen2-72B-Instruct模型,在IFEval数据集上,GPTQ-Int4的准确率比GPTQ-Int8的准确率高1.4个百分点,而在其他数据集上,GPTQ-Int8的准确率则更高。
总的来说,量化精度的选择是一个权衡,需要在模型大小、计算效率和模型性能之间找到平衡点。
如果我们认可上面这份量化模型效果评估结果的话,那这次我们选一个大参数模型Qwen2-72B-Instruct为例对比一下模型文件大小、参数大小更能感受到差异:
Qwen2-72B-Instruct | Qwen2-72B-Instruct-GPTQ-Int8 | Qwen2-72B-Instruct-GPTQ-Int4 | |
---|---|---|---|
模型文件大小 | ≈148.67 GB | ≈77.38 GB | ≈41.65 GB |
模型参数大小 | 72.7B | 20.8B | 11.9B |
效果评估平均 | 81.3 | 80.7 | 81.2 |
从上述对比中可以看出,虽然 Qwen2-72B-Instruct
在效果评估上稍好,但代价是需要更大的文件和更多的计算资源。而 Qwen2-7B-Instruct-GPTQ-Int4
尽管参数规模小很多,性能几乎不受影响,非常适合在资源受限环境下的部署
我们最后来看一下效率评估结果来结束这一篇内容。
Qwen2模型(原始模型和量化模型)的效率测试结果包括推理速度(tokens/s)与不同上下文长度时的显存占用(GB)。原文 测试HuggingFace transformers
时的环境配置:
我们还是看Qwen2-72B-Instruct
我们再看一下Qwen2-7B-Instruct
可以看到显存占用在输入长度为1的时候需要14.92GB,这也印证了我们前文说到的模型规模与显存大小估算结果是比较正确的。
我们再回过头来看看阿里对待开源生态的态度,Qwen2作为国内开源模型的领头羊,除了Qwen2-72B依旧使用此前的Qianwen License外,其余模型,包括Qwen2-0.5B、Qwen2-1.5B、Qwen2-7B以及Qwen2-57B-A14B在内,均采用Apache 2.0的许可。
现在,模型均已开源在Hugging Face和ModelScope上。欢迎查阅模型卡了解具体用法和更多关于模型的信息,如特性、指标等。
长时间以来,来自开源生态的朋友们一致支持着Qwen的发展,包括:
微调:(Axolotl、Llama-Factory、Firefly、Swift、XTuner)
量化:(AutoGPTQ、AutoAWQ、Neural Compressor)
部署:(vLLM、SGL、SkyPilot、TensorRT-LLM、OpenVino、TGI)
本地运行:(MLX、Llama.cpp、Ollama、LM Studio)
Agent及RAG框架:(LlamaIndex, CrewAI, OpenDevin)
评测:(LMSys, OpenCompass, Open LLM Leaderboard)
想了解更多关于如何在三方框架中使用Qwen,欢迎阅读各项目的官方文档以及官方文档了解更多用法!
当然,这里还有很多一直帮助我们的朋友们未被提及。我们真诚地感谢大家的支持,我们也希望社区的合作能够携手推动开源AI的发展。
从内容不难看出开源AI生态的多面性,涵盖了微调、量化、部署、本地运行、Agent及RAG技术、评测工具以及模型二次开发等多个关键领域。
这里面提到的每个领域单独拎出来讲都是一个全新的宏大主题,背后都是无数工程师的心血凝练,这些领域的丰富性和多样性不仅体现了开源社区的创新精神,也展示了其对AI技术进步的重要贡献。
随着社区合作在推动开源AI发展中的作用日益凸显,我们正步入一个不再由单一或少数企业主导AI技术发展的时代。社区、企业、组织间的紧密联系和相互依赖,共同塑造了一个更加繁荣的生态系统。这种生态的繁荣对下游的中小企业和组织尤为有利:
我认为开源AI生态的发展不仅促进了技术的创新和普及,也为整个行业带来了更加公平和可持续的发展环境,这也让我们作为“中小企业和组织的人工智能技术服务提供商”有了更清晰的目标和广阔的发展空间。
随着更多的参与者加入到这个生态系统中,我们可以期待一个更加开放、协作和充满活力的未来。
下一篇我们会重点关注上下文长度、多语言支持、全方位能力对比分析等部分,期待关注下期精彩。
作者:StrangeXin
链接:https://juejin.cn/post/7385752495534604303
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。