-
Notifications
You must be signed in to change notification settings - Fork 275
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add TorchScriptWrapper_v1 #802
Conversation
PyTorch `Module`s can be converted to TorchScript. TorchScript has the advantage that the model is serialized with the model parameters in a portable manner. Deserialization (in contrast to pickling) does not require certain Python types to be available. In fact, a TorchScript module can be loaded in C++ without a Python interpreter. For Thinc and spaCy, supporting TorchScript has two main benefits: 1. Since the model is serialized, we don't run into the issue that we have with the PyTorch wrapper where we have to construct the PyTorch model before deserializing its parameters but we can only know the model shapes through deserialization. 2. When a model is rewritten for e.g. quantization, it is unwieldy to construct the rewritten model by hand. So, with the TorchScript wrapper we would first have to construct the original model and then reapply the graph transformation. This is quite bad for transformations that reduce the model size, since we end up temporarily allocating all parameters. This is not an issue with TorchScript, since we serialize the rewritten model.
@danieldk : can you have a look at the conflicts? |
Fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be great to have! I'm particularly enthousiastic about the prospect of resolving the initialization/deserialization shape issues 🎉
I put the PR in draft for the moment, since I am still wondering if it's best to pass |
As discussed, I'd keep it as is. |
PyTorch
Module
s can be converted to TorchScript. TorchScript has the advantage that the model is serialized with the model parameters in a portable manner. Deserialization (in contrast to pickling) does not require certain Python types to be available. In fact, a TorchScript module can be loaded in C++ without a Python interpreter.For Thinc and spaCy, supporting TorchScript has two main benefits:
Since the model is serialized, we don't run into the issue that we have with the PyTorch wrapper where we have to construct the PyTorch model before deserializing its parameters but we can only know the model shapes through deserialization.
When a model is rewritten for e.g. quantization, it is unwieldy to construct the rewritten model by hand. So, with the TorchScript wrapper we would first have to construct the original model and then reapply the graph transformation. This is quite bad for transformations that reduce the model size, since we end up temporarily allocating all parameters. This is not an issue with TorchScript, since we serialize the rewritten model.