ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 1.2em;display: table;border-bottom: 1px solid rgb(248, 57, 41);">前言ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 1.2em;display: table;border-bottom: 1px solid rgb(248, 57, 41);">资源ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;">单机两4090，如图ingFang SC", BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size: 14px;letter-spacing: normal;text-align: start;text-wrap: wrap;">
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;">单卡24G，baichuan-13b-chat单卡推理需要至少26G，因此仅用一张卡，我们是无法加载百川13B的模型，所以，无论是推理还是训练，我们都必须并行！ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 1.2em;display: table;border-bottom: 1px solid rgb(248, 57, 41);">deepspeedingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;">核心思想：GPU显存不够，CPU内存来凑ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;">虽然我们两张卡加起来有48G，按理说显存是足够的，实则不是。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;">就两张卡而言，分别为GPU0和GPU1，两块GPU上分别有一半模型参数，即6.5B，占用13G，在使用deepspeed的参数并行进行前向传播时，GPU0需要把自己身上的参数传给GPU1临时保存起来，参与前向传播，这时，GPU1身上的参数即为整个模型的参数，即13B，占用26G，超出了单卡显存上限，因此，当只有两块卡时，不使用offload策略的前提下，单卡的显存必须大于模型大小 * 2，即13B的模型，双卡并行时，必须保证单卡显存大于26G。在使用三卡并行时，单卡显存大小理论上应大于：2 * 13 * 2 / 3 = 17.3G。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;">第一个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，没错，这个代码就是用来恢复权重的，在命令行执行： pythonzero_to_fp32.py.adapter_model.bin 输出： [2023-07-3010:51:11,819][INFO][real_accelerator.py:133:get_accelerator]Settingds_acceleratortocuda(autodetect)Processingzerocheckpoint'./global_step300'DetectedcheckpointoftypezerostageZeroStageEnum.weights,world_size:2Parsingcheckpointcreatedbydeepspeed==0.10.0ReconstructedFrozenfp32statedictwith283params13264901120elementsReconstructedTrainablefp32statedictwith400params27893760elementsSavingfp32statedicttoadapter_model.bin 再看下模型大小： 哇，25G，不太妙啊
妙不妙合并下就知道。 二、推理的坑好吧，合并试下呗。显存大的同学，合并时可能不会有任何问题，也许就是速度慢了些。 不过，咱只有48G的显存，拿个13B去和这25G大小的模型合并，差不多需要50G的显存，实在是顶不住。 原因：之所以adapter_model.bin达到25G，是因为这个参数包含了非lora层的参数，我们可以将非lora层的参数删除。 解决办法： importtorchckpt=torch.load('adapter_model.bin')forkeyinlist(ckpt.keys()):ifkey.find('lora_')==-1:delckpt[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值都不一样，所以我用了时间戳。 |
