昇腾910C爆显存，三步查清算子对齐

加卡先放到排查单最后一行。

模型从 PyTorch 的 CUDA 后端迁到 CANN，前几个 Batch 就 OOM，确实很像硬件容量不够。但 910C 的 96 GB HBM 只是账面上限；自定义算子前后的格式转换、数据复制和临时张量，都可能抬高某一时刻的显存峰值。

这里的算子对齐，别只理解成某个固定的内存边界。迁移时更值得逐项核对的是 shape、dtype、format/layout、输入输出语义，以及临时内存何时申请、何时释放。具体要求和 Profiler 字段会随 CANN、Ascend C 版本变化，应以当前版本文档为准。

腾讯云开发者社区的一篇材料列出的 910C 参考指标包括：FP16 算力 800 TFLOPS、HBM 96 GB、HBM 带宽 1.8 TB/s、HCCS 400 GB/s，以及 MFU 约 30%。同一材料给出的 H100 带宽是 3.35 TB/s，并称 910C 低约 46%。这些数字能提醒团队重视数据搬运，却不能直接解释一次具体的 OOM。

先把 OOM 钉在一条时间线上

固定代码版本、Batch、输入形状和并行配置，只运行能稳定复现问题的短任务。一次采集只改一个变量，否则前后结果很难比较。

用 CANN Profiler 或 msprof 对齐三类信息：

• OOM 前最后一组 Kernel 及其对应算子；
• 显存峰值出现的时间点；
• 自定义算子入口、出口附近是否连续出现 Data Copy 或临时内存分配。

同时记录输入输出的 shape、dtype 和 format。如果条件允许，把自定义 Ascend C 算子临时换回框架原生实现，在同一输入下跑一次。原生实现能跑、自定义实现 OOM，排查范围就收窄到了算子边界和内存路径；两者表现接近，再继续查模型配置和并行策略。

不要套用固定的 Copy 占比阈值。先看它是否与显存跳升、Kernel 等待出现在同一段时间线上。

顺着 Data Copy 查张量变化

不少迁移问题不会直接报对齐错误。算子可以正常完成计算，入口和出口却多出格式转换、填充或复制。特殊 Padding、切分、拼接以及非标准 Tensor Shape，都值得重点检查。

沿着自定义算子前后逐项核对：

• 输入输出 Shape 是否出现了预期外的补齐或裁切；
• dtype、format 是否被反复转换；
• 同一份中间结果是否在进入下一个算子前多次复制；
• 临时张量是否跨过多个 Kernel 后仍未释放。

发现额外复制后，先修数据路径：统一张量格式，减少重复转换，简化不必要的 Padding、切分和拼接。处理完这些，再决定是否保留或重写自定义算子。

单个 Kernel 跑得更快，不代表整段计算更省显存。应在同一输入下比较修改前后的显存峰值、Data Copy 和总耗时。910C 的 HBM 带宽为 1.8 TB/s，这并不能证明所有任务都受带宽限制，但足以说明频繁搬运中间结果值得优先排查。

小算子过密就融合，跨卡等待明显再重切

如果 Profile 中连续出现 Add、ReLU、Mul 这类小型 Element-wise 算子，可以评估算子融合。目标是减少中间张量和 Global Memory 读写，而不是单纯让 Kernel 数量变少。融合前后仍要使用相同输入，对比显存峰值、复制次数和整段耗时。

流水线并行则要看 HCCS 通信事件与 Kernel 等待是否发生在同一阶段。400 GB/s 是材料给出的标称参考值，不能当作当前任务的实测吞吐。如果某个 Stage 边界反复传输中间结果，同时相邻 Stage 出现明显空等，就该重新检查 Layer 切分和各 Stage 的负载。

流水线并行可以分摊模型状态，却不会自动消除自定义算子产生的额外临时张量。如果 OOM 总是贴着同一个算子出现，调整 Stage 只能移动问题位置，算子边界仍要先处理。

什么时候再考虑加卡

排除异常复制、临时张量滞留和流水线失衡后，如果同一任务的显存峰值依然稳定超过现有容量，再调整 Batch、内存策略、并行方案或评估 Atlas 服务器扩容，依据会更充分。

这类排查没有统一的吞吐收益承诺。最终应留下清楚的证据链：峰值在哪个算子出现，复制为何发生，融合或重切后是否下降。到这一步，再决定 96 GB HBM 是否真的不够。

参考资料

• 华为昇腾910C不是最好的AI芯片，但它是中国AI产业唯一的选择——然后呢：本文中的硬件指标及 H100 带宽对比来自该材料。
• 昇腾社区官网：CANN、Ascend C 与 Profiler 的当前版本文档入口。