13B modeling.py中xformers加速时未添加alibi_mask？ about baichuan2 HOT 40 OPEN

@piekey1994 @s-JoL 其实可以在memory_efficient_attention之前把query, key, value, attn_bias pad成8的倍数，memory_efficient_attention计算完成之后再把attn_output还原回原本的形状，这样就能利用xformers来提升推理效率了。具体可以参考这个代码 https://github.com/OFA-Sys/ONE-PEACE/blob/4f18350a161df9c01f8042484f579fafb6bef75c/one_peace/models/transformer/multihead_attention.py#L79-L101

from baichuan2.

我更新了最新的代码，发现不用xformer就正常了

from baichuan2.

fixed Now!

from baichuan2.

fixed Now!

使用了新的代码，报了一个错误：
query_states, key_states, value_states, attn_bias=attention_mask.unsqueeze(0).expand(bsz, -1, -1, -1)
RuntimeError: expand(torch.cuda.HalfTensor{[1, 4, 40, 241, 241]}, size=[4, -1, -1, -1]): the number of sizes provided (4) must be greater or equal to the number of dimensions in the tensor (5)

from baichuan2.

非常感谢指出这个问题，由于一些疏漏导致这里使用了和7B模型一样的mask，现已修复。

from baichuan2.

非常感谢指出这个问题，由于一些疏漏导致这里使用了和7B模型一样的mask，现已修复。

新的错误：
/python3.10/site-packages/xformers/ops/fmha/dispatch.py", line 63, in _run_priority_list
raise NotImplementedError(msg)
NotImplementedError: No operator found for memory_efficient_attention_forward with inputs:
query : shape=(4, 263, 40, 128) (torch.float16)
key : shape=(4, 263, 40, 128) (torch.float16)
value : shape=(4, 263, 40, 128) (torch.float16)
attn_bias : <class 'torch.Tensor'>
p : 0.0
decoderF is not supported because:
attn_bias type is <class 'torch.Tensor'>
[email protected] is not supported because:
attn_bias type is <class 'torch.Tensor'>
tritonflashattF is not supported because:
attn_bias type is <class 'torch.Tensor'>
operator wasn't built - see python -m xformers.info for more info
triton is not available
cutlassF is not supported because:
attn_bias.stride(-2) % 8 != 0 (attn_bias.stride() = (2766760, 69169, 263, 1))
attn_bias.stride(-2) % 8 != 0 (attn_bias.stride() = (2766760, 69169, 263, 1))
HINT: To use an attn_bias with a sequence length that is not a multiple of 8, you need to ensure memory is aligned by slicing a bigger tensor. Example: use attn_bias = torch.zeros([1, 1, 5, 8])[:,:,:,:5] instead of torch.zeros([1, 1, 5, 5])
smallkF is not supported because:
max(query.shape[-1] != value.shape[-1]) > 32
dtype=torch.float16 (supported: {torch.float32})
bias with non-zero stride not supported
unsupported embed per head: 128
result = forward_call(*args, **kwargs)

from baichuan2.

这其实是xformer本身的限制，他要求seq length为8的倍数，为支持多样的seq length改为使用F.scaled_dot_product_attention，可以根据实际情况动态选择不同算子。

from baichuan2.

这其实是xformer本身的限制，他要求seq length为8的倍数，为支持多样的seq length改为使用F.scaled_dot_product_attention，可以根据实际情况动态选择不同算子。

改成这个后损失非常大，都彪到10了，不开的话，就正常在1.0左右

from baichuan2.

这其实是xformer本身的限制，他要求seq length为8的倍数，为支持多样的seq length改为使用F.scaled_dot_product_attention，可以根据实际情况动态选择不同算子。

改成这个后损失非常大，都彪到10了，不开的话，就正常在1.0左右

本地测试没什么问题，中间加了一个transpose，看看是不是你运行的时候那个还没加，你再试试呢

from baichuan2.

这其实是xformer本身的限制，他要求seq length为8的倍数，为支持多样的seq length改为使用F.scaled_dot_product_attention，可以根据实际情况动态选择不同算子。

改成这个后损失非常大，都彪到10了，不开的话，就正常在1.0左右

本地测试没什么问题，中间加了一个transpose，看看是不是你运行的时候那个还没加，你再试试呢

加了，目前最新的代码还是不行，loss会爆掉，不知为啥，只能关掉训练了

from baichuan2.

@s-JoL 请问这个是要把torch升级到nightly版本嘛？标准的2.0.1的torch的sdpa应该不包含meff attention吧？meff好像是8约初的一个commit引入torch的？pytorch/pytorch#104310

from baichuan2.

@s-JoL 请问这个是要把torch升级到nightly版本嘛？标准的2.0.1的torch的sdpa应该不包含meff attention吧？meff好像是8约初的一个commit引入torch的？pytorch/pytorch#104310

应该不需要，可以看一下meff很早就被引入到pytorch中了 https://github.com/pytorch/pytorch/commits/v2.0.0/aten/src/ATen/native/transformers/cuda/mem_eff_attention

from baichuan2.

也是发现目前的evalloss偏大，但是 training loss还算正常。

from baichuan2.

@piekey1994 @s-JoL 其实可以在memory_efficient_attention之前把query, key, value, attn_bias pad成8的倍数，memory_efficient_attention计算完成之后再把attn_output还原回原本的形状，这样就能利用xformers来提升推理效率了。具体可以参考这个代码 https://github.com/OFA-Sys/ONE-PEACE/blob/4f18350a161df9c01f8042484f579fafb6bef75c/one_peace/models/transformer/multihead_attention.py#L79-L101

学习了一下，很好的实现，如有兴趣可以给模型提交相关pr。

from baichuan2.

@piekey1994 @jeffchy 可以描述一下更具体的情况么？我这里使用项目中提供的finetune代码测试一开始loss大概2.5，后面降低到1左右。

from baichuan2.

@s-JoL 我这边一样的问题，训练loss可以持续下降，eval loss 起初会下降到1以下，然后就会超过1，之后持续不下降了

from baichuan2.

我是用的自己的数据，全量训练。相同的数据，baichuan1没这个问题

from baichuan2.

我也类似，用的是baichuan2_13B的base + xformer，然后也更新了之前fix alibi mask的代码，训练loss是随着训练持续降低的，但是evalloss相比同样的数据的baichuan1_13B高很多，大概是2.8 vs 4.5，而且随着训练是evalloss不降低的

from baichuan2.

我是拼成3K的上下文做了小规模的continue pretrain

from baichuan2.

在本项目的finetune代码中没有输出eval loss，你们使用的是https://github.com/hiyouga/LLaMA-Efficient-Tuning 这个项目么？

from baichuan2.

@s-JoL 用的这个 https://github.com/modelscope/swift

from baichuan2.

我用的huggingface的trainer自带的eval

from baichuan2.

好的，我们尝试复现一下这个问题

from baichuan2.

@s-JoL 您好，有啥进展吗？

from baichuan2.

@piekey1994 @jeffchy 可以描述一下更具体的情况么？我这里使用项目中提供的finetune代码测试一开始loss大概2.5，后面降低到1左右。

要是开着加速的话，我这边是accelerate+deepspeed zero3+fp16训练的，一开始loss就超过10，一直处于溢出状态，关掉加速就没有这个现象了。不知道是不是我哪里配置有问题

from baichuan2.

我使用huggingface的trainer进行了一些复现，目前看训练loss正常下降，eval loss到一个值之后就不再降低了。目前认为这个现象应该是正常的，因为看训练loss其实在一个epoch内下降也没有特别明显，到第二个epoch会有明显下降，这说明可能出现一些过拟合的情况。建议可以看一下评价指标是否正常的，如果也是能正常上升的应该没问题。
关于另外几位说的loss很大这个问题倒是没有发现，我们后面再试一些别的数据集看看。

from baichuan2.

@jeffchy 是 eval losss 正常了吗？

from baichuan2.

@Xu-Chen training 也正常了，完全一样的超参数，区别只是xops设置成None，两个局部training curve的对比：evalloss和train loss大致是同步的。

from baichuan2.

也是发现目前的evalloss偏大，但是 training loss还算正常。

看normhead的代码，只会在第一次eval做norm，后续的eval没有做normalize

from baichuan2.

@Davidgzx 那如果训练的时候，固定steps 开启 eval的话，基本上是第一次eval正确，后面都有问题呗

from baichuan2.

@Davidgzx 看到了，确实这块有问题。其实加一行代码就行。在 train的时候，变量设置为true

from baichuan2.

@s-JoL 大佬可以看看

from baichuan2.

也是发现目前的evalloss偏大，但是 training loss还算正常。

看normhead的代码，只会在第一次eval做norm，后续的eval没有做normalize

感谢您的发现，已经有其他同学修改了这个问题。 cc @Xu-Chen

from baichuan2.

看起来不是这个问题啊，我这里并没有改善太多

from baichuan2.

我使用huggingface的trainer进行了一些复现，目前看训练loss正常下降，eval loss到一个值之后就不再降低了。目前认为这个现象应该是正常的，因为看训练loss其实在一个epoch内下降也没有特别明显，到第二个epoch会有明显下降，这说明可能出现一些过拟合的情况。建议可以看一下评价指标是否正常的，如果也是能正常上升的应该没问题。 关于另外几位说的loss很大这个问题倒是没有发现，我们后面再试一些别的数据集看看。

换目前最新的代码，换了bf16再开这个xops就不会有loss爆掉的问题了，fp16不开才能正常。暂时原因未知

from baichuan2.

@piekey1994 bf16+xops 是正常的？

from baichuan2.

@piekey1994 bf16+xops 是正常的？

目前最新的代码，开启xops，fp16loss会容易变差nan，bf16就正常

from baichuan2.

@s-JoL 我在huggignface上提交了个pr，你们可以看看，主要针对：1、重新启用xformers。pad到8的倍数可以在用户端解决，模型代码可以不改，且xformers不会出现在fp16精度下的nan问题，就凭这一点就不应该注释掉xops部分，期望用户显卡都支持bf16是不现实的。2、检测pytorch版本大于2的时候才用torch.backends.cuda.sdp_kernel，否则回到原始实现。

from baichuan2.

非常感谢指出这个问题，由于一些疏漏导致这里使用了和7B模型一样的mask，现已修复。
为啥要和7B不一样呢？不都是算attention吗

from baichuan2.

我在输入attn mask的情况下会报，bf16跟float不兼容，请问怎么解决？
------------自问自答：加个with autocast就行了。。。

@s-JoL 我在huggignface上提交了个pr，你们可以看看，主要针对：1、重新启用xformers。pad到8的倍数可以在用户端解决，模型代码可以不改，且xformers不会出现在fp16精度下的nan问题，就凭这一点就不应该注释掉xops部分，期望用户显卡都支持bf16是不现实的。2、检测pytorch版本大于2的时候才用torch.backends.cuda.sdp_kernel，否则回到原始实现。

from baichuan2.