[ARM] Ethos-U backend wheel or alternative versioned package (to avoid dev installs from source)

[jonasdaugalas]

🚀 The feature, motivation and pitch

I might be missing a workflow, but from what I understand today it’s hard to use the Arm Ethos‑U backend for QAT in a standard ML project environment without installing ExecuTorch + Arm requirements from source.

Concrete scenario (two python environments):

1. .venv-model-authoring normal ML environment with:
   • custom model code
   • custom data-loaders
   • custom losses, optimizers
   • custom training/tuning loops
   • Managed with uv (could also be poetry/conda/pixi etc.)
2. .venv-executorch-dev:
   • An environment with development ExecuTorch and Arm Ethos‑U backend installed from source. As instructed per documentation.

What works / what doesn’t:

1. PTQ works with two envs: I can export from .venv-model-authoring a .pt2 exported-program, load it in the .venv-executorch-dev environment and feed the representative data through.
2. QAT is a big struggle: seems like during the QAT loop I need pieces from both worlds - custom loaders, optimizers, losses from my authoring environment; and arm_quantizer from the Executorch ARM Ethos-U backend.

Why it’s difficult to “just install ExecuTorch from source” into .venv-model-authoring
Mixing a source/dev install into the main training environment tends to be fragile for reproducibility and dependency management:

• the ML authoring project likely has a uv.lock file (or analogous), which is not respected by the source install of ExecuTorch and ARM backend.
• the source install of ARM backend has hardcoded URLs (in contrast to configurable package indices) from where the dependencies are pulled, making it difficult to set up in firewall-restricted compute nodes.
• source builds are generally slower than installing pre-packaged wheels in CI jobs.

Feature Request: A published package would be very helpful.

Maybe there is an alternative workflow that allows to serialize a model, ready for QAT tuning, that does not require arm_quantizer to be available in the model authoring environment?

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

cc @kimishpatel @jerryzh168 @digantdesai @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell

[Erik-Lundell]

Hi Jonas, could you provide some more details of what issues you are running into?

For the AoT flow, you should be able to use the pip package of Executorch. If you run into issues with a missing tosa-tools dependency, try just pip(uv)-installing this https://pypi.org/project/tosa-tools/. Let me know if you see other issues.

You will only need source when you reach building the runtime. A bit annoying if that doesn't fit into your other setup, but should be more doable to have one venv for AoT and one for runtime at least.

/Erik

[jonasdaugalas]

Hi Erik,

Thank you for the hint. This helps a lot. Following the guides was always pointing me towards having a development setup of Executorch ready and installing dependencies in a custom examples/arm/setup.sh way. I see now that tosa-tools package is released to pypi, and this solves the QAT workflow for me.

Would be great to see this also in the documentation. As a supported way of lowering models without building executorch and ARM runtime from source. In particular, because currently "ehtos-u-vela>=5.0.0" and "tosa-tools>=2026.2.1" seem to be pinning incompatible versions of "flatbuffers".

Thanks!