Running model outside RETURNN about returnn HOT 7 CLOSED

The model is stored in HDF format, which should be easy to read from any language.
Of course, you can also use Returnn to just do forwarding. Or use Returnn as a server process. Or embed Returnn into some other application. We do that for speech recognition, for inference/decoding, where Returnn is embed into our speech recognizer.

from returnn.

Hi,

it depends on what parts of the environment you want to get rid off. You'll still need theano.
A theano function can be pickled and unpickled (at least this was supported at some point), so you could pickle a theano function, which forwards a minibatch and then unpickle it in your target application, so you would get rid of the RETURNN dependency, but you still need theano.

from returnn.

Thank you for the answers. So, I chose to go with serialization in order to get rid of the RETURNN dependency. I tried to serialize the Engine object and then call engine.init_network_from_config() and engine.forward_to_hdf() but it seems that some methods are no picklable. Therefore, maybe I should consider the remaining options.

from returnn.

Ah, I thought you want to implement it purely in C++ or so.
Why exactly do you want to get rid of the Returnn dependency then? You can just put it as a submodule to your project.

from returnn.

Indeed, implement purely in C or C++ it was my first thought. My goal concerns decreasing the recognition time and increase portability, maybe run some tests in a robot as an example. I mean, if I understood correctly I could implement the MDLSTM architecture in C++ and then load the weights, parameters etc. from the HDF model to perform forwarding, but it seems a time-consuming task. So, it didn't occur to me that I could try an embedding approach. Please, could you briefly comment the strategy used to carry out the embedding?

from returnn.

Well, yes, that will be some work, but on the other side, it's mostly straight forward. You can mostly copy the existing CUDA code and with some simple modifications run it like pure C++ code. Do some automatic testing that you get exactly the same outputs. It would also be nice to have that for the TensorFlow backend. Actually, that will be the best option anyway, that you convert everything to TF, and you need to port over the MDLSTM kernel to TF, and then you can dump the computation graph for forwarding and import that from pure C++ and it should be fast to execute. It depends how important the performance is for you. Also, if you want to run on CPU or GPU.

from returnn.

I think from the Returnn side, there is not much to be added, so I'm closing this now.

from returnn.