Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding model metadata in TorchScript model file #38273

Open
CoderHam opened this issue May 11, 2020 · 1 comment
Open

Adding model metadata in TorchScript model file #38273

CoderHam opened this issue May 11, 2020 · 1 comment
Labels
module: serialization Issues related to serialization (e.g., via pickle, or otherwise) of PyTorch objects oncall: jit Add this issue/PR to JIT oncall triage queue triage review

Comments

@CoderHam
Copy link

CoderHam commented May 11, 2020

馃殌 Feature

Adding model metadata in TorchScript model file including:

  1. Number of inputs and outputs
  2. Datatype of inputs and outputs
  3. Shape of inputs and outputs

It would greatly simply and improve model deployment and error handling for TorchScript models and add to the stability of the C++ Backend.

Motivation

We are working on the Triton Inference Server and support PyTorch (Libtorch) as one of the backends. The TorchScript model file (*.pt) does not contain sufficient metadata about the model such as the number, shape and datatypes of inputs and outputs. Our current workaround is for the user to specify this information manually.

As I understand, the shape data is not retained to allow for the model to be more generic. It would however be useful for us to have as much information about the model available in the model file itself. Without this we require the user to manually specify these details which can often be tedious and prone to error.

Pitch

Both TensorFlow and ONNX models store such information and it makes it easier to verify this information and deploy these models.

In addition to this it might be useful to have an option for shape specific information to be retained. In cases where certain dimensions are allowed to be variable these dimensions could be represented with a dummy value such as -1. All this information would allow us to validate that the data being passed to the model for inference is indeed valid.

Alternatives

I noted that there is a way to add additional metadata manually to the model but that too is a manual process.

Additional context

I had a discussion on the PyTorch Slack where I was informed that there exists function inputs() and outputs() [At least in Python] for the model that contains information about the number and datatype of the inputs however this required the @torch.jit.script decorator. Since there are two ways to export a model to torchscript (the second one using tracing) it could be useful and more user friendly to have this metadata always added to the model file (as in TensorFlow and ONNX) since it would add negligible size.

cc @suo

@facebook-github-bot facebook-github-bot added the oncall: jit Add this issue/PR to JIT oncall triage queue label May 11, 2020
@ailzhang ailzhang added the module: serialization Issues related to serialization (e.g., via pickle, or otherwise) of PyTorch objects label May 12, 2020
@suo
Copy link
Member

suo commented May 20, 2020

hey! PyTorch does not impose requirements of dtype/shape for inputs, so I'm not sure we can generically capture such information in the model metadata. Number of inputs conceivably we could, although it is also trivially derivable from the deserialized model (graph.inputs().size()).

I suppose we could require that the user supply information on dtype/shape, but it doesn't seem very user friendly, given that the information may not be known to the user upfront, and it is not required to run the model normally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module: serialization Issues related to serialization (e.g., via pickle, or otherwise) of PyTorch objects oncall: jit Add this issue/PR to JIT oncall triage queue triage review
Projects
None yet
Development

No branches or pull requests

5 participants