MiniMax H3 Spark-H3: Sparse Attention and ComfyUI Guide

H3Vid Teamon 11 days ago

Spark-H3 is a local attention backend for MiniMax H3. It changes how the model computes attention rather than supplying a new video checkpoint. Its public code includes Diffusers integration and ComfyUI nodes, giving local users another way to investigate the cost of each sampling step.

This guide reviews the project and its separate configuration and installation documents on October 12, 2026. We have not installed it or run its benchmarks. H3Vid does not currently expose Spark as a hosted generation backend.

What Spark changes

The project's two mechanisms are reblocking and reweighting. Reblocking groups tokens with similar attention preferences; reweighting adjusts summaries of the less directly computed blocks. The aim is to spend the attention budget more effectively while approximating interactions that do not receive full computation.

That is different from a Turbo LoRA, which supplies learned weights for a few-step recipe. It is also different from FastH3 as a distilled model release. A workflow can involve both a sampling accelerator and an attention backend, but each changes a different part of the execution.

Think about where your machine spends time before choosing an experiment. If weight transfers or decoding dominate a render, reducing attention work may change only part of the total. If attention is expensive because the video has many tokens, the potential benefit may be larger. Neither case can be diagnosed from the final video resolution alone.

Choose the package for your actual GPU

The ComfyUI guide describes standalone SM89 and SM120 nodes for native H3. Its release targets are Linux or Windows x86_64 with RTX 40-series or RTX 50-series/RTX PRO Blackwell GPUs and CUDA BF16 execution. Select the release for both the operating system and GPU architecture.

The broader Diffusers dispatch has additional architecture paths. That does not mean every path has the same release packaging or hardware validation. DGX Spark is a computer with a GB10 chip; its name does not establish compatibility with this project named Spark-H3. Read the exact architecture table instead of matching the word “Spark.”

Keep your working ComfyUI environment intact while investigating installation. Note its Python, PyTorch and CUDA versions, then compare them with the release's requirements. Model weights and ComfyUI itself are not bundled with the attention package.

Begin with a supplied workflow

The ComfyUI examples cover native H3 and several LoRA configurations. The LightX2V and Larryvrh adapters require their own weights; the Larryvrh route also has a documented conversion step. DMAD uses its specific re-noise sampler. These are explicit recipes, not permission to substitute any four-step sampler.

Place the matching Spark node on the MODEL path before BasicGuider and use one attention patch. Begin with the package's example values instead of adding it to a graph already carrying several attention overrides. First confirm the correct node, model files, and sampler connections; only then change creative inputs.

Its LBH example is especially easy to confuse with another workflow. Spark's official-style LBH graph performs four low-resolution model evaluations followed by three high-resolution evaluations, with Spark applied to the second stage. The separate LBH 3+1 package uses three low-resolution steps and one high-resolution step. They should not share a timing label.

Warmup and step counts need explicit definitions

The configuration guide distinguishes dense warmup evaluations from later sparse evaluations. Keeping the early part dense is part of a recipe, not an extra initialization time that can always be removed from the measurement.

MiniMaxH3Scheduler also includes a terminal zero in its requested inference-step grid. The documented Diffusers example requests 20 grid points for 19 actual denoising evaluations. Spark's installer should receive the actual evaluation count. Copying a requested number into every field without checking its meaning can change the warmup schedule.

When comparing runs, record requested steps, executed model evaluations, dense warmup, forced dense layers and Top-K settings separately. A single “20 steps” note loses information needed to reproduce the configuration.

The project describes exact handling for text, audio and conditioning context while sparsifying the generated target-video grid. That execution design does not replace listening to the result or checking the reference subject. Numerical handling and perceptual success answer different questions.

What the speed numbers measure

The kernel performance matrix reports CUDA-synchronized DiT/denoising time, excluding loading, VAE decoding and other end-to-end work. It records actual evaluations and aggregates four dense and four Spark measurements for each displayed duration.

For its ten-second native H3 profile, the matrix gives 988.0→581.5 seconds on A800 and 583.9→338.7 seconds on RTX PRO 6000 Blackwell. Both use a specified BF16, 1344×768, 19-evaluation profile with dense warmup. These author measurements are more useful with their configuration attached than as a headline promising every clip finishes that much faster.

Do not merge an attention-kernel ratio, a DiT ratio, and a complete generation ratio into one ranking. Compiled runtime state, cache warmth, model precision and sampler changes can all affect a comparison. A social post's larger ratio may refer to another workload; use its original record before repeating it.

Make a comparison that answers your own question

Choose one question first: shorter wait for drafts, lower peak memory, or closer visual agreement with dense attention. Keep the model, input, seed, duration and sampler unchanged for the initial pair. Label first-run compilation separately from repeated execution.

Measure the full workflow as well as the available sampling stage. Review several scenes: a quiet shot, an active shot and a reference-driven shot. Inspect identity, fine details, motion and sound. Keep rejected outputs in the record so a fast failure does not appear as a production improvement.

If a supplied workflow succeeds, save its revision and your actual file selections before adapting it. If it fails, capture the reported architecture and dependency versions. That information is more actionable than lowering random values until the graph queues.

For another attention approach, see Veda in ComfyUI. For the underlying local setup, start with MiniMax H3 in ComfyUI. Evaluate each backend in a matched experiment rather than stacking names into a presumed fastest configuration.

The cover is an AI-generated concept illustration of selective computation, not a Spark visualization, model output, or measured result.