[Model Repository] Export as ONNX

[Brett-Parker]

Is your feature request related to a problem? Please describe. Roadmap

Describe the solution you'd like Have the ability to store standard .zip model and ONNX model.

Additional context Export/import as ONNX is possible with ML.NET. https://docs.microsoft.com/en-us/dotnet/api/microsoft.ml.onnxexportextensions.converttoonnx?view=ml-dotnet-preview

[Brett-Parker]

@aslotte what did you have in mind for this?

[aslotte]

@Brett-Parker Thank you for creating this issue!

Jon did a great video on the topic actually https://www.youtube.com/watch?v=Yf7VXj1etdw and here's the official doc's https://docs.microsoft.com/en-us/dotnet/api/microsoft.ml.onnxexportextensions.converttoonnx?view=ml-dotnet-preview

We can solve this in many ways, e.g. always converting each uploaded model to ONNX and store for future use, or convert to ONNX when the user requests a model to be exported as ONNX. It will be a lot easier to do it for each uploaded model and store it, so that's what I want to go with :)

The user would need to also pass in the IDataView in the upload method. The idea I have is to store the ONNX model next to the other model with the same runid (I think the ONNX model has another file format). Happy to discuss this further though as I've only given it about 10 min of thought.

[willvelida]

@aslotte I'm interested in picking this issue up 👍

I'm leaning towards letting the user request the model being exported to ONNX over converting each model to ONNX, but I'm interested to hear if you've had time to think further on this issue and hear what your thoughts are before diving in 😊

[aslotte]

We would welcome you to the team of contributors with open arms @willvelida! 😄

I agree, the more I've thought about it, the more I think we shouldn't convert each model to ONNX upon upload, especially since not all transformers are able to do so yet.

I would love to hear your thoughts on this. One option we can do is to make UploadModelAsync a lot less smart than what it is today and as such be more useful.

We can:

• Set the RunArtifact name to the actual file name instead of {runId}.zip
• Add a property to RunArtifact to store the file extension, e.g. .zip or .onnx
• Modify the model repository methods to use the file endings of the RunArtifact when downloading a model or deploying it

There may be more details than that that need to be changed, but as such a user can decide themselves if the want to upload the ML.NET model or just the ONNX model directly (or both). I think that would make for a more re-usable approach and as such we can then in the future use RunArtifacts to store other things, e.g. if the user wants to upload data or notes as part of the run (via another method, e.g. LogRunArtifact).

(Side note: we still need the uploaded model to have the name of {runId}.{fileExtension} as it needs to be unique per run. The deployed model can have the name of {experimentName}.{fileExtension} as we only have one at a given time).

[willvelida]

I like adding a property to RunArtifact to store the file extension 😊 It seems a much more simpler approach than writing numerous overloads for different types of models, while keeping the integrity of the {runId}.{fileExtension} format for each run.

[aslotte]

@willvelida do you want me to assign this issue to do?

[willvelida]

@aslotte sure! 😊

[aslotte]

Awesome! I assigned the issue to you and also sent you a collaborator invitation for the repo so you can assign issues yourself in the future as well as review and merged reviewed PR's 😄

[aslotte]

@willvelida I added the hacktoberfest label to this issue in case someone would like to have a go at it :)