Record a real NVIDIA render for the LTX-2.5 generative video upscale and mark the CUDA backend verified

[atomantic]

The LTX-2.5 generative video upscale is code complete on both backends and verified end to end on macOS MLX (#6514). The Windows / Linux CUDA runner (scripts/upscale_ltx25_cuda.py, shipped in #6520 and corrected in #6534) carries the same recipe, argv, grid and adapter contract (scripts/_upscale_contract.py) and is covered without a GPU, but nobody has yet run it on an NVIDIA card. Until that evidence exists the backend is deliberately documented as unverified and stays capability-gated per host.

This is the one hands-on task that closes the loop. It needs an NVIDIA host with the LTX-2.5 CUDA runtime installed (requirements-ltx25-cuda.txt), the ltx25_cuda_distilled base pack cached, the Lightricks license accepted and the gated Lightricks/LTX-2.5-22b-IC-LoRA-Pixel-Spatial-Upscaler weight downloaded through the model download/verify surface.

What to do

1. Run the verification matrix from docs/features/video-upscale.md "Readiness" through the real route → media-job queue → scripts/upscale_ltx25_cuda.py → gallery row path. The macOS pass in Verify the generative video upscale end to end on both backends and advertise it as ready #6514 (comment of 2026-09-07) is the template: conforming source with audio, frame-padded source with audio, spatially padded source without audio, cancellation mid-render, legacy Lanczos before and after, the refusal codes, the pre-submit plan, and provenance against ffprobe.
2. Confirm the existing LTX-2.5 text-to-video and image-conditioned paths through scripts/generate_ltx25_cuda.py still render unchanged on the same host.
3. Record source/output dimensions, frame count, duration, audio sync, seed, runtime fingerprint and wall-clock render time per case in a comment here.
4. Flip the CUDA row of the readiness table in docs/features/video-upscale.md to verified and supported, mirroring the MLX row, in a PR that closes this issue.

Acceptance

• At least one real generative upscale rendered on an NVIDIA card with the numbers above posted here.
• The readiness table no longer describes the CUDA backend as unverified.
• No change to the shared contract; if the render exposes a runner defect, fix it in the same PR with a GPU-free regression test as in scripts/upscale_ltx25_cuda.test.js.

Why needs-input

This needs a licensed NVIDIA machine with at least 64 GB of system memory — not merely any NVIDIA card. ltx25_cuda_distilled declares minMemoryGb: 64, and a dispatch to a 32 GB / RTX 3090 host on 2026-09-07 confirmed the floor is real: every download and pre-submit check passed, but both LTX-2.5 CUDA runners die in ltx_core's safetensors loader ~18 s in, on the pack's 26 GB text encoder. See the comment of 2026-09-07 for the full evidence and the six-line repro.

Remove the label only when dispatching from (or with access to) a machine that meets BOTH requirements. PortOS now refuses the upscale up front on a host below the floor (#6541), so a wrong-host dispatch fails fast at submit instead of after a queued GPU job.

Refs #6502, #6513, #6514

[atomantic]

Dispatched to an NVIDIA host — no verified render; the attempt found a readiness bug instead

Ran this on a Windows / RTX 3090 (24 GB VRAM) host. The CUDA backend still cannot be marked verified, because no render completed — this machine has 32 GB of system memory against the ltx25_cuda_distilled pack's declared minMemoryGb: 64. Details below; the readiness table stays "unverified".

Shipped in #6541 (Refs, not Closes).

What was verified on real weights

Everything short of the render worked, through the real route → media-job queue → runner path:

Check	Result
Gated adapter download (model download/verify surface)	327,322,640 bytes — exactly the pinned sizeBytes
reference_downscale_factor	2, measured: true — read off the downloaded file, not the registry
Plan: conforming source (320×576, 25 f, 24 fps, 1.042 s, audio)	conforming: true, no padding, target 640×1152
Plan: frame-padded source (320×576, 23 f, audio)	padFrames: 2 → padded 25 f
Plan: spatially padded source (312×568, 25 f, no audio)	padWidth: 8, padHeight: 8 → padded 320×576; hasAudio: false
Base pack resolution	cache-only, 71,118,761,094 bytes, integrity ok
assert_adapter_fuses	adapter fuses into 480 transformer weights — adapter and pinned checkpoint genuinely match
Failure cleanup	source clips byte-identical (sha256 unchanged), no history row, no partial output, no scratch left

Runtime fingerprint emitted by the runner:

torch 2.10.0+cu128 | ltx-core 1.2.0 | ltx-pipelines 1.2.0
transformers 5.14.1 | accelerate 1.14.0 | huggingface-hub 1.29.0
python 3.13.12 | Windows-11

Why no render

Job video-upscale queued → started → failed after 17.6 s. Both scripts/upscale_ltx25_cuda.py and scripts/generate_ltx25_cuda.py fail identically, inside ltx_core's own loader (ltx_core/loader/sft_loader.py:36) while loading the 26 GB Gemma text encoder:

RuntimeError: Attempted to access the data pointer on an invalid python storage.

It reduces to a six-line repro with no PortOS code involved — hold one safetensors.safe_open handle on a pack file, then open a second on the same file with device="cuda":

Pack file	Size	Second handle (cuda)
duration head	0.004 GB	OK
audio VAE	0.36 GB	OK
latent upscaler	1.00 GB	OK
video VAE	1.47 GB	OK
text encoder	26.26 GB	RuntimeError
transformer	42.02 GB	RuntimeError

A subsequent read of the same file segfaults the process. ltx_core's disk-streaming path does exactly this: DiskTensorReader holds a CPU handle while _load_non_block_weights opens a CUDA one on the same file.

So the failure is not upscale-specific and not a defect in the shared _upscale_contract.py: it is the whole ltx25_cuda runtime on a host below the pack's memory floor. That also means acceptance item 2 (confirming the existing text-to-video / image-conditioned paths still render) has no working baseline on this host — they fail the same way.

The bug this surfaced (fixed in #6541)

The upscale readiness check covered the runtime venv, the adapter and the pack — but not whether the machine meets what the pack declares it needs. generateVideo.js has always refused a plain render on a host below minMemoryGb; the upscale path did not. It showed a ready button, queued a GPU job, and let it die seconds later — the exact "ready button for a job that dies minutes later" the base-pack axis exists to prevent. An upscale renders at twice the source's linear dimensions, strictly above a plain render's peak, so anything a plain render is refused for an upscale must be refused for too.

Remaining

This issue stays open. To close it, someone needs a licensed NVIDIA machine with ≥64 GB of system memory; on that host the full matrix (conforming / frame-padded / spatially padded / cancellation / legacy Lanczos / refusal codes / provenance vs ffprobe) can run and the readiness table can be flipped to verified.

[atomantic]

Restoring needs-input: the blocker is unchanged in kind, only sharper. This still requires a licensed NVIDIA machine, and now specifically one with ≥64 GB of system memory — the dispatch above proved a 32 GB NVIDIA host cannot run the pack at all. Left in the autonomous queue it would be re-picked and re-fail on every drain pass, so the label keeps it parked until someone dispatches from a host that meets the floor. Body updated with that requirement.