Azure上跑PyTorch，最直接的好处是能按秒计费地调用V100或A100。我去年帮一个做医学影像的团队迁移训练任务，他们原本用四块2080Ti在办公室跑，一个epoch要47分钟。换到Azure的NC6s v3实例后，同样的代码没改几行，时间压到11分钟。这不是优化算法，纯粹是硬件代差。

但别急着开虚拟机。Azure的GPU配额默认是零。新订阅想用NC系列，得先提工单申请。我见过有人卡在这一步三天，以为平台坏了。其实在“订阅”->“使用情况+配额”里提交申请，写清楚用途和预计用量，一般两小时内批下来。这个设计挺烦人，但能防止有人拿免费额度挖矿。

创建实例时有个坑：市场里的“Data Science Virtual Machine”镜像预装了PyTorch和CUDA，但版本往往落后。比如去年它带的是PyTorch 1.7，而你的代码需要1.13的torch.compile。不如直接选Ubuntu 20.04或22.04的纯净镜像，然后手动装。用conda建环境，conda install pytorch torchvision torchaudio pytorch-cuda=11.8 -c pytorch -c nvidia，三行命令搞定。比跟预装环境斗智斗勇快多了。

数据怎么上去？小文件用azcopy，大文件挂载Azure Blob。有个细节：Blob Fuse挂载点默认权限是777，但PyTorch的DataLoader多进程读取时，如果num_workers超过4，偶尔会报“输入/输出错误”。解决办法是把num_workers降到2，或者用--multiprocessing_context=spawn。这个bug不常见，但碰上了能查半天。

训练监控别只盯着nvidia-smi。Azure的“指标”面板里可以看GPU利用率、内存带宽、甚至NVLink流量。我习惯在代码里加一行torch.cuda.memory_summary()，每10个epoch打印一次。有一次发现reserved_bytes比allocated_bytes多了3GB，查出来是某个DataLoader没释放缓存。这种问题在本地机器上往往被忽略，因为显存够大。云上按小时计费，浪费显存就是浪费钱。

成本控制有个野路子：用az vm deallocate而不是stop。前者释放GPU资源，后者只是关机，GPU还被占着。但deallocate后公网IP会变，如果脚本里写死了IP，下次连不上。更稳的做法是配一个静态IP，或者干脆用Azure Machine Learning的ComputeCluster，它会自动缩容到零。不过AML的Environment构建慢，第一次跑要等15分钟拉镜像。适合长期项目，临时实验不如手动开虚拟机。

最后说个真事。上个月有个用户抱怨PyTorch在Azure上比本地慢20%。查了半天，发现他用了torch.backends.cudnn.benchmark = False。本地显卡是RTX 3090，Azure是V100，cudnn的启发式算法对V100的卷积核选择更敏感。改成True后，速度反超本地。云硬件的特性得单独调，不能照搬本地配置。

Azure的PyTorch支持不算完美，但胜在稳定。NC系列很少出现掉卡，Blob存储的吞吐也够喂饱A100。如果你能忍受配额申请和偶尔的驱动版本冲突，它比自建机房省心。至少不用半夜爬起来给服务器换风扇。