CI: Jetson nightly stage S4 builds apr with CUDA on the Orin and drives every apr verb against one tiny model #4885

Stage S4 of the Jetson Orin nightly, the follow-up to the fail-fast GPU lane (PMAT-4879, #4879): build apr with CUDA natively on the Orin and drive every apr verb against the one tiny model S3 already uses.

The order, verbatim (about 11:05Z 2026-10-06): "also why wouldn't it also run a nightly, i.e. aprender tiny model check and entire "VERB" infrastructure on it: serve, chat, etc"

Design

• Build. apr in release with cuda (and trueno-explain, which is what makes apr ptx exist), natively, in the persistent CARGO_TARGET_DIR, CARGO_BUILD_JOBS=4. The library and the link are timed apart, and the run prints cold or warm build time and the lowest MemAvailable it saw. An OOM kill is INFRA-RED (exit 3), never a code failure.
• Census. The binary just built lists its own top-level verbs (apr surface --json). .github/workflows/jetson-verb-ledger.tsv has one row per verb: covered by S4, or skipped with a reason. S4 is red when the two differ, so a new verb turns the nightly red until somebody classifies it. The check prints how many verbs it counted and from where.
• Drive. GPU verbs run with CUDA and must show CUDA evidence and never "falling back to CPU" (S3's assertion form). serve answers one /v1/chat/completions request with non-empty content and is stopped and checked. chat gets one scripted turn. Model-file verbs run once on the 1.1 GB q4_k_m GGUF. scripts/qwen-story.sh runs restricted to that model (it gains a model filter; it is not forked). Registry verbs use the resident model and never download.
• Memory. 7.4 GB unified: one verb at a time, never the 7.1 GB model.

Stacked on the lane branch of #4879; its PR opens after that lane merges.

Checklist row (2026-10-08): LAB lane for shipped aarch64-cuda apr verbs, plus the #4918 serve tool-call rows

This is a LAB check (C324): it runs at night on the idle Orin and can never block a merge or a release. A red updates this ticket, and stays silent. Runner registration and host provisioning are handled outside this repo.

• Run the shipped aarch64 -cuda release asset (the same one the other aarch64 CUDA box installs). Nothing is compiled on the Orin, since a full workspace build does not fit in 7 GB. This replaces the native build in the Design above. Known risks to check first: the asset's GLIBC floor, and one sm_90-only kernel that sm_87 cannot load.
• Verbs, each with its own timeout: devices (must list the Orin CUDA device), capability, gpu (expect gaps: no NVML/nvidia-smi on Jetson), check, run and bench on one small pinned model, parity (GPU vs CPU), ptx-map, qualify.
• P0: streaming /v1/chat/completions never emits tool_calls — tool calls arrive as raw <tool_call> text in delta.content, finish_reason "stop" #4918 surface: apr serve run <smallest Qwen3.5 GGUF with the tool template> --gpu, then POST /v1/chat/completions with a declared bash tool:
  • a. stream:false: message.tool_calls[0].function.name == "bash", finish_reason "tool_calls"
  • b. stream:true: one delta.tool_calls chunk, no <tool_call>/<function= text in any delta.content, terminal finish_reason "tool_calls" (red until P0: streaming /v1/chat/completions never emits tool_calls — tool calls arrive as raw <tool_call> text in delta.content, finish_reason "stop" #4918 lands)
  • c. stream:true, tools declared, plain-text answer: content deltas, finish_reason "stop"
  • d. stream:true, no tools: unchanged stream, finish_reason "stop"
  • e. the same tool request on /v1/chat/completions/stream and Ollama /api/chat (red until P0: streaming /v1/chat/completions never emits tool_calls — tool calls arrive as raw <tool_call> text in delta.content, finish_reason "stop" #4918's follow-ups land)
  • Rows b and e update P0: streaming /v1/chat/completions never emits tool_calls — tool calls arrive as raw <tool_call> text in delta.content, finish_reason "stop" #4918, not this ticket.