You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Failing Test]: Fix and re-enable the TensorRT integration test #33078
The TensorRT integration test went red when the workflow was moved from a base container with Python 3.8 to Python 3.10 as part of the 3.8 support deprecation. The problem is that the model engine staged at gs://apache-beam-ml/models/ssd_mobilenet_v2_320x320_coco17_tpu-8.trt (based on a TF Model Garden config) was built with TensorRT 8.x, and Python 3.10 containers use TensorRT 10.x. Unfortunately the documentation around loading the model from the TF side is somewhat out of date or not necessarily what we need; additionally, we need to convert the model from a TF format to a TensorRT format since we do not use the ONNX route in the test.
The gradle task for the test is :sdks:python:test-suites:dataflow:py310:tensorRTtests and is defined here:
When testing the workflow ensure that you're running on dataflow or on a machine with a GPU, as the workflow will fail with CUDA error 35 if there isn't a GPU present.
Issue Failure
Failure: Test is continually failing
Issue Priority
Priority: 2 (backlog / disabled test but we think the product is healthy)
This issue has been marked as stale due to 150 days of inactivity. It will be closed in 30 days if no further activity occurs. If you think that’s incorrect or this issue still needs to be addressed, please simply write any comment. If closed, you can reopen the issue at any time. Thank you for your contributions.
@akshayjadiyanv would it be possible for you to take a look at this one since you have the most context on this right now? I am happy to run necessary commands to rebuild images you need in the repo for these tests. Feel free to post here what's needed. Thanks!
@tvalentyn
here is the full state and what is left. Two of the steps need write access I do not have, and two are a PR I can send.
A serialized TRT engine can only be deserialized by the same TensorRT major version and GPU architecture that built it. All three .trt files under gs://apache-beam-ml/models/ were built with TensorRT 8.x in 2022:
single_tensor_features_engine.trt
multiple_tensor_features_engine.trt
ssd_mobilenet_v2_320x320_coco17_tpu-8.trt
Since #39922 the handler requires TensorRT 10+ , none of these load. Rebuilding them is the blocker.
sdks/python/test-suites/containers/tensorrt_runinference/build_test_engines.py rebuilds all three from the ONNX sources already staged in the same bucket — nothing new needs uploading as a source. It verifies each result by loading it back through TensorRTEngineHandlerNumPy, and only uploads after verification passes. README.md next to it has the commands.
I have run it on a Tesla T4 with TensorRT 11.0.0.114 in nvcr.io/nvidia/tensorrt:26.06-py3. All three build and verify:
single_tensor_features_engine → [2.5, 10.5, -5.5, 20.5], exactly what the unit test asserts
…or I can hand over the files I already built and verified, whichever you prefer.
The script deliberately refuses --dest gs://apache-beam-ml/models, since that bucket has no object versioning and an overwrite could not be undone.
One thing to decide : The script names its output with a _trt11 suffix, so the 2022 files survive. Can keep the same if we are okay with overwrite.
Rebuild and push the test container image
us.gcr.io/apache-beam-testing/python-postcommit-it/tensor_rt:latest, from the updated tensor_rt.dockerfile on master. It now uses nvcr.io/nvidia/tensorrt:26.06-py3 (TensorRT 11.0, CUDA 13.3) and apache/beam_python3.12_sdk. The old pushed image is still TensorRT 8.6 / Python 3.10, so the IT would fail on the image alone.
What I will send as a PR once those land
3. Bump the driver request.common.gradle:454 asks for install-nvidia-driver with no version, while the vLLM ITs on 486/490/503 ask for install-nvidia-driver:5xx. TRT 11 with CUDA 13.3 needs a 580+ driver - so without this it fails at CUDA init rather than at engine load.
4. Re-enable the task.tensorRTtests is commented out in inferencePostCommitITPy312. It already moved to the py312 suite in #39922 ,since the new base image is Python 3.12.
Plus the path updates from step 1 if we go with the suffixed names.
Not a blocker, just so it is not a surprise
The IT runs the example pipeline and passes if it completes - it does not diff against a golden output, so nothing needs regenerating.
Also, num_detections is always 100 because the ONNX pins EfficientNMSkeepTopK=100; that was equally true of the 2022 engine, so it is not a regression.
Activity
github-actions commentedon May 29, 2025
This issue has been marked as stale due to 150 days of inactivity. It will be closed in 30 days if no further activity occurs. If you think that’s incorrect or this issue still needs to be addressed, please simply write any comment. If closed, you can reopen the issue at any time. Thank you for your contributions.
github-actions commentedon Jun 29, 2025
This issue has been closed due to lack of activity. If you think that is incorrect, you can reopen the issue at any time.
tvalentyn commentedon Sep 15, 2026
@akshayjadiyanv would it be possible for you to take a look at this one since you have the most context on this right now? I am happy to run necessary commands to rebuild images you need in the repo for these tests. Feel free to post here what's needed. Thanks!
akshayjadiyanv commentedon Sep 15, 2026
@tvalentyn
here is the full state and what is left. Two of the steps need write access I do not have, and two are a PR I can send.
A serialized TRT engine can only be deserialized by the same TensorRT major version and GPU architecture that built it. All three
.trtfiles undergs://apache-beam-ml/models/were built with TensorRT 8.x in 2022:single_tensor_features_engine.trtmultiple_tensor_features_engine.trtssd_mobilenet_v2_320x320_coco17_tpu-8.trtSince #39922 the handler requires TensorRT 10+ , none of these load. Rebuilding them is the blocker.
Already done in #39922 :
sdks/python/test-suites/containers/tensorrt_runinference/build_test_engines.pyrebuilds all three from the ONNX sources already staged in the same bucket — nothing new needs uploading as a source. It verifies each result by loading it back throughTensorRTEngineHandlerNumPy, and only uploads after verification passes.README.mdnext to it has the commands.I have run it on a Tesla T4 with TensorRT 11.0.0.114 in
nvcr.io/nvidia/tensorrt:26.06-py3. All three build and verify:single_tensor_features_engine→[2.5, 10.5, -5.5, 20.5], exactly what the unit test assertsmultiple_tensor_features_engine→[17.5, 36.5, -27.5, 3.0], likewisessd_mobilenet_v2_320x320_coco17_tpu-8→ confident detections on both COCO images fromtensorrt_image_file_names.txt, top scores 0.77 and 0.72…or I can hand over the files I already built and verified, whichever you prefer.
The script deliberately refuses
--dest gs://apache-beam-ml/models, since that bucket has no object versioning and an overwrite could not be undone.One thing to decide : The script names its output with a
_trt11suffix, so the 2022 files survive. Can keep the same if we are okay with overwrite.us.gcr.io/apache-beam-testing/python-postcommit-it/tensor_rt:latest, from the updatedtensor_rt.dockerfileon master. It now usesnvcr.io/nvidia/tensorrt:26.06-py3(TensorRT 11.0, CUDA 13.3) andapache/beam_python3.12_sdk. The old pushed image is still TensorRT 8.6 / Python 3.10, so the IT would fail on the image alone.What I will send as a PR once those land
3. Bump the driver request.
common.gradle:454asks forinstall-nvidia-driverwith no version, while the vLLM ITs on 486/490/503 ask forinstall-nvidia-driver:5xx. TRT 11 with CUDA 13.3 needs a 580+ driver - so without this it fails at CUDA init rather than at engine load.4. Re-enable the task.
tensorRTtestsis commented out ininferencePostCommitITPy312. It already moved to the py312 suite in #39922 ,since the new base image is Python 3.12.Plus the path updates from step 1 if we go with the suffixed names.
Not a blocker, just so it is not a surprise
num_detectionsis always 100 because the ONNX pinsEfficientNMSkeepTopK=100; that was equally true of the 2022 engine, so it is not a regression.tvalentyn commentedon Sep 15, 2026
Created:
gs://apache-beam-ml/models/multiple_tensor_features_engine_trt11.trt
gs://apache-beam-ml/models/single_tensor_features_engine_trt11.trt
gs://apache-beam-ml/models/ssd_mobilenet_v2_320x320_coco17_tpu-8_trt11.trt
we can keep old ones for now
tvalentyn commentedon Sep 16, 2026
Pushed us.gcr.io/apache-beam-testing/python-postcommit-it/tensor_rt:latest
tvalentyn commentedon Sep 16, 2026
@akshayjadiyanv lmk if you need any other assistance and thanks for helping fix these once again.
akshayjadiyanv commentedon Sep 16, 2026
Thanks @tvalentyn , I opened a new PR #40139
Re-enable the TensorRT integration test (#40139)