LLaMA - Factory微调模型进行数据验证与deepspeed

LLaMA - Factory微调模型进行数据验证与deepspeed

一、模型微调验证流程

1. 初始验证：以“请列出继续教育学校针对五至17岁学生的最低三个免费费率是多少”为例，在不加载微调模块，直接使用原模型时，模型只能提供获取信息的途径，无法生成期望的SQL语句。
2. 微调后验证：经过30分钟微调，加载指定output输出的dll路径对应的训练模块后，模型能够生成包含SQL结构（如select、from、where条件等）的内容，表明模型在生成SQL语句方向有了进步 。
3. 模型导出与二次验证：微调后需导出模型，选择基座模型与LoRA模块，指定导出目录（若不存在会自动生成），点击开始导出。导出后，在相应界面加载合并导出的文件（而非基座模型路径），关闭检查点路径信息，再次输入问题进行验证，确保模型导出过程无问题，避免后续使用或部署时出现麻烦 。

二、批量数据预测操作

使用LLaMA - Factory的预测模块，选择基座模型命令与微调模块，指定熟悉的data路径（如相对路径）和期望的数据集（如alpaca_dev）。设置输入长度（如1024 ，与训练时2048有别）等参数后点击预览命令。参数含义如下：

1. 是否生成文本：决定预测后的数据块展示方式，若开启，除在界面展示，还会在指定路径下生成，防止界面刷新数据丢失。
2. 生成token相关参数：如生成token的最长数量、top_p（控制生成文本的随机性，取值越高越随机）、temperature（影响生成文本的多样性，值越大越多样） 。
3. 输出路径：指定生成数据的保存路径，为相对路径，基于启动位置生成 。

三、预测结果分析

预测完成后，在输出目录可找到与界面展示相同的文件，其中关键指标含义如下：

1. 文本相似度（如predict_bleu - 4）：衡量生成文本与参考文本的相似度，一般数值越高越好，但过高可能意味着过拟合，本次结果约68%，属于中等偏上水平。
2. 模型准备阶段时间（predict_model_preparation_time）：即加载模型和数据处理的时间，越短越好 。
3. 文本匹配相关指标（predict_rouge - 1、predict_rouge - 2）：predict_rouge - 1表示生成文本与参考文本在单个词层面的重叠度，越高越好；predict_rouge - 2表示两个词层面的重叠度，不宜过高，本次结果中该值为65% 。
4. 运行时长（predict_runtime）：本次约700秒（12分钟左右），反映模型处理数据的时间 。
5. 处理速度相关指标（predict_samples_per_second、predict_steps_per_second）：分别表示每秒处理样本数和每秒处理步数（涉及transform的前向传播和向后传播），速度越快越好 。

四、deepspeed微调

1. deepspeed的作用与模式：deepspeed是用于优化训练的工具，有ZeRO Stage1 - 3和offload模式。ZeRO Stage1对优化器状态进行分片，Stage2对优化器状态和梯度分片，Stage3对优化器状态、梯度和模型参数分片；offload将部分计算和数据存储任务从GPU卸载到CPU或NVMe存储，以节省GPU内存，训练更大模型，但会增加训练时间 。

优化模式	操作内容	内存节省原理	对训练的影响	适用场景
ZeRO Stage1	对优化器状态进行分片，每个进程只保留其所需的优化器状态的一部分	将优化器状态分散存储在不同进程中，减少单个进程的内存占用	- 减少了每个进程中优化器状态的内存占用，一定程度上节省内存。 - 相比未分片的情况，在内存使用上更高效，但对梯度和模型参数的内存优化不明显。 - 训练速度可能因数据读取和通信开销略有影响，但相对较小。	适用于内存稍有紧张，但对训练速度要求较高，且模型规模不是特别大的场景。例如，在使用多进程训练时，若单个进程内存接近上限，但整体内存还有一定余量，可采用此模式 。
ZeRO Stage2	对优化器状态和梯度进行分片	不仅分散优化器状态，还将梯度也进行分片存储，进一步减少每个进程的内存负担	- 除优化器状态外，梯度的分片存储大大降低了单个进程的内存需求。 - 能支持更大规模模型的训练，减少内存不足导致的训练中断情况。 - 由于梯度分片，在反向传播计算和更新参数时，需要进程间更多的通信协调，会在一定程度上增加训练时间，但通常在可接受范围内。	适用于模型规模较大，内存较为紧张，但希望在不显著增加训练时间的前提下进行训练的场景。例如，在训练一些参数较多的中型模型时，该模式能较好地平衡内存和训练效率 。
ZeRO Stage3	对优化器状态、梯度和模型参数进行分片	将优化器状态、梯度和模型参数都进行分片处理，全面降低内存占用	- 全面分片使得每个进程需要存储的内容大幅减少，可极大地节省内存，支持大规模模型的训练。 - 因为模型参数也参与分片，训练时进程间的通信量进一步增大，训练时间会明显增加。 - 对网络通信要求较高，若网络条件不佳，可能会导致训练效率严重下降。	适用于模型规模非常大，内存严重受限的场景。例如，在训练超大规模的语言模型时，ZeRO Stage3模式可以让原本因内存不足无法训练的模型得以训练 。
offload	将部分计算和数据存储任务从GPU卸载到CPU或NVMe存储	利用CPU或NVMe存储的大容量，分担GPU的存储压力，释放GPU内存	- 显著释放GPU内存，使GPU能够专注于计算任务，可用于训练更大的模型。 - 由于数据在GPU与CPU或NVMe之间传输以及CPU参与部分计算，会导致训练时间大幅增加。 - 对CPU性能和NVMe存储速度有一定要求，若CPU性能不足或NVMe存储读写速度慢，会进一步延长训练时间。	适用于GPU内存严重不足，但有足够的CPU资源和快速NVMe存储的场景。比如在进行一些超大型模型的训练，且GPU内存无法满足需求时，可结合offload模式来完成训练 。

2. 参数选择与效果：如选择ZeRO Stage3模式，在训练相同数据量和配置下，相比不使用deepspeed，可节省约20g显存（从44g减至12 - 24g ），但训练时间会大幅增加（从30分钟增至约两小时45分钟，约为原来的5倍）。
3. 版本注意事项：官网推荐deepspeed版本为0.14.0，但实际使用中，与LLaMA - Factory最适配的版本是0.14.5 。使用最新版本（如0.15.x）可能导致torch或其他依赖包崩溃，升级或降级版本时应避免跨越大版本，以防出现额外错误 。

五、课程总结

1. 微调全流程回顾：首先寻找数据，可从Hugging Face、国外大学合作网站（如kaggle、wikis等）或国内平台（如阿里、千言、百度等）获取。将数据处理为Alpaca或ShareGPT格式后，注册到LLaMA - Factory。接着进行微调，注意LoRA参数调整，避免资源浪费、过拟合、欠拟合以及梯度相关问题。微调后进行两次验证（导出前和导出后），评估模型整体能力 。
2. 资源与格式问题：若资源不足，可使用deepspeed，但要注意版本选择。LLaMA - Factory目前仅支持Alpaca和ShareGPT格式数据，若想处理其他格式数据（如图像相关），可在现有框架基础上，通过在特定模块（如ShareGPT相关模块）录入图片路径等方式进行尝试，但仍需遵循框架的数据处理范式 。
3. 后续课程展望：LLaMA - Factory适合新手快速上手，后续课程将教授如何脱离框架，使用Pytorch等工具自己进行微调，深入了解底层运行机制 。

六、老师重点提示汇总

1. 数据处理与格式：数据处理是微调的基础，重点关注Alpaca和ShareGPT格式。在处理数据时，要明确关键数据的提取和转换，找准input、output等关键信息。代码实现并非重点，理解数据处理思路才是关键。目前LLaMA - Factory仅支持这两种格式，若要处理其他格式数据，需在现有框架和格式基础上想办法，例如在特定模块中录入相关路径，但不能脱离框架的数据处理范式 。
2. 微调参数与问题：微调过程中，LoRA参数的调整至关重要。要关注其可能引发的资源浪费、过拟合、欠拟合以及梯度消失或爆炸等问题。掌握这些问题的应对方向，有助于在微调时合理设置参数，提升模型性能 。
3. 模型验证与评估：模型微调后，务必进行两次验证，即导出前和导出后验证。这能确保模型在导出过程中没有出现问题，避免后续使用或部署时出现麻烦。同时，通过评估模型的整体能力，如生成文本的质量、与参考文本的相似度等指标，判断模型是否达到预期效果 。
4. deepspeed使用要点：使用deepspeed进行微调时，版本选择非常关键。官网推荐版本不一定是最适配的，当前与LLaMA - Factory适配较好的是0.14.5版本。避免使用最新版本，升级或降级版本时不要跨越大版本，否则可能导致torch或其他依赖包崩溃，出现难以解决的错误 。
5. 框架使用与拓展：LLaMA - Factory适合新手快速上手，帮助初学者快速体验模型微调流程。但它也有一定局限性，后续课程会教授脱离框架，使用Pytorch等工具进行微调的方法，让大家深入了解底层运行机制，拓展技术能力 。