With all the fanfare of PyTorch, LibTorch, & ONNX, I’m surprised I’m not seeing any responses to this discussion. Day after day I just keep digging.
It’s counter-intuitive that the PyTorch and LibTorch have different file formats for the same torch functions save() and load(). Just provide an analogy… can you imagine if a image company writing functions for python saveJPEG() and the C++ saveJPEG() saved to completely different incompatible file formats? I’m not trying to criticize, I’m trying to show how the development community is being confused, in a way that causes days or weeks of lost time and money.
Anyways, my goal is to train in LibTorch C++ (PyTorch is not an option for training with our embedded customers) and somehow save it to ONNX so I can use it with NVIDIA’s TensorRT. Since it sounds like there’s no activity with implementing LibTorch’s torch::onnx::export()
, and there’s no activity to make save() & load() interoperable between PyTorch and LibTorch, then my only option is to try various hacks, as you can see from the posts above.
Another hack was to try (in C++):
torch::Tensor dummy_input = torch::randn({1, 3, 224, 224});
dummy_input.to(torch::kCUDA);
auto traced_script_module = torch::jit::trace(model, dummy_input);
traced_script_module.save("traced_model.pt");
and then import it into a simple PyTorch script to convert to ONNX:
import torch
import torchvision
model = torch.jit.load("traced_model.pt")
model = model.cuda()
model.eval()
input_names = [ "input" ]
output_names = [ "output" ]
dummy_input = torch.randn(1, 3, 224, 244, device='cuda')
dummy_output = torch.rand((1, 102), device='cuda')
torch.onnx.export(model, dummy_input, "resnet18_3x256x256.onnx", verbose=True, input_names=input_names, output_names=output_names, example_outputs=dummy_output)
But torch::jit::trace()
is not implemented in LibTorch, and I don’t see any activity indicating it will be worked on.
Am I the only person out there who needs to train in C++, export to ONNX, and import to TensorRT? If not, could you please voice yourself so the LibTorch developers can prioritize this a little higher.