[RFC]: Production VAE optimization for diffusion pipelines with MiniMax-H3

Motivation.

As diffusion transformers become faster, VAE decode becomes a larger share of end-to-end latency. MiniMax-H3 is a good first target because it combines:

• a large ViT3D video decoder;
• native tiled decode and tile parallelism;
• separate video and audio VAEs; and
• distributed execution.

Today H3 reports video and audio decode as one aggregate decode stage, making it difficult to identify the bottleneck or measure optimization impact. The current adapter also does not expose the remote VAE's stack_tiling option, has no VAE-specific compile path, and derives VAE parallelism from the DiT process group.

The end-to-end benefit must be evaluated with Amdahl's law:

speedup = 1 / ((1 - vae_share) + vae_share / vae_speedup)

This RFC proposes production-safe runtime improvements first, while keeping decoder replacement and latent-space changes as separate research tracks.

Proposed Change.

1. Add component-level observability

Keep the existing aggregate decode metric and add:

video_vae.decode_latent
audio_vae.decode_latent
video_vae.tile_decode
video_vae.tile_merge
decode

Report video/audio VAE time, tile/merge time, resolution, frame count, latent shape, parallel sizes, optimization mode, peak memory, and cold/warm state. Profiling synchronization should not be added to the normal serving path.

2. Make VAE options capability-driven

VAE implementations should declare whether they support:

• tiled decode;
• stacked tiles;
• VAE compilation;
• spatial sharding; and
• an independently sized process group.

Explicit unsupported options should fail during validation. auto may select the safe eager/tiled path and log the decision.

3. Optimize H3 execution

The initial H3 implementation should:

• expose --vae-stack-tiling=auto|true|false;
• enable stacked tiles only for validated shapes and sufficient memory;
• fall back to sequential tiles after allocation or runtime failure;
• compile only stable decoder regions inside fixed tiles, with bounded shape buckets and eager fallback; and
• allow a deterministic VAE process group smaller than the DiT group.

Tile mode should be implemented first. H3 spatial sharding should remain deferred until its attention communication and boundary semantics are defined.

4. Define production profiles and gates

Profile	Stack tiles	VAE compile	VAE group	Use
safe	Off	Off	Existing	Default fallback
optimized	Validated auto	Validated buckets	Qualified sizes	Production
diagnostic	Configurable	Configurable	Configurable	Benchmarking
student	Model-specific	Model-specific	Model-specific	Research

Every optimization must be compared with the eager decoder using identical latent inputs and seeds. Acceptance should cover:

• functional correctness, frame/audio synchronization, tile seams, offload, and failure fallback;
• video/audio quality metrics and documented tolerances; and
• cold, first-request, warm, VAE-only, total decode, denoising, end-to-end, memory, and rank-imbalance measurements.

A compile, OOM, or collective failure must not poison subsequent requests.

5. Separate runtime and post-training tracks

Track	Post-training required?	Recommendation
Timing, stacked tiles, compile, precision, parallelism	No	First production track
Same-latent decoder student, such as Flash-VAED/Turbo-VAED	Yes	H3-specific research
Streaming/causal decoder, such as FlashDecoder	Yes	Separate architecture effort
New VAE/latent space, such as DC-VideoGen	Yes	Separate end-to-end model effort

Published decoder checkpoints are not drop-in replacements for H3.

Rollout.

1. Instrument video/audio timing and establish H3 FL2VA/Ref2VA baselines.
2. Add capability discovery and validated stacked tiles.
3. Add H3 VAE compilation for stable decoder regions.
4. Add independent VAE process groups and benchmark group sizes.
5. Evaluate an H3-specific decoder student outside the serving runtime.

Open questions.

1. Should component timings be part of normal responses or diagnostic output only?
2. Should vae_stack_tiling be generic with capability validation or model-specific?
3. How should CFG, TP/SP, HSDP, and VAE groups compose?
4. What H3 resolution/duration matrix should be the release gate?
5. Should a future H3 student decoder live in vLLM-Omni or as a versioned model artifact?

Related issues and references.

• #2089: VAE as a separate stage for memory pressure.
• #5639: VAE patch-parallel configuration behavior.
• #5925: Diffusion profiler visibility.
• VAE Patch Parallelism design
• Flash-VAED, Turbo-VAED, FlashDecoder, DC-VideoGen

Feedback Period.

Please provide feedback over the next two weeks.

Any Other Things.

The goal of this RFC is to align on runtime architecture and qualification criteria. It does not request changing H3 weights, latent shapes, or default behavior before benchmarks and quality gates pass.

Before submitting a new issue...

• Searched existing issues for related VAE, H3, and profiler work.
• Checked the vLLM-Omni documentation and existing VAE parallelism design.