实行脚本相关

这篇记录解决什么

这是一则脚本性能复盘，记录一次“断点恢复看似快进、实际仍然很慢”的定位过程。结论是：模型推理本身没有卡死，问题出在恢复判断和输出逻辑的顺序。

现象与定位

恢复任务后，已经完成的 1803 对样本仍然逐对执行了以下操作：

1. 重新读取并预处理 VIS、IR；
2. 重写样本图片；
3. 重写每个样本的 metrics；
4. 每完成一对，就完整重写约 4.3 MB 的总 CSV 和汇总表。

“是否已经完成”的判断放得太靠后，导致前 1803 对重复进行图片和 CSV 写入，I/O 开销近似形成 (O(N^2))。因此进度看起来长期停在 1800 左右，根因不是 GPU 模型。

实测拆分

当时总进度约为 1829/3083，耗时构成如下：

时间线

18 点后的大部分时间被错误的断点快进消耗：脚本重新处理了前 1803 对的图片和汇总，直到约 19:39 才真正开始第 1804 对之后的推理。此前对完成时间的估计因此偏乐观。

可复用的修复原则

• 先读取完成标记，再决定是否读取、预处理和导出样本；
• 结果文件采用追加或批量写入，避免在循环中重写完整 CSV；
• 汇总统计按阶段刷新，并为中断保留可恢复的检查点；
• 预估总时长时，将模型计算、磁盘 I/O 和汇总开销分别测量。

结论

断点恢复的关键不是“从哪一对开始计数”，而是“已完成样本是否真正跳过全部副作用”。只有把完成判断前移，并控制输出频率，恢复任务才会接近线性耗时。