[RFC][Short] More on ExportRecipes

[abhinaykukkadapu]

Discussed in #12553

^{Originally posted by abhinaykukkadapu July 16, 2025}
This discussion outlines few proposals regarding the ExportRecipes (currently experimental). These requirements have emerged from various discussions, and I want to consolidate them here for further discussion and prioritization:

1. API Naming

There is potential confusion between torch.export.export() and executorch.export(), especially since the latter encompasses additional functionalities such as quantization, lowering, and serialization. A previously proposed solution is to rename executorch.export(..) -> executorch.compile(..). This change could enhance clarity, but it may also be unnecessary. I would like to gather your thoughts on whether a renaming is warranted.

2. Support for Additional Backend Recipes

Support additional backend recipes

• XNNPack (supported)
• CoreML
• QNN

3. QAT Quantization support

Currently, our recipes support Post-Training Quantization (PTQ). Should we extend this support to include Quantization-Aware Training (QAT)? Additionally, which backends currently support QAT, or we should at least transparently error out if QAT based recipe is passed?

4. Differentiating Calibration Inputs vs Example Inputs

The proposal is to add a new parameter, calibration_inputs, to the API alongside example_inputs. This parameter would explicitly indicate to users that the data provided in calibration_inputs is used for quantization purposes, while example_inputs are solely for export.

5. Support for ExportedProgram

At present, the API requires an nn.Module and assumes that the export stage is always run within the scope of the recipe. The proposal is to decouple this to accept either an ExportedProgram or an nn.Module. This change would help use cases such as HuggingFace Optimum, where the ExportRecipe can be utilized for post export stages such as graph quantization, lowering. This would provide greater flexibility for models to use torch.export.export(...) in a manner that suits their needs but use recipes for just quantization and lowering.

6. Support to_edge -> to_backend -> to_executorch along with to_edge_transform_and_lower

Currently, the executorch/export supports only the to_edge_transform_and_lower API. Is there a need to support to_edge() -> to_backend() -> to_executorch()?

7. Modularization of ExportRecipe

Split current ExportRecipe into piece-meal recipes such asExportRecipe, QuantizationRecipe, LoweringRecipe and have a root recipe for example: CompileRecipe which takes all the above. This might require re-writing most of the current ExportRecipe component, so not sure if this is needed, we may just get away with doing just (5) - Supporting ExportedProgram which skips torch.export.export() and SourceTransform stages which might be just sufficient.

8. Composable stages

Add support for composable stages to support dynamically running various lowering paths, user should have the power to choose the sequence of steps, we will validate if the provided sequence is valid. For example, user can choose between:

• TORCH_EXPORT -> TO_EDGE_TRANSFORM_LOWER -> TO_EXECUTORCH
• TORCH_EXPORT -> TO_EDGE -> TO_BACKEND -> TO_EXECUTORCH

CC: @cbilgin, @mergennachin, @kimishpatel, @metascroy, @JacobSzwejbka, @guangy10, @digantdesai, @mcr229, @jackzhxng, @JakeStevens