CANN 组织链接 ： https://atomgit.com/cann
GE 仓库链接 ： https://gitcode.com/cann/ge
1. 稀疏张量在图表示中的结构化需求
处理 MoE 模型等带来的稀疏张量（如 CSR 格式）需要 GE 能够理解和维护这些稀疏数据的特定结构（数据、索引、指针）。
1.1 稀疏张量表示的标准化
GE 必须为稀疏结构定义标准化的图节点表示，以区分于稠密张量。
- 多重句柄 ：稀疏张量在 GE 的图表示中，不再是一个单一的张量句柄，而是需要包含数据指针、索引指针 （如 CSR 的 Column Index）和元数据（如非零元素数量）。
- 专用算子匹配：GE 识别到这种多指针结构后，会查找 ops-nn 库中支持稀疏格式的专用算子（如 SpGEMM），而不是尝试将其降级为稠密 MatMul。
1.2 稀疏性对布局优化的影响
稀疏操作的优化重点在于数据访问的局部性，而不是维度排列。
- 布局无关性 ：稀疏算子对传统的 NHWC/NCHW 布局转换不敏感。GE 在优化过程中必须跳过对稀疏数据流应用昂贵的维度重排操作，因为稀疏数据的内存访问模式是高度非线性的。
2. 自定义算子（Ascend C/PyPTO）的融合兼容性
当图包含自定义算子时，GE 的融合引擎必须能够安全地整合这些非标准操作。
2.1 融合的边界约束：自定义算子的原子性
GE 在进行融合时，会检查自定义算子是否满足融合的条件：
- 无副作用/无外部依赖：如果自定义算子在执行过程中不产生需要被外部（如 HCCL）同步的副作用，并且其输出仅被下一个算子消费，它才有可能被融合。
- 属性检查：自定义算子在 MetaDef 中定义的属性，必须与被融合的 ops-nn 算子兼容。例如，如果一个自定义核函数只处理 FP16，GE 就不能将一个 FP32 的 ops-nn 算子与之融合，除非插入精度转换。
2.2 Tiling 策略与融合边界的对齐
自定义算子依赖于其 Tiling 策略。当 GE 决定融合该自定义算子与某个标准 ops-nn 算子时：
- Tiling 策略重构 ：GE 必须确保融合后的新算子使用一套统一的 Tiling 规则。这可能意味着需要修改或重新应用一个与融合后核函数匹配的 Tiling 方案，以避免内部数据块的划分与融合操作的边界冲突。
3. 总结
GE 在处理复杂图结构（特别是稀疏模型和包含自定义节点的图）时，需要超越简单的稠密图优化。它通过对稀疏数据结构的精确识别和对自定义算子定义的严格遵循，确保了在应用算子融合和资源调度等高级优化时，模型的数学语义和底层执行的一致性。
CANN 组织链接 ： https://atomgit.com/cann
GE 仓库链接 ： https://gitcode.com/cann/ge