evidence(containers): the SBSA image RUNS on Tegra — Orin generates on the GPU

[localai-bot]

W6's Tegra determination — and it contradicts what the spec predicted. Refs #170.

The risk entry said Thor and Orin "are Tegra/L4T with a different CUDA runtime" and that the arm64 image made no claim there. It runs. There is no CUDA-version wall, and no separate Tegra lane is needed: one SBSA image serves both arm64 families.

Measured on Jetson AGX Orin (sm_87, L4T R36.4.3, Docker 27.5.1)

Running the image built on GB10, unmodified:

axis	result
validator	config + layout verified; /health 200, /version 200, declared healthcheck passed, clean SIGTERM
model	Qwen3-0.6B (rev c1899de2…, 1.5 GB) loads and generates: "The capital of France is" → " Paris. …", 24 completion tokens
GPU	tegrastats GR3D_FREQ 95–97% during a 120-token generation, vs 14–15% idle

That last row is the one /health cannot make — on Orin or on GB10. It's the difference between "the server came up with a GPU attached" and "the GPU produced the tokens".

The invocation differs, and all three cases fail differently

flags	Tegra behaviour
--gpus all alone	refused by the runtime hook
--runtime nvidia alone	starts, no driver mounted, dies on libcuda.so.1: cannot open shared object file
--runtime nvidia --gpus all	works

The middle case is the trap: the container comes up and dies on a missing library, which reads as a broken image rather than a wrong flag. docs/USAGE.md documented only --gpus all and was therefore wrong for every Jetson; now fixed.

Two portability defects the second box exposed

Both invisible on GB10 because that box happened to match:

• validate-container-image.py used docker stop --timeout, which is newer-Docker only; Orin's 27.5.1 rejects it. -t works on both.
• /models must be readable by uid 1000. On GB10 the model was owned by uid 1000, so mode 0600 worked; on Orin (files owned by 65535) the server initialised CUDA and then died on safetensors: cannot open file — which reads like a corrupt checkpoint. Now documented.

Running a deliberately different second box is what surfaced these; a second GB10 would have found none of them.

A wrong hypothesis, killed by test rather than shipped

I assumed the injected driver path simply wasn't on the loader search path and tried patching LD_LIBRARY_PATH to include /usr/lib/aarch64-linux-gnu/nvidia. Still not found — because with --runtime alone the driver isn't mounted at all. No Dockerfile change is needed; the nvidia runtime handles ldconfig itself in csv mode.

Scope

Orin (sm_87) only. Thor (sm_110) has never been probed and inherits nothing from this. Nothing is published to GHCR.

Gates

scripts/agent-preflight.sh --staged exits 0; agent-record, container matrix, workflow guard and public-doc tables all green.

🤖 Generated with Claude Code