3 ms·
It is our framework of choice especially when prototyping and implementing new differentiable programs. Although we use Caffe2 in production right now mainly be
by JacobiX 9y ago
It is our framework of choice especially when prototyping and implementing new differentiable programs. Although we use Caffe2 in production right now mainly because of Windows support for some of our customers.
But both of them support ONNX exchange format, we can prototype and train in PyTorch and then deploy the model using Caffe2 CPU version.
- agibsonccc 9y agoI just want to call out something with onnx. It will be slated to improve this year but be very careful what you try to do with it. A lot of basic things don't work yet. See: http://pytorch.org/docs/0.4.0/onnx.html http://pytorch.org/docs/0.4.0/onnx.html The other frameworks are using (in my opinion) slightly misleading language as to how "ready" it is. onnx to Caffe2 is facebook's use case so I could see that being supported fine. It's hard to go much beyond that though. Support for onnx will be bottlenecked by what pytorch can export right now. The file format just hit 1.0, but it will take some time for the ecosystem around it (including the export) to mature. Disclaimer: I am a framework vendor who has spent the last few months messing with it for end users writing model import for tensorflow's file format as well.
- ipsum2 9y ago> Caffe2 to onnx is facebook's use case so I could see that being supported fine. It's hard to go much beyond that though. ONNX to Caffe2*. Though it's possible to go from Caffe2 to ONNX to some custom hardware accelerator (TensorRT?)
- agibsonccc 9y agoAhh yes sorry for the typo. Fixed! And it will be possible but again support isn't actually implemented by anyone yet. They just "signed on". Tensorflow is the only supported format right now for tensorrt.
- JacobiX 9y agoYes ONNX support is not mature even for PyTorch --> Caffe2. There are problems with basic things like affine BatchNormalization. But still the situation is a lot better now ... before we had to write our own converters from one framework to another.