I'm not neutral, but so: Just as there are many different applications of deep learning, "Production" is quite heterogeneous (you put something behind a server

I'm not neutral, but so: Just as there are many different applications of deep learning, "Production" is quite heterogeneous (you put something behind a server, or integrate it in a large codebase written in $foo, or put it on some embedded device or phone, want to deploy on one or several machines with or without GPUs or other HW accelleration,...). I would not expect a single tool or method to be universal. This means that I would not expect either to be uniformly better than the other. But it also means that a tool has an edge if it allows deployment in a wide range of ways. In my view, it is nice that PyTorch has achieved a high level of consistency between the Python interface and other ways of using / deploying PyTorch. Also, PyTorch does have some vision of interop (eg with ONNX). The other part is that when looking at a complete lifecycle, with detecting / analysing potential update needs, updating models and deploying the updates, it would seem beneficial to be able to seemlessly go back and forth. In my experience, PyTorch does a good job here (although I might also have ideas for further improvements), in that you can take, say, a JIT exported module and then look at it and it has much of the structure of how it was originally written. Taking a, say, tflite exported model and looking at what it does seemed to involve looking at low-level things much more.