5、大模型试跑与结果判断
更换模型前，先安排一次范围明确的短跑，回答“能否运行、预计花多久、是否值得继续”。本节用 8B 候选模型作配置推演，用教学日志练习判断；没有随附这次 8B 训练的实测结果。
可以直接读准备表、日志与选择方法。决定试用 8B 时，再展开下载和配置说明；第 2.6 节的小模型资源数字不能直接套用。
5.1 准备一次范围明确的试跑
短训练首先回答：当前模型与设置能否运行，完成计划大约需要多久。
仍使用第 29 章的 keywords-clean 数据划分：训练用 keywords_train，过程中检查用 keywords_validation，不要把测试集混入训练，也不要每次试跑都重新随机划分。
先检查模型文件大小、下载位置和加载精度，再准备模型与数据。下载方法见第 31 章“提前下载模型，不启动训练”，无卡模式也可完成。大模型要按下面的文件大小检查剩余空间，并选择合适的下载位置。
配置可以以配套的 案例与源码-4-微调/configs/keywords_clean_train.yaml 为起点，在编辑器中另存实验副本，再调整：
| 要调整的位置 | 怎样处理 |
|---|---|
| 模型路径与模板 | 指向准备试用的模型；重新确认其分词器、模板和长度 |
| batch 与累积 | 从能够放下的 batch 开始，再算有效批次 |
| 训练方式 | 明确普通 LoRA、QLoRA 或全参数，不同时试多种方案 |
| 输出目录 | 使用新的试跑目录，不覆盖第 31 章训练结果 |
| 训练轮数或步数上限 | 写清这次只测短跑，还是观察计划中的完整训练后提前停止 |
先记住一条估算原则：模型文件能存进磁盘、权重能放进显存、整个训练能运行，是三次不同检查。 训练还需要中间结果和训练状态，不能用模型文件大小直接回答需要多少显存。
例如，候选模型可以是同系列的 Qwen/Qwen3-8B。官方模型说明列出的参数量约为 8.2B，模型文件页显示文件总量约为 16.4GB。下载前先用 df -h / /root/autodl-tmp 检查剩余空间，将新模型放在数据盘，还要为下载过程和训练输出留出余量；不能只看磁盘的总容量。
按每个参数占 2 字节粗算，仅这份模型权重就约占 15.3GiB。这不是训练所需的全部显存：还要放中间计算结果、LoRA 参数和训练状态，也不能直接沿用小模型的 batch。官方配置标注的权重精度为 BF16，而本课程 V100 的训练计算采用 FP16；下载完成后仍需核对实际加载精度，不能只凭页面勾选了 FP16 就认定所有权重都以 FP16 加载。官方模型配置。
决定下载时，在第 31 章的 snapshot_download 调用中改用候选模型 ID，设置 cache_dir="/root/autodl-tmp/model-cache"，让新文件落到数据盘。记下函数返回的具体模型目录，随后填入配置。下面只展示模型与输出位置：
# 只列出模型与输出位置，不是可直接启动的完整配置
model_name_or_path: /root/autodl-tmp/model-cache/替换为下载返回的模型子目录
finetuning_type: lora
output_dir: saves/Qwen3-8B/lora/keywords-trial把第一项替换为下载返回的模型子目录。再按第 2 节检查实际加载精度、重新统计 token 长度，并从能放下的小 batch 开始试跑；其余任务设置保持一致，便于判断模型变化的影响。
没有合适硬件时，可先完成配置阅读和下面的日志练习，理解怎样估算资源、识别报错和判断结果。
5.2 “五分钟”从哪里开始算
第一次启动可能花时间加载权重、准备缓存，然后才出现不断增长的训练进度。要估算训练速度，应从正常处理训练 step 后观察，不是从点击按钮或下载模型时开始计时。
可以先运行几分钟，看看：
- step 是否持续增长，有没有重复报错；
- 速度是否逐渐稳定；
- 显存采样值有没有明显逼近上限；
- 预计剩余时间是否在合理范围。
“五分钟”只是一个便于入门的短跑长度，不是可靠性保证。它可能还没遇到最长样本、验证阶段和第一次保存。
例如第 31 章每 50 步保存一次。如果短跑在第 30 步停止，目录中可能还没有可恢复的 checkpoint-50，此时就不能从这份尚未生成的检查点恢复训练。
若希望验证保存流程，应在允许的运行范围内观察实际保存，或在新的试跑配置中明确设置保存时机；这项改变也会增加保存开销。
5.3 读懂进度条与预计时长
下面是教学示例，不是本课程某个 8B 模型的实测成绩：
30/150 [04:00<16:00, 8.00s/it]先按位置拆开：
| 内容 | 怎样读 |
|---|---|
30/150 | 已完成 30 个更新 step，计划共 150 个 |
04:00 | 已运行约 4 分钟 |
<16:00 | 根据当前进度估计还需约 16 分钟 |
8.00s/it | 平均每次进度迭代约 8 秒 |
这里讨论的是 Trainer 的更新进度条，不是模型下载或数据预处理的进度条。结合第 30 章的梯度累积，更新一步之前可能已经处理了多批数据。
按示例速度做粗略计算：
剩余步数 = 150 - 30 = 120
预计剩余 = 120 × 8 秒 = 960 秒 = 16 分钟
预计总计 = 4 + 16 = 20 分钟
图：先读进度和速度，再判断是否继续。所有时间均为教学算例，不是指定硬件的性能承诺。
有些进度条显示 it/s，意思是每秒完成多少次，数值越大通常越快；s/it 则是每次花多少秒，数值越小通常越快。先看单位，不能只比较数字大小。
预计时间会受长短样本、验证、保存和运行波动影响。不要把刚启动时的一个估计写成最终训练耗时。
如果在试跑配置里直接设置 max_steps: 30，总进度就可能是 30 步。这时进度条估算的是这次短任务，不能把它的剩余时间当作三轮完整训练的剩余时间。
5.4 比较速度前，先比较工作量
“每步快了一倍”，可能只是每步处理的文章少了一半。
假设两种方案都能正常运行，得到下面这组教学数据：
| 方案 | 每次更新处理 | 每个更新 step 耗时 | 平均处理速度 |
|---|---|---|---|
| 甲 | 32 篇 | 8 秒 | 4 篇 / 秒 |
| 乙 | 16 篇 | 4 秒 | 4 篇 / 秒 |
乙的 step 时间更短，但单位时间处理的文章没有增加。若要完成相同的数据轮数，它还需要更多更新步。
因此，对比单卡与多卡、LoRA 与 QLoRA 时，至少先对齐数据范围、实际长度和有效批次，再看耗时。不能一边改 batch，一边仅用 s/it 宣称加速比例。
文章长短差异很大时，也可以参考工具报告的 tokens/s，即每秒处理多少 token；比较时仍要确认它是否包含填充位置、统计的是哪一段运行。
在同一份数据、同一套任务设置下，结合完整耗时与样本处理速度判断性能变化。
5.5 根据结果决定下一步
试跑后，把原配置与调整后的结果放在一起，比较报错是否消失、速度和显存怎样变化，再决定下一步。
第 2.6 节的单卡对照已经展示了一种取舍：batch 4 更快，batch 2 留下更多显存余量。选择时要结合自己的运行情况，判断增加的时间是否值得，而不是只选显存数字最小的一组。
不同结果，下一步也不同：
- 路径、数据或模板错误： 先停止，回到第 29～31 章修正；暂时不用 GPU 就关机。
- 仍然 OOM： 回到本章第 2 节，按报错阶段继续排查。
- 能运行但很慢： 先按相同工作量比较，再判断是否需要调整资源方案；QLoRA 不应被直接当作提速开关。
- 能运行，预计时长也能接受： 可以继续当前任务，或保存配置后安排完整训练。
- 训练完成但质量不够： 按第 32 章检查回答，不把它简单归为“显卡不够好”。
短跑回答的是资源问题。完整训练后，还要用验证集选择方案；方案固定后，再用独立测试集比较结果。资源允许和质量合格，两项都不能省略。
若因改变模型、量化方式或数据而重新实验，应作为新任务启动；只有兼容的配置和完整恢复状态，才适合从检查点继续。不要把“加载 Adapter”与“恢复原训练进度”混为一谈。
把这个决定写入实验记录卡：这次瓶颈是什么、改了哪项、在相同工作量下多花或节省多少时间、还需验证什么。面试或向同事说明方案时，这些依据比罗列所有优化开关更能解释你的选择。
5.6 停止任务、关机与文件保存
先分清任务从哪里启动，再到对应位置停止：
| 当前运行的任务 | 到哪里操作 | 如何确认 |
|---|---|---|
| LLaMA-Factory WebUI 启动的训练 | 回到 Train 页底部，点击“开始”右边的红色 “中断” | 日志显示中断，训练进度不再增长；继续检查训练进程是否已退出 |
| 第 31 章 YAML 命令或本章对照脚本启动的训练 | 回到启动它的 AutoDL 终端，按 Ctrl+C | 命令结束并返回提示符，相关训练进程已退出 |
| Chat 页加载的模型 | LLaMA-Factory Chat 页 → 卸载模型 | 页面提示卸载完成，再核对显存变化 |
| 后台 WebUI 或 vLLM 服务 | 按第 31 章后台 WebUI或第 32 章后台 vLLM的步骤，在 AutoDL 终端核对 PID 后停止 | 对应进程退出、监听端口关闭；加载过模型时还要检查显存 |
在看日志的 tail -f 终端、监控显存的 watch 终端或本机 SSH 隧道终端按 Ctrl+C，都不等于停止远端训练。训练结束后，可在 AutoDL 终端用 ps -eo pid,ppid,args | grep '[l]lamafactory' 查看相关进程，再用 nvidia-smi 核对占用；WebUI 服务本身仍在列表中，不代表训练还在运行，要看具体命令。
决定不继续以后，按下面的顺序收尾：
- 保存当前配置、日志和报错；截图隐藏连接地址、账号等信息。
- 按上表停止对应任务，确认训练进程已经退出。关闭网页本身不会停止训练。
- 查看输出目录实际有哪些文件。只备份已经产生的日志、Adapter 或检查点，不假定短跑必然保存了模型。
- 按第 31 章的方法下载到本机或其他独立存储，并确认备份可以读取。
- 暂时不用 GPU 时，在 AutoDL 控制台关机并确认状态。
停止训练只结束训练任务，不会自动停止实例计费。关机与释放实例也不同：释放会清空实例本地数据，不能用来代替普通停机。
保存在同一实例数据盘中的文件，不算独立备份。若以后需要释放实例，应先核实备份，再按控制台提示操作；数据保留条件以 AutoDL 官方说明及当前控制台为准。
章节思考题：
加载模型时就 OOM，与处理长样本时才 OOM，可能对应哪些不同占用？为什么排查前还要看显卡上已有的进程？
参考思路： 加载阶段先看基础权重、加载精度、设备分配与已有占用；批次计算阶段重点看实际长度、单批样本数与中间结果。其他进程可能已占用显存，应先确认归属和用途，再判断当前任务需要怎样调整。减 batch 不会缩小基础权重本体，也不应直接结束用途不明的进程。
模型能加载，但训练批次放不下；当前 batch=4、累积=8。怎样先减小单批压力并保持有效批次？长度上限是否也应该直接减半？
参考思路： 可先改为 batch=2、累积=16，保持有效批次 32，核对实际配置和运行结果。长度上限应根据实际 token 数、填充和截断判断；本课最长训练序列为 957，2048 改为 1024 不会自动让计算长度减半，改为 512 则可能丢掉文章或答案。先确认问题所在，再分别调整。
梯度检查点、QLoRA 和 CPU 卸载分别适合缓解哪部分显存压力？各自需要付出什么代价？
参考思路： 梯度检查点减少保存的中间结果，代价是重算；QLoRA 低位量化基础权重，引入近似误差和相应计算、依赖要求；CPU 卸载把选定状态或参数移到系统内存，可能增加传输与 CPU 开销。优化器卸载与参数卸载的对象不同，具体收益要看哪部分占用最大，量化后也仍有激活和可训练参数的开销。
数据并行、张量并行和流水线并行，分别怎样安排文章与模型计算？为什么增加 GPU 数量之前要先分清这三种方式？
参考思路： 普通数据并行让模型副本处理不同样本，张量并行让多个 GPU 分担同一层计算，流水线并行让不同设备负责不同层并接力。数据并行不自动解决单份模型权重放不下的问题；后两种还涉及模型支持和通信安排。先明确要提高吞吐还是分担模型与计算，再选择分工。
两张卡做数据并行，每卡 batch=4、累积=4，有效批次是多少？两张卡用 TP 合作处理同一批 4 篇文章、仍累积 4 次，又是多少？
参考思路： 前者为 4×4×2=32，后者为 4×4=16。有效批次计入的是不同样本的份数，不能把 TP 合作处理的相同输入重复计算。混合并行时要按实际数据并行组数计算，不能直接乘全部 GPU 数量。
ZeRO Stage 1、2、3 分别分片什么？Stage 3 与 TP 有什么区别，为什么不必总选最高阶段？
参考思路： Stage 1 分片优化器状态，Stage 2 再分片梯度，Stage 3 再分片参数。ZeRO 组织训练状态的分片与按需获取，TP 拆分同一层的计算。更高阶段可能带来更多通信，激活占用也仍需处理；LoRA 可训练参数较少时，部分状态原本已较小，应根据实际显存与耗时选择。
原来每步处理 32 篇用 8 秒，调整后处理 16 篇用 4 秒，吞吐是否提高？再看第 2.6 节的两组实测，你会怎样比较并选择？
参考思路： 两者都是每秒 4 篇，不能只按每步时间判断加速。正文两组都完成相同的 50 步，batch=2、累积=16 比 batch=4、累积=8 更省显存，但命令耗时更长。比较时固定模型、数据与工作量，记录测量范围，再按所需显存余量、时间与任务效果作选择；不同长度的任务还可比较 token 吞吐。
准备换大模型或多卡前，短跑应覆盖哪些阶段、记录什么？什么时候才有依据决定完整训练？
参考思路： 从环境就绪后观察加载、训练批次、验证和保存，尽量覆盖代表性长样本，记录配置、实际样本与步数、显存和耗时。根据这些记录判断可行性并估算同等工作量成本；五分钟未报错不代表覆盖了所有阶段。完整训练后的模型仍需按第 32 章检查任务效果和旧能力。
本章小结：
- 显存排查从报错阶段和已有占用开始。权重加载、批次计算与参数更新的主要压力不同，应分别分析权重、梯度、优化器状态和中间结果。
- 减 batch 可配合梯度累积维持有效批次，缩短序列要检查截断。混合精度按硬件与计算需求选择，重算、量化和卸载则分别用计算、数值近似或数据搬运换取部分显存空间。
- 数据并行处理不同样本，TP 分担同层计算，流水线并行按层接力。有效批次中的倍数取决于实际数据并行份数。
- ZeRO 逐阶段分片优化器状态、梯度和参数，减少重复保存的训练状态。ZeRO 把状态分散到多张 GPU，CPU 卸载则把选定状态或参数移到系统内存；是否使用要结合具体占用、通信和耗时判断。
- 资源比较要固定工作量并说明测量范围，短跑用于确认已覆盖阶段的可行性。决定完整训练时还要考虑成本，训练完成后继续用实际回答与指标验证质量。
建议下一步： 回看第 28–33 章，整理一份简短项目复盘：用任务约定与数据说明解释为什么微调、怎样准备样本；用配置、日志和资源记录解释训练选择；用预测与报告说明效果、限制和下一轮计划。练习向同事讲清这些判断，并用自己的文件与结果回答实操和面试中的追问。没有亲自运行的部分注明来自课程案例。