LTX-2.5: the only shipped DiT declares use_keyframes_abs_pos_embedding=True and carries ZERO keyframe tensors, so #658's trained bias is unexercised by any render we can run

[localai-bot]

Found while verifying #880 end-to-end on dgx.casa (GB10) against the real NVFP4 weights. This is a measurement, not a code change.

What I measured

The capstone render for #658 ran on main at 98f8e046d — the merge commit of #880 — without --allow-unported, which is the flag that row exists to retire. It succeeded: 9 frames at 128x128 @ 24 fps plus 48 kHz stereo audio, zero refusals in the log (control: 12 log lines).

Then I compared it to the previous render, which used the pre-#880 binary (3ce5a1dc1, built 2026-08-14) with --allow-unported — that is, with use_keyframes_abs_pos_embedding force-cleared at ltx2_loader.cpp:1035. Same prompt, same seed 20260814, same resolution.

frame 0: 128x128 mean=93.2 sd=69.2 adj=7.25  md5=fb1f4a55a8a1   IDENTICAL
frame 4: 128x128 mean=81.5 sd=68.9 adj=6.42  md5=33a5d75c6964   IDENTICAL
frame 8: 128x128 mean=84.7 sd=72.1 adj=6.08  md5=5ab4e7149823   IDENTICAL
9/9 distinct frame md5s within the render; audio 31678/31680 non-zero

Byte-identical. Bias off and bias on produce the same pixels.

That contradicts the seam comment this row itself landed at src/vllm/multimodal/ltx2_video.cpp:1695-1697, which records the opposite as its motivating evidence: "five LTX-2.5 suites stayed GREEN while the rendered pixels moved — frame 0 went from a flat 127 to a flat 130."

Why: the weights are not in the file

Reading the safetensors header directly:

ltx-2.5-22b-distilled-transformer-nvfp4.safetensors
  tensors: 7876
  keyframe tensors: []          <-- zero
  control: 48 adaln tensors
  __metadata__.config.transformer.use_keyframes_abs_pos_embedding = True

The config declares the flag true. The file carries no keyframe tensor at all. So on this checkpoint the trained term has no weights to apply, keyframes_abs_pos_embedding stays default-constructed (ltx2.h:256-258), and the render is correct to be identical.

What this means for the row

Three separate things, and only the first is proven:

1. PROVEN — the shipped NVFP4 DiT now loads and renders with allow_unported retired. That is feat(LTX25-KEYFRAMES-ABS-POS): the trained keyframe bias both shipped DiTs were refused over (#658) #880's user-visible claim and it holds end-to-end on real weights.
2. UNEXERCISED — the trained bias itself. No render we can run on this box touches ltx2_dit.cpp:527 / ltx2_device.cpp:817, because the only DiT on the NAS has no keyframe weights. The guarantee is covered by reduced-dimension fixtures only.
3. UNVERIFIABLE HERE — docs/FEATURES.md and the feat(LTX25-KEYFRAMES-ABS-POS): the trained keyframe bias both shipped DiTs were refused over (#658) #880 subject say "both shipped DiTs". Only one DiT is on the NAS (ls shows a single 18.7 GB file). The second was not available to me, so I could neither confirm nor refute that half.

The question this leaves open

A checkpoint that declares use_keyframes_abs_pos_embedding = True while carrying no keyframe tensor is a contradiction between the declared config and the shapes, and Ltx2AdoptDeclaredDitParams is exactly the function that reconciles those two. Which way does it resolve, and is that the upstream behaviour?

It matters because the two arms differ sharply:

• Resolves false from shapes — correct, and the render above is right. Then the seam VT_CHECK at ltx2_video.cpp:1707 never arms on this checkpoint, and neither does ltx2_dit.cpp:520.
• Resolves true from the declared config — then ltx2_dit.cpp:520 (m.keyframes_mask == nullptr || keyframes_embedding != nullptr) should have refused this render, and it did not. That would be a live hole in the guard the row was written to add.

I did not determine which, so I am not asserting either. Whoever picks this up should answer it against upstream model.py:166-173 (supports_keyframes_abs_pos_embedding) rather than from our own code, and add the smallest test that enters through the loader with a declare-true/carry-nothing checkpoint — a shape our fixtures currently do not have.

Related: #658, #880, #886 (POLICY-NOTHING-LANDS-DEAD — a mechanism whose only driver is its own fixture is exactly the shape that policy names), #655 (the LTX oracle admissibility question).

FOLLOWING_AGENTS_PROTOCOL

[localai-bot]

Addendum, so this issue is not read as new news on one point.

The declare-true / carry-nothing split for the NVFP4 DiT was already known and is recorded against #658: the first-party NVFP4 DiT declares the flag and carries no tensor, so --allow-unported drops nothing the file holds — whereas the vonkaiser FP8 tower carries a trained keyframes_abs_pos_embedding, where the same flag silently discards a trained tensor. Same flag, opposite honesty. I re-derived the NVFP4 half from the safetensors header rather than recalling it, which is why the measurement above is stated from scratch.

What is new here is the rest:

• the byte-identical A/B across the port boundary (bias force-cleared vs bias live, same prompt and seed, same md5 on every sampled frame), which is the empirical confirmation that the term is inert on this checkpoint;
• the observation that the DiT which does carry the trained tensor — the FP8 tower — is not on the NAS, so docs/FEATURES.md's "BOTH DiTs load" cannot be checked on this box at all;
• the open question about Ltx2AdoptDeclaredDitParams, which the earlier record does not answer.

The second bullet is the one worth acting on: the bias is currently covered by reduced-dimension fixtures only, and the single checkpoint that could exercise it end-to-end is unavailable. Getting the FP8 tower onto the NAS would turn #902 from an open question into a test.

FOLLOWING_AGENTS_PROTOCOL

[localai-bot]

Answered from upstream at the pin fd4ded7f2d88d3da713abcdd4ad41ecc4a9314ca, as this issue asks, rather than from our own code. Ltx2AdoptDeclaredDitParams resolves FALSE from shapes, that is upstream's behaviour, and the hypothesised live hole does not exist. No code change is owed.

Upstream resolves the same contradiction two ways, at two layers, deliberately

LTXModel.supports_keyframes_abs_pos_embedding (model/transformer/model.py:166-173) reads the materialized tensor:

embedding = self._keyframes_embedding()
return embedding is not None and not embedding.is_meta

_init_video (:216-218) builds the parameter whenever the flag is declared, models are created on the meta device and loaded with strict=False, assign=True, so a declare-true / carry-nothing checkpoint leaves it on meta and this returns False. Its own docstring names our exact case: "False for models built without the flag, and also for a model whose config set the flag but whose checkpoint carried no weight for it (the parameter would still be on meta)."

DiffusionStage.supports_generated_keyframes (ltx-pipelines/utils/blocks.py:395-403) reads the declared flag only:

transformer_config = self._transformer_builder.model_config().get("transformer", {})
return bool(transformer_config.get("use_keyframes_abs_pos_embedding", False))

and says why: "Read from the checkpoint's transformer config, so it is answered before any weights are built." On the shipped NVFP4 DiT that returns True, so upstream's admission gate assert_generated_keyframes_supported (:405-419) would let a generated-keyframe request through.

So, taking the issue's two arms

The first arm is the one that holds. Ours resolves false from shapes, matching supports_keyframes_abs_pos_embedding, and the render measured in this issue is right to be byte-identical. ltx2_dit.cpp's m.keyframes_mask == nullptr || keyframes_embedding != nullptr guard never arms on this checkpoint because the flag is false, so there was nothing for it to refuse. The second arm, and the live hole it implied, is refuted.

Ours is the safer of upstream's two answers

apply_keyframes_absolute_embedding (transformer_args.py:23-43) skips only when the provider is None or the mask is None. The provider is self._keyframes_embedding (model.py:314, :349), which returns getattr(self, "keyframes_abs_pos_embedding", None) — a meta parameter is not None, so upstream on this checkpoint reaches embedding.to(dtype=hidden_states.dtype) on a meta tensor. enable_keyframes_abs_pos_embedding (model.py:175-200) exists precisely for that, and it has one hit repo-wide at the pin: its own definition, no caller. Its docstring is explicit that materializing real zeros only makes the marker harmless, not meaningful — "it does not give an untrained checkpoint the keyframe capability."

What remains

Checkpoint availability, not code. The trained bias stays unexercised end-to-end until a DiT that actually carries a keyframe tensor is on the NAS; the vonkaiser FP8 tower does carry one per #658, so that half is exercisable where the file is reachable. The "both shipped DiTs" wording flagged as UNVERIFIABLE HERE is untouched by this analysis.

Found while doing #920 (generated keyframe slots), which is the feature that would put the marker on tokens other than the first latent frame. Recorded in .agents/specs/ltx25-generated-keyframes.md §5 and in #929.