Engineering · Video inference

How ProsGrow Improves MiniMax-H3 Video Inference Latency by 54%

MiniMax-H3 server inference fell from 19.392 to 8.913 seconds for the same BF16 Turbo request on the same eight GPUs. Separate studies cut Wan warm latency by 59.1% and raised Animate throughput by 17.62%.

· Updated · ProsGrow AI Engineering · 8 min read

MiniMax-H3 server inference: 19.392 to 8.913 seconds on the same eight GPUs, 54% lower latency for the same BF16 Turbo request.

Different jobs need different service classes

A creative preview needs a short wait. Motion transfer needs to preserve a source performance over a longer output. A high-resolution audiovisual request may occupy several GPUs at once. Optimizing these services requires decisions across precision, attention, memory residency, parallelism, compilation, and quality.

ProsGrow evaluated these service classes on an eight-GPU RTX PRO 6000 Blackwell node. The MiniMax-H3 comparison reduced server inference from 19.392 to 8.913 seconds for the same BF16 Turbo request on the same eight GPUs: 54.0% lower latency. Separate Wan and Animate studies show how delivery deadlines, aggregate demand, and quality requirements change the useful configuration.

Our approach was to establish a workload contract, profile its bottlenecks, compare candidate operating points, and validate the selected result. The studies connect each measured improvement to its resource and quality constraints.

MiniMax-H3: latency, memory, and quality

MiniMax-H3 exposed the cost of distributing a large audiovisual workload across a PCIe node. Changing how parallel work was divided reduced server inference from 19.392 to 8.913 seconds on the same eight GPUs: 54.0% lower latency for the same BF16 Turbo request.

Tensor and sequence parallelism create different communication and memory demands. The controlled measurements supported reducing communication overhead for this workload, although no usable kernel trace established the cause at kernel level. The selected latency profile consumed about 84.2 GB per GPU; configurations with more memory headroom carried a latency penalty.

The upstream SGLang MiniMax-H3 stack supplies the model-serving and parallelism building blocks. ProsGrow’s contribution was evaluating their behavior on this hardware and selecting against the service objective.

A separate approximation experiment reused intermediate computation and reduced server inference from 8.913 to 7.092 seconds, a further 20.44%. API completion fell from 10.045 to 8.040 seconds, with all eight GPUs still allocated to one request. Decode time stayed essentially unchanged.

That additional gain has a different acceptance condition: approximate computation requires a quality gate. The selected candidate passed a limited numerical-consistency check on one scene. This is evidence for a candidate operating point, not broad perceptual parity or approval for every customer workload.

Wan2.2: a controlled four-step comparison

Baseline · distilled BF16, dense attention, CPU offload22.164 seconds
ProsGrow configuration · reduced precision, sparse attention, GPU residency9.062 seconds · 59.1% lower
One RTX PRO 6000 Blackwell GPU; same prompt, seed, four-step schedule, and 81-frame 832×480 output. Both paths are warmed. Precision, attention, and memory placement change together. Generated compositions differ; perceptual equivalence was not established.
Same GPU, prompt, seed, four-step schedule, and output geometry
MetricDistilled BF16 baselineSelected LightX2V configuration
Warm pipeline22.164 s9.062 s · 59.1% lower
Denoising19.164 s6.076 s
VAE decodingAbout 2.37 sAbout 2.36 s

The selected path combines reduced precision, sparse attention, and GPU residency. These capabilities come from the upstream LightWan2.2 model and LightX2V runtime, including quantization-aware step distillation. ProsGrow integrated and validated the execution path, established local controls, and measured the resulting service trade-offs.

A standard 40-step BF16 run took 357.640 seconds. Much of the difference from that reference comes from upstream step distillation. The four-step BF16 control measures an additional combined runtime gain of 2.45×, separate from the benefit of step distillation.

Precision, attention, and residency interact

The opportunity spanned several layers of the execution path:

  • Precision and attention: a smaller numeric representation and sparse attention reduced denoising work. Their combined benefit depends on the model and supported execution path; a format change alone does not guarantee faster serving.
  • GPU residency: smaller expert weights could remain in GPU memory, removing host-to-device transfers from the critical path. Memory savings changed where computation could run as well as how much arithmetic it required.
  • Pipeline balance: decoding stayed near 2.36 seconds. As denoising accelerated, this largely unchanged stage became a greater share of the request, limiting what further denoiser improvements could deliver.
  • Warm versus cold service: the optimized isolated process took 72.12 seconds including model load, warmup, and shutdown. A short warm inference result therefore depends on a service that manages startup work and residency.

The controlled result measures these changes together. It does not assign an independent causal speedup to every layer. This is why optimization needs both stage timings and an end-to-end delivery boundary.

A synchronized node round showed similar warm latency across the GPUs. Its slowest completion projects to about 3,138 clips/hour for this preview contract. That is a capacity conversion from one measured round, not a sustained hourly API test. Quality also constrains the result: generated compositions differed, and perceptual equivalence was not established.

Animate-2: throughput for an asynchronous service

Animate-2 produces an 11.21-second motion-transfer video from a reference image and source video. Its longer jobs belong in an asynchronous queue, where completed outputs and energy per job matter more than an interactive preview deadline.

ProsGrow combined a validated FP8 execution path with a persistent compilation cache. Reusing compiled code reduced repeated startup work, while precision changed the steady execution cost. Both were measured within the full launch boundary used by this service.

Matched node workload, with compilation cache populated for the selected result
MetricBF16 baselineFP8 + compile cache
Node output rate24.382 outputs/h28.678 outputs/h · +17.62%
Mean whole-node power6.581 kW6.575 kW
Energy per output0.270 kWh0.229 kWh

Nearly unchanged server power and higher throughput reduced energy per output by about 15.1%. The selected configuration left only about 4 GiB of GPU memory headroom, making output geometry and concurrent work material deployment constraints.

A compilation cache is also an operational artifact: it must be versioned or rebuilt as hardware, runtime, model shape, or compile settings change. The useful result includes that lifecycle decision alongside throughput and the visual regression check.

Select the operating point for the customer

Using the whole node can shorten one request. Partitioning capacity into smaller replicas can complete more independent jobs in aggregate. A separate MiniMax study using upstream model pruning and the Turbo adapter produced a 478.14-clips/hour rate from one synchronized round, with requests taking about 30.1 seconds each. Its changed model and service shape require their own quality assessment.

What to optimize for each service class
Service classPrimary objectiveConstraint to carry forward
Interactive previewShort request completion timeWarm residency, queueing, and acceptable visual change
Aggregate generationAccepted clips per nodeReplica memory, per-request wait, and quality
Asynchronous motion transferCompleted jobs and energy per outputCompilation lifecycle, memory headroom, and source fidelity

There is no single winning setting across these objectives. The useful outcome is a set of measured choices between latency, throughput, memory, energy, and quality. These studies provide the evidence needed to choose a service class; a customer pilot must then validate accepted outputs, queueing, and delivery deadlines on representative media.

Methodology and limitations

Request contracts behind the three studies
StudyOutput contractMeasurement boundary
Wan2.2 / LightWan2.281 frames, 832×480, 16 FPS, 5.0625 s; controlled prompt and seedLightX2V; warm synchronized pipeline through encode/save; excludes model load and warmup
Wan2.2 Animate-2 14B269 frames, 713×1264, 24 FPS, 11.2083 s, source audio; same reference media and four segments × ten stepsLightX2V; complete launch wall time, populated compile cache for selected result
MiniMax-H3 FL2VA Turbo1344×768, 124 frames, 24 FPS, 5.175 s file, generated audio; same prompt and seed, four observed denoiser evaluationsSGLang; server inference and full API completion measured separately
  • Hardware and repetition: one eight-GPU RTX PRO 6000 Blackwell node, 96 GB nominal memory per GPU. Wan records one measured warm generation per worker. Animate’s selected rate is the slower of two node runs. Each H3 latency candidate has one warmup and one measured request; replica rates come from one simultaneous round. These short studies do not establish sustained-load SLAs or latency percentiles.
  • Wan quality: contact-sheet review found coherent clips, but the standard 40-step reference had cleaner literal prompt adherence in the single tested scene. Distillation, sparsity, and precision changes do not establish perceptual equivalence.
  • Animate quality: all 269 frames were compared with BF16, yielding SSIM 0.9534 and PSNR 31.74 dB. These are visual regression checks on one input.
  • H3 quality: the selected approximation scored SSIM 0.8128 against the reference, narrowly above the 0.8102 floor observed across local parallelism configurations. That numerical check does not replace multi-prompt review of motion, prompt adherence, audio synchronization, or human preference. The separate pruned-model throughput study scored SSIM 0.8815 against its original-model reference.
  • Attribution and timing: upstream models and runtimes supply the optimization building blocks. Combined changes do not isolate every component’s effect. H3 server inference excludes client polling and download; its 8.913-second server result and 10.045-second API result must remain distinct in comparisons.

Wan measurements were collected August 12–18 and MiniMax follow-ups September 1–2, 2026. Results apply to the stated media and output contracts.

Define the video service your workload needs

Bring source media, output geometry, quality requirements, and a delivery target. We’ll establish a baseline and compare the operating points that change capacity or latency for that service.

Discuss a pilot