-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Support DLPack protocol in non-training builds #15963
Labels
feature request
request for unsupported feature or enhancement
Comments
Update: It is possible to use an OrtValue in cupy using the data pointer like this:
However, it is not possible as far as I know to go from a cupy ndarray to an ortvalue without doing a copy of the data |
ashrit-ms
pushed a commit
that referenced
this issue
Feb 11, 2025
### Description <!-- Describe your changes. --> This PR will enable python dlpack interface by default. ### Motivation and Context <!-- - Why is this change required? What problem does it solve? - If it fixes an open issue, please link to the issue here. --> dlpack python interface is useful in inference mode not only training mode. Since some inference result preprocess may be written in torch and making unnecessary device transfer should be reduced in those cases. closes #15963 closes #22061 TODOs: - [x] Add tests like https://github.com/microsoft/onnxruntime/blob/5407c69028ae6dd4e87521aea147c22153d8e6c7/orttraining/orttraining/test/python/orttraining_test_ortvalue.py that's unrelated to training feature --------- Co-authored-by: Xavier Dupré <[email protected]> Co-authored-by: Justin Chu <[email protected]>
guschmue
pushed a commit
that referenced
this issue
Mar 6, 2025
### Description <!-- Describe your changes. --> This PR will enable python dlpack interface by default. ### Motivation and Context <!-- - Why is this change required? What problem does it solve? - If it fixes an open issue, please link to the issue here. --> dlpack python interface is useful in inference mode not only training mode. Since some inference result preprocess may be written in torch and making unnecessary device transfer should be reduced in those cases. closes #15963 closes #22061 TODOs: - [x] Add tests like https://github.com/microsoft/onnxruntime/blob/5407c69028ae6dd4e87521aea147c22153d8e6c7/orttraining/orttraining/test/python/orttraining_test_ortvalue.py that's unrelated to training feature --------- Co-authored-by: Xavier Dupré <[email protected]> Co-authored-by: Justin Chu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature request
Currently, the DLPack protocol can only be used in non-training build. See:
ortValue
totorch.tensor
for GPU? #10327I believe it would make sense to enable this in the main build and not only the training one. Many AI modules already support this:
Having DLPack support in onnxruntime allows us to have "zero" cost copys between these modules. This is not only interesting during training. Often, multiple models are used in which case the ouput of one model will be used as the input of the next one. When we want to do postprocessing/preprocessing on these models we currently can't do this without moving them to CPU using
.numpy()
. This comes with a significant performce cost.Describe scenario use case
We want to use cupy for processing our model inbetween different inference runs. Cupy supports the DLPack protocol which would allow us to do so. One option would be to build with training support but this makes our package size quite a bit bigger which I'd like to avoid.
The text was updated successfully, but these errors were encountered: