We’re waiting for a day or 2 to switch the default. Please let us know if you would like something added. Otherwise, we’ll be adding new tutorials and other things over the next week or so to cover the new features.
In light of the coming 1.0, the project has decided to cut a number of modules before the final release.
The Deeplearning4j Suite Overview reads this:
The use cases include importing and retraining models (Pytorch, Tensorflow, Keras) models and deploying in JVM Micro service environments, mobile devices, IoT, and Apache Spark. It is a great compliment to your python environment for running models built in python, deployed to or packaged for other environments.
For years now, I have developed a web app to automate the model development, only using Java and DL4J. I have built upon Arbiter that has been cut now. I see that I will have to switch to what most people do: use Python frameworks for model development, and DL4J only for deployment. However, this raises some questions, that I would be happy to read about.
Which framework is best supported in DL4J?
Can you tell some advantages and disadvantages of using Pytorch, Tensorflow, Keras with DL4J?
What is the difference between models deployed to or packaged for other environments?
@printomi could you DM me about your Arbiter use case? Separately, to answer your question.
To increase the number of models in the dl4j model zoo, we’ll be importing a lot of models from different ecosystem like huggingface, tensorflow zoo etc.
Finetuning models will also be a fairly big focus (post import) - that means training a model for your use case starting from a bigger model that was pretrained (which is how a lot of models are created now a days)
There is now a new custom model import framework that will make using samediff easier. Samediff will be the way forward for training new models. It has a proper file format (no zip files) with op descriptors and other things people are used to from onnx and tensorflow.
Keras will continue to be maintained since it works well (there’s even upgrades to the dl4j layers due to keras)
Training models from java will be very doable and even encouraged.
As for disadvantages: mainly the support outside of tensorflow is weak yet. The new framework for import is very extensible though. You can see some of that here:
As for pytorch, it still requires you to convert to onnx. Onnx needs some work yet, but due to the core model import framework being the same now it’s very easy to add defitions, example:
Pytorch and other frameworks will use the same definition. We have the ops already implemented in both c++ and cuda, it’s mostly about combining the right op calls together to support any use case at this point.
@agibsonccc thank you for explaining the current situation of DL4J, and pointing out the implementation details of the model import framework.
I am happy read that “training models from java will be very doable and even encouraged”.
These thoughts will help shaping the future development of our web app.
@printomi yes of course. The main point of the model interop is to allow people to train models from scratch with finetuning. It’s how many models are built now a days. We either have to build and maintain model import or we have to manually curate these models ourselves. That’s something we don’t have time to do correctly. Instead, piggybacking off of the existing work in the python community while both be easier and easier to troubleshoot. Eg: if a model from one provider has a bug, it’s easier to switch to another one.