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
| Metric | Distilled BF16 baseline | Selected LightX2V configuration |
|---|---|---|
| Warm pipeline | 22.164 s | 9.062 s · 59.1% lower |
| Denoising | 19.164 s | 6.076 s |
| VAE decoding | About 2.37 s | About 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.
| Metric | BF16 baseline | FP8 + compile cache |
|---|---|---|
| Node output rate | 24.382 outputs/h | 28.678 outputs/h · +17.62% |
| Mean whole-node power | 6.581 kW | 6.575 kW |
| Energy per output | 0.270 kWh | 0.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.
| Service class | Primary objective | Constraint to carry forward |
|---|---|---|
| Interactive preview | Short request completion time | Warm residency, queueing, and acceptable visual change |
| Aggregate generation | Accepted clips per node | Replica memory, per-request wait, and quality |
| Asynchronous motion transfer | Completed jobs and energy per output | Compilation 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
| Study | Output contract | Measurement boundary |
|---|---|---|
| Wan2.2 / LightWan2.2 | 81 frames, 832×480, 16 FPS, 5.0625 s; controlled prompt and seed | LightX2V; warm synchronized pipeline through encode/save; excludes model load and warmup |
| Wan2.2 Animate-2 14B | 269 frames, 713×1264, 24 FPS, 11.2083 s, source audio; same reference media and four segments × ten steps | LightX2V; complete launch wall time, populated compile cache for selected result |
| MiniMax-H3 FL2VA Turbo | 1344×768, 124 frames, 24 FPS, 5.175 s file, generated audio; same prompt and seed, four observed denoiser evaluations | SGLang; 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