Drop the ExecuTorch runtime from the Torch-TensorRT runtime wheel

The torch-tensorrt-executorch-runtime wheel shipped a full ExecuTorch Python
runtime alongside the TensorRT delegate. This ships only the delegate: a single
shared library that registers TensorRTBackend with the ExecuTorch runtime that
the executorch distribution already provides, rather than bundling a second copy
of that runtime. Shipping a second copy is also what made the old wheel prone to
a libstdc++ clash, because two C++ runtimes could end up in one process.

The native build produces just the delegate library, its RUNPATH points at the
executorch package the delegate links against, and setup.py packages the one
shared object. The runtime dependency stays commented out in the top-level
setup.py because the delegate wheel is not published to any index yet, so the
docs and the load-time and save-time errors direct users to build it from
py/torch-tensorrt-executorch-runtime/README.md.

The delegate links the C++ runtime dynamically, the way every other shared
object in the process already does. The build toolchain is newer than the
libstdc++ on a user's machine, so an optimized build emits out-of-line calls
into the newer runtime, for example std::string::_M_replace_cold. Naming stdc++
as a link library puts the reference after the objects, where the toolchain's
own libstdc++.so linker script resolves it: the old, stable symbols bind
dynamically to the system libstdc++.so.6 and only the newer helpers are pulled
statically from the toolchain's companion archive. The delegate ends up needing
no C++ runtime version above what the ExecuTorch it loads beside already needs.
A static C++ runtime is deliberately avoided: this library is loaded next to
libtorch and ExecuTorch, and a private libstdc++ would give it its own exception
type_info and locale state, which breaks exceptions and dynamic_cast across the
boundary. The build guard checks the shape: the delegate keeps a dynamic
libstdc++ dependency, has no unversioned C++ runtime symbol left undefined, and
requires no symbol version above the paired runtime.

The wheel is tagged py3-none rather than per-interpreter, because the delegate
is a plain shared object with no Python ABI and one build serves every CPython.

test_api.py checks the shipped layout: the delegate resolves through the loader
in the layout that ships, the wheel's RUNPATH is compared whole against the one
the build asks for, the symbol versions and the C++ runtime dependency are
compared against the runtime the delegate links, and the wheel's own metadata is
checked. The reachability scans that assert the import and static-C++ checks run
in CI parse each language's grammar rather than matching text, and none of them
execute the workflow they inspect.

The wheel exposes no runtime API at all. Loading and running a program belongs to
ExecuTorch, which already ships Runtime, Program and Method, so the Python wrapper
this wheel used to carry is gone along with the load(format="executorch") entry
point that reached it. That wrapper duplicated ExecuTorch's own classes down to the
line that keeps the file buffer alive, and its CPU copy of top-level inputs quietly
defeated programs exported for device-resident inputs. A consumer now imports this
package and uses executorch.runtime directly.

Registration happens on import, so there is nothing to call. ExecuTorch's own
delegates register because they are linked into its pybindings extension, and
loading that extension pulls them in; a delegate in a separate wheel cannot join
that link and ExecuTorch has no discovery hook for out-of-tree backends, so this
package performs the equivalent step itself. A load it cannot complete raises from
the import rather than being swallowed, because the diagnosis here names the real
cause, a CPU-only ExecuTorch wheel or an ABI mismatch, which a later "backend not
available" cannot. TORCH_TENSORRT_SKIP_DELEGATE_REGISTRATION=1 imports the module
without the side effect, for tooling that wants the metadata only.

The wheel now follows the layout ExecuTorch uses for its own backends, so the
TensorRT delegate is an out-of-tree sibling of them rather than a Python-only
artifact. The shared library moves to lib/, next to where executorch keeps
libexecutorch_backend_cuda.so and friends, and the wheel ships a CMake package
under share/cmake so a C++ app can link it:

    find_package(executorch REQUIRED COMPONENTS backend_cuda)
    find_package(torchtrt_executorch REQUIRED)
    target_link_libraries(app PRIVATE executorch::runtime torchtrt::executorch_backend)

Before this the shared library was reachable only from Python, even though it is
a drop-in sibling of ExecuTorch's backends: same naming, same soname convention,
register_backend imported rather than defined. What was missing was the discovery
layer, so the only way for C++ to get the delegate was add_subdirectory against a
source checkout of this repository.

The imported target links with --no-as-needed, bracketed by push-state and
pop-state. Nothing in a consumer references a symbol the delegate defines, so the
default would drop the dependency and the backend would never register: the app
would build, load the program, and fail with an unregistered backend. That is the
shared-library counterpart of the --whole-archive the in-repo source build needs
for the same reason. No headers ship, because a consumer calls no Torch-TensorRT
code; registration happens in the library's static initializer and the rest is
ExecuTorch's runtime API.

Moving the library under lib/ also moves what $ORIGIN means, so the delegate's
own RUNPATH gains a level: $ORIGIN/../../executorch/lib rather than
$ORIGIN/../executorch/lib, and likewise for tensorrt_libs and nvidia/cu13/lib.
Without that the entries resolve inside the package directory instead of
site-packages, the delegate cannot find libexecutorch.so, libcudart or libnvinfer,
and a C++ consumer fails to link it with undefined references to cudaMemcpyAsync
and friends. The depth and the install location are one decision, so the test that
reads the declaration now rejects the single-level form it used to require.

The CMake package installs to lib/cmake/torchtrt_executorch, which is where ExecuTorch
puts its own: find_package resolves executorch from
site-packages/executorch/lib/cmake/executorch, so following that layout rather than
share/ means a consumer points CMAKE_PREFIX_PATH at the two package roots and both
resolve the same way. The walk that locates the package root now looks for the delegate
itself instead of for a directory named lib, because the config now lives inside lib/ and
stopping at the first lib/ it meets would set IMPORTED_LOCATION to that directory.

The CMake package test now configures the package with real CMake and asks for the imported
target back, because a string search over the config cannot tell a working package from a
broken one: inserting return() after cmake_minimum_required makes the config define nothing
and every string assertion still passes. The README command locates ExecuTorch through its
distribution metadata, since it is a namespace package whose __file__ is None, so the
documented one-liner raised TypeError before CMake ran.

The delegate builds for CUDA 12 as well as CUDA 13, because torch-tensorrt publishes both
channels. Three places assumed one major. The version check now accepts either, since a minor
bump inside a major does not change the ABI the delegate links. The RUNPATH carries both
layout directories, because the two majors package their runtime differently: the CUDA 13
wheels install nvidia/cu13/lib while the CUDA 12 wheels install nvidia/cuda_runtime/lib. The
artifact check maps the CUDA runtime the delegate asks for to the directory that carries it and
fails when the RUNPATH has no matching entry, which is the case that would link cleanly and then
find nothing at load time.

The symbol version ceiling is compared against the manylinux platform the wheel ships under
rather than against the ExecuTorch distribution beside it, and that platform is passed in per
architecture because the two rows use different builder images. A symbol version requirement is a
floor on the host, not a ceiling a library imposes on its neighbours: two libraries in one
process may need different versions, and the loader only needs the host to satisfy the highest.
Comparing against the sibling rejected the delegate wherever TensorRT itself was built with a
newer toolchain than ExecuTorch, which is the case on aarch64 today, and by that rule the check
would reject TensorRT too.

The delegate is built for aarch64 as well as x86_64, matching the architectures the
torch-tensorrt wheel it pairs with already ships. The native build already selected the right
TensorRT per architecture; what was missing is that the only caller generated an x86_64 matrix,
and the architecture input defaults to x86_64, so nothing ever asked for the other rows. The
aarch64 workflow now calls the same build against its own matrix, ordered after the job that
uploads the wheel it downloads, and deliberately outside that workflow's gate so a delegate
failure cannot block pull requests that have nothing to do with the delegate.

The check that the downloaded wheel carries the C++ runtime looks for the library instead of
importing the compiler package. That import reaches torch.cuda.get_device_capability() while
deciding whether it is running on Tegra, so it needs a GPU, and the aarch64 builder has none.

The symbol version cases in the guard's own test pass the manylinux tag, without which the
ceiling is skipped and every one of them passes for the wrong reason. Three of them asserted the
old rule, that a version above the ExecuTorch distribution's own is a rejection, and now expect
the artifact to be accepted: all three sit below what the platform guarantees, and the host
provides the C++ runtime rather than the sibling wheel.

The export and the reference runner run only where a GPU is present. Both compile and execute a
TensorRT engine, and the aarch64 builders are CPU-only instances, which is why the wheel's own
aarch64 lanes build without running their tests. The delegate is still built and checked on
aarch64; its runtime behaviour stays covered by the x86_64 rows, which have a GPU. Keyed on
whether the device is usable rather than on the architecture, so a GPU runner never skips it.

The delegate follows the main wheel's CUDA versions, CUDA 12.6 included. Both read the
same matrix filter, so the rows agree by construction: 25 rows, with cu126 on x86_64
only and the Arm rows on CUDA 13, which is what the main wheel publishes. The TensorRT
distribution is resolved from the CUDA the build actually uses rather than hardcoded, so
a cu126 row declares tensorrt-cu12 and a cu13 row declares tensorrt-cu13. The RUNPATH
and the ELF guard already carried both CUDA layouts, nvidia/cuda_runtime/lib for 12 and
nvidia/cu13/lib for 13, so no packaging change was needed for the new rows.

Test plan:

Ran the real filter from this branch against a full three-CUDA, five-Python,
two-architecture input and compared it against main's filter on the same input: both
return the same 25 rows. Added a test that asserts cu126 is present on x86_64, absent on
aarch64, and that both CUDA 13 rows survive on each architecture. It fails when cu126 is
removed from the x86 list. Replaced the test that asserted a hardcoded tensorrt-cu13,
which would have kept passing while a cu126 row declared the wrong dependency; the
replacement fails when the resolution is hardcoded again.

The release lane installs ExecuTorch too, so it is a pin site and now names the pinned
nightly from the nightly channel. It arrived with the CUDA 12.6 rows naming a stale
release off the default index, which resolves no ExecuTorch at all, and the pin checks
caught it.

A URL is no longer mistaken for a comment. The trailing-comment strip cut at the first
"//", so any line carrying an index URL was truncated before its requirement and the
site was reported as missing rather than as wrong. It now skips a "//" that follows a
colon, which is a scheme rather than a comment.

The channel variable that install reaches through is asserted to stay in scope. The URL
is built from CU_VERSION, which the reusable build workflow exports from the matrix row;
if that export is renamed the URL collapses to a channel that does not exist, pip falls
back to the default index, and the install resolves the wrong ExecuTorch without failing.

Author: shoumikhin

.github/workflows/ci-sbsa.yml

@@ -114,7 +114,30 @@ jobs:
       name-prefix: "RTX Python-only SBSA "
       raw-matrix: ${{ needs.generate-matrix.outputs.matrix }}
 
+  executorch-runtime-build:
+    # Ordered after `build`, not just after the matrix: this job downloads the torch-tensorrt wheel
+    # that `build` uploads, and starting earlier fails with "Artifact not found for name:
+    # pytorch_tensorrt__...". The x86_64 caller waits on its own wheel job for the same reason.
+    needs: [decide, generate-matrix, build]
+    # Same lane gating as the standard SBSA channels, plus the rtx exclusion the x86_64 caller
+    # applies: the delegate links stock TensorRT, not TensorRT-RTX.
+    if: >-
+      !cancelled() &&
+      needs.build.result == 'success' &&
+      (needs.decide.outputs.lane == 'full' || needs.decide.outputs.lane == 'nightly') &&
+      needs.decide.outputs.backend != 'rtx'
+    uses: ./.github/workflows/executorch-build-linux.yml
+    with:
+      repository: pytorch/tensorrt
+      ref: ""
+      test-infra-repository: pytorch/test-infra
+      test-infra-ref: main
+      build-matrix: ${{ needs.generate-matrix.outputs.matrix }}
+      architecture: aarch64
   gate:
+    # Deliberately not depending on executorch-runtime-build. The gate fails the whole workflow on
+    # any failure among its needs, so putting the delegate here would let it block every unrelated
+    # pull request that touches SBSA. It reports on its own check instead.
     needs: [decide, build, python-only, build-rtx, python-only-rtx]
     if: always()
     runs-on: ubuntu-latest

.github/workflows/executorch-build-linux.yml

@@ -23,6 +23,10 @@ on:
         description: "Test infra reference to use"
         default: ""
         type: string
+      architecture:
+        description: "x86_64 or aarch64. Must match the os the caller generated its matrix for."
+        default: "x86_64"
+        type: string
 
 jobs:
   filter-matrix:
@@ -49,6 +53,7 @@ jobs:
     uses: ./.github/workflows/linux-test.yml
     with:
       job-name: executorch-runtime-build
+      architecture: ${{ inputs.architecture }}
       repository: ${{ inputs.repository }}
       ref: ${{ inputs.ref }}
       test-infra-repository: ${{ inputs.test-infra-repository }}
@@ -85,15 +90,37 @@ jobs:
         # CU_VERSION selects the row's own channel, which is what keeps the runtime the
         # delegate links to the same CUDA build as the rest of the job.
         EXECUTORCH_INDEX_URL="https://download.pytorch.org/whl/nightly/${CU_VERSION}"
-        python -m pip install pyyaml --extra-index-url "${EXECUTORCH_INDEX_URL}" "executorch==1.5.0.dev20260901"
+        python -m pip install pyyaml patchelf --extra-index-url "${EXECUTORCH_INDEX_URL}" "executorch==1.5.0.dev20260901"
         export TORCH_TENSORRT_EXECUTORCH_RUNTIME_VERSION="$(python -c 'import importlib.metadata; print(importlib.metadata.version("torch-tensorrt"))')"
 
         # The downloaded wheel has to carry the C++ runtime. A wheel built with
         # PYTHON_ONLY=1 has no libtorchtrt.so, which leaves
         # ENABLED_FEATURES.torch_tensorrt_runtime False, and the export near the
         # end of this script then fails after the Bazel builds have already run.
         # Check it here so the wrong wheel is reported as the wrong wheel.
-        python -c 'from torch_tensorrt._features import ENABLED_FEATURES as f; assert f.torch_tensorrt_runtime, f'
+        #
+        # Checked by looking for the library rather than by importing
+        # torch_tensorrt._features, which reaches torch.cuda.get_device_capability()
+        # while deciding whether it is on Tegra and so needs a GPU. The aarch64
+        # builder has none, and the presence of the file is what this cares about.
+        # Matched exactly, not with a trailing wildcard: a glob of libtorchtrt.so*
+        # also matches a renamed neighbour, so the check passed against a wheel whose
+        # real library had been moved aside.
+        python - <<'PY'
+        import importlib.util
+        import pathlib
+        import sys
+
+        spec = importlib.util.find_spec("torch_tensorrt")
+        assert spec is not None and spec.origin, "torch_tensorrt is not importable"
+        lib = pathlib.Path(spec.origin).parent / "lib" / "libtorchtrt.so"
+        if not lib.is_file():
+            sys.exit(
+                "the downloaded torch-tensorrt wheel ships no libtorchtrt.so, so it is a "
+                "python-only build and the delegate cannot link its C++ runtime"
+            )
+        print(f"torch-tensorrt C++ runtime present: {lib.name}")
+        PY
 
         # Bazel truncates a failing action's output at 1 MB by default and then
         # prints nothing but the size, which hid the real error behind
@@ -105,6 +132,159 @@ jobs:
 
         # Build the no-compile-for-users Python runtime wheel.
         python -m pip wheel --no-build-isolation --no-deps --wheel-dir dist py/torch-tensorrt-executorch-runtime
+        # The point of this wheel is that it carries the TensorRT delegate and leaves the
+        # ExecuTorch runtime to the executorch wheel. Nothing else here would notice it
+        # quietly going back to shipping a second copy of that runtime, and the wheel would
+        # still work, so assert the contents rather than the behavior.
+        python - "$(ls dist/torch_tensorrt_executorch_runtime-*.whl)" <<'PY'
+        import ast, pathlib, re, sys, zipfile
+
+        import yaml
+        # Read the name out of setup.py rather than repeating it, so renaming the delegate
+        # keeps this honest instead of quietly turning the assertion below into a no-op.
+        # Parsed rather than imported: importing setup.py would run setup().
+        source = pathlib.Path("py/torch-tensorrt-executorch-runtime/setup.py").read_text()
+        library, = [
+            node.value.value
+            for node in ast.parse(source).body
+            if isinstance(node, ast.Assign)
+            and any(getattr(t, "id", None) == "DELEGATE_LIBRARY" for t in node.targets)
+        ]
+        names = zipfile.ZipFile(sys.argv[1]).namelist()
+        # ".so" and ".so.<version>" both: libnvinfer.so.10 and libstdc++.so.6 are shared objects
+        # the wheel must not carry, and a suffix test for ".so" alone does not see them.
+        objects = sorted(n for n in names if re.search(r"\.so(\.\d+)*$", n))
+        print("shared libraries in the wheel:", objects)
+        # sys.exit rather than assert throughout: under PYTHONOPTIMIZE or python -O every assert
+        # is compiled out, and this step would print its success message over a bad wheel.
+        def reject(message):
+            sys.exit(f"FATAL: {message}")
+        if len(objects) != 1:
+            reject(f"expected exactly the delegate, got {objects}")
+        # The full expected path, not a suffix: the wheel must ship the ExecuTorch delegate name
+        # inside the package directory, so neither a setuptools-mangled name nor a stray copy in
+        # some other package satisfies this. Under lib/, the same place ExecuTorch keeps its own
+        # backends, so one location serves both the Python loader and the CMake package.
+        expected = "torch_tensorrt_executorch_runtime/lib/" + library
+        if objects[0] != expected:
+            reject(f"expected {expected}, got {objects}")
+        # A C++ consumer links this wheel through its CMake package, the same way it links
+        # ExecuTorch's own backends. Without these two files the delegate is reachable from Python
+        # only, and the shared library above is unusable outside this repo's source tree.
+        for required in (
+            "torch_tensorrt_executorch_runtime/lib/cmake/torchtrt_executorch/torchtrt_executorch-config.cmake",
+            "torch_tensorrt_executorch_runtime/lib/cmake/torchtrt_executorch/torchtrt_executorch-config-version.cmake",
+        ):
+            if required not in names:
+                reject(f"the wheel ships no CMake package: {required} is missing")
+        forbidden = [n for n in names if any(
+            part in n for part in ("_portable_lib", "libexecutorch.so", "libextension_cuda", "libaoti_cuda_shims"))]
+        if forbidden:
+            reject(f"the wheel ships ExecuTorch runtime components: {forbidden}")
+        # The platform tag, because the payload is a Linux ELF object. Dropping
+        # distclass=PlatformDistribution from setup.py yields a py3-none-any wheel that pip would
+        # install into purelib on Windows or macOS, and the content checks above all still pass.
+        tag = pathlib.Path(sys.argv[1]).name.rsplit("-", 1)[-1][: -len(".whl")]
+        # Every platform in a compressed tag, not a substring search: "win_amd64.linux_fake"
+        # contains "linux" and expands to a tag pip will install on Windows.
+        platforms = tag.split(".")
+        alien = [
+            p for p in platforms
+            if not re.fullmatch(r"(many|musl)?linux[0-9_.]*_(x86_64|aarch64|i686)", p)
+        ]
+        if alien or not platforms:
+            reject(f"wheel is tagged {tag}, which would install on non-Linux platforms: {alien}")
+        wheel_metadata = next(
+            (n for n in names if re.fullmatch(r"[^/]+\.dist-info/WHEEL", n)), None)
+        if wheel_metadata is None:
+            reject("wheel carries no dist-info/WHEEL to check Root-Is-Purelib against")
+        purelib = zipfile.ZipFile(sys.argv[1]).read(wheel_metadata).decode()
+        if "Root-Is-Purelib: false" not in purelib:
+            reject(f"wheel declares itself pure python:\n{purelib}")
+        # Requires-Dist, which is where the build environment leaks into the artifact: setup.py
+        # derives the executorch pin from whatever is installed, so a wheel built beside the wrong
+        # version requires that version, and every content check above still passes. A local label
+        # is the same class of problem -- it binds the wheel to one CUDA train, which is why every
+        # requirement is stripped of one with public_version().
+        core_metadata = next(
+            (n for n in names if re.fullmatch(r"[^/]+\.dist-info/METADATA", n)), None)
+        if core_metadata is None:
+            reject("wheel carries no dist-info/METADATA to check Requires-Dist against")
+        metadata = zipfile.ZipFile(sys.argv[1]).read(core_metadata).decode()
+        requires = [
+            r.strip()
+            for r in re.findall(r"^Requires-Dist:\s*(.+)$", metadata, re.MULTILINE)
+        ]
+        pinned = yaml.safe_load(
+            open("dev_dep_versions.yml"))["__executorch_version__"]
+        if f"executorch=={pinned}" not in requires:
+            reject(
+                f"wheel requires {[r for r in requires if 'executorch' in r]} but the "
+                f"repository pins executorch=={pinned}:\n" + "\n".join(requires))
+        # setup.py derives torch-tensorrt, torch, tensorrt-cu13 and nvidia-cuda-runtime from
+        # importlib.metadata the same way it derives executorch, so a wheel built beside the wrong
+        # version of any of them requires that version and every content check above still passes.
+        # torch-tensorrt is the requirement that binds this runtime wheel to the producer that
+        # emitted the program; torch is the framework both were built against. None has a repository
+        # pin to compare a value against -- their version is whatever CI installed -- but the
+        # derivation can still be checked for shape: each must be present and pinned with an exact
+        # "==", so a requirement that went missing or loosened to a range is caught here rather than
+        # shipping. executorch is checked above against the repository pin, which is stricter.
+        for distribution in (
+            "torch-tensorrt",
+            "torch",
+            "tensorrt-cu13",
+            "nvidia-cuda-runtime",
+        ):
+            matched = [
+                r for r in requires
+                if re.match(rf"{re.escape(distribution)}\s*(==|[<>!~ ;]|$)", r)
+            ]
+            if not matched:
+                reject(
+                    f"wheel does not require {distribution}, which setup.py derives from the "
+                    f"build environment:\n" + "\n".join(requires))
+            if not any(
+                re.match(rf"{re.escape(distribution)}==[^;]+", r) for r in matched
+            ):
+                reject(
+                    f"wheel requires {matched} without an exact == pin, so it does not bind "
+                    f"{distribution} to the version it was built beside:\n" + "\n".join(requires))
+        labelled = [r for r in requires if "+" in r.split(";")[0]]
+        if labelled:
+            reject(f"these requirements carry a local version label: {labelled}")
+        print(
+            f"the wheel ships only {objects[0]}, tagged {tag}, requiring "
+            f"executorch=={pinned}")
+        PY
+
+        # Every dependency actually resolves from where the wheel puts it. The ELF guard that runs
+        # at link time compares the whole RUNPATH against what the build asked for and checks one
+        # ExecuTorch symbol, but it cannot resolve anything: in a Bazel output tree the sibling
+        # distributions do not exist yet, so it reasons about the artifact's own metadata rather
+        # than loading it. Here the installed layout exists, so ask the loader instead of inferring:
+        # a pin bump that drops some other ExecuTorch export reaches an undefined symbol at import
+        # time that the link-time guard cannot see. -r resolves data and function symbols, which is
+        # what turns an undefined ExecuTorch symbol into a failure rather than a silent success.
+        # env -u LD_LIBRARY_PATH, because the test lane exports the CUDA site-packages directory
+        # onto LD_LIBRARY_PATH (install-torch-tensorrt.sh), which puts nvidia/cu13/lib on the load
+        # path and lets a missing $ORIGIN/../nvidia/cu13/lib RUNPATH entry resolve here while it
+        # would not on a user's process. Clearing it makes ldd -r see what the user would.
+        python -m pip install --no-deps "$(ls dist/torch_tensorrt_executorch_runtime-*.whl)"
+        # Skip registration for this one call. Importing the package now LOADS the delegate, so a
+        # pin bump that dropped a symbol would abort here with the package's own error and the
+        # ldd -r guard below, which exists to diagnose exactly that, would never run. Resolving
+        # the path is all this needs, and the plain import further down still proves the side
+        # effect works.
+        delegate="$(TORCH_TENSORRT_SKIP_DELEGATE_REGISTRATION=1 python -c 'import torch_tensorrt_executorch_runtime as m; print(m._delegate_path())')"
+        echo "resolving ${delegate} from its installed location"
+        if env -u LD_LIBRARY_PATH ldd -r "${delegate}" 2>&1 | grep -E "not found|undefined symbol" ; then
+          echo "FATAL: the installed delegate has unresolved dependencies, so importing it fails." >&2
+          echo "Either a RUNPATH entry is missing or the pinned ExecuTorch no longer provides a symbol it uses." >&2
+          exit 1
+        fi
+        python -c "import torch_tensorrt_executorch_runtime"
+
         # this is to build the libtorchtrt.tar.gz
         bazel build //:libtorchtrt --compilation_mode opt --config=linux
         # Run the ExecuTorch backend C++ unit tests, which are otherwise only
@@ -142,7 +322,18 @@ jobs:
         python -m venv "${RUNNER_TEMP}/range-check-venv"
         # pin-check: range-ok
         "${RUNNER_TEMP}/range-check-venv/bin/python" -m pip install --no-deps --extra-index-url "${EXECUTORCH_INDEX_URL}" "executorch>=1.5.0.dev20260901,<1.6"
-        python examples/torchtrt_executorch_example/export_static_shape.py \
-          --model_path="${RUNNER_TEMP}/torchtrt-reference-runner.pte"
-        .github/scripts/verify-executorch-reference-runner.sh \
-          "${RUNNER_TEMP}/torchtrt-reference-runner.pte"
+        # The export compiles a TensorRT engine and the reference runner executes it, so both need a
+        # GPU. The aarch64 builders have none: every arm64 runner label is a CPU-only Graviton
+        # instance, which is why the wheel's own SBSA lanes pass run-tests false and build without
+        # testing. Skipped rather than failed, so the aarch64 rows still produce and check an
+        # artifact; the delegate's runtime behaviour stays covered by the x86_64 rows, which run
+        # this on a GPU runner.
+        if python -c 'import torch, sys; sys.exit(0 if torch.cuda.is_available() else 1)'; then
+          python examples/torchtrt_executorch_example/export_static_shape.py \
+            --model_path="${RUNNER_TEMP}/torchtrt-reference-runner.pte"
+          .github/scripts/verify-executorch-reference-runner.sh \
+            "${RUNNER_TEMP}/torchtrt-reference-runner.pte"
+        else
+          echo "No GPU on this runner, so the export and reference runner are skipped." >&2
+          echo "The delegate itself was built and checked above." >&2
+        fi