Optional Torch Multiprocessing in nnUNet for Improved Security and Compatibility #2556
Comments
|
Hi Team, I would also like to address this issue but from the perspective of user debugging. I think having an option to set I see a few issues that would probably benefit from this as well: Looking forward to hear what you think |
|
Sounds like a reasonable proposal. |
|
Setting num_workers=0 will probably be more work than just offering a new member function of nnUNetPredictor that covers this. This function would then not be supported via command line but if you are packing nnU-Net in a Docker you might not need that anyways. Would this be a sensible solution to your problem? |
|
I've come along similar issues when trying to deploy nnUNet models in docker containers, and although my multiprocessing issues might come from somewhere else, I also agree that having a sequential predictor might simplify a lot of things, especially when you don't need to do inference in big batches. In my use-case, a quick fix that didn't require messing with your code is to simply use the predict_single_npy_array function while looping through my input arrays. This isn't a big issue for me as I already do all the dataloading manually, but might be a bit more cumbersome for other applications. |
Dear nnUNet team,
We are currently facing challenges when running nnUNet in Docker containers.
The requirement to use flags like
--ipc=hostor--shm-sizefortorch.multiprocessing(as reported and discussed in previous issues) makes it difficult to deploy models in our mhub.ai platform. We hesitate to suggest the use of--ipc=host, which is a simple solution but removes security restrictions and should therefore be used with caution. On the other hand, manually specifying theshm-sizemeans an additional burden and makes the inference even more complicated from MHub's point of view.We currently have some contributions to our portfolio on hold to discuss this topic. In our particular case, the inference is executed sequentially and therefore does not require multiprocessing per se. We propose to make the use of
torch.multiprocessingoptional during inference.We welcome any comments and an open discussion on this topic.
Thank you very much!
Leo.
The text was updated successfully, but these errors were encountered: