Datawhale AI夏令营-多模态大模型数据合成Task2 学习笔记-CSDN博客

本文链接：https://blog.csdn.net/IshmaelChen/article/details/141232292

Task2学习笔记

由于经济限制，这次跑不动全量了。

8张3090使用NVlink连接还要跑十几个小时，嗯，我已经闻到了钞票燃烧的焦味了。

提前做点功课的好处

在Task1时由于为了内测做了不少功课，等到教程负责人推出Task2时发现这前面的内容怎么那么眼熟？

多模态模型其实内容很丰富，包括了图像/音视频等多种领域，此处比赛提供的数据为图像和预训练好的生成对图片描述的大模型。因此本次就着重从图像上来解读。

本次比赛一共进行了两件事（环境配置？那是基本功。）：

需要进行数据合成，此处官方提供的脚本中是为我们提供了data-juicer作为数据合成的方法
等待数据合成结束后，使用MGM增强框架对多模态模型进行微调。

机枪向左移五米……

再战多模态

多模态模型有两个关键组件，一是视觉编码器，二是语言模型。

其中我们将会使用 gemma 作为我们的语言模型基座，gemma-2B 是谷歌开源的强大人工智能模型，参数量只有2B。

而对于视觉编码器我们将会使用 CLIP-L (clip-vit-large-patch14-336)。

这两者的下载都可以从download.sh中找到，不过在这里还是得提醒一下，一定要确定文件完整下载了。2B的参数量只是相较于其他的大模型才“不多”！本身如果已经好几个GiB的大小了，那少个2~3MiB的内容人是很难自己判断出来的！

前期复盘：如何确保文件正确且完整的下载

首先最为推荐的方法是将这方面的工作量交给别人。以本次Baseline为例，我们使用axel工具将下载的文件分为

用于占位的文件头。
实际存放数据的.st文件。
若下载成功，则将两个文件数据合并，返回一个指向原有文件的指针。

这样相较于wget而言可以更好的维护下载的情况，并在下载失败发生时迅速清理现场，不浪费宝贵的存储空间。

从密码学的角度出发，其实还可以通过前人已经成功的案例中计算出正确文件的Hash值，通过比对Hash来判断文件是否完整。不过我们考虑的是单人参赛的场景，如果真的有前人能够提供成功的数据包，我为什么不直接找他要一份从本地上传到服务器中呢？

炼丹是这样的，模型只需要接收一些参数就行了，而炼丹师们考虑得可就多了，不是想着硬件能否把模型伺候舒服，就是想着中途模型会不会在硬件上“造反”，比如说因为电气干扰等来自物理层的不良现象，导致模型训练的途中悄悄反转几个比特，然后这个人的努力就这样被浪费了一部分。

要想解决这种事情也很简单，加钱上ECC内存即可，不过正经的ECC内存价格同样很“美丽”。

模型：我保留了大部分的计算正确性，但我特地改错了一小部分。我认为只保留这一点出错造成的变动，才能让你知道你在炼丹。

我：是故意的还是不小心？

模型：是故意的。

前期的准备工作大概就这样了。

温馨提示：虽然我是成功在阿里云的实例上完成了最原始的baseline，但是目前人们已经发现autodl上不仅网速不错，而且价格也便宜很多，所以，除非阿里云上你已经配置好了，否则无脑转autodl。别花冤枉钱！

数据处理

对于多模态模型，我们需要首先筛选出文本和图片对的数据；

是的，其他助教以及学习者都表示可以用 GPT4V 作为处理的 caption 模型，但是，ChatGPT Plus的费用是20美元一个月吧。我觉得我花这笔钱在这里还不如去买个CN2专线的VPS，后者能干的事情可比这多了去了。

说到底就是没钱，所以在这我们选择了一个免费的模型BLIP ：其相关论文发表在 ICML-2022，在多模态大模型还没有出现的时候，BLIP就是那个时代的caption的顶流方案。

不过，大人，时代变了。现在BLIP被我们使用主要是因为它善：根本原因在于免费，重要原因在于它参数小，容易拿捏，训练起来速度快啊。

我们在数据处理中会使用 BLIP 来进行图片对应文字字幕的获取。

对于 Data-juicer，则会在此扮演“调度者”的操作，我们可以把对应的多模态caption算子指定为 BLIP

dj-process --config

还记得这个命令吗？它是将后面接着的文件作为了它的配置文件，这里我们查看一下它的细节：

dataset_path: input/pretrain_stage_1_10k/mgm_pretrain_stage_1_10k.jsonl
export_path: output/image_captioning_output/res_10k.jsonl

np: 1
process:
  - image_captioning_mapper:
      hf_img2seq: '/root/autodl-tmp/better_synth_baseline_autoDL/models/goldsj/blip2-opt-2.7b'  # You can replace this path to a local downloaded HF model
      keep_original_sample: false  # we only need the recaptioned captions

这个是Autodl方案下课程组讨论得出的10k方案，其作用在于让模型能够先运行起来。不过全量运行也就只是更改配置文件和download.sh的事情而已，这份配置文件中的关键字已经能哆告诉我们一些信息：

最开始的两条路径用于指定数据和输出结果的位置
np则是代表着线程数，在Task1中，为了能确保机器可以顺利运行，一般设置为1，但其实可以通过提高np的值让它训练的更快（当然，要有足够的配置）。在本次的介绍中，我们得知如果条件允许，其实可以直接将这行注释掉，现在已经是自动化的时代了，程序应该学会自己找到合适的np值了。

不要向井里吐痰,也许你还会来喝井里的水。

通过注释，保留上一版本操作的一些痕迹还是有必要的。

训练，然后捡到良好分数

训练其实就是那一个脚本，但只有运行过的人才知道，它其实跑了三个东西，所以最后时间还是花了三个多小时

首先映入眼帘的是显卡的相关设置环节，涉及到几个环境变量，因为我们在云服务器平台用多卡并不是为了多卡，而是为了大内存，所以需要关闭其他显卡的一些通信环节以及可见性。

实际上，老黄为了保证AI卡和游戏卡业务分离，从4000系列开始就不再让游戏显卡支持NVlink功能。

这有什么区别呢？假如两张3090的并行和两张4090的并行进行比较——的确，4090因为升级换代过，显存比3090大，但是3090尚且支持的NVlink可以让3090的位宽一起叠加，位宽对于擅长处理并行计算的显卡而言，重要性不言而喻了。

老黄，你的刀法无敌了。

重点还是在于这片区域：

# training args
# pretraining
# make sure PRETRAIN_BATCH_SIZE_PER_GPU * PRETRAIN_GRADIENT_ACCUMULATION_STEPS * num_gpus = 256
# **NOTICE**: the default setting is for 1 GPU
PRETRAIN_BATCH_SIZE_PER_GPU=4
PRETRAIN_GRADIENT_ACCUMULATION_STEPS=64
PRETRAIN_DATALOADER_NUM_WORKERS=4
# finetuning
# make sure FINETUNE_BATCH_SIZE_PER_GPU * FINETUNE_GRADIENT_ACCUMULATION_STEPS * num_gpus = 128
# **NOTICE**: the default setting is for 1 GPU
FINETUNE_BATCH_SIZE_PER_GPU=4
FINETUNE_GRADIENT_ACCUMULATION_STEPS=32
FINETUNE_DATALOADER_NUM_WORKERS=4

我们需要满足两个关系，也就是 4* 64 = 256 ，以及 4*32 = 128 ，这是必须满足的数量关系，最后的乘法结果需要满足 256 以及 128，如果想要真正的多卡并行训练，则有几张卡就得除以几。

如果我们想降低显存和内存占用，最好的想法当然是强行修改 FINETUNE_BATCH_SIZE_PER_GPU 为1 ，并且把 FINETUNE_DATALOADER_NUM_WORKERS 变成 1

可不是吗，将加载器数量和数据大小都调低了，但是，这样又会让速度降下去，然后耗费更多的时间，最后让自己多花冤枉钱。

所以，这下彻底明白计算机操作系统课程中的一个核心问题了：