SpecAR ·

Distributed target blocks for fast autoregressive video generation

A simpler way to generate Realtime videos: fewer expensive model calls, no runtime routing, and up to 10.54× faster inference.

AuthorHudeifa Hassan
AffiliationStatite
Explore
WatchWhat changes when the target runs less often?2.81× faster on Krea · B200PlaceWhere should the target blocks go?5 blocks longest draft run at k = 7MeasureHow much speed for how much quality?10.54× faster on Helios at k = 2

What if we stopped judging every block?

A video can go wrong without any single block looking obviously wrong.

This is a peculiar challenge in autoregressive video generation. Each new block builds on the ones before it, so small errors in appearance or motion can accumulate over time. A smaller model can generate these blocks quickly, but the longer it runs on its own, the further the video can drift. Periodically bringing in a larger model helps, but deciding when to do so is less straightforward.

The intuitive solution is to inspect each drafted block and invoke the larger model whenever a perceptual score falls below some threshold. This is the idea behind online routing. It sounds reasonable: spend the expensive compute only where it is needed.

But our experiments revealed something surprising. On Krea Realtime, online routing accounted for 37% of total generation time in one measured configuration. Yet across matched acceptance rates, its decisions offered no statistically significant quality improvement over random acceptance. Worse, the router sometimes allowed more than twenty consecutive blocks to be generated without a target intervention, leaving small errors to accumulate across the video.

This suggested a different way to think about the problem. Perhaps the important question isn't which individual blocks need the large model, but how long the smaller model should be allowed to run without it.

That is the idea behind SpecAR: treat target-model placement as a scheduling problem rather than a sequence of runtime decisions.

01 / Watch

Watch SpecAR finish first

Both clips start from the same prompt and opening frame. The race uses each method’s measured mean generation time, so SpecAR finishes while the target keeps generating. Select another scene and it plays automatically; switch to “Same frame” to compare the two outputs at matching video times.

View
GPU timing
Clock
Scene
Target budget
SAME PROMPT · DIFFERENT PROGRESS36 blocks · measured mean generation time
⇆
SpecAR 0 / 36
Target-only 0 / 36
SpecAR0 / 36 blocks
Target-only0 / 36 blocks

B200 mean latency: SpecAR 18.5 s; target-only 51.8 s. Timing animation at 1× wall-clock speed.

Race starts as you scroll here.

These are separate Krea Realtime 14B outputs from the same prompt and opening frame (Self-Forcing 1.3B drafter, 832 × 480, 36 blocks). The race spreads each clip evenly across its measured mean generation time; individual block times were not recorded. B200 times average four prompts; H100 times are from the paper. The k = 2 clips are available for the neon-city scene.

02 / Mechanism

Where should the target blocks go?

Suppose we are generating a video of 36 blocks, but can afford to run the large model only seven times. Where should we spend those seven invocations?

We could concentrate them at the beginning, scatter them randomly, or decide as we go using a perceptual router. But these choices can leave long stretches where the smaller model generates without any intervention. And because each block becomes part of the context for the next, errors made early in such a stretch can propagate through everything that follows.

SpecAR takes a different approach: spread the target blocks as evenly as possible.

For 36 blocks and seven target invocations, this guarantees that the drafter never generates more than five consecutive blocks on its own. No other placement with the same budget can guarantee a shorter maximum run. The schedule is determined before generation begins, requires no training, and adds no per-block scoring overhead.

This is a guarantee about how often the target intervenes, not a guarantee of video quality. Whether such a simple schedule can actually outperform an adaptive router is an empirical question.

Try moving the target blocks below. Cluster them, scatter them, and see how the longest uninterrupted draft run changes.

Your placementChoose a blue block to move it
SpecAR placementevenly spaced
Your longest draft run5 blocks
Smallest possible5 blocks

You matched the minimum.

The target always generates block 0. Try clustering the remaining targets to see how a long draft-only stretch appears. The schedule is a figure for H = 36; the released implementation uses the same placement formula.

Given a rollout of H blocks and a target budget k, SpecAR places target blocks at approximately equal intervals, including block 0. Exactly one model generates each block; its output is committed to a shared context for all later blocks. The worst draft run is at most ⌈H/k⌉ − 1 blocks, which is the theoretical minimum.

See the decoding diagram from the paper
SpecAR decoding loop: the target or drafter generates each block according to the fixed schedule; the output joins the committed shared context.
Each scheduled block is generated by one model and committed to the shared context.

03 / Results

Can a fixed schedule outperform an adaptive router?

Even spacing gives us a useful guarantee: the drafter can never run for too long without the target intervening. But minimizing uninterrupted draft runs does not necessarily produce better video. An adaptive router has access to information that a fixed schedule ignores. In principle, that should give it an advantage.

So we compared SpecAR against SDVG, which uses perceptual scores to decide when to invoke the target model.

The results were surprising. Across all three evaluated target budgets, SpecAR was both faster and better on the measured quality metrics. On a single H100, it ran 1.63–1.73× faster than SDVG on Krea Realtime 14B, and 1.10–1.84× faster on Helios 14B, while achieving higher VisionReward and VBench Quality-6 scores at every evaluated operating point.

For example, with seven target blocks on Krea Realtime, SpecAR finished in 42.9 seconds, compared with 70.3 seconds for SDVG. Its VisionReward score was also higher: 0.0972 versus 0.0886.

The router had more information and made more decisions. Neither translated into an advantage in these experiments.

Target-onlySDVGSpecARClick a point or choose k above
Krea, k = 2: SpecAR 2.67× faster than target-only

32.8 s versus 87.6 s target-only and 56.8 s SDVG. Quality-6: 77.25 for SpecAR, 76.95 for SDVG, and 78.06 for target-only.

One H100 per model pair; H = 36. SDVG thresholds were selected on held-out prompts to approximate the same draft fraction. Full VisionReward values and system details are in the paper.

From Hopper to Blackwell

A useful acceleration should survive beyond a single hardware configuration. We evaluated SpecAR on two generations of NVIDIA GPUs: Hopper (H100) and Blackwell (B200), using Krea Realtime 14B.

On a single H100, SpecAR reduces generation time from 87.6 to 32.8 seconds, a 2.67× speedup over target-only inference. On a single B200, generation takes just 18.5 seconds instead of 51.8, achieving 2.81× acceleration. The gains persist across all three evaluated target budgets, with speedups exceeding 2× on both architectures.

The Blackwell results also cross an important threshold. At 23.1 generated FPS, SpecAR exceeds the video's 16 FPS playback rate. Even when allocating more blocks to the target model, throughput remains between 18.0 and 19.7 FPS. In all three configurations, the model produces frames faster than they are played.

Generated frames per second
16 FPS playback rate · B200, mean of four prompts
Read H100 and B200 latency, FPS and speedup
Krea Realtime 14B · one H100 · paper
MethodLatencyFPSSpeedup
Target-only87.6 s4.91.00×
SpecAR, k = 232.8 s13.02.67×
SpecAR, k = 539.0 s10.92.25×
SpecAR, k = 742.9 s9.92.04×
Krea Realtime 14B · one B200 · FlashAttention 4
MethodLatencyFPSSpeedup
Target-only51.8 s8.21.00×
SpecAR, k = 218.5 s23.12.81×
SpecAR, k = 521.6 s19.72.40×
SpecAR, k = 723.7 s18.02.19×
FPS uses 426 generated frames. Displayed latency, FPS and speedup are rounded separately, so ratios recomputed from the displayed values may differ slightly. H100 values are from the paper; B200 values average four prompts and are not in the paper. SDVG is omitted on B200 because the recorded run did not match its target-block budget.
Read the full benchmark tables
Krea Realtime 14B · Self-Forcing 1.3B drafter · 832×480, 36 blocks
LatencySpeedupVisionRewardQuality-6
Target-only87.6 s1.00×0.091478.06
k = 2
SDVG56.8 s1.54×0.085576.95
SpecAR32.8 s2.67×0.087677.25
k = 5
SDVG63.5 s1.38×0.087277.01
SpecAR39.0 s2.25×0.094377.32
k = 7
SDVG70.3 s1.25×0.088676.91
SpecAR42.9 s2.04×0.097277.85
Helios 14B · Helios-Distilled 14B drafter · 640×384, 36 chunks
LatencySpeedupVisionRewardQuality-6
Target-only2911.5 s1.00×0.148778.98
k = 2
SDVG507.3 s5.74×0.111275.89
SpecAR276.2 s10.54×0.122377.05
k = 5
SDVG665.4 s4.38×0.115675.88
SpecAR509.6 s5.71×0.127077.17
k = 7
SDVG735.8 s3.96×0.119975.69
SpecAR666.5 s4.37×0.137577.73

Quality-6 is VBench's Quality Score restricted to six dimensions. Mean latency and VisionReward are taken from the paper.

04 / Quick start

Run SpecAR yourself

The code behind these results is publicly available. We've released SpecAR with support for Krea Realtime 14B and Helios 14B, allowing you to generate videos, adjust the target-block budget, and explore the speed–quality tradeoff on a single supported GPU.

You can run SpecAR directly from the command line or use the ComfyUI integration for a visual workflow. Both expose the same central idea: control how often the target model runs, without relying on an online router.

The released code and public weights run on one NVIDIA Hopper GPU (H100 80GB or H200 141GB) with Python 3.11. Choose a way to run it below. FlashAttention 3 is fetched prebuilt on first use.

Install

git clone https://github.com/statite-ai/SpecAR && cd SpecAR
python3.11 -m venv .venv-krea && source .venv-krea/bin/activate
pip install ".[krea]"
specar download --backbone krea

Generate

specar generate --backbone krea \
    --prompt "A papercraft coral reef full of colorful fish" \
    --k 2 --out reef.mp4

About 50 GB download. A 26.6 s video (426 frames) generates in under a minute on an H100, after about 3 minutes of model loading.

--k is the number of target blocks: 2 is the fastest setting in the paper, 7 the default. Set the length with --seconds or try a curated prompt with --example cat; all options are in the README.

References

  1. Hassan, H. (2026). SpecAR: Distributed Target Blocks for Fast Autoregressive Video Generation. Preprint. H100 benchmarks and routing ablations.
  2. Hu, Y., & Zhang, J. (2026). Speculative Decoding for Autoregressive Video Generation. arXiv:2604.17397. SDVG baseline.
  3. Millon, E., & Krea AI. (2025). Krea Realtime 14B: Real-Time, Long-Form AI Video Generation. Model description.
  4. Yuan, S., et al. (2026). Helios: Real Real-Time Long Video Generation Model. arXiv:2603.04379.
  5. Huang, X., et al. (2025). Self Forcing: Bridging the Train-Test Gap in Autoregressive Video Diffusion. arXiv:2506.08009. Krea drafter.
  6. Huang, Z., et al. (2024). VBench: Comprehensive Benchmark Suite for Video Generative Models. CVPR 2024.
  7. Xu, J., et al. (2026). VisionReward: Fine-Grained Multi-Dimensional Human Preference Learning for Image and Video Generation. AAAI 2026.

B200 measurements on this page average four Krea prompts and are separate from the preprint.

Cite this work

@misc{hassan2026specar,
  title  = {SpecAR: Distributed Target Blocks for Fast Autoregressive Video Generation},
  author = {Hassan, Hudeifa},
  year   = {2026},
  note   = {Preprint},
  url    = {https://statite.ai/specar}
}