TensorRT 11.3.0 Release Notes#

These Release Notes apply to x86 Linux and Windows users, and to systems that incorporate ARM® based CPU cores for Server Base System Architecture (SBSA) users on Linux. This release includes several fixes from the previous TensorRT releases and additional changes.

Announcements#

  • CUDA 13.4 dependency upgrade: TensorRT 11.3.0 packages are built against CUDA 13.4 (Debian, RPM, tar, and zip package filenames use cuda-13.4). TensorRT 11.3.1 DriveOS packages use CUDA Toolkit 13.4. Refer to the TensorRT Support Matrix for supported CUDA releases per platform and to Prerequisites for installer prerequisites.

Key Features and Enhancements#

  • NVIDIA Vera Rubin support added in TensorRT 11.3.0: NVIDIA Vera Rubin GPUs are supported by TensorRT 11.3.0 Enterprise (general-release). Linux x86, Linux SBSA, and Windows x64 support NVIDIA Vera Rubin GPUs with compute capability version 10.7.

  • FP32 accumulation for FP16 fused attention: FP16 fused attention can accumulate in FP32 when you upcast query, key, and value around IAttention or the primitive attention graph. Accuracy can improve; throughput can drop versus FP16 accumulation. Refer to FP32 Accumulation for FP16 Fused Attention.

  • Refit Enhancement in TensorRT 11.3.0: High-precision weights used in FP4 double quantization are supported to be refittable.

Breaking ABI Changes#

  • TensorRT 11.0 removed weak typing APIs along with several other deprecated APIs. Refer to the NVIDIA TensorRT Migration Guide for more information.

  • TensorRT 11.3.0 changed the safety Consistency Checker C++ API (nvinfer2::safe::consistency) from STL-container parameters to pointer and count parameters. createConsistencyChecker now takes char const* const* pluginBuildLibs and int64_t nbPluginBuildLibs instead of std::vector<std::string>, and the serialized-blob size argument is int64_t instead of size_t. IPluginChecker::validate now takes a pointer and counts TensorDescriptor arguments instead of std::vector<TensorDescriptor>. Applications that call createConsistencyChecker and custom libraries that implement IPluginChecker must rebuild against matching TensorRT 11.3.0 headers and libraries. Mixing binaries built against the previous signatures with the new checker library can crash.

Breaking Behavioral Changes#

trtexec

  • The --useCudaGraph, --noDataTransfers, --useSpinWait, and --separateProfileRun flags were enabled by default and deprecated in TensorRT 11.0. Each flag is still accepted but has no effect. For replacement flags and details, refer to the trtexec migration page.

  • The --stronglyTyped flag has no effect in TensorRT 11.0.0+, since strongly typed networks are now the default. The flag is still accepted for backward compatibility.

TensorRT Samples

  • You must use a TensorRT tar or zip package when building the TensorRT samples. The Debian and RPM packages are missing the necessary CMake configuration files. The TensorRT samples have been removed from the Debian packages for multiple releases, but this incompatibility applies even when cloning the TensorRT samples from GitHub. This will be fixed in an upcoming release.

Compatibility#

For comprehensive platform compatibility, hardware requirements, and feature availability information, refer to the TensorRT Support Matrix. The support matrix provides detailed information about supported operating systems, CUDA versions, GPU architectures, precision modes, compiler requirements, and ONNX operator support for TensorRT 11.3.0.

Limitations#

  • DLA is not supported in TensorRT 11.3.0 or in TensorRT 11.3.1 for DriveOS. TensorRT 10.7 was the last release that supported DLA. Refer to Working with DLA for guidance that applies to supported earlier releases.

  • NVIDIA JetPack is not supported in TensorRT 11.3.0. Jetson deployments must remain on a TensorRT 10.x release supported by their JetPack version.

  • Version Compatible engine builds from ONNX models with explicit quantization/dequantization (Q/DQ) nodes may fail during engine build if Q/DQ is per-channel scaling for convolution filter.

  • When implementing a custom layer using IPluginV3 plugin class where the custom layer has data-dependent shape (DDS), the size tensors must be of only INT64 type and not INT32 type, as the latter would result in a compilation failure. Related samples have been updated accordingly.

Deprecated API Lifetime#

  • APIs deprecated in TensorRT 11.3.0 will be retained until August 2027.

  • APIs deprecated in TensorRT 11.2.1 will be retained until July 2027.

  • APIs deprecated in TensorRT 11.1.0 will be retained until June 2027.

  • APIs deprecated in TensorRT 11.0.0 will be retained until March 2027.

  • APIs deprecated in TensorRT 10.16 will be retained until March 2027.

  • APIs deprecated in TensorRT 10.15 will be retained until January 2027.

  • APIs deprecated in TensorRT 10.14 will be retained until October 2026.

See also

Migrating from TensorRT 10.x to 11.x

Step-by-step migration guide for upgrading from TensorRT 10.x.

Upgrading TensorRT

Package-level upgrade instructions (pip, Debian, RPM, tar, zip).

Deprecated and Removed Features#

  • For a complete list of deprecated C++ APIs, refer to the C++ API Deprecated List.

  • Windows 10 support is considered deprecated and Windows 10 will no longer be supported by TensorRT after October 2026. Windows 10 has been End-of-Life since October 2025. GeForce driver support for Windows 10 will also be reduced at that time. For more information, refer to GeForce Support Plan for Windows 10.

  • The TensorRT Python bindings for Python versions 3.8 and 3.9 are deprecated. These Python versions are considered End-of-Life by Python upstream and have not been supported by the TensorRT samples for multiple releases. These bindings will be removed in a future release.

  • The Detectron 2 Python sample (samples/python/detectron2) is removed in TensorRT 11.3.0. Refer to the Sample Explorer for remaining samples, including object detection.

Fixed Issues#

  • Fixed a NumPy 2.x ValueError when evaluating a default-constructed tensorrt.PluginField().data in a boolean context. The empty ndarray previously made expressions such as assert not pfield.data or if not pfield.data raise ValueError: The truth value of an empty array is ambiguous. This addresses the issue described in the TensorRT 11.2.1 release notes Known Issues.

  • Fixed a TypeError: issubclass() arg 1 must be a class during Quickly Deployable Plugin (QDP) validation on Python 3.14. Plugins registered with @trtp.register previously failed in the Python plugin annotation checks used by the QDP path. The failure had been observed for shape and serialization QDP tests in TensorRT 11.2.x. This addresses the issue described in the TensorRT 11.2.1 release notes Known Issues.

  • Fixed a GPU inference slowdown for some transformer models that use multi-head attention, including vision-transformer architectures. These models previously ran slower on GPU in TensorRT 11.x than in TensorRT 10.16 because of additional layout-related overhead during inference. This addresses the performance issue described in the TensorRT 11.2.1 release notes Known Issues.

Known Issues#

Functional

  • On CUDA versions prior to 13.2, the compute-sanitizer initcheck tool may flag Uninitialized __global__ memory read errors when running TensorRT applications on NVIDIA Hopper GPUs. These errors are false positives and can be safely ignored. To suppress them, upgrade to CUDA 13.2 or later.

  • Running TensorRT applications under Valgrind memcheck on CUDA 13.3 may report host-side memory leaks attributed to NVRTC components used during engine build and runtime compilation. These reports are not known to affect normal inference behavior. This will be addressed in a future CUDA or TensorRT release.

  • Running TensorRT inference under compute-sanitizer memcheck may report device memory errors during execution or engine teardown. These reports are not known to affect normal inference behavior when sanitizers are not enabled. This will be addressed in a future release.

  • On NVIDIA B100, networks that use multi-head attention with variable-length key-value input (IAttention with setKeyValueLengths) may fail under compute-sanitizer memcheck. The sanitizer can report invalid __global__ atomic accesses in the attention kernel, followed by CUDA error 719 during memory deallocation and an unrecoverable CUDA error. This is not a memory leak; sanitizer leak summaries showed 0 leaked bytes. Equivalent runs without the sanitizer have passed. A related failure on NVIDIA B100 may reject an unsupported stride order [3, 2, 1, 0] for a key operand under compute-sanitizer or Valgrind. This will be addressed in a future release.

  • inplace_add mini-sample of the quickly_deployable_plugins Python sample may produce incorrect outputs on Windows.

  • TensorRT may exit if inputs with invalid values are provided to the RoiAlign plugin (ROIAlign_TRT), especially if there is inconsistency in the indices specified in the batch_indices input and the actual batch size used.

  • On Windows, Version Compatible engines built with TensorRT 10.1 through 10.4 that use the RoiAlign plugin (ROIAlign_TRT) cannot be deserialized with the TensorRT 11.x runtime due to a bug in how those engines were produced. Deserialization fails inside the runtime dispatch VC plugin loader when loading nvinfer_vc_plugin.dll (Windows ERROR_MOD_NOT_FOUND / error 126), surfaces as TensorRT error code 6 (API Usage Error), and leaves the returned ICudaEngine pointer null. The bug was fixed in TensorRT 10.5. Engines built with TensorRT 10.5 or later are expected to deserialize correctly. As a workaround, rebuild affected engines with TensorRT 10.5 or later before loading them with TensorRT 11.x.

  • Inspecting very large engines with the Engine Inspector may fail on systems with limited host memory. The inspection process can exceed available memory and be terminated by the operating system without a TensorRT error message. This has been observed with very large diffusion-model engines. As a workaround, run engine inspection on a system with sufficient host memory.

  • Explicit quantization with NVIDIA TensorRT Model Optimizer ONNX quantization may fail during calibration with ValueError: Too many bins for data range. Cannot create 128 finite-sized bins. The failure occurs in the ModelOpt ONNX calibration histogram path (ONNX Runtime calibration calling np.histogram), not during TensorRT engine build or inference. It has been observed for some explicitly quantized ONNX models, including networks targeting the NVIDIA Blackwell architecture and quantized ResNet-50 transformer configurations, on SBSA platforms with CUDA 13.3.

  • Building TensorRT OSS samples with Visual Studio / MSBuild on Windows may fail during the CMake configure step when CUDA_HOME and CUDA_PATH point to different CUDA Toolkit installations. The failure is environment-wide rather than sample-specific and can affect multiple sample targets and trtexec. As a workaround, ensure CUDA_HOME and CUDA_PATH refer to the same CUDA Toolkit, or unset one of the variables so CMake discovers a single consistent toolkit. This will be addressed in a future release.

  • Building an SDXL UNetXL ONNX network with trtexec may fail during optimizer shape analysis with an API Usage Error from IConcatenationLayer. The failure has been observed on Windows with NVIDIA RTX 4090 for standard and strongly typed FP16 UNetXL ONNX models, with and without TF32. The error is raised at the /up_blocks.1/Concat node and reports that axis 2 dimensions must be equal for concatenation on axis 1, with mismatched dimensions 2 and 1. The failure occurs when trtexec auto-overrides the sample input shape to 1x4x1x1, which produces mismatched spatial dimensions on the UNet down and up path before concatenation. As a workaround, specify the intended input shape so trtexec does not auto-override it to 1x4x1x1. This will be addressed in a future release.

  • Building a FLUX.1-dev single-transformer attention ONNX network with trtexec may fail during optimizer shape analysis with an API Usage Error from IAttentionInputLayer. The failure has been observed on Windows with NVIDIA RTX 4090, with and without TF32. The error is raised at fused_attention_0_AttentionInput and reports that Key and Value do not match at dimension 2. Before the check fails, trtexec may auto-override unspecified dynamic inputs, including hidden to 1x1x3072, img_ids to 1x3, and pooled_projections to 1x768. This will be addressed in a future release.

  • Building some strongly typed ONNX networks that use float quantization may fail during tactic cost computation with Could not find any implementation for node {ForeignNode[...]}. The failure has been observed on NVIDIA GH200 480 GB SBSA systems running Ubuntu 22.04, including quantized encoder and RoBERTa-base Q/DQ models built with trtexec. This will be addressed in a future release.

  • Building some ONNX networks with trtexec may crash during engine build with return code -7 (SIGBUS), immediately after the compiler backend starts. The failure has been observed on NVIDIA RTX PRO 6000 Blackwell SBSA systems running Ubuntu 26.04 with CUDA 13.4, especially for Stable Diffusion, SDXL, and GPT-2 class models. Similar crashes have been reported for T5, weight-streaming, and version-compatible trtexec builds. This will be addressed in a future release.

  • Enabling kREFIT may produce incorrect numerical output compared with a non-refit engine, even when no refit is performed. Both engines are deterministic across runs. The discrepancy occurs because a GEMM bias can be dropped and treated as zero, and that bias is not exposed through the refit API. kREFIT_IDENTICAL does not reproduce the issue and matches the non-refit engine bit-for-bit, including after a refit with identical weights. As a workaround, use kREFIT_IDENTICAL when you will refit with weights identical to those used at build time. This will be addressed in a future release.

  • Building a strongly typed LSTM autoencoder ONNX network with dynamic batch and sequence length 10 may fail during engine build. Shape verification can fail on a reshape whose element count does not match. A follow-on Could not find any implementation for node {ForeignNode[...]} error may appear after that check fails. The failure has been observed on NVIDIA RTX PRO 5000 Blackwell AArch64 systems running Ubuntu 26.04. This will be addressed in a future release.

  • Creating an execution context for a GridSample FP16 network may fail on Windows with NVIDIA RTX 5080. ICudaEngine::createExecutionContext returns TensorRT error code 1 with CUDA error 700 while loading a CUDA module. The failure has been observed in TensorRT 11.3.0 on a case that previously passed on the same GPU with TensorRT 11.2. This will be addressed in a future release.

Performance

  • On NVIDIA DGX Spark (compute capability 12.1), some networks may show higher GPU compute time in TensorRT 11.3.0 than in TensorRT 11.2.1. Reproduced cases include 3dUNet INT8 (about 43% to 44% higher) and hardware-compatible BERT INT8 (about 23% higher). These are independent regressions. The 3dUNet INT8 slowdown is associated with the CUDA 13.4 device compiler. The hardware-compatible BERT INT8 slowdown is associated with a slower GELU path on compute capability 12.1. This will be addressed in a future release.

  • Strongly typed FP16 DeBERTa may show higher GPU time in TensorRT 11.3.0 than in TensorRT 11.2.1 because fused multi-head attention is lost and replaced by extra GEMM and memory-movement work. Observed increases are about 16.7% on NVIDIA RTX 4090 (about 12.25 ms to 14.30 ms) and NVIDIA L40S, and about 20% on NVIDIA DGX Spark. Activation memory can grow from about 105 MB to about 197 MB. This will be addressed in a future release.

  • On NVIDIA RTX PRO 6000 Blackwell (compute capability 12.0), a strongly typed FP16 ViT-Base patch-16 384 network (vit_base_patch16_384_strongType_fp16.onnx) may show about 6% to 7% higher GPU time in TensorRT 11.3.0 than in TensorRT 11.2.1. The slowdown is associated with tactic selection for the MLP fc2 MatMul layers and does not reproduce on NVIDIA Ada Lovelace architecture GPUs. This will be addressed in a future release.

  • On NVIDIA B200, a strongly typed FP16 dense network may show about 8.4% higher GPU time in TensorRT 11.3.0 than in TensorRT 11.2.1, from about 1.68 ms to 1.82 ms. Execution-context GPU memory also increases by 120 MiB, from about 839 MiB to 959 MiB. The slowdown is associated with a change in GEMM fusion: separate GEMMs are replaced by fused MatMul work plus extra concatenation and memory movement. The regression is stable on locked clocks. This will be addressed in a future release.

  • On NVIDIA GH200 480 GB SBSA (AArch64), FP8 causal attention may show about 11% higher GPU compute time in TensorRT 11.3.0 than in TensorRT 11.2.1. The slowdown is associated with the CUDA 13.4 device compiler: fused multi-head attention kernel source is unchanged, but the compiled device code is slower. Engine structure and tactic selection are otherwise the same. This will be addressed in a future release.

  • A non-zero tilingOptimizationLevel might introduce engine build failures for some networks on L4 GPUs.

  • The kREFIT and kREFIT_IDENTICAL have performance regressions compared with non-refit engines where convolution layers are present within a branch or loop, and the precision is FP16/INT8. This issue will be addressed in future releases.

  • Some Maxine™ AR Facial Landmark Detection models (landmark_quality_68_dynamic_strongtype_fp16 and landmark_quality_126_dynamic_strongtype_fp16) may exhibit approximately 7–9% higher GPU inference time in TensorRT 11.2.x than in TensorRT 11.1.0 on NVIDIA RTX PRO 6000 Blackwell Max-Q. It is for functional fixing, absolute impact is typically about 0.1 ms on workloads of roughly 1.7–1.9 ms.