feat(#672): vt::Conv1d and vt::ConvTranspose1d, with a CUDA provider that is BYTE-IDENTICAL to the host

[localai-bot]

vt had no transposed 1-D convolution of any kind, on any device. The two 1-D convolutions it carried are vt::CausalConv1dFwd (causal, stateful, SiLU-folded) and vt::DepthwiseConv1d (centre-padded, depthwise), and neither can express a scatter that GROWS the time axis. vt::Conv2d and vt::DepthwiseConv1d are moreover registered CPU-only. So the stage that is 88.5 % of MiniMax-Music3's acoustic-half profile had no device op to route to at all, and hand-rolling a kernel outside the shared seam is what AGENTS.md forbids.

This adds vt::Conv1d and vt::ConvTranspose1d with a CPU provider and a CUDA provider, and routes the shared 1-D BigVGAN core through them.

What reaches the op

Verified by call-site survey, not assumed. vocoder1d is the shared core, so routing it routes everything that decodes through it:

file	Conv1d sites	ConvTranspose1d	reaches
minimax_music3_acoustic.cpp	:154, :710, :720, :785, :794, :812	:741	yes
minimax_h3_audio_vae.cpp	:111, :133, :181, :196, :232, :305, :671	:146	yes
ltx2_audio_vae.cpp	:582, :643, :702, :794	:654, :838	yes
bigvgan.cpp	:25	:60	yes
minimax_music3_ar.cpp	:502	—	yes
indextts2_pipeline.cpp	:164	—	yes
bigvgan_loader.cpp, minimax_music3_loader.cpp	—	—	n/a: load-time weight-norm folding, no convolution

A whole-src/ sweep found no other caller. One gap is named rather than left to be discovered: ltx2_audio_vae.cpp:75 carries its own 2-D host convolution loop behind no op at all; out of scope here and filed with the rest of the unrouted surface as #1114.

The CPU path did not move, and it is proved

The CPU kernels are the vocoder1d host loops as they stood at 8fa405bb7, carried into src/vt/cpu/cpu_conv1d_general.cpp statement for statement — same f64 accumulator, same visit order, same bias seeding, same value == 0.0 skip, same output-channel partition over the same threadpool, and the tensors are VIEWS over the caller's own std::vector rather than copies.

test_host_parallel compares the shipped function against a verbatim copy of the pre-change loop at five thread counts, bitwise. This PR also adds the transposed op's missing catastrophic-cancellation case, which §12 had for LinearNoBias and Conv1d but not for ConvTranspose1d.

The CUDA provider is BYTE-IDENTICAL — no tolerance is claimed

The row was scoped expecting a tolerance to justify against a measured control. None is needed.

Both providers are one f64 accumulator per output element. For Conv1d that is trivial — the host loop is already a gather. For ConvTranspose1d it is the whole design: the host loop is a SCATTER, so fix a destination cell p and ask which additions land in it and in what order. The answer is ic ascending, then input position t ascending, and for each t at most ONE tap k (the one with t*stride + k*dilation == p). A thread that owns p and sweeps in that order performs the identical sequence of f64 additions into the identical accumulator.

Two details are load-bearing rather than cosmetic:

• the value == 0.0 skip is reproduced exactly, because dropping it changes the sign of a zero output cell — (-0.0) + (+0.0) == +0.0 while -0.0 alone stays -0.0;
• the bias is added LAST for the transposed op and FIRST for the forward one, matching each host loop respectively.

That leaves one way the arms could disagree: FMA contraction. Both sides are pinned. The host by the project-wide -ffp-contract=off (CMakeLists.txt:40-56, added for exactly this class of bug); the device kernel locally by __dmul_rn / __dadd_rn, because nvcc's flags are separate and its -fmad default is on. So the gate asserts memcmp equality.

The f64 accumulator is a deliberate divergence from torch

torch accumulates an f32 conv in f32. These do not, because f64 is what the host reference used and therefore what every committed golden for all four consumers was taken with. Named here rather than inherited silently, per .agents/porting.md "Mirror the memory format" — a WIDER accumulator is exactly the class of divergence a token gate cannot see. It costs nothing in bytes moved: activations and weights stay f32 in memory and only the register width differs.

vt::DepthwiseConv1d accumulates in f32 and its own byte-exactness gate pins that width, so these are siblings and it is untouched — the same call that op made against vt::CausalConv1dFwd.

The gate had to earn its teeth, twice

An f64 accumulator stored through an f32 cannot see a reduction-order change on well-scaled data. That is measured, not supposed. So every equality claim is also exercised on engineered catastrophic cancellation (+2^40 / -2^40 taps through a shared weight row).

And the cancellation case asserts its own teeth: reversing the input-channel sweep must change the answer, and the check reports how many cells move. A weaker mutation was tried first and correctly read 0 — swapping which channel carries the positive tap leaves the partial sums at the same magnitude at the same step, so it is not an order change at all. Recorded in the test so it is not re-derived.

Gates

Assertion counts included because assertions: 0 is a skip wearing a pass. The last four need CHECKPOINT_ROOT=/mnt/nas_share/checkpoints or they silently skip.

suite	cases	assertions
test_ops_conv1d_general (new)	8	347 (x86) / 385 (Thor sm_110)
test_host_parallel	8	877
test_vocoder1d	10	58
test_bigvgan	6	65
test_minimax_h3	79	57,395
test_ltx2_vae	42	3,120
test_indextts2_family	7	22
test_op_provider	12	412

The stronger leg, which was not planned

The consumer gates were run twice on Thor, once on each arm, and they are identical:

suite	VLLM_CPP_VOCODER_DEVICE=cpu	=cuda
test_host_parallel	8 / 877	8 / 877
test_vocoder1d	10 / 58	10 / 58
test_bigvgan	6 / 65	6 / 65

test_host_parallel is not an ordinary suite to pass on a device arm: its oracle is a verbatim in-test copy of the pre-op host loop and its comparison is bitwise. A green there with the device selected says the CUDA kernel is byte-identical to the pre-change scalar host loop end to end through the consumers' own entry point, at every shape it carries including the engineered cancellation cases — not merely at the op boundary.

Two things it does not say, so the leg is not over-read: its thread-count sweep is redundant on the device arm (the host pool is unused there), and these are three suites, not the four consumers' full golden sets. test_minimax_h3 (79 / 57,395) and test_ltx2_vae (42 / 3,120) were run on the CPU arm only, and re-gating them with the device selected is exactly the work the default flip waits on.

Measurements taken on b25a7ebf6; git diff against HEAD is empty for both kernels, ops.cpp, include/vt/ops.h and both gate files. A same-SHA re-run is queued.

The 347 → 385 difference IS the CUDA-vs-CPU memcmp arm, which is how the Thor run proves it executed rather than skipped (both [SKIP] lines are absent from its output). Measured on Jetson Thor kairos-4db2, aarch64, sm_110, driver 595.78, in vllmcpp-thor:cuda13.0.1 (nvcc 13.0.88), built -DVLLM_CPP_CUDA=ON -DVLLM_CPP_CUDA_ARCHITECTURES=110 -DVLLM_CPP_TRITON=OFF.

Full local build exit 0; scripts/agent-preflight.sh --no-require-role reports All gates green.

One checker changed, and it got stronger

tests/scripts/test_vocoder1d_single_home.py went red with Conv1d has 2 definitions. It guards a FORK of the vocoder core — a failure no numeric test can see, because a fresh copy agrees on the day it is made — using a line-anchored TEXT match, which cannot see a namespace and so read vt::Conv1d's definition in src/vt/ops.cpp as a second copy of vocoder1d::Conv1d. It is the opposite of a second copy: it is the op the core now delegates to.

Excluding src/vt/ was priced, not simply taken, because excluding a tree from a guard is how guards die. Two assertions were added beside it:

1. the core must still call vt::Conv1d / vt::ConvTranspose1d — without it the count reads a happy 1 while vocoder1d.cpp quietly re-grows its own loops and all six consumers leave the shared seam, with every numeric gate still green;
2. the walk must report how many files it examined — without it a scan narrowed to vocoder1d.cpp alone reports every count as 1 and passes while seeing none of the tree.

Mutated, not argued (scratch copy, restored byte-for-byte):

	result
RED-BEFORE: unrepaired checker, this tree	AssertionError: 2 != 1 : Conv1d has 2 definitions — the exact CI failure
GREEN-AFTER	6 tests, OK
M1: delegation removed	FAILS on the new assertion — while the count still read 1
M2: genuine fork added to bigvgan.cpp	FAILS — the original invariant survives
M3: walk narrowed to one file	FAILS on the new count-of-files assertion

The first mutation attempt was itself broken — no .git in the scratch copy, so git ls-files failed and the suite reported ERRORS rather than a failure, an infra fault presenting as a code verdict. That is why a control run of the unmutated copy is part of the evidence. Recorded in the spec at §13.9.

Staged, and said so

What is not reached is the DEFAULT. The device arm ships opt-in behind VLLM_CPP_VOCODER_DEVICE=cuda; cpu remains the default, so every consumer above is byte-for-byte where it was. Flipping four shipped audio models onto a device arm needs its own re-gate against each one's goldens, and that is not a default the row that ADDED the arm is entitled to set.

Per .agents/reachability.md "Landing a slice that is not reached yet", the three things it asks for: what is not reached is ResolveConvDevice()'s default resolution; the row that owns the wiring is MODEL-MUSIC-minimax-music3-mini-max-music3-for-conditional-generation; the issue is #672. Listed in the spec's owed table.

Also owed and named rather than hidden: the device arm allocates, uploads, downloads and frees per call, with a queue per call. That is deliberately literal — cuda means cuda, with no size threshold quietly sending small shapes back to the host, because a threshold would make the consumer gates report on a state they were not given. Device-resident weights, one persistent queue, and a chain that stays on the device between stages are all left on the table.

Speed: VOID — the timings were taken outside the fleet lease

Every timing here is void, and the reason is more useful than the numbers were.

The GPU fleet is scheduled by rc. These runs went in by ssh + docker run directly on the box, serialised by flock ~/gpu.lock — the old mutex — while the concurrent MiniMax-Music3 DiT session held the same box through rc. Two different mutexes, neither excluding the other: verbatim the failure .agents/environment.md already records for a GPU_LOCK naming the wrong path ("flock succeeds on it, so the run is unserialised and only looks like someone else misbehaving. That cost a whole Marlin series, #777"). That is almost certainly the 3x swing below — a defect in how the samples were taken, not a fact about the kernel.

It was not simply re-run under a lease because rc run executes inside the worker's container, and thor's worker has no toolchain at all (no gcc / g++ / cmake / ninja / nvcc / make, probed) and does not mount the box's $HOME where the build tree lives; its /workspace is the shared NAS. A valid re-measurement needs a worker image carrying the CUDA devel toolchain, or this build placed on /workspace by something that has one. Until then the speed axis has no instrument, and that is step zero of the open gap, not a caveat.

dgx:gpu0 is also UP and schedulable (GB10, unified memory) — the "dgx.casa is down" note this row was briefed with was stale — so a second, materially different device is available for the re-measurement.

The void numbers, retained rather than deleted

Two things, and they must not be collapsed. Measured on Thor sm_110, idle box (uptime 4.54 before / 4.57 after, 0 other users), same binary, VLLM_CPP_VOCODER_DEVICE the only variable, best-of-3, three interleaved reps, via the new vocoder-conv-ab:

stage	shape	CPU (14 cores)	CUDA
up0	1536→768, L=96, stride 8, K=16	0.0596 s	0.1538 s	0.39x
up1	768→384, L=96	0.0142 s	0.0388 s	0.37x
up2	384→192, L=96	0.0022 s	0.0056 s	0.39x
up3	192→96, L=96	0.0004 s	0.0010 s	0.40x
chain		0.0765 s	0.2000 s	0.38x

And that A/B is not accepted, because a sweep taken minutes later on the same box and binary put the CPU chain at frames=96 at 0.2280 s against 0.0765 s — 3x, same arm, same workload — while CUDA read 0.2000 s in both:

frames	CPU	CUDA
96	0.2280 s (0.0765 s in the run above)	0.2000 s
384	0.7950 s	0.7757 s
1536	2.5908 s	3.0677 s

The device arm is stable to four digits across runs; the HOST arm is the untrustworthy instrument here. So no ratio is claimed. What survives is the weaker and defensible statement: at no measured size did the device arm win, and at the largest, most compute-dominated point it was 1.18x slower.

A hypothesis, labelled as one. The per-stage ratios are flat (0.37–0.40x across a 150x span of work), which is the signature of a compute-RATE difference rather than per-call staging, since fixed overhead would punish the smallest stage most. The candidate is the f64 accumulator — consumer/Jetson Blackwell runs fp64 at a fraction of its fp32 rate — and f64 is not optional here: it is what makes the arms byte-identical and what four models' goldens were taken with. Nothing has read a counter: nsys in that image is 2024.2.3 and cannot trace CUDA on that box.

Open gap, not a ceiling. Next steps, in order: take the lease (nothing above is admissible until the arms are measured under rc); get an instrument (newer nsys/ncu on Thor); remove the per-call staging (§13.6's owed list — the flat ratio argues it is not the dominant term, which is why it should be measured rather than assumed); an f32-accumulate device variant, which is the lever if the fp64 hypothesis holds and which is expensive in the right way because it is not byte-identical and cannot inherit this row's memcmp; and a GPU whose fp64 is not 1/64 (Thor is the only one here, dgx.casa is down).

This does not touch the correctness result, which is what the PR turns on. The device arm shipping OFF by default was already right for numerics reasons; this says it would also have been right for speed.

The Conv2d / DepthwiseConv1d device arms — assessed, and declined here

The obvious follow-on was to extend the same machinery to the two existing CPU-only conv ops. The survey says do not, and the reason is not kernel difficulty: a CUDA provider for them would be dead on arrival. Of the seven models named as stuck behind them, exactly ONE (parakeet_encoder.cpp:166,194) calls either; the other six run their own host loops, and three of those are 3-D convolutions the 2-D op cannot express. muse_glimmer_vision.cpp has no convolution at all — it is already on vt::MatmulBT. No caller passes device tensors either, so a provider landed today would be reached by its own test and nothing else.

Filed with the full evidence, including why the 27 gated dtype combinations and the f32 accumulator make the kernel bodies non-shared: #1114.

Issue: #672

FOLLOWING_AGENTS_PROTOCOL

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