粤ICP备17114055号
微信扫码
与创始人交个朋友
支持私有云部署
我要投稿
单机两4090，如图
单卡24G，baichuan-13b-chat单卡推理需要至少26G，因此仅用一张卡，我们是无法加载百川13B的模型，所以，无论是推理还是训练，我们都必须并行！
核心思想：GPU显存不够，CPU内存来凑
虽然我们两张卡加起来有48G，按理说显存是足够的，实则不是。
就两张卡而言，分别为GPU0和GPU1，两块GPU上分别有一半模型参数，即6.5B，占用13G，在使用deepspeed的参数并行进行前向传播时，GPU0需要把自己身上的参数传给GPU1临时保存起来，参与前向传播，这时，GPU1身上的参数即为整个模型的参数，即13B，占用26G，超出了单卡显存上限，因此，当只有两块卡时，不使用offload策略的前提下，单卡的显存必须大于 模型大小 * 2，即13B的模型，双卡并行时，必须保证单卡显存大于26G。在使用三卡并行时，单卡显存大小理论上应大于：2 * 13 * 2 / 3 = 17.3G。
第一个2表示：每块GPU上都需要保存一份自己独有的参数和其他卡发送过来的临时参数，共2份 第二个2表示：参数的数据类型是fp16，占两个字节，所以乘2 13表示：13B的模型 3表示：3块GPU
下面的视频展示了 ZeRO（包含所有三个阶段）如何执行训练步骤，包括前向传递、后向传递和参数更新。要用到多卡并行的同学建议一定要看！ ZeRO-deepspeed-new-system-optimizations-enable-training-models-with-over-100-billion-parameters[1]
从上面的分析可以看出，我的硬件资源在不使用offload的情况下，是不足的，我的deepspeed参数配置：
{"bfloat16": {"enabled": false},"fp16": {"enabled": "auto","loss_scale": 0,"loss_scale_window": 1000,"initial_scale_power": 16,"hysteresis": 2,"min_loss_scale": 1},"zero_init": 0,"optimizer": {"type": "AdamW","params": {"lr": "auto","betas": "auto","eps": "auto","weight_decay": "auto"}},"scheduler": {"type": "WarmupLR","params": {"warmup_min_lr": "auto","warmup_max_lr": "auto","warmup_num_steps": "auto"}},"zero_optimization": {"stage": 3,"offload_optimizer": {"device": "cpu","pin_memory": true},"overlap_comm": true,"contiguous_gradients": true,"sub_group_size": 1e9,"reduce_bucket_size": "auto","stage3_prefetch_bucket_size": "auto","stage3_param_persistence_threshold": "auto","stage3_max_live_parameters": 1e9,"stage3_max_reuse_distance": 1e9,"gather_16bit_weights_on_model_save": true},"gradient_accumulation_steps": "auto","gradient_clipping": "auto","steps_per_print": 1e5,"train_batch_size": "auto","train_micro_batch_size_per_gpu": "auto","wall_clock_breakdown": false}可以看到，我这里使用offload_optimizer到cpu的策略，这就导致，训练速度慢了很多。
总共307w数据，batch size为1，梯度累积步为16，每个batch的输入token为1024，两卡4090，offload优化器参数到cpu，需要训练50天。
怕大家不理解什么是offload optimize，给大家贴张图
通过上面一顿操作，总算不OOM了！
我这里是使用Lora的增量预训练方式，给模型注入领域知识，成功启动训练之后，下面是训练了300个step后的模型文件。
理论上这个adapter_model.bin就是lora的参数，实际并不安全是
可以看下每个文件的大小
细心的同学可以发现，adapter_model.bin的文件非常小，看起来不像是真的lora模型参数，的确，使用deepspeed stage3策略训练得到的模型参数，还需要恢复权重才能用！如果你不恢复，直接使用PeftModel.from_pretrained合并模型的话，会报错，如下图：
用以上报错各种Google后都没找到正确答案，就问你绝不绝望！
细心的同学又发现了，保存的checkpoint文件夹里有个 zero_to_fp32.py，没错，这个代码就是用来恢复权重的，在命令行执行：
python zero_to_fp32.py . adapter_model.bin
输出：
[2023-07-30 10:51:11,819] [INFO] [real_accelerator.py:133:get_accelerator] Setting ds_accelerator to cuda (auto detect)Processing zero checkpoint './global_step300'Detected checkpoint of type zero stage ZeroStageEnum.weights, world_size: 2Parsing checkpoint created by deepspeed==0.10.0Reconstructed Frozen fp32 state dict with 283 params 13264901120 elementsReconstructed Trainable fp32 state dict with 400 params 27893760 elementsSaving fp32 state dict to adapter_model.bin
再看下模型大小：
哇，25G，不太妙啊
妙不妙合并下就知道。
好吧，合并试下呗。显存大的同学，合并时可能不会有任何问题，也许就是速度慢了些。
不过，咱只有48G的显存，拿个13B去和这25G大小的模型合并，差不多需要50G的显存，实在是顶不住。
原因：之所以adapter_model.bin达到25G，是因为这个参数包含了非lora层的参数，我们可以将非lora层的参数删除。
解决办法：
import torch ckpt = torch.load('adapter_model.bin')for key in list(ckpt.keys()):if key.find('lora_') == -1:del ckpt[key]torch.save(ckpt, 'adapter_model.bin')移除其他层的权重之后，大概就100M多些，这下可以正常推理了
大模型的并行训练，中途完全有可能需要中断，然后继续训练，这应该很好理解，你除了需要加载最新的模型外，之前已训练过的数据，最好也需要有标记，标记出哪些数据已训练过，尽可能保证每条数据只训练过一次。
不过，考虑到时间上的因素，我这里只做了随机采样，在一定程度上保证了每条数据尽可能只参与一次训练。
class MyDataset(Dataset):def __init__(self, dataset):self.dataset = datasetself.total_len = len(dataset)def __getitem__(self, idx):# 随机采样random.seed(int(time.time()))sample_idx = random.sample(range(self.total_len), k=1)[0]return self.dataset[sample_idx]def __len__(self):return self.total_len
注意：如果这里你固定seed值，每次取到的数据还是一样，一定要保证每次取数据时seed值都不一样，所以我用了时间戳。
53AI，企业落地应用大模型首选服务商
产品：大模型应用平台+智能体定制开发+落地咨询服务
承诺：先做场景POC验证，看到效果再签署服务协议。零风险落地应用大模型，已交付160+中大型企业
2024-03-30
2024-04-26
2024-05-14
2024-04-12
2024-05-10
2024-05-28
2024-07-18
2024-04-25
2024-05-22
2024-04-26
回到顶部