🚀 The feature, motivation and pitch
Hi ExecuTorch maintainers,
Following the guidance in #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
🚀 The feature, motivation and pitch
Hi ExecuTorch maintainers,
Following the guidance in #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:
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:
BackendDetails.preprocess()to lower delegated graph regions into an Ascend executable artifact..ptesmall, and use ExecuTorch named data / external data for larger compiled artifacts or shared weights when needed.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