Inspect the delegation summary

The script walks the lowered graph and counts delegate calls and fallback operations:

    

        
        
graph = edge.exported_program().graph_module.graph
delegate_op = torch.ops.higher_order.executorch_call_delegate

delegate_calls = 0
fallback_targets = []
for node in graph.nodes:
    if node.op != "call_function":
        continue
    if node.target == delegate_op:
        delegate_calls += 1
    else:
        fallback_targets.append(str(node.target))

    

An executorch_call_delegate node marks a region handled by XNNPACK. Other call_function nodes remain on the default ExecuTorch path. The counts show graph fragmentation, but not the amount of computation in each region.

One XNNPACK delegate call site means that ExecuTorch will hand one region to XNNPACK at runtime. In this graph, that region contains the expensive CNN work. The only remaining call_function operation is <built-in function getitem>. This operation selects a value from the graph output. It is not part of the main convolutional workload.

This example provides a good contrast with Module 1. The models have different graph sizes and different operation costs, so the counts are not directly comparable. However, the table below shows that GPT-2 and DistilBERT are split across many delegated and fallback operations, while MobileNetV2 is captured as one large XNNPACK region with one small helper operation left on the default ExecuTorch path. This is because MobileNetV2’s convolution-heavy operators delegate extremely well to XNNPACK.

Consider what benchmark result this might lead you to anticipate.

Before moving on, confirm that the lowering step produced:

• mobilenetv2_xnnpack.pte
• mobilenetv2_xnnpack.json