Support quantization in Dynamo, ONNX and ET exporters

[IlyasMoutawwakil]

What does this PR do?

Fixes # (issue)

Code Agent Policy

The Transformers repo is currently being overwhelmed by a large number of PRs and issue comments written by
code agents. These often are low-quality, or fix extremely minor issues that occur rarely or never in practice.
As a result, we're instituting a rule that first-time contributors should not use code agents to submit PRs or issues.
We'd also ask autonomous "OpenClaw"-like agents not to open any PRs or issues.

Issues/PRs from first-time contributors that violate this rule will probably just be closed without review, and we
might block you, especially if you open more than one or appear to be deliberately ignoring this. We especially do not
want new contributors to jump in on random issues to contribute an agent-written fix. This creates lots of noise
for reviewers and other users and will almost certainly get you blocked.

For more information, please read CONTRIBUTING.md.

• (First-time contributors only): I confirm that this PR description and code is not written by an LLM or code agent

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline and the
  Pull Request checks?
• Was this discussed/approved via a Github issue or the forum? Please add a link
  to it if that's the case.
• Did you make sure to update the documentation with your changes according to the guidelines?
• Did you write any new necessary tests?

Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[digantdesai]

Skimmed it, and looks nice for PT2E flow, I will properly review once you are ready. What is our plan to support eager mode or pre export quantization - I guess through 'HfQuantizer's classes?

[IlyasMoutawwakil]

What is our plan to support eager mode or pre export quantization

can you elaborate what you mean please 🙏

[stevhliu]

hope you don't mind my review! very well-structured docs though 🤗

[psiddh]

These imports reach into ExecuTorch's internal QNN impl:

_from executorch.backends.qualcomm.passes.qnn_pass_manager import QnnPassManager

_passes is underscore-marked internal and not a stable API — and it's actively churning: pytorch/executorch#20738. Hand-wiring
QnnPassManager.transform_for_export_pipeline() +get_to_edge_transform_passes() here will break as that migration series lands.

(Also, this PR patches _passes.replace_inf_values.ReplaceInfValues, already deleted from ET main: see pytorch/executorch#19660.)

Since #20738 is consolidating QNN pass execution into the standard to_edge_transform_and_lower flow, could the exporter integrate the way every other backend does?

edge = to_edge_transform_and_lower(
programs, partitioner=[QnnPartitioner(compiler_specs)], compile_config=...
)

What do you think?

The generic config.quantizer hook, added as part of this PR is awesome , backend-agnostic, touches zero QNN internals

[IlyasMoutawwakil]

yes we can remove them once these fixes/patches are released, that's the plan

[github-actions]

---

CI recap

Dashboard: View test results in Grafana
Latest run: 31332916436:1
Result: success | Jobs: 16 | Tests: 180,328 | Failures: 0 | Duration: 16h 27m