社区供稿 | 2张卡部署72B大模型 - 百亿大模型部署系列

简介: 2张卡部署72B大模型

2张卡部署72B大模型

0x00 前言

在23年初,还只是勉强跑起来6B的我,是怎么也想不到,在24年的时候,72B也能勉勉强强跑起来了。

直接说结论:

  • • 部署的模型 Qwen-72B-Int4
  • • 性能指标
  • • token处理速度 5.86 token/s
  • • 每次对话上下文上限 1000 token
  • • 基准测试情况:
  • • 跑了3000个任务,输入500个字,输出500个字左右,稳定跑完。

如果上面的性能指标能够满足你的业务诉求又或者想试一下最顶级的大模型,那就接着继续往下看吧。

0x01 部署环境

1. 硬件环境

  • • 两张 3090( 24G*2 = 48G 内存)
  • • 内存 64G
  • • CPU 32核

总计花费 2W出头。(8千一张卡)

2. 软件环境

  • • ubuntu22.04
  • • cuda11.8.0
  • • py310
  • • torch2.1.0
  • • tf2.14.0-1.10.0

3. 模型选型

https://github.com/QwenLM/Qwen/blob/main/README_CN.md

Qwen-72B-Chat(Int4)基本没什么太大的损失。

但是 Qwen-72B-Chat(Int4)只需要 BF16的1/3的资源。

0x02 部署

直接一把梭,很遗憾,没成功。

根据魔搭的样例 , 怀着侥幸的心理,想蒙混过关,啥也没弄,直接跑了一把:


from modelscope import AutoTokenizer, AutoModelForCausalLM
from modelscope import snapshot_download
model_dir = snapshot_download('qwen/Qwen-72B-Chat-Int4', revision='master')
tokenizer = AutoTokenizer.from_pretrained(model_dir, revision='master', trust_remote_code=True)

model = AutoModelForCausalLM.from_pretrained(
   model_dir, revision='master',
  device_map="auto" ,
   trust_remote_code=True
).eval()
response, history = model.chat(tokenizer, "你好", history=None)
print(response)

结果报错:


device_map 导致内存分配不均

仔细分析后,发现是 device_map 导致的内存分配不均。当前GPU0 用了22GGPU1 用了16G,还有8G没打满,想了想,应该还是有机会加载完成的。

在官方的文档中 https://huggingface.co/docs/transformers/main_classes/model , 以及 博客 https://huggingface.co/blog/accelerate-large-models 发现device_map 有4种用法:

模式 作用
auto 模型均匀地分配到所有可用的 GPU 上。
balanced 模型均匀地分配到所有可用的 GPU 上。
balanced_low_0 除了第1个GPU,模型均匀地分配其它GPU上。
sequential 从第1个GPU开始分配,直到最后1个GPU分配完。

但是理想很美好,显示很骨感,无论怎么修改,始终没办法加载成功。

正当以为没辙之际,突然看到还有一句 You can also pass your own device_map as long as it follows the format we saw before (dictionary layer/module names to device). 即 自己控制每一层分配到哪个GPU。

然后找了一下千问的官方人员咨询了一下,不一会儿,官方人员把手动的切好的 device_map 发了过来。

device_map={'transformer.wte': 0, 'transformer.drop': 0, 'transformer.rotary_emb': 0, 'transformer.h.0': 0,'transformer.h.1': 0, 'transformer.h.2': 0, 'transformer.h.3': 0, 'transformer.h.4': 0, 'transformer.h.5': 0, 'transformer.h.6': 0, 'transformer.h.7': 0, 'transformer.h.8': 0, 'transformer.h.9': 0, 'transformer.h.10': 0, 'transformer.h.11': 0, 'transformer.h.12': 0, 'transformer.h.13': 0, 'transformer.h.14': 0, 'transformer.h.15': 0, 'transformer.h.16': 0, 'transformer.h.17': 0, 'transformer.h.18': 0, 'transformer.h.19': 0, 'transformer.h.20': 0, 'transformer.h.21': 0, 'transformer.h.22': 0, 'transformer.h.23': 0, 'transformer.h.24': 0, 'transformer.h.25': 0, 'transformer.h.26': 0, 'transformer.h.27': 0, 'transformer.h.28': 0, 'transformer.h.29': 0, 'transformer.h.30': 0, 'transformer.h.31': 0, 'transformer.h.32': 0, 'transformer.h.33': 0, 'transformer.h.34': 0, 'transformer.h.35': 0, 'transformer.h.36': 0, 'transformer.h.37': 0, 'transformer.h.38': 0, 'transformer.h.39': 0, 'transformer.h.40': 0, 'transformer.h.41': 1, 'transformer.h.42': 1, 'transformer.h.43': 1, 'transformer.h.44': 1, 'transformer.h.45': 1, 'transformer.h.46': 1, 'transformer.h.47': 1, 'transformer.h.48': 1, 'transformer.h.49': 1, 'transformer.h.50': 1, 'transformer.h.51': 1, 'transformer.h.52': 1, 'transformer.h.53': 1, 'transformer.h.54': 1, 'transformer.h.55': 1, 'transformer.h.56': 1, 'transformer.h.57': 1, 'transformer.h.58': 1, 'transformer.h.59': 1, 'transformer.h.60': 1, 'transformer.h.61': 1, 'transformer.h.62': 1, 'transformer.h.63': 1, 'transformer.h.64': 1, 'transformer.h.65': 1, 'transformer.h.66': 1, 'transformer.h.67': 1, 'transformer.h.68': 1, 'transformer.h.69': 1, 'transformer.h.70': 1, 'transformer.h.71': 1, 'transformer.h.72': 1, 'transformer.h.73': 1, 'transformer.h.74': 1, 'transformer.h.75': 1, 'transformer.h.76': 1, 'transformer.h.77': 1, 'transformer.h.78': 1, 'transformer.h.79': 1, 'transformer.ln_f': 1, 'lm_head': 1}


重新加载了一下,成功输出。

有没有可能,在没有官方人员的协助下,自己来完成这个device_map的分解?

当然是可以的。 如果遇到一个大模型,自己算了一下,显存是可以放的下的话,那么可以通过来加载。

from transformers import AutoConfig, AutoModelForCausalLM

config = AutoConfig.from_pretrained(modelpath)
with init_empty_weights():
   model = AutoModelForCausalLM.from_config(config)

如图,可以看到Qwen的结构如下,此时并没有加载模型。

可以通过 for name,md in   model.named_children():  打印每一层的size , 这样遇到自己加载失败的模型就可以自己手搓 device_map 了。

最后,安装 flash-attn 。

在软件环境和我相同的情况下,直接一个命令 pip install flash-attn --no-build-isolation

就是编译和时间会等很久。

0x03 测试

使用 脑筋急转弯 100 道题目,统计 histroy的token,提问和回答累计达到的 x个 token 来评估能力。

每轮跑3000次,次数是随便拍的,想起周星驰电影,要你命3000,评估是否会OOM。

测试结果如下,到了2000就直接跑不动了 😢,放弃继续测试了:

x 没有OOM token /s
1000 5.86
2000

0x04 总结

遇到没办法加载的大模型怎么办?

  • • 评估一下显存是否足够。
  • • 通过 AutoConfig 加载模型的参数,评估一下是否可以拆分。
  • • 手写 device_map 尝试加载。
相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
相关文章
|
6月前
|
缓存 API 开发者
魔搭社区牵手FastChat&vLLM,打造极致LLM模型部署体验
FastChat是一个开放平台,用于训练、服务和评估基于LLM的ChatBot。
|
6月前
|
数据采集 自然语言处理 前端开发
社区供稿 | 猎户星空百亿参数大模型 Orion-14B系列开源,一张3060就能跑(附魔搭社区推理微调最佳实践)
1月21日,傅盛在猎户星空大模型发布会上宣布,“为企业应用而生” 的开源百亿参数猎户星空大模型正式发布。猎户星空大模型(Orion-14B)是由猎户星空研发的预训练多语言大语言模型,以其140亿参数规模展现出了卓越的性能。
|
机器学习/深度学习 人工智能 算法
阿里公开自研AI集群细节:64个GPU,百万分类训练速度提升4倍
从节点架构到网络架构,再到通信算法,阿里巴巴把自研的高性能AI集群技术细节写成了论文,并对外公布。
阿里公开自研AI集群细节:64个GPU,百万分类训练速度提升4倍
|
2月前
|
机器学习/深度学习 人工智能 自然语言处理
社区供稿 | 元象发布255B大规模MoE开源大模型,落地应用登顶港台榜
元象XVERSE发布 中国最大MoE开源模型:XVERSE-MoE-A36B,加速AI应用低成本部署,将国产开源提升至国际领先水平。
社区供稿 | 元象发布255B大规模MoE开源大模型,落地应用登顶港台榜
|
5月前
|
编解码 人工智能 测试技术
ShareGPT4V作者团队又一力作!百万高质量视频-字幕数据助力社区提升多模态大模型视频理解及生成能力
【6月更文挑战第30天】ShareGPT4Video`团队推出百万视频-字幕数据集,强化多模态模型的视频理解和生成。包括40K视频的`ShareGPT4Video`数据集、`ShareCaptioner-Video`模型和8B参数的`ShareGPT4Video-8B`模型,后者在视频基准测试中取得最佳效果。差异化字幕生成策略解决了传统方法的局限。尽管取得突破,但数据规模和模型泛化仍是未来挑战。[论文链接](https://arxiv.org/abs/2406.04325v1)
66 1
|
6月前
|
人工智能 Rust Apache
社区供稿 | 更长、更强、更开放,零一万物 Yi-1.5 系列开源模型发布一周广受好评
5 月 13 日,零一万物 Yi 系列开源模型全新升级为 Yi-1.5。相较于去年 11 月的开源版本,这次的 Yi-1.5 在保持原 Yi 系列模型优秀的通用语言能力的前提下,通过增量训练 500B 高质量 token,大幅提高了数学逻辑、代码能力。
|
机器学习/深度学习 自然语言处理 测试技术
社区供稿 | 封神榜团队揭秘大模型训练秘密:以数据为中心
近一年来,各种各样的开源和闭源的大语言模型,不断在多个中文英文的测试基准中刷新着记录。然而,大语言模型的开发仍然面临诸多挑战,比如从头开始训练大语言模型的高昂成本,以及继续预训练导致的灾难性遗忘等等。尽管许多研究致力于解决这些问题,但一个重要而且实际的限制是,许多研究过于追求扩大模型规模,没有全面分析和优化预训练数据在训练大语言模型过程中的使用。
|
6月前
|
存储 自然语言处理 负载均衡
元象开源首个MoE大模型:4.2B激活参数,效果堪比13B模型,魔搭社区最佳实践来了
近日,元象发布其首个Moe大模型 XVERSE-MoE-A4.2B, 采用混合专家模型架构 (Mixture of Experts),激活参数4.2B,效果即可媲美13B模型。该模型全开源,无条件免费商用,支持中小企业、研究者和开发者可在元象高性能“全家桶”中按需选用,推动低成本部署。
|
6月前
|
人工智能 Apache
社区供稿 | 140B参数、可商用!OpenBuddy 发布首个开源千亿中文 MoE 模型的早期预览版
我们很自豪地于今天发布OpenBuddy最新一代千亿MoE大模型的早期预览版本:OpenBuddy-Mixtral-22Bx8-preview0-65k。此次发布的早期预览版对应约50%的训练进度。