社区供稿 | 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盲盒。
相关文章
|
8月前
|
机器学习/深度学习 vr&ar 决策智能
创新性3D数据合成模型,微软推出EgoGen
【2月更文挑战第6天】创新性3D数据合成模型,微软推出EgoGen
71 2
创新性3D数据合成模型,微软推出EgoGen
|
21天前
|
存储 人工智能 编解码
多模态实时交互大模型浦语·灵笔 2.5 OmniLive开源:能看、能听、会记、会说!
2024年12月12日,多模态实时交互大模型书生·浦语灵笔2.5-OL(InternLM-XComposer2.5-OmniLive)开源,该模型可以通过视觉和听觉实时观察和理解外部世界,自动形成对观察到内容的长期记忆,并可通过语音与人类用户进行对话交谈,提供更自然的大模型交互体验。
多模态实时交互大模型浦语·灵笔 2.5 OmniLive开源:能看、能听、会记、会说!
|
8天前
|
人工智能 自动驾驶 安全
《解锁数据新动能:数据标注工具与AI模型训练平台的无缝对接热潮》
在人工智能快速发展的今天,数据成为核心驱动力。数据标注工具与模型训练平台的集成,实现了数据无缝流转,犹如为AI发展装上双引擎。集成不仅提高了数据传输效率、减少了人工干预,还确保了数据准确性,提升了模型性能。统一的数据标准、高效的接口设计和严格的安全保障是实现无缝流转的关键要素。这种集成推动了医疗、自动驾驶等领域的快速发展,促进了数据驱动的创新,为企业和社会带来巨大价值。未来,这一趋势将更加高效智能,进一步推动AI技术的广泛应用。
|
1月前
|
人工智能 测试技术 API
哪个模型擅长调用工具?这个7B模型跻身工具调用综合榜单第一
《Hammer: Robust Function-Calling for On-Device Language Models via Function Masking》提出了一种新型基础模型Hammer,通过函数掩码技术显著提升了大型语言模型在工具调用方面的性能,减少了对特定命名约定的依赖,展现了强大的泛化能力和超越现有模型的表现。该研究已开源,旨在促进智能设备的本地AI功能发展。
78 6
|
7月前
|
编解码 人工智能 测试技术
ShareGPT4V作者团队又一力作!百万高质量视频-字幕数据助力社区提升多模态大模型视频理解及生成能力
【6月更文挑战第30天】ShareGPT4Video`团队推出百万视频-字幕数据集,强化多模态模型的视频理解和生成。包括40K视频的`ShareGPT4Video`数据集、`ShareCaptioner-Video`模型和8B参数的`ShareGPT4Video-8B`模型,后者在视频基准测试中取得最佳效果。差异化字幕生成策略解决了传统方法的局限。尽管取得突破,但数据规模和模型泛化仍是未来挑战。[论文链接](https://arxiv.org/abs/2406.04325v1)
86 1
|
7月前
|
数据采集 存储 人工智能
LinkedIn在利用大型语言模型服务十亿用户中的收获
LinkedIn在利用大型语言模型服务十亿用户中的收获
|
8月前
|
人工智能 Apache
社区供稿 | 140B参数、可商用!OpenBuddy 发布首个开源千亿中文 MoE 模型的早期预览版
我们很自豪地于今天发布OpenBuddy最新一代千亿MoE大模型的早期预览版本:OpenBuddy-Mixtral-22Bx8-preview0-65k。此次发布的早期预览版对应约50%的训练进度。
|
8月前
|
搜索推荐 数据安全/隐私保护
ATEC“数星”计划发布,开源亿级工业数据集
9月8日,ATEC前沿科技探索社区在外滩大会见解论坛现场正式宣布,启动ATEC“数星”计划。
ATEC“数星”计划发布,开源亿级工业数据集
|
机器学习/深度学习 自然语言处理
社区供稿 | EcomGPT:基于任务链数据的电商大模型(附魔搭推理实践)
在电商领域中,自然语言处理和深度学习的发展对电商技术的推进做出了很大的贡献。通过这些技术,可以实现从产品信息提取到用户查询理解等多种能力,尤其是近期各类大语言模型(Large Language Models,LLMs)的涌现,让我们看到了它们在电商领域引用的潜力。然而,通用的大语言模型并不是专门为电商领域设计的,这可能导致它们在电商任务中表现不佳。