After #1041 the LTX-2.5 render is dominated by a ~1731 s single-threaded phase that is CONSTANT in resolution, not by the decode

[localai-bot]

Measured during the max-quality render run on dgx.casa on 2026-08-16/17, against main 0b0b8900f (i.e. with #1041's threaded decode in). Reported by the operator from the render agent's per-phase sampler; the classification method is stated below so it can be disputed.

The finding

Two rungs completed. Phase classification came from the CPU-time rate in a 2 s sampler (>3 cores = threaded, 0.4-3 = one core, below = load/IO):

Rung	Wall	load/IO	one-core	threaded	peak cores
448x256 / 25f	3085 s	352 s (11.4%)	2023 s (65.6%)	705 s (22.9%)	29.8
704x448 / 25f	4231 s	330 s (7.8%)	2399 s (56.7%)	1497 s (35.4%)	30.9

Inside those one-core totals, a single contiguous phase measured 1731 s and 1732 s across the two rungs — i.e. essentially constant while the voxel count grew 2.75x (448x256 vs 704x448, same 25 frames). Only the later phases scale.

So the render cost now fits a fixed ~2300 s (load + this serial phase + the first threaded burst) plus ~2.7e-4 s per output voxel. #1041 removed the decode as the bottleneck and this phase inherited the position.

Why this matters more than the raw ratio

#1041 is real and it worked: the pool reaches 19-31 cores in the decode phases, and the decisive evidence is that 448x256/25f completed at all, in 3085 s — docs/USAGE.md still records that exact geometry as "Measured NOT to complete". But the ~9x is a decode figure and does not appear end to end, because a phase #1041 never touched is now ~57-66% of wall.

A resolution-independent serial cost is also the shape that punishes exactly the direction this campaign cares about: it is pure overhead on small renders and it does not amortise.

What this owes

• Identify the phase. The sampler classifies by CPU-time rate, not by symbol, so this issue names a duration and a scaling law, not a function. A phase-boundary log (An LTX-2.5 render emits ONE log line in 2.5 hours, so no phase of it can be measured without re-deriving the timing from a memory sampler #1010, already open and already asking for exactly this) or a profile would name it. Do not guess it from the duration.
• Once named, decide whether it is threadable the way the decode was, or whether it is the memory-format/serial gap between decode bursts that the same run observed scaling with voxels.
• Re-derive the fixed/variable split on a third geometry before treating the two-point fit as a law. Two points define a line; they do not prove one.

Related: #1041 (the decode threading that landed), #1009, #1010 (per-phase timings), #1007 (no device arm), #1024 (GPU idle), and the investigation spec .agents/specs/ltx25-decode-speed.md.

Not measured: no oracle comparison, no ratio against vLLM or Lightricks, and the phase attribution is one-sided against our own engine.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]

[localai-bot]

First trace showing this phase is paid twice, on the full 21.004 B model

Measured 2026-08-18 on dgx (GB10, 20 cores), one_stage --device cuda, 1024x576/25f, full/dev transformer (42,018,190,584 B) loaded from local NVMe. Sampled at 1 Hz for 6482.6 s.

window	duration	cpu	rss
t=1-114	103 s	one core	0.63 → 69.38 GiB (load)
t=114-142	28 s	multi, peak 1995%	→ 30.31 (device staging)
t=142-1882	1740 s	one core	32.78 → 41.28 GiB
t=1882-2043	161 s	multi	41.87 → 31.13
t=2043-3781	1738 s	one core	32.58 → 41.14 GiB
t=3781-3894	113 s	multi	42.14 → 41.79
t=3894-6483+	2589 s+	one core	flat 30.99 (still running at kill)

Two single-core stretches of 1740 s and 1738 s — 0.11% apart, both matching this row's recorded ~1731 s within 0.5%. This row described the phase as costing ~1731 s; the new fact is that a render pays it at least twice, which doubles its share of wall and makes it correspondingly more valuable to identify.

Overall the run was 95% single-threaded (6175 s of 6478 samples) on a 20-core host.

A third stretch is probably a different operation. It runs with rss flat at 30.99 GiB where the paired two climb ~8.5 GiB (32→41). That rss delta is the cleanest discriminator available for telling them apart, since stack sampling is unavailable (see below).

Hypothesis, not attributed to a symbol: two stretches of equal cost fit the guided render's two text-conditioning passes — positive and unconditional, as cfg_scale 3.0 ≠ 1.0 forces the unconditional branch at ltx2_pipeline.cpp:521-523. It fits better than #1208's caption projection, whose two project() calls have a 2:1 size ratio (4096 vs 2048 out_features) and so should not produce equal stretches.

Instrument note for anyone continuing this: eu-stack attaches and lists TIDs but resolves zero frames in the rc worker container, so this phase still cannot be named by stack sampling. An in-process phase marker (#1010) is likely the shortest path to naming it.

Not claimed: no denoise step was observed, because both forward counters were broken in this run (gpu_pct read nan — a GB10 [N/A] for memory.used discarded utilization.gpu in the same parse — and eu-stack was blind). The run ended when the rc worker pod restarted (RESTARTS: 1), not by timeout or guard abort, so 6482.6 s is a lower bound and the third stretch never completed.