Kamimoto — Jev-gated dynamic sparsity for MiniMax H3 video generation (41.7% wall-clock reduction on RTX 4070)

TL;DR

Kamimoto (@sep_is_heim) plugs TypeSafe AI’s Jev (System One decision model, see Introducing System One Models & Jev) into 4-step MiniMax H3 video generation as a per-layer runtime sparsity router. At each of the 49 attention layers, Jev is queried to pick one of four sparsity rates (1%, 3%, 5%, 10%) for that layer’s attention computation. Reported wall-clock on a consumer RTX 4070: 6 min 07 s → 3 min 34 s (41.7% reduction). The demo also concedes fixed 10% sparsity alone captures a large fraction of the speedup, so Jev’s contribution is more about adaptive quality preservation than raw acceleration. Two ablations (using Jev to choose step count 3/4/5 and to select which layers to skip) reportedly did not work well. Author frames Jev as a “super-fast, high-functioning if statement” and notes the cloud-call cost is negligible after ~20-30 test videos.

Key claims

Setup: 4-step MiniMax H3 video generation with 49 attention layers targeted; Jev makes one sparsity decision per layer per denoising step [tweet body].
Sparsity option set: {1%, 3%, 5%, 10%}, chosen per-layer at request time [tweet body].
Wall-clock: 6:07 → 3:34 on RTX 4070 = 41.7% reduction [tweet body].
Fixed 10% sparsity alone already yields “considerable” speedup — author explicitly cautions the wins are not attributable to Jev alone [reply thread].
Two failed ablations reported: (a) using Jev to dynamically pick step count from {3, 4, 5}, and (b) using Jev to pick which of the 49 layers to skip entirely; both “did not work well” and were shelved [reply thread].
Jev API cost across 20-30 generated demo videos was negligible (“really low cost”) [reply thread].
One replier (@tensorquay) asks for the missing A/B: fixed4-step / API-call-zero baseline at same prompt+seed to cleanly isolate Jev’s contribution from raw sparsity [reply thread].

Method

Two-stage attention path per DiT block: (1) Jev is called with the block’s context to score the four sparsity option markers, returning a categorical distribution; (2) the argmax sparsity rate is passed to the sparse-attention kernel for that block. The Jev call is a single ~30 ms forward pass over the cloud API and runs concurrently with (or between) DiT block executions — small enough that the author is surprised the overall generation stays fast despite the round-trip. The decision is fresh per layer per step (4 steps × 49 layers = up to 196 Jev calls per generation), though the author does not clarify whether decisions are cached across steps.

The base model is MiniMax H3 (33B dense single-stream joint text-to-video-and-audio), the same base FastVideo attacks with 4-step VSA distillation in FastVideo FastH3 V1 — 4-Step Sparse Distilled MiniMax H3 for 14x Blackwell Speedup and openvdn attacks with hybrid attention in VideoDeltaNet on MiniMax H3 — Near-Lossless Hybrid Attention for Video Models. Unlike those retrofits, this demo touches no weights and requires no distillation training — it is a pure inference-time router.

Results

Single-video wall-clock on RTX 4070, 4-step H3: baseline 6:07, Jev-gated adaptive sparsity 3:34 (41.7% reduction). No quality numbers, no VBench / JavisBench / MOVA Arena scores, no side-by-side against fixed-10% sparsity, no measurement of audio-visual sync preservation. Author’s stated intuition is that adaptive sparsity should produce better quality than fixed sparsity “probably” (“多分”), but the paired comparison is not shown.

Why it’s interesting

This is the first filed datapoint of a decision model used as a runtime attention router for a diffusion transformer — a genuinely new pole in Diffusion serving optimization. All other filed H3 accelerators — FastVideo FastH3 V1 — 4-Step Sparse Distilled MiniMax H3 for 14x Blackwell Speedup (4-step VSA distillation), VideoDeltaNet on MiniMax H3 — Near-Lossless Hybrid Attention for Video Models (hybrid Video Delta Attention retrofit), TaoMate-H3 — Low-Latency Streaming LoRA Distillation of MiniMax H3 for Joint Audio-Video (LoRA-distilled streaming) — modify the model weights or architecture; this modifies neither and inserts a learned scheduling policy between DiT blocks at request time. The natural comparison is a hard-coded sparsity schedule or an oracle-tuned per-layer sparsity table; the interesting question is whether Jev’s calibrated probabilities beat those baselines on quality-per-second, and the author has not shown that A/B.

It is also an unexpected concrete use of Introducing System One Models & Jev‘s “System One Model” pitch outside the announced tool-use / structured-decision domain. TypeSafe’s launch pitched Jev at agentic function-call substitution; this repurposes it as an inference-time compute-allocation policy — the same “typed decision under uncertainty at ~30 ms latency” primitive, applied one abstraction layer down inside a diffusion model. If the sparsity-quality trade-off holds up under real ablations, this generalizes: any per-layer / per-step scheduling knob in a diffusion model (step-count, guidance strength, expert-routing in MoE-DiTs, KV-cache eviction) becomes a Jev-shaped decision problem. That is a much larger deployment surface than the tool-use pitch.

Two caveats keep this a “demo” rather than “result” filing. The 41.7% number is a single wall-clock measurement on one prompt, and the author explicitly concedes fixed 10% sparsity captures much of it — the marginal contribution of Jev over a hard-coded schedule is unknown. The two failed ablations (dynamic step count, layer skipping) suggest the useful decision surface for a bolt-on router is narrower than the “Jev-shaped if statement everywhere” framing implies. Open-source Laya — Non-Autoregressive System One Decision Model (open-source RLCD) is the natural next step here — running the same demo with Laya locally would remove the API round-trip cost from the picture and let the sparsity-quality trade-off be measured cleanly on a single machine.