Standardizing OpenAI’s deep learning framework on PyTorch

At work, we switched over from TensorFlow to PyTorch when 1.0 was released, both for R&amp;D and production... and our productivity and <i>happiness</i> with PyTorch noticeably, significantly improved.<p>Back when we were using TensorFlow, whenever we wanted to try something new that wasn&#x27;t already provided out-of-the-box by existing APIs, sooner or later we would find ourselves <i>wrestling</i> with its machinery, especially for models with more complex control flow.<p>TensorFlow <i>feels</i> like it was built from the ground up to scale up to billions of users and all kinds of devices, with developer productivity and happiness a secondary priority. PyTorch <i>feels</i> like it was built the other way around, prioritizing developer productivity and happiness; other considerations were secondary.<p>That said, we are keeping an eye on Swift + MLIR + TensorFlow. We think it could unseat PyTorch for R&amp;D and eventually, production, due to (a) the promise of automatic creation of high-performance GPU&#x2F;TPU kernels without hassle, (b) Swift&#x27;s easy learning curve, and (c) Swift&#x27;s fast performance and type safety. Jeremy Howard has a good post about this: <a href="https:&#x2F;&#x2F;www.fast.ai&#x2F;2019&#x2F;03&#x2F;06&#x2F;fastai-swift&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.fast.ai&#x2F;2019&#x2F;03&#x2F;06&#x2F;fastai-swift&#x2F;</a>

I&#x27;ve started working with Flux [1] in Julia, and it&#x27;s so elegant and such a great experience :). Just look at this definition of a U-net model for image segmentation: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;haampie&#x2F;bceb1d59fd9a44f092f913062e58d482" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;haampie&#x2F;bceb1d59fd9a44f092f913062e58...</a>. Apart from that, you can write your own custom loss functions in pure Julia that run efficiently on the GPU, language level automatic differentiation, proper integration with other packages. If people are moving away from Tensorflow, then Flux could be a solid alternative as well.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;FluxML&#x2F;Flux.jl" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;FluxML&#x2F;Flux.jl</a>

As someone who has used both PyTorch and TensorFlow for a couple years now, I can can attest to the faster research iteration times for PyTorch. TensorFlow has always felt like it was designed for some mythical researcher that could come up with a complete architecture ahead of time, based on off-the-shelf parts.

Happy to see PyTorch get some love. The company I am at made the same switch and everyone has loved PyTorch. It has more expressive power than Tensorflow 1.x (there are models that cannot be done with static graphs) and is simultaneously much easier to use.

Is there any equivalent of TF Serving for PyTorch? We have been thrilled with how robust and easy it is to deploy our models to production on the TF stack, and it worries me that the inertia in the deep learning community seems to be toward PyTorch.

This is second large framework making the switch to Pytorch.<p><a href="https:&#x2F;&#x2F;medium.com&#x2F;syncedreview&#x2F;japanese-unicorn-preferred-networks-migrates-its-dl-platform-to-pytorch-a509ac8f4ba0" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;syncedreview&#x2F;japanese-unicorn-preferred-n...</a>

If PyTorch had a viable way to convert models to run on a mobile GPU or DSP, that&#x27;s all I&#x27;d ever use. Currently I have to do my research in PyTorch and then laboriously port to TF to convert to TFLite, which kinda sucks because TF is full of bugs, and there are gotchas due to differences in how ops are implemented.

It&#x27;s somewhat disappointing that research is the primary motivator for the switch. PyTorch still has a ways to go in tooling for toy usage of models and <i>deployment</i> of models to production compared to TensorFlow (incidentally, GPT-2, the most public of OpenAI&#x27;s released models, uses TensorFlow 1.X as a base). For AI newbies, I&#x27;ve seen people recommend PyTorch over TensorFlow just because &quot;all the big players are using it,&quot; without listing the caveats.<p>The future of AI research will likely be interoperability between multiple frameworks to support both needs (e.g. HuggingFace Transformers which started as PyTorch-only but now also supports TF 2.X with relative feature parity).

This is a surprisingly unintelligent move from OpenAI. It adds corporate inertia to something as mundane as choice of DL framework.<p>Imagine you worked at OpenAI. Imagine you wanted to experiment with Jax, and that it turned out to be the best solution for the problem. Now you can&#x27;t ship without a solid technical justification.<p>Except, it&#x27;s not really a technical justification that you need. You need corporate clout. You can&#x27;t just be a junior engineer and make a decision that goes against corporate policy. That&#x27;s the point of having a corporate policy.<p>I can hear a thousand people about to type &quot;C&#x27;mon, OpenAI isn&#x27;t a normal corporation.&quot; But it is. Every corporation is a normal corporation. And having policies against specific tech should make productive programmers pause.<p>People get jobs at companies based on whether they use React or Vue, for example. And in DL, a programming library is basically a programming language, so it&#x27;s one step more powerful than that.<p>Here&#x27;s an example. Pytorch, as far as I can tell, doesn&#x27;t support running code on a TPU&#x27;s CPU. (I could be wrong about this!) When you enumerate the list of accelerators available after connecting to a TPU, you get a list of 8 entries. That means they only support executing code on the <i>cores</i> of a TPU, not the TPU&#x27;s CPU. This is a huge difference. It means you&#x27;re restricted to 8GB on TPUv2-8&#x27;s (which you get on Colab) instead of 300GB.<p>Does that count as a solid technical justification to use Tensorflow for a research project instead of Pytorch? Who knows. But who wants to be the odd one out on corporate politics? Especially if a project doesn&#x27;t generate any tangible results, which is often the case for research.

Just FYI I looked at PyTorch for the first time now, and unfortunately they require Mac OS users to build it from source in order to get CUDA support:<p><a href="https:&#x2F;&#x2F;pytorch.org&#x2F;get-started&#x2F;locally&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pytorch.org&#x2F;get-started&#x2F;locally&#x2F;</a><p>Please if someone at PyTorch is reading this, put in a request to make CUDA support the default on Mac OS.<p>Also, it looks like PyTorch doesn&#x27;t currently support OpenCL:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;pytorch&#x2F;pytorch&#x2F;issues&#x2F;488" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pytorch&#x2F;pytorch&#x2F;issues&#x2F;488</a><p>I can&#x27;t tell by the issue comments if it&#x27;s been added yet or if they plan to use Intel&#x27;s oneAPI or similar.<p>To me, these are prerequisites for switching to PyTorch. Hopefully someone can clarify the state of these thanks!

I think it was just a matter of time till TF would get superseded by PyTorch. The only reason we kept TF on prod is the java api which allowed us to quickly load and serve TF models. I spent so many sleepless nights trying to port Torch model to TF back in the days and make it work the same as Lua based prototype. Whole TF &quot;experience&quot; made us switch to plain Python services model throwing away all the boilerplate Scala&#x2F;Java code for TF. It doesn&#x27;t happen often in tech that a better engineered product gets more traction and recognition eventually and I am glad that PyTorch did.

I believe these days one has to know both, TensorFlow (Keras) and PyTorch; most new research is in PyTorch and most deployments are in TensorFlow. Academia can afford to run on PyTorch only, stable businesses on TensorFlow only, but for individual developers they need to know both.

For folks interested in Julia and RL, I&#x27;ve been involved in <a href="https:&#x2F;&#x2F;www.lyceum.ml&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.lyceum.ml&#x2F;</a> a set of tools for continuous control problems like robotics.<p>It&#x27;s pretty quick.

Has anyone taken the course mentioned &quot;Spinning Up in Deep RL&quot;? I&#x27;ve been meaning to learning some Deep RL and I was wondering if this is the best first step.