ONE编译图失败的表现通常很直接：模型转换能通过，但进入图编译阶段后报错，错误栈指向 operator validation 或 subgraph partition。这类问题看起来像算子不支持，实际可能只是子图划分把某些节点强行合并到了不该进入的加速后端。要解决它，需要先理解ONE编译器的中间表示在两个阶段做了什么。第一是算子合法性检查，第二是子图划分。本文按照报错现象、检查规则、划分策略和修复手段四个层面拆解。
排查的第一步不是盲目替换算子，而是确认失败究竟发生在检查阶段还是划分阶段。检查阶段报错通常包含 op type、input shape、dtype、attribute 等信息，划分阶段报错则更多出现 partition、subgraph、boundary、fallback 等关键词。把这两类日志区分开，后续定位效率会高很多。
一、失败现象与根因定位链路
ONE编译图失败时，终端日志可能会打印 Illegal operator: Conv_0 with dtype int64 或 Cannot partition graph due to control flow node If_1。这两种信息对应完全不同的处理路径。前者说明算子合法性检查没有通过，后者说明算子本身合法，但子图划分规则不允许当前拓扑被拆分。
想要定位具体节点，建议先开启图编译的 dump 与日志开关。通常在编译配置中可以设置 dump_graph_ir=true 和 dump_partition_info=true。dump 出来的 IR 文件会保留每个节点的输入输出、属性和后端标记。如果使用命令行工具，也可以把中间图导出为 dot 格式，再配合可视化工具查看哪些节点落在异常子图中。
C:\Users\your_name\.one_cache\graph_dump\partition_0.dot C:\Users\your_name\.one_cache\graph_dump\op_check.log
定位链路可以总结为：先看报错节点名，再在 IR 中搜索该节点，确认它属于哪个子图，接着检查该节点的算子签名是否匹配，最后看子图边界是否被错误划分。不要只看表面报错，很多非法算子问题其实是上游 shape 推导错误导致 dtype 不匹配。
二、算子合法性检查的完整清单
ONE编译器在将前端模型转换为执行图之前，会对每个算子做一轮静态合法性检查。第一项是注册检查，即当前编译后端的算子库中是否存在该 op type。如果模型里有自定义算子或新版本引入的算子，而部署镜像没有同步更新，就会直接报 op not registered。
第二项是签名检查，包括输入输出数量、数据类型、形状推导结果和属性取值范围。例如 Conv 算子通常要求输入为四维张量，权重的 out_channels 必须与 bias 长度一致，padding 不能超过 kernel 尺寸等。这些约束如果被破坏，图编译会在检查阶段就终止。
第三项是后端能力检查。同一个算子在 CPU、GPU、NPU 上支持的 dtype 和 shape 可能完全不同。比如某些 NPU 只支持 float16 和 int8，模型却输入了 float32 或 int64。此时算子本身合法，但目标后端无法执行。合法性检查会读取后端能力描述，拒绝不支持的组合。
下面是一个简化版的算子合法性检查函数，展示了检查顺序和报错方式。
def validate_node(node, backend_caps):
op_type = node.op
if op_type not in BACKEND_REGISTRY:
raise IllegalOpError('op %s is not registered' % op_type)
schema = BACKEND_REGISTRY[op_type]
if len(node.inputs) != schema.input_num:
raise IllegalOpError('input num mismatch for %s' % op_type)
for tensor, allowed in zip(node.inputs, schema.input_dtypes):
if tensor.dtype not in allowed:
raise IllegalOpError(
'dtype %s not allowed for %s' % (tensor.dtype, op_type)
)
if node.attrs.get('axis') is not None:
if node.attrs['axis'] not in schema.valid_axis:
raise IllegalOpError('invalid axis attribute')
if not backend_caps.supports(op_type, node.inputs[0].dtype):
raise IllegalOpError(
'backend does not support %s with dtype %s' % (
op_type, node.inputs[0].dtype
)
)
return schema
动态 shape 是检查阶段的另一个高频失败点。如果模型输入维度包含 None 或 -1，但后端要求静态形状，检查就无法通过。修复方式通常是固定 batch 或输入尺寸，或者在编译配置中显式声明允许动态维度的算子范围。
三、子图划分规则与失败处理
子图划分发生在算子合法性检查之后。ONE会根据后端能力矩阵，将连续支持目标后端的算子聚合成一个加速子图，遇到不支持的算子则切断，形成回退到通用后端的子图。划分结果直接影响执行效率，也决定图编译是否成功。
划分失败的第一个常见原因是跨后端依赖。比如子图 A 运行在 NPU，子图 B 运行在 CPU，但 B 的输入恰好是 A 中间某个未导出节点的输出，这会造成数据搬运路径非法。第二个原因是控制流算子，If 和 While 这类算子必须作为整体子图，不能把内部分支拆到不同后端。第三个原因是子图过小，划分出来的加速子图节点数低于阈值，编译器可能会直接拒绝生成，认为编译开销大于执行收益。
下面是一段简化子图划分逻辑，处理了不支持节点和控制流边界。
def build_partitions(graph, backend):
partitions = []
current = []
for node in graph.topo_order():
if node.op in ('If', 'While'):
if current:
partitions.append(current)
current = []
partitions.append([node])
continue
if backend_supports(backend, node):
current.append(node)
else:
if len(current) >= MIN_SUBGRAPH_SIZE:
partitions.append(current)
else:
fallback_nodes.extend(current)
current = []
fallback_nodes.append(node)
if current:
if len(current) >= MIN_SUBGRAPH_SIZE:
partitions.append(current)
else:
fallback_nodes.extend(current)
return partitions
修复划分失败，可以从配置入手。例如降低最小子图节点数、允许回退到 CPU、关闭控制流拆分、或把不支持的算子提前转换为后端支持的形式。不要直接删除算子，那样会破坏语义。更稳妥的做法是在编译参数中调整 min_subgraph_size、allow_control_flow_partition 和 fallback_to_cpu 三个选项，观察划分结果变化。
四、实践修复案例与检查清单
一个典型的失败案例是：模型包含 Conv -> BatchNorm -> ReLU，目标后端为 NPU，编译报错指向 BatchNorm 节点 dtype 不支持。表面看是 BatchNorm 算子非法，实际上检查日志会发现上游 Conv 输出的 dtype 被推导为 float32，而 NPU 的 BatchNorm 只支持 float16。解决方法是固定 Conv 权重为 float16，或在 Conv 后插入 Cast 节点。
另一个案例是：图编译报错 subgraph partition failed near node Slice_5，检查 IR 后发现 Slice_5 与后面的 Concat_6 被划分到了不同子图，但两者之间有一个隐式 reshape 依赖。此时需要把 Slice 和 Concat 合并到同一个回退子图，或通过调整划分策略让它们同时留在 NPU 子图中。
总结修复清单如下：先确认失败阶段，再导出 IR 和分区结果；检查报错节点的算子注册、dtype、shape 和属性；查看子图边界是否存在跨后端依赖或控制流拆分；根据日志调整编译配置或修改模型结构。按这个顺序排查，大部分 ONE 编译图失败都能在较短时间内定位并解决。