# cuDLA Python on Jetson: Standalone Loadable vs Hybrid Mode

The compiler flag describes the model artifact, while the runtime mode determines how Python coordinates DLA execution.

By Paras Madan | 2026-11-15

A standalone DLA loadable does not require you to select standalone runtime mode. NVIDIA’s November 13 cuDLA Python tutorial compiles a standalone artifact, then runs it through hybrid mode using a CUDA stream. Confusing those two meanings of “standalone” can send an otherwise correct Jetson setup down the wrong debugging path.

The [NVIDIA tutorial](https://developer.nvidia.com/blog/run-native-dla-inference-in-python-on-nvidia-jetson-agx-orin-using-cudla/) targets Jetson AGX Orin. Its Python path uses `cudla.Mode.CUDA_DLA` and explicitly says standalone runtime mode is unsupported in the release it describes. Requesting that mode raises an unsupported-operation error. This is a guide to those documented distinctions, not a hardware test I have performed.

## Separate compilation from execution

The tutorial’s `--buildDLAStandalone` compiler option produces a DLA loadable that can run without TensorRT at inference time. It does not remove the need for the cuDLA runtime or choose the application’s synchronization model.

Think of two separate decisions. First, can the model be compiled into an artifact the accelerator accepts? Second, how will the application supply memory and coordinate that artifact’s execution? Changing the second decision will not repair an incompatible layer in the first.

That matters when adapting an example. Keep the compiler configuration and runtime setup as separate entries in your deployment record, along with the model revision. “Standalone enabled” is too ambiguous to help the next person reproduce the problem.

## An enum is not a support guarantee

The [versioned cuda.bindings 13.3.1 reference](https://nvidia.github.io/cuda-python/cuda-bindings/13.3.1/module/cudla.html) lists both `CUDA_DLA` and `STANDALONE` enum values. Their presence in an API reference does not establish that every exposed combination is supported by the Python workflow on your platform.

The distinction also appears in the [cuDLA C API reference](https://docs.nvidia.com/cuda/archive/13.4.2/cudla-api/cudla_api/group__CUDLA__API.html). Hybrid submissions use a CUDA stream and leave task wait/signal event fields null. Standalone submissions instead require a null stream and use their own event synchronization. These are different execution contracts, not two interchangeable spellings of the same option.

For the tutorial’s hybrid path, do not mix in standalone event-handling snippets from a separate C example. When a call fails, record the call and its parameters before changing the model or reinstalling the entire stack. The same broad error category can arise from different unsupported combinations.

## Match the Python environment to the documentation version

The [13.3.1 installation guide](https://nvidia.github.io/cuda-python/cuda-bindings/13.3.1/install.html) specifies Python 3.10–3.14 and lists cuDLA as an optional native dependency. That is a version-specific statement, not a promise that every future package release has the same interpreter support.

Use these read-only checks in the intended virtual environment to establish which interpreter and package you are inspecting:

```bash
python --version
python -m pip show cuda-bindings
```

These commands do not validate DLA hardware, model compatibility or successful inference. They simply prevent a common diagnostic mistake: reading documentation for one binding version while running another interpreter’s installation.

Record the JetPack, TensorRT and CUDA versions separately as well. A Python package installation is only one part of the system. Avoid upgrading all components at once merely to make an import succeed, because that erases the comparison you need to identify the failing layer.

## Prove one stage at a time

Start with the vendor’s known example on the supported hardware and keep your own model out of the first diagnostic pass. Distinguish import failure, device creation failure, loadable rejection and incorrect output. Each points to a different question; none is adequately described by “DLA does not work.”

After a known example succeeds, change one input to the deployment at a time. If your model loads but produces unexpected results, compare its input preparation and output interpretation against a trusted reference before changing execution mode. Successful submission is not evidence of correct inference.

The useful mental model is simple: the artifact defines what DLA runs, while the runtime configuration defines how your application runs it. Keep those boundaries explicit and debugging becomes a sequence of checks instead of a cycle of reinstallations.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain deployment constraints and engineering decisions in language developers can use.

[Book a 30-minute call](https://cal.com/paras-madan/30min)