为什么fine-tune过程中loss会忽大忽小呢？

[alisyzhu]

13B llama + 70w开源语料，其中1w作为test，为什么fine-tune的loss最开始是1.0左右，后续就一会儿变得很大，一会儿变成0呢？是因为test集合相对于fine-tune的集合太小吗？

[Facico]

@alisyzhu
感谢你提供这个问题。这个可能是bitsandbytes的问题，如果是V100用8bit加载很容易炸loss。想问一下你的显卡是V100吗，我们之前确实没有注意这个问题，V100是不支持8bit tensor core的，如下图。

相关issue: issue1, issue2, issue3

还有一个问题，我想知道你用我们的generate、interaction等测试文件能生成正常的结果吗（我们推理文件也是自动load 8bit
的）

如果用V100的话，可以把load_in_8bit改成False，loss应该就不容易炸了。

[alisyzhu]

是v100的，我之前就感觉配置环境的时候，这个bitsandbytes总是感觉不太正常，但本人对GPU不是很懂。因为一直感觉fine-tune不太正常，还没有generate和interaction。
如果我只能用v100fine-tune和generate的话，是不是把所有load_in_8bit的地方都设置成false就可以呢？那还需要配置bitsandbytes这个依赖包吗？
另外，我还想问下，如果不用8bit了，那么在后续还需要调用tools里的脚本做LLAMA的量化吗？一直没看懂这个量化什么时候需要做，有什么作用，我理解就是让模型变小的？

[alisyzhu]

将fine-tune里的load_in_8bit设置为False，4个GPU就报

[rookiebird]

讲道理load_in_8bit=True的话，v100跑个程序应该会报错啊，我是一直报错的，后面改成了load_in_8bit=False 才正常，然后用了.half()来记载模型训练，否则32Gv100会报oom

[alisyzhu]

但是改成load_in_8bit=False，报了OOM，我用了8个v100，也还是OOM，请问你是几个v100，数据量个batch_size多少呀，可以跑起来？
.half()是怎么执行的呀？

[alisyzhu]

讲道理load_in_8bit=True的话，v100跑个程序应该会报错啊，我是一直报错的，后面改成了load_in_8bit=False 才正常，然后用了.half()来记载模型训练，否则32Gv100会报oom

请问是将finetune.py的这部分这样修改吗？

[rookiebird]

我没有用8个v100, 我是两个啊， 一个v100 是32G的， 是你这样改的，然后micro_batch_size 是4， 好像我记得默认也是4， batch_size 我没改

讲道理load_in_8bit=True的话，v100跑个程序应该会报错啊，我是一直报错的，后面改成了load_in_8bit=False 才正常，然后用了.half()来记载模型训练，否则32Gv100会报oom

请问是将finetune.py的这部分这样修改吗？

[alisyzhu]

我没有用8个v100, 我是两个啊， 一个v100 是32G的， 是你这样改的，然后micro_batch_size 是4， 好像我记得默认也是4， batch_size 我没改

讲道理load_in_8bit=True的话，v100跑个程序应该会报错啊，我是一直报错的，后面改成了load_in_8bit=False 才正常，然后用了.half()来记载模型训练，否则32Gv100会报oom

请问是将finetune.py的这部分这样修改吗？

好的，我试试，感谢。我想问问你之前load_in_8bit=True的时候，v100报错是什么呀？我也有bug信息，但是能执行fine-tune，就是loss不对；可是我换成A100，好像bug信息也没变，但是按照硬件信息，A100是支持8int的呀 ~

[rookiebird]

我没有用8个v100, 我是两个啊， 一个v100 是32G的， 是你这样改的，然后micro_batch_size 是4， 好像我记得默认也是4， batch_size 我没改

讲道理load_in_8bit=True的话，v100跑个程序应该会报错啊，我是一直报错的，后面改成了load_in_8bit=False 才正常，然后用了.half()来记载模型训练，否则32Gv100会报oom

请问是将finetune.py的这部分这样修改吗？

好的，我试试，感谢。我想问问你之前load_in_8bit=True的时候，v100报错是什么呀？我也有bug信息，但是能执行fine-tune，就是loss不对；可是我换成A100，好像bug信息也没变，但是按照硬件信息，A100是支持8int的呀 ~

没报错，看上去是个奇怪的bug, 但是我马上反应过来可能是load_in_8bit设置为True了，改了就好了，我推理的时候，generate.py 设置load_in_8_bit也不会报错

[Facico]

@alisyzhu 把prepare_model_for_int8_training(model)去掉，然后在get_peft_model之后加上model.half()试试

[alisyzhu]

我没有用8个v100, 我是两个啊， 一个v100 是32G的， 是你这样改的，然后micro_batch_size 是4， 好像我记得默认也是4， batch_size 我没改

讲道理load_in_8bit=True的话，v100跑个程序应该会报错啊，我是一直报错的，后面改成了load_in_8bit=False 才正常，然后用了.half()来记载模型训练，否则32Gv100会报oom

请问是将finetune.py的这部分这样修改吗？

好的，我试试，感谢。我想问问你之前load_in_8bit=True的时候，v100报错是什么呀？我也有bug信息，但是能执行fine-tune，就是loss不对；可是我换成A100，好像bug信息也没变，但是按照硬件信息，A100是支持8int的呀 ~

没报错，看上去是个奇怪的bug, 但是我马上反应过来可能是load_in_8bit设置为True了，改了就好了，我推理的时候，generate.py 设置load_in_8_bit也不会报错

请问是这种bug信息吗？

我按照上面改了model的half部分，但还是OOM，哭了 ~

[alisyzhu]

@alisyzhu 把prepare_model_for_int8_training(model)去掉，然后在get_peft_model之后加上model.half()试试

还是不行，

[alisyzhu]

是不是load_in_8bit=False了，v100就跑不了13B的模型了。。。一直OOM

[Facico]

@alisyzhu 我们没拿V100跑过。粗略估算，7B+8bit差不多是1B1G，13B+16bit可能就是1B4G，你可以拿之前开8bit（虽然会有问题）的显存*2算算。

如果实在需要跑，需要使用deepspeed+zero2/3 offload的技术，在huggingface的trainer上很好加，你可以试试（可以参考这些博客）。由于使用zero offload代码会跑的很慢，当时我们就没有考虑，如果之后有需求会加上的。或者如果你成功加上跑上了，我们也会非常感谢你的贡献。

[Facico]

@alisyzhu 我好像忘记问你mirco batch size开的多少了，你可以试试开到1

[lucasjinreal]

v100 7B是可以训练的，只是int8太慢了（可能是huggface里面int8很慢）。
可以训的组合是 fp16 load + deepspeed offload

[lyccyl1]

This may be due to hardware reasons. On some hardware, the quantization model is not compatible with fp16. You can try set fp16=False. It works for me.

[fclearner]

我有个问题，如果int8加载的参数是freeze掉的，还会影响训练吗，因为看官网介绍，v100其实是不支持int8 tensor cores

[Facico]

@fclearner 你说的方式就是正常的qlora+fp16/fp32优化器的方式。如果是qlora的话，按照之前的写法用的是默认的fp16/fp32的混合精度优化，本质上是只有lora那块需要训练，lora那块的梯度其实是fp16。显存里保存的模型本身是int8，而这一块确实是freeze住的，只有计算的时候会dequant出来。v100不支持int8，可能导致dequant计算的这一部分，速度和精度都不行

[fclearner]

@fclearner 你说的方式就是正常的qlora+fp16/fp32优化器的方式。如果是qlora的话，按照之前的写法用的是默认的fp16/fp32的混合精度优化，本质上是只有lora那块需要训练，lora那块的梯度其实是fp16。显存里保存的模型本身是int8，而这一块确实是freeze住的，只有计算的时候会dequant出来。v100不支持int8，可能导致dequant计算的这一部分，速度和精度都不行

嗯嗯，感谢解答，我对int8 tensor core和int8的定义有些困惑，我之前理解int8 tensor core是用于训练加速的，int8是正常推理计算的，所以我觉得freeze掉int8相关参数，这部分参数不会参与训练加速的部分，所以不会有异常，但看你的描述，计算部分的int8 v100也是不支持的是吗，那这个图里的v100 int8支持具体是什么意思呢，期待你的回复！

[Facico]

@fclearner 你的理解是对的，我的回答确实会产生误解。int8 tensor core就是用来优化int8 tensor的计算的，支持int8就是能进行计算。所以上面用v100训练是能在一定程度上进行的（不炸loss的情况下），但是可能速度精度受限。如果支持int8 tensor core速度会更快，精度可能也会高一点。
因为我没咋用过v100的卡，不过感觉用一些防止炸loss的手段应该也是可以让训练过程更稳定一点。

[fclearner]

@fclearner 你的理解是对的，我的回答确实会产生误解。int8 tensor core就是用来优化int8 tensor的计算的，支持int8就是能进行计算。所以上面用v100训练是能在一定程度上进行的（不炸loss的情况下），但是可能速度精度受限。如果支持int8 tensor core速度会更快，精度可能也会高一点。 因为我没咋用过v100的卡，不过感觉用一些防止炸loss的手段应该也是可以让训练过程更稳定一点。

好的，感谢解惑