[RFC] Ascend CANN backend/delegate for ExecuTorch #20732
leograssroot
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions