Found while reviewing #657 (image conditioning). Pre-existing DiT gap, not introduced by that row — but that row's text asserts the opposite, so it surfaced here.
The gap
At pin fd4ded7f, ltx_core/tools.py:184 plus _first_frame_keyframes_mask (:186-195) marks the target's first latent frame unconditionally — the comment says so in terms: "the reference implementation marks it unconditionally -- independently of whether any keyframe slots exist."
The consumer is model/transformer/transformer_args.py:42-43, called once at :269:
mask = (keyframes_mask > 0)
return hidden_states + mask * embedding
So on a shipped checkpoint, upstream adds a trained keyframes_abs_pos_embedding [1, 4096] bias to every token of the first latent frame, on every forward, whether or not any keyframe was supplied.
We never add it. ltx2.cpp:191-196 refuses the module, and ltx2_loader.cpp:974-981 clears the flag on every real load under allow_unported_modules. The shipped LTX-2.5 DiT does carry the tensor (ltx2_loader.h:120-121).
Why it matters now
#657 serves first-frame image conditioning by writing into exactly those first-latent-frame tokens. So the tokens we condition are the tokens upstream additionally biases, and the served arm is not upstream-equivalent — it is missing a trained per-token term on precisely the positions the feature is about.
This is invisible to every current gate: the tensor is refused at load, so no golden exercises it, and the reduced fixtures do not carry it.
Related, and part of why this went unnoticed
include/vllm/model_executor/models/ltx2.h:47-49 still says "LTX-2.5's checkpoint does not carry the parameter", which is false for the FP8 DiT and already contradicted twice in-tree (.agents/model-matrix.md:98, tests/vllm/multimodal/test_ltx2_video.cpp:914). That correction is owed separately on row/LTX25-ADALN-CLAIMS.
Note the flag resolution differs per shipped file and neither resolves the way the code assumes:
- FP8 carries the tensor but declares no
__metadata__, so upstream resolves the flag False (model_configurator.py:82) and never builds the module — dead weight upstream too.
- NVFP4 declares the flag
true but does not carry the tensor; upstream's parameter is torch.zeros(1, inner_dim) (model.py:217-219), a no-op.
So on these two files the omission may be numerically inert — but that is a property of the checkpoints, not of the port, and it is not what any comment in the tree currently says. A checkpoint that both declares the flag and carries the tensor would diverge silently.
What is owed
Port apply_keyframes_absolute_embedding and the unconditional first-frame marking, or state precisely — with the per-file resolution above — why omitting it is inert, and gate that claim rather than asserting it. Anything else leaves a trained term unapplied on the exact tokens the conditioning feature writes.
Related: #644 (full port), #657 (image conditioning), #655 (oracle admissibility).
Found while reviewing #657 (image conditioning). Pre-existing DiT gap, not introduced by that row — but that row's text asserts the opposite, so it surfaced here.
The gap
At pin
fd4ded7f,ltx_core/tools.py:184plus_first_frame_keyframes_mask(:186-195) marks the target's first latent frame unconditionally — the comment says so in terms: "the reference implementation marks it unconditionally -- independently of whether any keyframe slots exist."The consumer is
model/transformer/transformer_args.py:42-43, called once at:269:So on a shipped checkpoint, upstream adds a trained
keyframes_abs_pos_embedding [1, 4096]bias to every token of the first latent frame, on every forward, whether or not any keyframe was supplied.We never add it.
ltx2.cpp:191-196refuses the module, andltx2_loader.cpp:974-981clears the flag on every real load underallow_unported_modules. The shipped LTX-2.5 DiT does carry the tensor (ltx2_loader.h:120-121).Why it matters now
#657 serves first-frame image conditioning by writing into exactly those first-latent-frame tokens. So the tokens we condition are the tokens upstream additionally biases, and the served arm is not upstream-equivalent — it is missing a trained per-token term on precisely the positions the feature is about.
This is invisible to every current gate: the tensor is refused at load, so no golden exercises it, and the reduced fixtures do not carry it.
Related, and part of why this went unnoticed
include/vllm/model_executor/models/ltx2.h:47-49still says "LTX-2.5's checkpoint does not carry the parameter", which is false for the FP8 DiT and already contradicted twice in-tree (.agents/model-matrix.md:98,tests/vllm/multimodal/test_ltx2_video.cpp:914). That correction is owed separately onrow/LTX25-ADALN-CLAIMS.Note the flag resolution differs per shipped file and neither resolves the way the code assumes:
__metadata__, so upstream resolves the flagFalse(model_configurator.py:82) and never builds the module — dead weight upstream too.truebut does not carry the tensor; upstream's parameter istorch.zeros(1, inner_dim)(model.py:217-219), a no-op.So on these two files the omission may be numerically inert — but that is a property of the checkpoints, not of the port, and it is not what any comment in the tree currently says. A checkpoint that both declares the flag and carries the tensor would diverge silently.
What is owed
Port
apply_keyframes_absolute_embeddingand the unconditional first-frame marking, or state precisely — with the per-file resolution above — why omitting it is inert, and gate that claim rather than asserting it. Anything else leaves a trained term unapplied on the exact tokens the conditioning feature writes.Related: #644 (full port), #657 (image conditioning), #655 (oracle admissibility).