The 11.04x figure compares Sol-H3's default profile against a dense 50-step H3 run at 18.25 seconds [6][7]. The FastH3 adapter accounts for most of that gap, cutting the denoising schedule from 49 transformer forwards to four [8]. Four forwards instead of forty-nine is roughly 12x less transformer work before anyone touches attention, and the fastest multi-GPU configuration then adds approximate sparse attention plus INT8 and FP8 transport on top [8][9]. So the runtime engineering is real, and it is layered on a workload that was already an order of magnitude smaller.
NVIDIA's repository says the same thing in its own defaults: the default profile prioritizes speed and uses lossy acceleration, with a dense mode available when closer reference behavior matters [10]. That default setting is the thing to check before trusting the headline number. If your acceptance criterion is "matches the reference model", you are running dense mode, and dense mode is the 18.25-second number.
The measurement boundary is drawn where a serving engineer would want to check it. The 1.653 seconds is the median of three requests after one warmup, on eight B300s, and it covers text encoding, denoising and VAE decode for video and audio [3][4]. It excludes model loading, compilation warmup and MP4 encoding [5]. A cold production request pays all three of those, and NVIDIA does not claim otherwise [12].
Scale down and the claim inverts. One B300 takes 13.745 seconds for the same five-second output [11]. Eight to one is an 8x drop in silicon for an 8.3x increase in wall clock, so the multi-GPU path is holding near-linear scaling, which is the part of this release I would call good craft rather than good marketing [3][11][17]. Desk-side is a different story again: the separate Sol Engine work reports 4.52x on an RTX 5090 and 3.92x on a DGX Spark, with the five-second jobs still taking 231.2 and 181.3 seconds because they kept the 50-step schedule and ran different resolutions [13][14]. Same model, two orders of magnitude apart in latency, because the step count and the box changed.
On the distribution argument, the sources support the mechanism but not a broad conclusion. MiniMax opened H3's weights on August 3rd, a 33B model with native 32 kHz stereo audio and four-to-15-second outputs at 24fps [15]. Five weeks later the serving stack it promoted was built by NVIDIA Research's Efficient AI Team and Singapore Lab, with the four-step adapter from Hao AI Lab at UC San Diego and hosted access from Reactor [2][16]. MiniMax promoted the result on September 7th, three days after NVIDIA published the package [1]. That is outside engineering MiniMax did not pay for. What the material does not show is any cost figure, any licence term for H3 itself, or any adoption number, so "open weights buy free serving-cost engineering" is a plausible reading of one case, unsupported by any measurement. The one licence fact on the table is that Sol-H3's code is Apache 2.0 [18].
