训练时间预估
xiaozhu1106 opened this issue · comments
请教一下，13B在V100-32G机器上的全量预训练时间，基于您的数据集上，大概是多久
您好，我们在24张V100-32G的机器上，启用ZeRO-3的策略，单条样本最大长度为1024，我们一天约能跑50w条样本。
我们目前并没有训练完成，未来会发布新的版本。
目前没有训练完成的是全量版本吗？
另外问一下为什么没有重新编码词表呢，llama原版的词表编码中文比较慢
您好，关于第一个问题，预训练模型的部分还没有训练，全量指令微调的部分也暂时还没有训练完成。近期会继续更新。
关于第二个问题，在README_ZH.md中有提及：为了在保留原来的代码能力和英语能力的前提下，来提升模型对于中文的理解能力，我们并没有对词表进行扩增。
另外请教下， 没有那么多张V100卡，预训练时间太慢了。 预训练的话，目的是预训练语言模型，那是否训练最大长度值对后续指令精调影响不大呢？ 比如我是否可以预训练最大长度512， 来缩短预训练的时间？后面做指令精调的时候，在扩大最大长度值？
您好，从技术上来说是可行的，但是目前似乎好像没有工作使用这种策略，此外由于我们没有对中文扩充词表，一个中文汉字可能对应2~3个token，因此512的长度实际的中文字符可能更少。下面是关于这个问题的个人理解：
预训练的目的之一是使得模型可以输出一个像样的句子（通常使用perplexity指标进行评估），如果您的512个长度的句子均以[BOS]开头和[EOS]结尾，那么模型输出的长度可能也在512左右，因为训练数据的分布让模型以为现实世界的句子的长度上限为512；如果512长度的句子中以[EOS]结尾的句子不多，那么我觉得再加上LLaMA使用的RoPE位置编码的长度外推能力，是可能可以输出更大长度的句子的。而指令微调的目的之一是让模型可以学习到人类指令的语义，如果使用LoRA微调，这个增大最大长度是否可以增加模型对于长文本的输出能力不得而知；如果使用全量微调，且数据量足够的话，可能是可以的。
以上仅是我个人的观点，如果您的实验有一些有趣的结论，欢迎讨论 :)
您好，从技术上来说是可行的，但是目前似乎好像没有工作使用这种策略，此外由于我们没有对中文扩充词表，一个中文汉字可能对应2~3个token，因此512的长度实际的中文字符可能更少。下面是关于这个问题的个人理解：
预训练的目的之一是使得模型可以输出一个像样的句子（通常使用perplexity指标进行评估），如果您的512个长度的句子均以[BOS]开头和[EOS]结尾，那么模型输出的长度可能也在512左右，因为训练数据的分布让模型以为现实世界的句子的长度上限为512；如果512长度的句子中以[EOS]结尾的句子不多，那么我觉得再加上LLaMA使用的RoPE位置编码的长度外推能力，是可能可以输出更大长度的句子的。而指令微调的目的之一是让模型可以学习到人类指令的语义，如果使用LoRA微调，这个增大最大长度是否可以增加模型对于长文本的输出能力不得而知；如果使用全量微调，且数据量足够的话，可能是可以的。
以上仅是我个人的观点，如果您的实验有一些有趣的结论，欢迎讨论 :)
感谢您的指点。 您的代码是否能基于
中文Chinese-LLaMA-Alpaca扩词表的llama模型进行二次预训练呢？ 我目前使用扩词表的llama模型,基于您的代码训练报错，报错信息里大概如下信息(exits with return code = -9)：
[2023-06-06 08:32:36,346] [INFO] [comm.py:622:init_distributed] Initializing TorchBackend in DeepSpeed with backend nccl
[2023-06-06 08:32:57,597] [INFO] [partition_parameters.py:454:exit] finished initializing model with 13.20B parameters
^MLoading checkpoint shards: 0%| | 0/3 [00:00<?, ?it/s]^MLoading checkpoint shards: 0%| | 0/3 [00:00<?, ?it/s]^MLoading checkpoint shards: 33%|███▎ | 1/3 [00:29<00:58, 29.35s/it]^MLoading checkpoint shards: 33%|███▎ | 1/3 [00:29<00:58, 29.47s/it]^MLoading checkpoint shards: 67%|██████▋ | 2/3 [00:59<00:29, 29.72s/it]^MLoading checkpoint shards: 67%|██████▋ | 2/3 [00:59<00:29, 29.77s/it]^MLoading checkpoint shards: 100%|██████████| 3/3 [01:19<00:00, 25.41s/it]^MLoading checkpoint shards: 100%|██████████| 3/3 [01:19<00:00, 26.54s/it]
数据的分布为：[52]
False
^MLoading checkpoint shards: 100%|██████████| 3/3 [01:19<00:00, 25.43s/it]^MLoading checkpoint shards: 100%|██████████| 3/3 [01:19<00:00, 26.57s/it]
数据的分布为：[52]
False
Using /root/.cache/torch_extensions/py310_cu117 as PyTorch extensions root...
Using /root/.cache/torch_extensions/py310_cu117 as PyTorch extensions root...
Detected CUDA files, patching ldflags
Emitting ninja build file /root/.cache/torch_extensions/py310_cu117/cpu_adam/build.ninja...
Building extension module cpu_adam...
Allowing ninja to set a default number of workers... (overridable by setting the environment variable MAX_JOBS=N)
ninja: no work to do.
Loading extension module cpu_adam...
Time to load cpu_adam op: 2.49210786819458 seconds
Loading extension module cpu_adam...
Time to load cpu_adam op: 2.469583749771118 seconds
Using /root/.cache/torch_extensions/py310_cu117 as PyTorch extensions root...
Emitting ninja build file /root/.cache/torch_extensions/py310_cu117/utils/build.ninja...
Building extension module utils...
Allowing ninja to set a default number of workers... (overridable by setting the environment variable MAX_JOBS=N)
ninja: no work to do.
Loading extension module utils...
Time to load utils op: 0.1338198184967041 seconds
Using /root/.cache/torch_extensions/py310_cu117 as PyTorch extensions root...
Emitting ninja build file /root/.cache/torch_extensions/py310_cu117/utils/build.ninja...
Building extension module utils...
Allowing ninja to set a default number of workers... (overridable by setting the environment variable MAX_JOBS=N)
ninja: no work to do.
Loading extension module utils...
Time to load utils op: 0.1277756690979004 seconds
Parameter Offload: Total persistent parameters: 414720 in 81 params
[2023-06-06 08:35:14,223] [INFO] [launch.py:428:sigkill_handler] Killing subprocess 8597
[2023-06-06 08:35:30,494] [INFO] [launch.py:428:sigkill_handler] Killing subprocess 8598
[2023-06-06 08:35:30,495] [ERROR] [launch.py:434:sigkill_handler] ['/opt/conda/bin/python', '-u', 'train.py', '--local_rank=1', '--model_name_or_path', '../../merge_llama/llama_13b_hf', '--model_max_length', '1024', '--data_path', 'data3/dataset3', '--output_dir', 'output', '--num_train_epochs', '1', '--per_device_train_batch_size', '4', '--per_device_eval_batch_size', '1', '--evaluation_strategy', 'no', '--save_strategy', 'steps', '--save_steps', '100', '--save_total_limit', '1', '--learning_rate', '1.5e-5', '--warmup_steps', '300', '--logging_steps', '1', '--report_to', 'tensorboard', '--gradient_checkpointing', 'True', '--deepspeed', 'configs/config.json', '--fp16', 'True', '--log_on_each_node', 'False', '--lr_scheduler_type', 'cosine', '--adam_beta1', '0.9', '--adam_beta2', '0.95', '--weight_decay', '0.1'] exits with return code = -9
您好，仅从上面的报错信息来看，无法判断是什么原因造成的。您可以在运行的时候检查一下运行内存是否溢出或者显存是否溢出，可以尝试减少batch size，此外您也可以尝试它们的7B版本，来验证是代码的问题还是运行环境的问题。
您好，仅从上面的报错信息来看，无法判断是什么原因造成的。您可以在运行的时候检查一下运行内存是否溢出或者显存是否溢出，可以尝试减少
batch size，此外您也可以尝试它们的7B版本，来验证是代码的问题还是运行环境的问题。
好的，确实是oom了，已经跑成功了。 在预训练的代码里，未发现加载词表的代码，是否需要额外加类似的LlamaTokenizer.from_pretrained代码呢？
为了在保留原来的代码能力和英语能力的前提下，来提升模型对于中文的理解能力，我们并没有对词表进行扩增。
这个更多的是从正面的角度，从反向思考，如果扩充词表是否能提升中文能力更多呢？换句话说，是否有充足的证据表明llama的默认tokenizer能够有效编码中文数据。
希望你们下一次发布新的模型，千万别再用13作差了。。。。 用7b吧，huggingface上最好穿fp16的模型，不一定要用差值，也可以用xor，如果非得要这么一部的话。参考openbuddy他们13b的分发方式。。
您好，仅从上面的报错信息来看，无法判断是什么原因造成的。您可以在运行的时候检查一下运行内存是否溢出或者显存是否溢出，可以尝试减少
batch size，此外您也可以尝试它们的7B版本，来验证是代码的问题还是运行环境的问题。好的，确实是oom了，已经跑成功了。 在预训练的代码里，未发现加载词表的代码，是否需要额外加类似的LlamaTokenizer.from_pretrained代码呢？
您好，我们没有修改词表，因此直接使用LLaMA官方提供的tokenizer.model即可，您如若修改了词表，可以参考Chinese LLaMA项目。
为了在保留原来的代码能力和英语能力的前提下，来提升模型对于中文的理解能力，我们并没有对词表进行扩增。
这个更多的是从正面的角度，从反向思考，如果扩充词表是否能提升中文能力更多呢？换句话说，是否有充足的证据表明llama的默认tokenizer能够有效编码中文数据。
希望你们下一次发布新的模型，千万别再用13作差了。。。。 用7b吧，huggingface上最好穿fp16的模型，不一定要用差值，也可以用xor，如果非得要这么一部的话。参考openbuddy他们13b的分发方式。。
您好，关于第一个问题，我们对中文的常用字使用原来的分词器进行编码，然后对编码结果进行解码，结论是一一对应的，因此原来的分词器可以对中文进行编码。关于扩充词表能否提升中文能力，这个我也不能给出定性的结论，如果您有明确的结论，欢迎分享。
关于第二个问题，非常抱歉，您的建议非常好，也有其他用户与您提出了相同的建议，我们会在下个版本中使用您的建议。