关于基于NTK的超长上下文支持

[ymcui]

我们在attn_and_long_ctx_patches.py实现了基于NTK的自适应上下文适配方法，其中基于transformers的推理脚本、gradio demo以及OpenAI API均调用了该方法。

• 当上下文小于4K时，默认关闭，因为原生的效果更好
• 大于4K时开启NTK，AUTO_COEFF默认为1.0

以下是不同AUTO_COEFF下，在不同上下文长度上的PPL变化（越低越好），供使用参考。
对NTK方法熟悉的用户可直接修改代码中的ALPHA取值。

• 12K以下：几乎和原生4K的PPL没有显著差异
• 12K-16K：开始存在一定损失，大约是3比特量化级别的效果
• 18K+：存在较大损失，大约是2比特量化级别效果，20K+不可用

以上结果仅供参考，应在实际场景中测试调整AUTO_COEFF或者ALPHA取值。

[moseshu]

如何在预训练阶段训练超长文本呢？如果文本长度是8192，block-size=512,那么这条文本会被切分成16个分片做语言模型训练么？

[moseshu]

你们在做预训练的时候，有按照这种格式训练么<s> <INT> {sys_prompt} </INT> {response} </s>？指令的这种格式应该在预训练阶段训练过之后，然后在经过指令集微调，效果才比较好吧？我直接用原始llama-2-7b-hf做指令微调的时候，loss会出现0的现象，比如

{'loss':9.914, 'learning_rate': 2.9994117644338537e-05, 'epoch': 0.0}                                                                        
{'loss': 8.3956, 'learning_rate': 2.9991342948271806e-05, 'epoch': 0.0}                                                                       
{'loss': 8.8805, 'learning_rate': 2.9988568252205075e-05, 'epoch': 0.0}                                                                       
{'loss': 8.6417, 'learning_rate': 2.9985793556138348e-05, 'epoch': 0.0}                                                                       
{'loss': 0, 'learning_rate': 2.9983018860071617e-05, 'epoch': 0.0}                                                                       
{'loss': 0, 'learning_rate': 2.9980244164004886e-05, 'epoch': 0.0}                                                                       
{'loss': 0, 'learning_rate': 2.997746946793816e-05, 'epoch': 0.0}                                                                       
{'loss': 0 'learning_rate': 2.9974694771871428e-05, 'epoch': 0.0}

对output之前的token进行了padding -100.这是什么原因造成的呢？

[airaria]

预训练用的是无格式的自由文本。只在指令精调用了llama2的指令格式。

[moseshu]

感谢回复，很奇怪，为什么原始的llama2直接做中文的指令微调loss会出现为0的现象呢？

[wccccp]

请问是什么原因呀 解决了吗

[moseshu]

解决了，具体原因不是很清楚，有可能是fp16精度越界，也有可能是训练中把label给截断了

[flymark2010]

请问这个 NTK-scale 的方法，有没有测过 passkey retrieval 的任务？只是 PPL 不降，并不一定说明模型能够利用超长距离上下文的信息。

[jamesljl]

有了这个参考数据非常重要！

我们在attn_and_long_ctx_patches.py实现了基于NTK的自适应上下文适配方法，其中基于transformers的推理脚本、gradio demo以及OpenAI API均调用了该方法。

• 当上下文小于4K时，默认关闭，因为原生的效果更好
• 大于4K时开启NTK，AUTO_COEFF默认为1.0

以下是不同AUTO_COEFF下，在不同上下文长度上的PPL变化（越低越好），供使用参考。 对NTK方法熟悉的用户可直接修改代码中的ALPHA取值。

• 12K以下：几乎和原生4K的PPL没有显著差异
• 12K-16K：开始存在一定损失，大约是3比特量化级别的效果
• 18K+：存在较大损失，大约是2比特量化级别效果，20K+不可用

以上结果仅供参考，应在实际场景中测试调整AUTO_COEFF或者ALPHA取值。

[moseshu]

你们在训练的时候有用到attn_and_long_ctx_patches 这里的方法么？

[airaria]

训练时用的是flash-attention，可以参考我们的训练代码。
至于长度外推，16K长文本模型使用的是PI训练而不是NTK，可以参考我们的release note

[jiangix-paper]

您好，对比了您NTK的代码与llama2的代码，当默认AUTO_COEFF=1.0时候，您的代码相当于llama2中scaling factor=2.0。请问llama2中的scaling factor如何理解呢？我看您那边相当于固定为2.0了。
llama2代码：

您的代码：

[airaria]

是的，我们这里的alpha=auto差不多等价于HF llama代码中的scaling_factor=2，两种不同经验公式的选择。

[Orion-Zheng]

1. 请问一下外推的中文数据集是否开源呢？
2. 请问评测PPL所用的数据集是哪一个呢？评测的代码是否可以公开呢？

[zhangfan-algo]

为啥不使用RoPe呢 我看好多模型都用了这个

[airaria]

长上下文扩展方案也是基于RoPE的

[gahoo]

最近有研究表明缩放RoPE旋转角的底数甚至能达到1M的上下文，你们有尝试过吗？

https://github.com/OpenLMLab/scaling-rope

https://zhuanlan.zhihu.com/p/660073229

https://arxiv.org/abs/2310.05209

[zhangfan-algo]

建议研发人员 在训练的时候可以在增加一下数据量 200G的语料训练有点不太够
按照最新的结论来看10B的模型至少需要200B的token训练量

[ymcui]

我相信大家都清楚数据量的重要性。为什么不用这么多数据，我觉得大家都比较清楚。😂