本章主线不是背 API，而是让已有 PyTorch 代码在明确版本、设备和证据边界下迁移到 NPU。
先给出本讲路线图；后续每一段都对应这里的一行，最后回到路线收束。
学生经常只看到一个 Python 异常，就把问题归到 NPU。先按三层定位，后面的验证才有意义。
强调 PyTorch 兼容性降低代码改写量，但不会自动保证所有算子在目标 CANN 和精度下都可用。
版本组合必须来自可核对的配套表，不能从“最新版”推断兼容。双板旧记录也不能拿来替代当前安装核对。
这页专门防止证据拼接。教材中的版本是安装示例，双板实际记录是 Python 3.9.2 和 CANN 8.0.0，且日志没有保留框架插件版本号。
导入 torch_npu 只证明模块可加载，最小张量运算才证明请求到达 NPU。出现 warning 时要保存原文，但 warning 本身不等于失败。
迁移要保持算法不变，只替换设备与必要兼容点。任何算子替换、精度改变和 batch 改变都要进入实验记录。
曲线证明这组代码在该记录中完成训练并收敛，不证明推理性能或整机吞吐。横轴是 epoch，纵轴是训练 MSE。
严格保留 8T 的 56.908 s 和 20T 的 78.532 s，不能互换，不能平均。最终参数相同说明本次训练路径得到了同组拟合值，不说明速度排名。
这页解释为什么更高档位的单次墙钟可能更长。不能把总时间除以 epoch 就称为 NPU 算子性能。
MLP 通过隐藏层和非线性激活突破线性模型限制。迁移时要继续检查每层算子、激活函数和输入维度，而不是只把设备改成 NPU。
LeNet 教材实现把 Sigmoid 调整为 ReLU，并使用 FP16。曲线说明该配置在记录中完成训练，不能替代兼容性测试和最终质量评估。
这里记录的是教材中的 CANN 8.3.RC1 + PyTorch 2.8.0 环境，不是双板任务记录。失败项和通过项都必须保留，不能用“多数通过”掩盖阻塞问题。
这条曲线是教材历史训练结果，不属于本次双板 50 epochs 线性回归记录。它说明该配置曾完成训练，不能与双板墙钟或其他硬件直接排名。
不能用一个网络通过就推断另一个网络可用。尤其关注池化替换、BN 与 FP16 稳定性，以及更深的图编译内存。
这是本章的证据纪律。CPU 能跑、Python 能导入、曲线好看，都不能替代 NPU 设备路径和板端原始记录。
排查顺序从环境到设备，再到最小算子，最后才进完整模型。这样可以避免把 OOM、算子缺陷和版本不匹配混成同一个问题。
最后检查学生是否同时提交通过证据和失败边界。没有 NPU 设备证据、没有版本、没有原始日志的结果不计为完成。