evidence(containers): W6 — the arm64 cuda lane runs on GB10 with --gpus all

[localai-bot]

First runtime evidence for any container lane on accelerator hardware. Refs #170.

Measured 2026-08-11 on promaxgb10-4ad8 (GB10, sm_121a, aarch64, CUDA 13.3, Docker 29.2.1 with the nvidia runtime), building docker/Dockerfile --target cuda natively on the box:

axis	result
build	673/673 objects; ten-SM gencode audit PASS; Triton AOT "six exact trees and namespaces OK"
image	1.71 GB (linux/arm64, cuda lane)
driver	/usr/lib/aarch64-linux-gnu/libcuda.so.1 -> libcuda.so.580.159.03, injected by the host runtime — the image ships none
runtime	/health 200, /version 200, the image's own declared healthcheck passing inside the container, clean SIGTERM — with --gpus all, on opt-125m-bf16-st

Scope, so the record cannot be read wider than the measurement

This is one tuple: linux/arm64 + cuda + sm_121a. amd64 cuda has never been built. Nothing is published to GHCR.

SBSA is now confirmed, and that sharpens the Tegra question rather than answering it. The runtime libraries were copied from /usr/local/cuda/targets/sbsa-linux/lib, so the arm64 image is an SBSA image. GB10 runs it. Thor (sm_110) and Orin (sm_87) are Tegra/L4T with a different CUDA runtime, remain unprobed, and are not covered. release/container-matrix.json therefore flips runtime_evidence for cuda/linux-arm64 only.

Lock discipline on a shared box

The build ran outside gpu.lock because it needs no GPU; only the container run took the lock, and it took it blocking — queued 16:58:38 → 17:50:43 behind other users rather than jumping them. Holding the lock across an 18-minute CUDA build would have blocked four waiting processes for nothing.

What it cost

Four defects, every one found by building rather than reading:

1. the CUDA 12.9 base that could not compile sm_110 (fix(containers): the cuda lane could not build at all — wrong CUDA base, stale build cache #366)
2. the BuildKit cache mount that outlived its toolchain (fix(containers): the cuda lane could not build at all — wrong CUDA base, stale build cache #366)
3. Marlin gencode drift failing the audit on 14 correctly-compiled TUs — check-cuda-fat-gencode.py hardcodes Marlin as sm12x-only and now fails every fat CUDA build (sm_110 was added to marlin-nvfp4) #394, which blocked both cuda tuples project-wide, not just this lane
4. a validator whose boot smoke never passed --gpus, so an accelerator lane could only ever produce build evidence (fix(cuda): Marlin gencode drifted from the feature table; validator can now take GPU evidence #407)

Records

Spec gains a W6 result section; engine-matrix row carries the anchors and the explicit not-established list; BENCHMARKS gains the image size and the GPU boot; STATUS states the lane and the Tegra gap.

.agents/NOW.md is deliberately untouched — it is authored at operator cadence and is never a per-row deliverable (AGENTS.md:252).

Gates

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

🤖 Generated with Claude Code