[cehongwang]

Description

Adds an example that deploys a robot policy with Torch-TensorRT and ExecuTorch. It takes LeRobot's pi0.5 (lerobot/pi05_base), a vision-language-action model with 3.6 billion parameters, and turns it into one .pte that predicts a chunk of 50 actions from three camera images and a task in words. It's one script, examples/torchtrt_executorch_example/export_lerobot_pi05.py, plus one line in the deployment guide's list of examples.

It builds on @shoumikhin's LeRobot export work, reduced to the smallest working setup. It uses the released lerobot==0.6.1 and its stock PI05Policy, and needs no patches and no low-memory techniques.

What the script does:

1. Loads the policy in bfloat16 with LeRobot's processors, and preprocesses an observation: the frames, the state, and the task.
2. Wraps the policy's own predict_action_chunk in a module with tensor inputs: the stacked camera images, the prompt's tokens and mask, and the starting noise.
3. Runs torch.export, then torch_tensorrt.dynamo.compile, then torch_tensorrt.save(..., output_format="executorch", use_cuda_graphs=True). The whole chunk becomes one TensorRT engine, the 10 denoising steps unrolled, with nothing left to PyTorch. With use_cuda_graphs=True (feat(executorch): optional CUDA graph replay in the TensorRT delegate #4781), the delegate replays the engine's kernel launches as one CUDA graph.
4. Loads the .pte with ExecuTorch's runtime, after import torch_tensorrt_executorch_runtime. It checks the actions against PyTorch, exiting with an error above 0.1, runs LeRobot's postprocessor, and times both.

Measured

One A40, in a fresh virtual environment with the 2.15.0 release candidate:

Compile	193 s
Program	7.1 GB, one TensorRT engine
Largest difference from PyTorch (normalized actions, bfloat16)	0.0106
One chunk of 50 actions	100.6 ms, against 363.9 ms in PyTorch (3.6×)
Peak memory	24.3 GB host, 23.5 GB GPU
Whole script	7.5 min

CUDA graph replay, measured with each program loaded alone in a fresh process:

	GPU memory	One chunk
Without replay	6,964 MiB	104.4 ms
With use_cuda_graphs=True	6,986 MiB	101.1 ms (−3.2%)

The two programs' actions are bit-identical. In five alternating rounds of 30 calls each, replay was faster every time: 100.8 to 101.5 ms, against 104.2 to 104.9 ms.

Without replay, three runs of the script gave 104.3 to 104.5 ms per chunk, against 360 to 369 ms in PyTorch, with the same 0.0106 difference each time.

Testing

• The example, end to end, in a fresh venv with:
  • torch 2.15.0+cu132, torch_tensorrt 2.15.0+cu132 and torch_tensorrt_executorch_runtime 0.2.0+cu132, all from whl/test/cu132;
  • executorch 1.6.0.dev20261009+cu132 (nightly) and tensorrt-cu13 11.4.0.106;
  • lerobot 0.6.1 (--no-deps) with transformers 5.5.4.
• The install command in the docstring, resolved with pip install --dry-run and whl/test/cu132 in place of whl/cu132. It picks torch 2.15.0, Torch-TensorRT 2.15.0, the delegate 0.2.0 and ExecuTorch 1.6.0.dev20261009, and no other pre-releases. I chose this form over --pre "torch_tensorrt[executorch]", which also pulls in pre-releases such as tokenizers 1.0.0rc3 and protobuf 7.37.0rc1.
• The dependency list: every listed package is imported when the policy and its processors run. The version ranges are lerobot 0.6.1's own, which --no-deps would otherwise drop.
• CI checks: test_every_printed_install_instruction_names_the_nightly_channel and test_write_pins_requires_a_separate_lock_refresh pass, and so does pre-commit.

Still to check at release:

• torchvision 0.30.0 isn't published yet. lerobot imports torchvision, and the test channel stops at 0.29.2. I tested with the last 0.30 nightly (0.30.0.dev20261007, --no-deps). Once 2.15.0 and torchvision 0.30.0 are on whl/cu132, the docstring's commands should be run as written in a fresh venv.
• The delegate pin, torch_tensorrt_executorch_runtime==0.2.0, should match what 2.15.0 ships. If [2.15] Bump the ExecuTorch delegate to 0.2.1 #4909, which moves the delegate to 0.2.1, lands first, this line needs the same bump. The 2.15.0 executorch extra doesn't install the delegate, since [2.15] Backport #4882: install the matching runtime companion with the executorch extra #4913 was closed, which is why the command names it.

Type of change

• Documentation update (an example)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified