Exporters onnx module#403
Conversation
|
The documentation is not available anymore as the PR was closed or merged. |
|
Any plans or advice about adding speech related tasks ? |
|
Hi @flozi00 , |
regisss
left a comment
There was a problem hiding this comment.
Thanks for this huuuge work @michaelbenayoun! I have a few comments and I also spotted a few typos.
regisss
left a comment
There was a problem hiding this comment.
Huge work @michaelbenayoun 🚀 🚀 🚀
lewtun
left a comment
There was a problem hiding this comment.
Amazing work @michaelbenayoun - I really like the elegant approach to using inheritance with the ONNX configs!
I've left a few comments, but overall this looks really nice. The main question is whether we should use this feature as an opportunity to clean up some name choices we made in transformers
Also, I think this PR should copy-paste the serialization.mdx docs from transformers to optimum (with the appropriate changes of course)
optimum/exporters/features.py
Outdated
| # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| # See the License for the specific language governing permissions and | ||
| # limitations under the License. | ||
| """Model export features manager.""" |
There was a problem hiding this comment.
I always found the word "features" a bit confusing in the original exporter - does it refer to feature vectors or something else?
Since we have the opportunity to do something new, would something like "architecture" or "head" be more appropriate?
There was a problem hiding this comment.
👍 for architecture, or what about just pipeline type or task type?
More generally 100% agree that we could use this opportunity to improve the DX as much as we can
There was a problem hiding this comment.
I like:
TaskManagerArchitectureManager
There was a problem hiding this comment.
I fully agree that "features" sounds odd here.
My 2 cents: "task" sounds great, especially since people with little ML knowledge will understand it instantly whereas "head" will not mean much to them, "architecture" is as confusing as "features" IMO and "pipeline" can mean many different things.
There was a problem hiding this comment.
either task or pipeline would be consistent with the rest of the Hub. If consistent with the Hub, then task fits better. If consistent with transformers, then pipeline.
There was a problem hiding this comment.
I went for task!
Actually I think that pipeline is not suitted because we do not match the pipeline names. Like sequence-classification instead of text-classification.
There was a problem hiding this comment.
Task sounds good (even if we can't 100% match the Hub definitions because of past key-value variants + the fact we're really mapping "task" to AutoModelForXxx).
optimum/exporters/features.py
Outdated
| ) | ||
|
|
||
| ExportConfigConstructor = Callable[[PretrainedConfig], "ExportConfig"] | ||
| FeatureNameToExportConfigDict = Dict[str, ExportConfigConstructor] |
There was a problem hiding this comment.
Is it necessary to include the type in this object? Wouldn't FeatureNameToExportConfig be better?
| if self.use_past: | ||
| common_inputs["attention_mask"][1] = "past_encoder_sequence + sequence" | ||
| common_inputs["decoder_input_ids"] = {0: "batch"} | ||
| # common_inputs["decoder_attention_mask"] = {0: "batch", 1: "past_decoder_sequence + sequence"} |
There was a problem hiding this comment.
No, still not sure about this.
| } | ||
|
|
||
|
|
||
| class AlbertOnnxConfig(BertOnnxConfig): |
optimum/exporters/features.py
Outdated
| # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| # See the License for the specific language governing permissions and | ||
| # limitations under the License. | ||
| """Model export features manager.""" |
There was a problem hiding this comment.
I fully agree that "features" sounds odd here.
My 2 cents: "task" sounds great, especially since people with little ML knowledge will understand it instantly whereas "head" will not mean much to them, "architecture" is as confusing as "features" IMO and "pipeline" can mean many different things.
What does this PR do?
This PR adds the ONNX export to optimum, under
optimum.exporters.onnx, which was previously supported in transformers. This also comes with a refactoring.DummyInputGeneratorclasses have been added: their goal is to handle the generation of dummy inputs. This can be used in any sitution, and is not tied to the ONNX export at all.DummyInputGenerators to generate dummy inputs. This means that there is no need to provide a tokenizer or a feature extractor to theOnnxConfig.EncoderOnnxConfig,DecoderOnnxConfig,Seq2SeqOnnxConfig,VisionOnnxConfig,TextAndVisionOnnxConfig, etc.What's left?
DummyInputGenerators docstringattention_maskas input when not needed? Or make it an option?