关于GLM4-9B模型训练过程中的OOMM问题

[XCF-Mike]

System Info / 系統信息

模型：glm4-9B-chat
配置文件：
data_config:
train_file: train.jsonl
val_file: dev.jsonl
test_file: dev.jsonl
num_proc: 1
max_input_length: 3500
max_output_length: 2500
training_args:

see transformers.Seq2SeqTrainingArguments

max_steps: 20000

needed to be fit for the dataset

learning_rate: 3e-4

settings for data loading

per_device_train_batch_size: 1
dataloader_num_workers: 16
remove_unused_columns: false

settings for saving checkpoints

save_strategy: steps
save_steps: 500

settings for logging

log_level: info
logging_strategy: steps
logging_steps: 10

settings for evaluation

per_device_eval_batch_size: 2
evaluation_strategy: steps
eval_steps: 12000

debug: underflow_overflow

predict_with_generate: true

see transformers.GenerationConfig

generation_config:
max_new_tokens: 512

set your absolute deepspeed path here

deepspeed: configs/ds_zero_3.json
peft_config:
peft_type: LORA
task_type: CAUSAL_LM
r: 8
lora_alpha: 32
lora_dropout: 0.1

Who can help? / 谁可以帮助到您？

No response

Information / 问题信息

• The official example scripts / 官方的示例脚本
• My own modified scripts / 我自己修改的脚本和任务

Reproduction / 复现过程

实验1：同样的配置文件，单卡H800训练，80g显存几乎占满
实验2：同样的配置文件，双卡H800训练，发生

双卡的指令为：
CUDA_VISIBLE_DEVICES=4,5 OMP_NUM_THREADS=1 torchrun --standalone --nnodes=1 --nproc_per_node=2 finetune1.py

Expected behavior / 期待表现

请问是什么原因导致的该问题呢

[zhipuch]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

[XCF-Mike]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

请问方便看一下您这边用的指令吗，就是我的数据里面确实有这种长度的数据，不清楚您这边数据有吗

[XCF-Mike]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

再就是您这边deepspeed用的什么版本，我看repo里面没有写相关的要求，并且我没有用flash-attn来加速，目前这个repo支持使用flash-attn吗

[elesun2018]

GLM-4/finetune_demo/finetune_vision.py微调训练时显存变化剧烈变化频率约为30S，显存不稳定，请问是什么原因
per_device_train_batch_size: 4 未进行评估

请问gradient_accumulation_steps: 1如何设置，设置2 3计算loss是否存在token长度不统一的bug ？

[zhipuch]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

再就是您这边deepspeed用的什么版本，我看repo里面没有写相关的要求，并且我没有用flash-attn来加速，目前这个repo支持使用flash-attn吗

我用的指令跟你的差不多：（CUDA_VISIBLE_DEVICES=4,5 OMP_NUM_THREADS=1 torchrun --standalone --nnodes=1 --nproc_per_node=2 finetune.py 数据路径 模型路径 lora.yaml路径）yaml文件里有lora和deepspeed配置
然后版本的话也参考一下basic_demo中的requirement.txt文件

[zhipuch]

GLM-4/finetune_demo/finetune_vision.py微调训练时显存变化剧烈变化频率约为30S，显存不稳定，请问是什么原因 per_device_train_batch_size: 4 未进行评估 请问gradient_accumulation_steps: 1如何设置，设置2 3计算loss是否存在token长度不统一的bug ？

显存变化剧烈是指占用显存忽高忽低？因为训练样本长度的原因吗？gradient_accumulation_steps这个参数在lora.yaml文件中设置，token长度统一与否与这个没关系吧

[elesun2018]

是的，显存忽高忽低，训练样本文本长度：中文字数大概范围30-100个汉字。答案文本长度变化不大。30-100个汉字。
显存忽高忽低会造成忽低时，显存被别的进程趁机抢占，这样本进程就会报OOM错误。
显存忽高忽低应该跟finetunevsion 训练流程中modeling_chatglm有关系吧。应该如何排查。谢谢

[XCF-Mike]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

再就是您这边deepspeed用的什么版本，我看repo里面没有写相关的要求，并且我没有用flash-attn来加速，目前这个repo支持使用flash-attn吗

我用的指令跟你的差不多：（CUDA_VISIBLE_DEVICES=4,5 OMP_NUM_THREADS=1 torchrun --standalone --nnodes=1 --nproc_per_node=2 finetune.py 数据路径 模型路径 lora.yaml路径）yaml文件里有lora和deepspeed配置 然后版本的话也参考一下basic_demo中的requirement.txt文件

可能是依赖问题，我排查一下，再者就是请问官方仓库这边支持flash-atten加速了吗，我看huggingface里面的模型文件的modeling_chatglm中已经具备了相关的代码

[zhipuch]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

再就是您这边deepspeed用的什么版本，我看repo里面没有写相关的要求，并且我没有用flash-attn来加速，目前这个repo支持使用flash-attn吗

我用的指令跟你的差不多：（CUDA_VISIBLE_DEVICES=4,5 OMP_NUM_THREADS=1 torchrun --standalone --nnodes=1 --nproc_per_node=2 finetune.py 数据路径 模型路径 lora.yaml路径）yaml文件里有lora和deepspeed配置 然后版本的话也参考一下basic_demo中的requirement.txt文件

可能是依赖问题，我排查一下，再者就是请问官方仓库这边支持flash-atten加速了吗，我看huggingface里面的模型文件的modeling_chatglm中已经具备了相关的代码

模型实现里有flash-attn，因此是支持的，只不过需要自己修改modeling_chatglm文件了，定义selfattn的时候改成flash-attn，里面flashattention似乎有点问题，需要自己改一下啦

[zhipuch]

是的，显存忽高忽低，训练样本文本长度：中文字数大概范围30-100个汉字。答案文本长度变化不大。30-100个汉字。 显存忽高忽低会造成忽低时，显存被别的进程趁机抢占，这样本进程就会报OOM错误。 显存忽高忽低应该跟finetunevsion 训练流程中modeling_chatglm有关系吧。应该如何排查。谢谢

这样的话确实序列长度影响不大，可能还有就是梯度累积和梯度检查点导致的，把微调代码里model.gradient_checkpointing_enable()试一下吧

[XCF-Mike]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

再就是您这边deepspeed用的什么版本，我看repo里面没有写相关的要求，并且我没有用flash-attn来加速，目前这个repo支持使用flash-attn吗

我用的指令跟你的差不多：（CUDA_VISIBLE_DEVICES=4,5 OMP_NUM_THREADS=1 torchrun --standalone --nnodes=1 --nproc_per_node=2 finetune.py 数据路径 模型路径 lora.yaml路径）yaml文件里有lora和deepspeed配置 然后版本的话也参考一下basic_demo中的requirement.txt文件

可能是依赖问题，我排查一下，再者就是请问官方仓库这边支持flash-atten加速了吗，我看huggingface里面的模型文件的modeling_chatglm中已经具备了相关的代码

模型实现里有flash-attn，因此是支持的，只不过需要自己修改modeling_chatglm文件了，定义selfattn的时候改成flash-attn，里面flashattention似乎有点问题，需要自己改一下啦

您这边用deepspeed-zero3是用的最新的hg上面的模型文件和这个项目更新后的repo吗，我这个可能是太早了，是七月份之前的repo以及当时搭建的环境了

[zhipuch]

理论上不应该啊lora+zero3，我也复现了一下，A100机器2卡没爆显存

再就是您这边deepspeed用的什么版本，我看repo里面没有写相关的要求，并且我没有用flash-attn来加速，目前这个repo支持使用flash-attn吗

我用的指令跟你的差不多：（CUDA_VISIBLE_DEVICES=4,5 OMP_NUM_THREADS=1 torchrun --standalone --nnodes=1 --nproc_per_node=2 finetune.py 数据路径 模型路径 lora.yaml路径）yaml文件里有lora和deepspeed配置 然后版本的话也参考一下basic_demo中的requirement.txt文件

可能是依赖问题，我排查一下，再者就是请问官方仓库这边支持flash-atten加速了吗，我看huggingface里面的模型文件的modeling_chatglm中已经具备了相关的代码

模型实现里有flash-attn，因此是支持的，只不过需要自己修改modeling_chatglm文件了，定义selfattn的时候改成flash-attn，里面flashattention似乎有点问题，需要自己改一下啦

您这边用deepspeed-zero3是用的最新的hg上面的模型文件和这个项目更新后的repo吗，我这个可能是太早了，是七月份之前的repo以及当时搭建的环境了

config文件夹下面的那个，改一下lora.yaml的路径就行

[elesun2018]

finetune_vision.py微调训练时显存变化剧烈变化频率约为30S，显存不稳定
是不是finetune_vision中torch.cuda.empty_cache()导致的。

[XCF-Mike]

finetune_vision.py微调训练时显存变化剧烈变化频率约为30S，显存不稳定 是不是finetune_vision中torch.cuda.empty_cache()导致的。

我好像也遇到了类似问题，同样的配置，数据换了一下，就爆显存了。我现在没搞明白GLM4这边遇到太长的数据是截断还是删除，但是无论怎么样之前能跑起来的配置也不应该出现OOMM问题

[XCF-Mike]

是的，显存忽高忽低，训练样本文本长度：中文字数大概范围30-100个汉字。答案文本长度变化不大。30-100个汉字。 显存忽高忽低会造成忽低时，显存被别的进程趁机抢占，这样本进程就会报OOM错误。 显存忽高忽低应该跟finetunevsion 训练流程中modeling_chatglm有关系吧。应该如何排查。谢谢

这样的话确实序列长度影响不大，可能还有就是梯度累积和梯度检查点导致的，把微调代码里model.gradient_checkpointing_enable()试一下吧

我这边的训练数据比较长，每条数据之间长度差异也比较大，我尝试过训练数据从长到短排序后只删除了其中一条导致OOM的数据，就成功训练了，但是长短交替的时候，尝试了十来次去删除在OOM问题的steps位置的数据，依然没能成功开启训练