Ascend CANN backend/delegate for ExecuTorch

🚀 The feature, motivation and pitch

Hi ExecuTorch maintainers,

Following the guidance in https://github.com/pytorch/executorch/issues/16034, I would like to start a discussion about adding a Huawei Ascend CANN backend/delegate for ExecuTorch.

This is not a request for maintainers to implement the backend. I would like to check whether this direction makes sense for ExecuTorch before spending more time preparing patches.

Motivation

Huawei Ascend NPUs are widely used in data center and server-side inference deployments today. We are also interested in whether ExecuTorch's lightweight AOT runtime can become a good fit as Ascend expands into more edge deployment scenarios.

The usual software stack around Ascend is CANN, including graph/AOT compilation through the CANN toolchain, ACL runtime model loading and execution, Ascend device memory management, and optional external weight binding for larger models.

ExecuTorch's backend delegation model looks like a natural fit for this stack:

PyTorch model
  -> torch.export()
  -> ExecuTorch edge lowering
  -> backend partitioning
  -> backend preprocess / AOT compilation
  -> .pte / .ptd packaging
  -> lightweight C++ runtime
  -> backend delegate execution

The intended direction is to keep ExecuTorch core unchanged and implement Ascend as an optional backend.

Proposed direction

The proposal is to fit Ascend into ExecuTorch as a normal backend delegate, instead of requiring a separate runtime or a separate model packaging format.

At a high level, this could mean:

• AOT side: use a partitioner plus BackendDetails.preprocess() to lower delegated graph regions into an Ascend executable artifact.
• Packaging side: keep the delegate blob in .pte small, and use ExecuTorch named data / external data for larger compiled artifacts or shared weights when needed.
• Runtime side: implement a C++ backend runtime that loads the Ascend artifact and executes the delegated block through ACL.

CANN would be treated as an optional external dependency and would not be redistributed by ExecuTorch or required for default builds.

If this direction looks reasonable, I would appreciate guidance on the preferred way to proceed.

Thanks.

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

cc @cccclai

Begin by reviewing ExecuTorch's backend delegation flow, especially the partitioner and BackendDetails.preprocess() entry point, then examine how delegate artifacts are packaged in .pte/.ptd. The proposed runtime boundary is a C++ backend delegate using ACL to load and execute Ascend artifacts, but no files or tests are named; done would require maintainer agreement on this direction and a concrete implementation plan.