Read the deployment pipeline like you debug it live
A vision-language-action policy is three very different networks wearing one coat: a vision encoder, an LLM, and a flow-matching action head that runs several times per step. Getting it onto an edge GPU means splitting it into tensor-only graphs, compiling each for the target, and proving the actions didn't move. Click any block for what happens there, what to check, and a short code snippet.
ModelNVIDIA Isaac-GR00T N1.6 (open)
TargetJetson AGX Thor · TensorRT 10
Graphs / engines6 + metadata + manifest
Core runtime callexecute_async_v3
Click stageDebug checkpointArtifact boundary
Mental model
The concepts that make unfamiliar ONNX/TRT code readable
Six tensor contracts
Names and shapes must agree across exporter, ONNX, builder profile, and runtime bindings
| Component | Inputs | Output | Shape idea | Profile note |
|---|
Contract changes travel. If a training recipe changes how the action head is conditioned (say, a scalar
timestep becomes a per-token timestep), that is not a one-file fix: capture, the action encoder and DiT exports, the engine profiles and the runtime bindings all change together.Debug lab
Choose the symptom you see, then work one boundary at a time
Code snippets
Short snippets written for these notes. Names follow the public Isaac-GR00T code but may differ by version.
Select a file
Knowledge check
Click a question to reveal the answer
Debug order
- Identify the boundary: environment, PyTorch capture, ONNX export, artifact handoff, TensorRT parse/build, runtime binding, or parity.
- Prove inputs: path, hash, metadata, shape, dtype, device and versions.
- Run the smallest unit: one component, one observation, one engine.
- Compare at the nearest tensor boundary: don't wait for the final robot action.
- Only then optimize: PTQ, engine reuse, parallel builds, async execution.