perf(LTX25-DECODE-THREADS): the video VAE decode had 20 cores and used one (#1009)

.agents/issue-index.md

@@ -292,3 +292,4 @@ rather than merged. `scripts/check-agent-record.py` gates both.
 | [#1040](https://github.com/mudler/vllm.cpp/issues/1040) | — | `LTX25-DECODE-SPEED` ([#1006](https://github.com/mudler/vllm.cpp/issues/1006)) records three sets of PASSING measurements and **none has a retrievable evidence artifact**, which `.agents/verification.md` requires alongside the SHA, command, environment and exit status. Rung 1's 248 per-PID sampler rows, rung 2's 1082 rows and 347 side-car per-PID samples, rung 2's `run.log`, and §1.4's `~/work/ltx25-e2e/render8-console.log` all live only on `dgx.casa` — `ping -c 2 -W 3 dgx.casa` exits 1 with 100% packet loss and `Destination Host Unreachable` (checked 2026-08-16), this box's documented unified-memory OOM-reboot mode, which needs a physical power cycle. The spec's `REMOTE_UNVERIFIED` mark was correctly scoped to rung 2's EXIT REASON; this issue extends the same honesty to the passing numbers. **Second and more corrosive: neither rung's sampler cadence closes.** Rung 1 states 248 samples at 2 s over a 701 s run split 192+56 across 450 s and 164 s windows — at 2 s those windows hold 225 and 82, and 248 samples cover 496 s of 701. A draft of rung 2's §5 stated 347 per-PID samples at 2 s "over the first 1192 s" — at 2 s that window holds 596. No dropped-sample rate is recorded anywhere, so the wall each sample set covers is NOT derivable, and the spec now states sample counts and fractions rather than minute figures. The raw CSVs settle both in one pass. Filed while repairing the fresh review of [PR #1038](https://github.com/mudler/vllm.cpp/pull/1038); not fixable in that flow, because no edit to the tree produces a file on a host that does not answer. Listed under `## Owed` in [`ltx25-decode-speed.md`](specs/ltx25-decode-speed.md) | bug |
 | [#1029](https://github.com/mudler/vllm.cpp/issues/1029) | `ENG-EXPERT-STREAM` | `IsCudaKeepQuantSupported` (`src/vt/cuda/cuda_quant_dot.cu`) returns true for `kIQ1_S` and `kIQ1_XXXS` since [#967](https://github.com/mudler/vllm.cpp/pull/967), and THREE dispatch switches consume that predicate while #967 extended only the dense one. `MatmulBTQuantGroupedKernelCuda` uses the predicate to SKIP its CPU fallback and then dispatches through a `switch (w)` with no case for either dtype and no `default:`: it quantizes the activation, launches NOTHING, returns, and `CheckCuda(cudaGetLastError())` reports success because there was no launch to fail, so the output tensor is never written. Measured on GB10 by an independent review through a poisoned output buffer: both IQ1 encodings leave `-12345` in place at NMSE `4.58e6` / `9.96e6` against the CPU oracle, with `iq2_s` passing as the control. Reachable by DEFAULT (`qwen3_5_gguf_weights.cpp` -> `qwen3_5.cpp` `KqGrouped` -> `vt::MatmulBTQuantGrouped`, `VT_QWEN35_GROUPED_MOE` on) on the 96.92 % of `Qwen3.8-2.4T` those two encodings make up, so #967 converted correct-but-slow into silently wrong. Same omission in the fused `MoeGateUpSwiGLUGroupedCuda` seam, where it turned a NAMED refusal into silence. It landed green because the CUDA grouped dispatch had NO test: `grep -rl MatmulBTQuantGrouped tests/` found two files and neither mentioned `kCUDA`. Repaired by adding both arms to both grouped switches, a `default:` that THROWS and names the dtype on all three (the general fix: past that predicate there is no fallback left), and a grouped + fused CUDA gate over the dense gate's case table driven through a POISONED output buffer. Also seals the device codebooks against the CPU tables, which `cuda_quant_iq_tables.cuh` claimed from the day it landed and no test did: 266 of 2048 `d_iq1s_grid` entries (13.0 %) are never addressed by the gate's own `mt19937(0x5EED)` stream. Device evidence is OWED and the issue stays open for it: `dgx.casa` was unreachable throughout and this box has no CUDA device, so only the CPU arm ran. Spec [`expert-streaming.md`](specs/expert-streaming.md) | bug |
 | [#1055](https://github.com/mudler/vllm.cpp/issues/1055) | `ENG-RECORD-CONFLICT-SURFACES` | `main` went RED on `check-public-doc-tables.py` at `e34d71379`: two prose paragraphs added beside a two-character source fix took docs/BENCHMARKS.md to 36 paragraphs of 35 and docs/FEATURES.md to 22 of 21, and the checker runs both in the `pre-push` hook and at `.github/workflows/ci.yml:160`, so every branch in the repository inherited a red it did not cause. Fixed in flow by folding each paragraph into the keyed row its content belongs to, which is what the checker's own message prescribes: the Apple Clang build disposition into the docs/BENCHMARKS.md `Open gaps` table, the Apple Clang platform fact into the docs/FEATURES.md backend table. No paragraph was deleted and no budget was raised. The deeper defect is the budget itself, a whole-page count on a shared file, which AGENTS.md Records names as the anti-pattern (`Limit an entry, not a shared file`); redesigning it is `ENG-RECORD-CONFLICT-SURFACES` scope, whose spec already carries the obligation | bug |
+| [#1044](https://github.com/mudler/vllm.cpp/issues/1044) | `LTX25-DECODE-THREADS` | The three parallel dispatch sites [#1009](https://github.com/mudler/vllm.cpp/issues/1009) added to the LTX-2.5 conv video VAE share ONE work-stealing cursor, so reverting any SINGLE one of them is detected by nothing: `CausalConv3d`'s padding gather (`src/vllm/model_executor/models/ltx2_video_vae.cpp:170 @ 249418305`), its output nest (`:218`) and `Linear3d` (`:276`). The instrument, the case "the decode DISPATCHES its convolutions to the CPU threadpool", reads `Threadpool::ChunkAdd(0)` and that cursor is seeded once per pool (`src/vt/cpu/cpu_threadpool.cpp:438 @ 249418305`, advanced at `:455`), so it gates "at least ONE of the three dispatches", never each site. MEASURED as T1/T2/T3 in [`ltx25-decode-threads.md`](specs/ltx25-decode-threads.md) §8.6 and reproduced independently by that row's reviewer: each single-site revert BUILT with 0 errors and left ctest at exit 0 and 42/42 + 10/10 green; only reverting all three (T0) goes red. NOT a correctness hole -- 34 golden margins were byte-identical, the bit-identity case `memcmp`s five worker counts, and ThreadSanitizer is clean against an 84-race positive control -- but a site can silently go serial again and only a wall-clock nobody runs in CI would notice. Closing it needs a per-dispatch `Threadpool::RunCount()` bumped in `Run()` (`src/vt/cpu/cpu_threadpool.h:112 @ 249418305`; no such counter exists) and an EXACT expected count rather than `> 0`, plus a fixture carrying a `res_x_y` block, because `MakeLtx2ThreadFixture` sets `decoder_blocks = {}` and `Linear3d` is unreachable without one. A new gate needs its own red-before evidence and its own fresh review, so it is a row rather than an in-flow repair. Listed under `## 7. Owed` in [`ltx25-decode-threads.md`](specs/ltx25-decode-threads.md) | verification |