🚀 The feature, motivation and pitch
Currently, export and lowering requires the user to make many decisions about delegates and quantization, which require the user to have a deeper understanding of the domain and stack. It would be desirable to provide a higher-level export API that handles the majority of the most common use cases, especially for mobile.
Ideally, this API should have the following characteristics:
- Provide out-of-box support / recipes for the most common backend and quantization patterns. That might be things like Mobile CPU with 8-bit static quantization, Mobile CPU with 4-bit quantization, CoreML, Mobile GPU, etc.
- Power users should be able to easily understand what each recipes is doing from looking at the code. This allows them to use them as a starting point for more advanced use cases. Maybe each recipe has a dedicated .py file.
- Use naming that the user understands (Mobile CPU or CPU vs XNNPACK), though we want to include enough information to learn more. For example, we can provide a Mobile CPU target, but in the description, we mention that it uses the XNNPACK backend.
- It should be first-class and under the executorch namespace and repository. It should be called something that indicates that it is a "core" or "core-adjacent" ET API. Getting Started docs should focus on this high-level API, where possible, with enough information to guide power users to the lower-level APIs.
- Available targets/recipes should represent well-supported paths for ET usage and should work out-of-box. We can use this to help guide the user to things (backends, quant schemes, etc.) that are well supported.
Alternatives
No response
Additional context
No response
RFC (Optional)
No response
cc @mergennachin @byjlw
🚀 The feature, motivation and pitch
Currently, export and lowering requires the user to make many decisions about delegates and quantization, which require the user to have a deeper understanding of the domain and stack. It would be desirable to provide a higher-level export API that handles the majority of the most common use cases, especially for mobile.
Ideally, this API should have the following characteristics:
Alternatives
No response
Additional context
No response
RFC (Optional)
No response
cc @mergennachin @byjlw