ops-transformer 基础设施性能实验报告：GE 融合边界与 Runtime 调度效率实测

ops-transformer 基础设施性能实验报告：GE 融合边界与 Runtime 调度效率实测

之前聊了 GE 和 Runtime 的工作原理，但原理归原理，实战里这两层到底怎么影响 ops-transformer 的性能，还得用数据说话。这篇文章设计了三个实验，分别测 GE 融合在不同条件下的命中率、Runtime 的数据搬运与计算 overlap 效率、以及 ops-transformer 算子走融合链路和走裸链路的真实性能差距。

实验环境基于 910B NPU + CANN 8.0，算子来自 ops-transformer 仓库 v1.0。

实验一：GE 融合命中率的四个关键变量

实验假设：GE 的融合决策由 shape、dtype、分块策略、算子注册完整性四个变量共同决定，四个变量同时满足最优值时融合命中率最高，任一变量偏离最优值都会导致命中率下降。

实验设计：控制变量法，每次固定三个变量，单独测试第四个变量的四个档位。

测量方法：每个配置跑 100 次，使用 Profiler 的 GPU Trace 视图记录融合前后的算子序列，计算融合率 = 融合后算子数 / 融合前算子数。同时用 Runtime 日志输出每次融合的匹配规则名称。

实验结果（融合率/%）：

结论一：float16 是 ops-transformer 的最优 dtype，bfloat16 次之，float32 和 float64 的融合率显著偏低——这跟 GE 的融合规则主要针对混合精度场景设计有关。tile_size 不是越大越好，128 是拐点，256 反而因为 UB 寄存器压力增大导致部分融合失败。算子注册越完整，GE 的跨算子融合窗口越大，融合率越高——ops-transformer 的全量注册是官方推荐做法，不要只注册单个算子。

结论二：序列长度越长，融合率越高。这个趋势在 float16 和 bfloat16 下都很明显，但在 float32 下不明显。这说明 GE 的融合策略对长序列有更好的优化空间——当中间结果足够大时，融合带来的 HBM 读写节省足以覆盖融合本身的开销。

实验二：Runtime 数据搬运与计算 overlap 效率

实验假设：Runtime 的核心能力是把数据搬运和计算做成 pipeline，但这个 overlap 效率受 batch size 和 shape 固定程度的影响。动态 shape 场景下 overlap 效率会显著下降。

实验设计：测量不同 batch_size（1, 4, 8, 16）和不同 shape 模式（固定 shape、动态 batch、动态 seq_len）下的端到端耗时构成。

测量方法：使用torch.npu.synchronize()精确切分数据搬运和计算阶段的时间。通过 Profiler 的 AI Trace 视图，分别记录三个阶段的时间占比：Host→Device 搬运、数据等待（数据到了但计算单元还没启动）、NPU 计算。

实验结果（时间占比/%）：

结论三：batch_size 从 1 增到 8，计算占比从 46% 升到 80%，提升效果非常显著。batch_size=1 是最浪费 NPU 算力的场景，数据搬运和等待时间加起来比计算时间还长。动态 seq_len 对性能的影响比动态 batch 大得多——动态 seq_len 时等待占比达到 28.7%，因为 Runtime 无法提前规划 tile 级别的数据预加载，必须等前一个 tile 计算完才知道下一个 tile 的 shape。

结论四：ops-transformer 的 FlashAttention 算子在长序列（seq_len≥2048）+ batch≥8 + float16 的组合下，Runtime 的 overlap 效率达到最高水平。如果你的训练场景 batch 很小（batch=1），不要指望 Runtime 的 overlap 能弥补 batch 太小的问题——你需要先增大 batch，或者接受在这个场景下计算单元利用率只有 50% 左右的现实。

实验三：融合链路 vs 裸链路的端到端性能差距

实验假设：ops-transformer 算子的性能优势主要来自 GE 的融合决策，而不是算子本身的实现质量。融合链路和裸链路在同一个硬件上的性能差距，可以量化地说明融合的价值。

实验设计：对比两种调用路径下 FlashAttention 的单次执行耗时：(A) 融合链路——PyTorch 模型层通过 Framework Adaptor 注册，GE 识别并融合，执行；(B) 裸链路——通过 AscendCL API 直接调用单个算子，跳过 GE 的图优化。测试三个 shape。

测量方法：固定 dtype=float16，causal=True，分别测量 (A) 和 (B) 在 seq_len=512/1024/2048 下的单次耗时，每个 shape 跑 200 次取 P50/P95/P99。

实验结果（耗时/ms）：

结论五：融合链路比裸链路快 3x 以上，加速比在不同 shape 下稳定在 3~4x 之间。P99 延迟的差距更大（超过 3x），说明融合链路不仅更快，而且更稳定——GE 在编译期做了内存规划，减少了运行期的显存分配抖动，这对 P99 延迟的影响尤为明显。

结论六：裸链路的 P99/P50 比值约为 1.38，而融合链路是 1.52，反而裸链路更稳定。这看似矛盾，但可以解释：融合链路虽然平均更快，但因为涉及更多运行时决策（tile 级别的数据预加载、UB 寄存器分配），在边界条件下（shape 刚好卡在融合边界上）的波动反而更大。

综合结论与调优方向

三个实验放在一起看，有一条清晰的主线：ops-transformer 的性能上限由 GE 融合决定，ops-transformer 的性能下限由 Runtime 调度效率决定。融合决定你能达到多高，Runtime 决定你实际能用到多少。

基于实验数据，推荐以下调优优先级：

相关仓库：

https://atomgit.com/cann/ops-transformer

https://atomgit.com/cann/ge

https://atomgit.com/cann/cann-learning-hub