Azure ML Notebook训练远慢于同配置Colab的原因与优化方案

相同GPU、代码、训练参数、框架版本下出现3倍性能差，90%以上的根因是IO瓶颈导致GPU长期空转，剩余为环境配置的隐性差异：

• 存储链路差异是首要因素：Colab挂载Google Drive时默认会对高频访问文件做本地SSD缓存，绝大多数用户训练前也会主动将数据集从Drive拷贝到Colab本地临时盘（/content路径，直连实例本地SSD），训练时的数据读取几乎没有网络开销；而你在Azure ML中直接从Azure Files读取训练数据，标准层Azure Files属于网络共享存储，零散小文件的读取延迟是本地SSD的几十上百倍。Detectron2训练过程中需要逐批次加载大量零散图片文件，IO被打满时GPU利用率可能仅维持在10%-30%，绝大多数时间在等待数据加载，耗时自然会暴涨数倍。
• 隐性资源配置差异：Colab免费版分配的K80默认功耗墙、资源配额相对宽松，而STANDARD_NC6是Azure第一代老旧GPU实例，6vCPU搭配半规格K80，如果没有做主动校验，很容易出现CUDA驱动与Torch版本匹配度差、后台默认运行的Azure监控/日志进程抢占CPU资源、DataLoader参数与硬件规格不匹配的问题，进一步拉低训练效率。

按优化收益从高到低排序操作，基本可以将训练耗时拉到与Colab持平甚至更优水平：

• 优先解决IO瓶颈：训练启动前先执行文件拷贝，将全量数据集从Azure Files复制到计算实例的本地临时SSD（NC6本地临时盘默认路径为/mnt/resource，读写性能与Colab本地盘相当），拷贝完成后从本地路径启动训练，禁止直接读取网络共享盘上的零散文件。如果数据集大小超过本地临时盘容量，提前将零散图片打包为WebDataset、LMDB这类单文件顺序存储格式，大幅降低小文件网络寻址开销。
• 校验GPU实际运行状态：训练启动后执行nvidia-smi查看实时GPU利用率，正常训练Detectron2时GPU利用率应稳定在85%-95%区间：如果利用率长期低于30%，继续排查IO或DataLoader配置问题；如果利用率为0，说明当前环境未正确调用GPU，需检查CUDA驱动版本、Detectron2的CUDA扩展是否正确编译，避免误跑CPU版本。
• 调优数据加载参数：匹配NC6的6vCPU规格，将Detectron2配置中DataLoader的num_workers参数设为4-6，数值不要过高避免CPU资源争抢，同时开启pin_memory=True，配置2-3个batch的预取队列，减少GPU等待数据的空转时间。
• 裁剪冗余资源开销：关闭Azure ML默认开启的高频诊断日志、实时监控采样进程，训练过程中产生的日志、模型checkpoint先写入本地临时盘，等训练全部结束后再统一上传到Azure Files，避免每轮训练都向网络盘写入文件抢占IO带宽。
• 校验实例规格有效性：确认申请的STANDARD_NC6为常规优先级实例，低优先级、配额受限的实例会被设置CPU/GPU功耗墙，性能会出现明显折扣；如果预算允许，直接更换为NC6s_v3这类搭载V100、自带本地NVMe盘的新一代实例，单位训练成本反而比老旧K80实例更低。

内容的提问来源于stack exchange，提问作者Natrium2