MiniMax H3 on RTX 4090: 14m16s for 5.17s 720p at Full 50 Steps, No Turbo LoRA
MiniMax H3 on RTX 4090: 14m16s for 5.17s 720p at Full 50 Steps, No Turbo LoRA
G80 Experimental Report · September 20, 2026 · Reference video: 1280×736, 124 frames, 50 steps
G80 generated a 5.167-second video in 14 minutes 16.125 seconds, including process startup, preparation, image/audio generation, and file export. The initial full-attention Flex run took 40 minutes 50.065 seconds using the same prompt, reference images, seed, and output dimensions. Runtime was reduced by 65.06%, corresponding to a 2.86× processing speedup.
This result reflects the combined effect of a checkpoint change and system improvements: moving from the original H3 BF16/Euler configuration to Singularity INT8/RES, together with kernel optimizations, memory management, and computation reuse. This is not a code-only test with every other condition held constant, nor does it demonstrate unchanged quality across every scene.
1. Scope and Measurement Method
“G80” is the identifier for an experimental configuration in this project, not the name of a model released by MiniMax. The runtime platform is Wan2GP, with local modifications and community backends. The final model is Singularity v1.3, a community model developed from the MiniMax H3 family.
The main milestones in this report use the same Test 1 workload: a fast-action combat scene, four reference images, and seed 12345. The SHA-256 of the prompt and the ordering of the four images were verified to match between the initial version and G80. The test generates approximately 5 seconds of video. Because the prompt describes a longer sequence of events, this should not be treated as verification of a complete 15-second action sequence.
End-to-end runtime: measured from the start of the test process until completion, including preparation, sampling, decoding, and video export. It excludes model loading, software installation, earlier research/calibration, and post-render file inspection.
Sampling: taken from the denoising completion time in the log and rounded to the nearest second. It is not a dedicated CUDA timer for each kernel.
Each row represents one saved run executed at a different time. Warm/cold cache state, starting temperature, and background workload were not controlled as paired repeated measurements.
The “initial full” configuration already included several modifications, such as AdaLN precomputation. There is no untouched Wan2GP control run, so no speedup claim is made relative to an unmodified upstream build.
2. Hardware and Software
GPU
Recorded Configuration: NVIDIA GeForce RTX 4090, 24 GB VRAM
CPU
Recorded Configuration: Intel Core i9-13900K
System RAM
Recorded Configuration: Approximately 127.72 GiB detected by the operating system; this is the machine's installed memory, not the amount of RAM used by G80
Operating system
Recorded Configuration: Windows, local execution
Python
Recorded Configuration: 3.11.13
PyTorch / CUDA build
Recorded Configuration: 2.10.0+cu130
Triton Windows
Recorded Configuration: 3.6.0.post26
MMGP / Optimum Quanto
Recorded Configuration: 3.7.14 / 0.2.7
Comfy Kitchen
Recorded Configuration: 0.2.33, native CUDA backend confirmed to execute
Wan2GP base commit
Recorded Configuration: 362c3467a70e1136ceb52eec95907205a8f88543, with local modifications
The CPU, RAM, and installed software versions were read when this report was prepared. They improve traceability but do not replace a complete environment snapshot for every historical run. The base commit alone is also insufficient to reproduce the project's patches.
3. Actual G80 Configuration Used
Checkpoint
Value: Minimax-h3_Singularity_ref2va_v1.3_int8.safetensors
Execution architecture
Value: Full 50 DiT blocks; no reduced-block variant was used in the test
Weights / computation
Value: INT8 ConvRot for the applicable linear layers; per-row activation quantization in Kitchen; multiple components and outputs remain BF16
Checkpoint size
Value: 34,004,507,622 bytes, approximately 31.67 GiB; excludes encoder/VAE
Input
Value: Original Prompt 1, 4 reference images; no start/end image or video guide
Seed / batch
Value: 12345 / 1
Output
Value: 1280×736, 124 frames, 24 fps, 5.166667 seconds
Sampler / steps
Value: res_multistep / 50
Guidance / flow shift
Value: CFG 1, audio guidance 1, flow shift 12
Attention
Value: H3 SLA BF16, sparsity 0.5; dense backend Flex
Measured cache schedule
Value: 30 full forward + 20 reuse forward
Offload
Value: MMGP profile 5, transformer budget 100 MB; staged text encoder
AdaLN
Value: Exactly 50 timestep vectors prepared once per run
MLP activation cap
Value: 4096 rows, split within the original group
Video VAE
Value: FP16, SDPA attention, tile 256, overlap 64; G58 buffer-lifetime optimization
Conditioning layout
Value: h3_mask_mode=grouped_rows, preserving the pipeline's token-packing layout
Audio
Value: Same 50-step schedule; no additional audio refinement pass
Export
Value: MP4, H.264; AAC stereo 32 kHz
LoRA / resolution enhancement
Value: No LoRA; no two-resolution WF, no upscaling, and no frame interpolation
1280×736 is informally referred to as the “720p” test within the project, but this report preserves the actual dimensions. The video track is 5.166667 seconds long, while the audio track in the MP4 is 5.152 seconds. The file was decoded and verified to contain the complete frame sequence and audio.
The parameters above were cross-checked against the effective configuration and execution logs, including SLA, Kitchen CUDA, and the fixed G80 cache schedule.
4. Full-Video Results
Same Input, Different Historical Runs
Early SDPA control
Model / sampler / attention: Original H3 BF16 / Euler / SDPA · End-to-end runtime: 46:09.681 · Sampling: 41:59 · Full / reuse: 50 / 0
Early Full Flex
Model / sampler / attention: Original H3 BF16 / Euler / dense Flex · End-to-end runtime: 40:50.065 · Sampling: 35:14 · Full / reuse: 50 / 0
Early SLA
Model / sampler / attention: Original H3 BF16 / Euler / SLA + Flex · End-to-end runtime: 37:50.161 · Sampling: 34:23 · Full / reuse: 50 / 0
G65
Model / sampler / attention: Singularity INT8 / RES / SLA + Flex · End-to-end runtime: 19:08.297 · Sampling: 14:47 · Full / reuse: 35 / 15
G79
Model / sampler / attention: Same as G65, with a different cache schedule · End-to-end runtime: 14:56.328 · Sampling: 13:06 · Full / reuse: 32 / 18
G80
Model / sampler / attention: Same as G79, with two additional selected reuse steps · End-to-end runtime: 14:16.125 · Sampling: 12:22 · Full / reuse: 30 / 20
Full Flex is the primary comparison point because it was the stronger full-attention configuration in the early testing phase. SDPA is listed separately to avoid conflating the “first baseline” with the “full version after attention optimization.”
Early SDPA
Time saved: 31 minutes 53.556 seconds · Runtime reduction: 69.09% · Relative speed: 3.24×
Early Full Flex
Time saved: 26 minutes 33.940 seconds · Runtime reduction: 65.06% · Relative speed: 2.86×
Early SLA
Time saved: 23 minutes 34.036 seconds · Runtime reduction: 62.29% · Relative speed: 2.65×
G65, same Singularity checkpoint
Time saved: 4 minutes 52.172 seconds · Runtime reduction: 25.44% · Relative speed: 1.34×
G79
Time saved: 40.203 seconds · Runtime reduction: 4.49% · Relative speed: 1.05×
Formula: runtime reduction = (T_old - T_new) / T_old; relative speed = T_old / T_new. Percentages from individual optimizations are not added together to derive the total gain.
How Much of the Difference Can Be Attributed to Video Generation Time?
G65 and G80 use the same checkpoint, generation parameters, and underlying compute code; the difference is the cache policy. Sampling decreased from 887 to 742 seconds, a reduction of 145 seconds, or 16.35%. However, end-to-end runtime fell by 292.172 seconds, leaving approximately 147.172 seconds outside the sampling interval. G65 had a longer preparation phase, so the 25.44% end-to-end reduction is not evidence that the entire gain came from the G80 cache policy.
From G79 to G80, sampling decreased from 786 to 742 seconds, or 5.60%, while end-to-end runtime decreased by 4.49%. These are still two historical runs, not the median of repeated paired A/B measurements.
In the G80 run, each second of finished video required an average of 165.70 seconds of processing, approximately 2 minutes 45.70 seconds. This ratio should not be used to promise the runtime of a 15-second video because longer duration changes token count, memory use, and attention cost.
5. Main Mechanisms Used in the G80 Configuration
5.1. Singularity INT8 Checkpoint and Actual INT8 Computation
Replacing the original checkpoint with Singularity is a model change, not merely a speed patch. The user judged Singularity to be clearly better than the original model in the viewed scene. The project performed no additional training and uses community-released weights.
INT8 reduces the size of many matrices and lowers weight-transfer cost. G80 also uses ConvRot + per-row activation quantization + INT8 GEMM from Comfy Kitchen, through an adapter modified for this pipeline. The system therefore does more than simply store 8-bit weights and fully dequantize them back to BF16 before matrix multiplication. Small AdaLN operations retain the appropriate native path.
This numerical change can produce outputs that differ from BF16. A checkpoint that is nearly half the size does not imply that total VRAM usage or runtime is halved, because attention, activations, VAE processing, and data transfers still consume resources.
5.2. SLA Combined with Flex for Full-Attention Regions
SLA computes only selected key groups for the video portion instead of always evaluating the entire dense attention space. The conditioning prefix is protected, while the early and late steps still include dense processing according to the native schedule. Flex handles the cases that require full attention.
The G80 log reports block size 32, sparsity 0.50, a prefix of 8,345 tokens, and retention of 923/1,325 key blocks. The effective retained fraction is therefore approximately 69.66%, not simply 50% of all attention, because the prefix is added to the retained portion. SLA is an attention approximation and is not claimed to be mathematically identical to dense attention.
Chunked routing limits the size of temporary score matrices. Head-wise streaming is also present in the runtime, but activates only when a threshold is exceeded; the presence of an enabled flag alone is not treated as proof that it contributed to this test. G80 does not use the experimental SLA direct-output branch.
5.3. Network-Tail Cache: G28 to the G77/G79/G80 Schedule
Each reuse step still computes the first block from the current state, then reuses the cached residual for the remaining 49 blocks before performing the necessary output computation. This is an intermediate cache inside the denoising process. It does not replay an old video or skip processing of the new prompt.
The base G28 configuration used an error criterion to decide whether reuse should occur. G80 switches to a preselected fixed schedule, continuing the G77 and G79 approach. At scheduled reuse positions, G80 bypasses the native direct/cumulative error thresholds of 0.06 used for the reuse decision, while retaining execution guards, finite-value checks, buffer ownership rules, and forced-full-compute flags.
With 50 blocks, the execution count implied by the schedule is:
No reuse: 50 × 50 = 2,500 DiT block executions
G65: 35 × 50 + 15 × 1 = 1,765 DiT block executions
G80: 30 × 50 + 20 × 1 = 1,520 DiT block executionsG80 reduces the number of DiT block executions by 39.20% relative to no reuse, or by 13.88% relative to G65. This is a reduction in block-level work, not the percentage speedup of the complete video pipeline. All 50 sampler steps still exist, but they should not be described as 50 full-network evaluations.
5.4. Exact AdaLN Precomputation
Conditioning projections that depend only on timestep are prepared once and then replayed using the exact vector for the corresponding step. In G80, this preparation phase took 29.146 seconds, retained 1,379.6 MiB in CPU RAM, and removed approximately 12.18 GiB of projection weights from the repeated offload transfer path during step execution. The 12.18 GiB figure is not simultaneous VRAM savings and is not the total data traffic for the full video.
This is a tradeoff that adds preparation work at the start of the run in exchange for less computation and transfer work during sampling. The mechanism was already present in the early baseline and is therefore not counted again in full as part of the G80 improvement.
5.5. Offload, Staged Encoder, and the G46 Prefetch Fix
The entire checkpoint does not need to reside in 24 GB of VRAM. MMGP transfers weights block by block, while the text encoder is moved off the GPU before the heavy phase. The 100 MB transformer budget is an offload-policy parameter, not a claim that the application uses only 100 MB of total VRAM.
G46 corrects block-name comparison in the loader so that already-prefetched blocks are recognized correctly, avoiding unnecessary reload processing. The fix preserves the original copy, unload, stream, and synchronization ordering. It reduces redundant work in the data-transfer path without removing model content.
5.6. RES Multistep Instead of Euler
Starting with G51, the pipeline uses the native RES multistep sampler instead of Euler while retaining 50 steps. RES uses previous-step history according to the sampler's formulation, and both image and audio continue to follow the pipeline's update schedule.
This changes the sampling trajectory and is not a bit-identical optimization of Euler. Retaining 50 steps is not enough to describe the two configurations as computationally identical. Candidate videos were shown to the user and evaluated before this option was retained.
5.7. Pointwise and RoPE Kernels
The in-place RoPE kernel reduces Q/K copies and intermediate buffers while preserving the rounding boundaries of the original BF16 path within the supported cases. It does not replace RMSNorm with a new approximation.
G59 fuses modulation and gated-residual operations by segment to reduce kernel launch count and memory read/write traffic. Branches that do not meet layout or aliasing requirements fall back to the original path. This direction references community work in the H3 Optimization Suite; the integration was adapted to preserve the numerical behavior of the runtime used by this project.
A previously measured 44 to 46% improvement for a group of pointwise operations is a microbenchmark result only. It does not mean the entire video pipeline is 44 to 46% faster.
5.8. VAE Buffer Lifetime and MLP Activation Limit
G58 releases VAE buffers earlier and keeps only the necessary overlap data, while preserving the same formula and tile configuration. The primary benefit is reduced temporary memory use during decoding.
G62 limits each MLP segment to at most 4,096 activation rows, splitting work within the native group while preserving FC1, SiLU/gate, FC2, and the existing per-row INT8 path. It does not reduce hidden width, remove neurons, or lower resolution. The G62 video was verified to have byte-identical decoded image and audio output compared with its corresponding control.
The isolated MLP test reduced temporary memory by approximately 403.2 MiB. In the historical full-video comparison from G59 to G62, runtime decreased by only 1.38%. The temporary-buffer result is not converted into a claim of a proportional reduction in total VRAM use.
5.9. Supporting Caches That Must Be Distinguished
Reference-image encoder caches and compiled-kernel caches can benefit later runs when conditions match. However, the G80 log records cache misses for all four reference images in both the VAE and vision encoder. Image caching therefore is not used as an explanation for the speed of this run. Warm/cold compiled-kernel cache conditions were also not paired across all baselines.
G80 does not stack obsolete INT8 backends that were replaced, does not use Turbo LoRA at 4 or 8 steps, does not use a reduced model, does not render at lower resolution and upscale afterward, and does not include post-G80 experiments that were not accepted.
6. Exact Cache Schedule for Comparison
The indices below are zero-based for the 50-step RES test:
FULL = [0,1,2,3,4,5,6,7,8,9,11,12,13,15,17,19,21,23,25,28,
32,35,39,41,43,44,45,47,48,49]
REUSE = [10,14,16,18,20,22,24,26,27,29,30,31,33,34,36,37,38,
40,42,46]Compared with G79, G80 adds reuse at steps 30 and 37, creating two three-step reuse sequences at 29 to 31 and 36 to 38. No four-step sequence is allowed. Structural points 0, 5, 45, and 49 remain full-compute steps.
The schedule was selected using earlier calibration on Prompt 2, followed by candidate-video runs on Prompt 1. For the third reuse in a sequence, the selection criterion used the sum of lag-2 and lag-1 error as a heuristic. Direct lag-3 error was not measured on the new trajectory, so this is not a proven error bound. The initial numerical screening did not pass; later acceptance was based on a pair of videos viewed by the user and does not retroactively change the numerical screening result to “passed.”
The schedule can be rerun without recalibrating on every launch, but there is no evidence that it preserves quality across every prompt, reference image/video, duration, or step count. The accompanying JSON is a research configuration record, not a preset that can be dropped into unmodified Wan2GP to obtain G80 automatically. The corresponding patches and schedule controller are also required.
7. VRAM, Temperature, and Quality
G80 recorded the following highest values from nvidia-smi samples taken approximately every 30 seconds:
Total GPU memory in use
Value: 10,638 MiB, approximately 10.39 GiB
GPU utilization
Value: 100%
GPU temperature
Value: 81°C
GPU power
Value: 447.01 W
These figures represent total GPU measurements and may include other processes. They are not the H3 allocator's dedicated peak values. Sparse sampling can miss short-lived peaks. The early baseline used denser sampling, so the two reported “peak” figures are not used to publish a precise VRAM-reduction percentage. The G80 run also does not have an equivalent process-level peak RAM measurement from which a minimum RAM requirement could be derived.
No card-wide power limit or fan setting was changed for this test. The shorter processing time does not demonstrate a lower temperature, and there is no paired energy measurement supporting a claim of reduced power consumption.
Based on direct visual inspection, Singularity G65 produced clearly better quality than the original model in the test scene, while G80 continued to maintain usable quality in the compared video pair. This is a subjective assessment within the scope of the test, not an objective benchmark score or a guarantee that quality is unchanged across every scene. INT8, SLA, sampler choice, and caching can all alter the result. A byte-level difference does not automatically imply worse visual quality, but it also does not prove equivalent quality.
8. Cross-Check Data and References
For configuration cross-checking, the report package includes G80-cau-hinh-va-so-lieu.json and G80-thoi-gian.csv, containing raw timing data, formulas, the cache schedule, prompt/image/checkpoint hashes, environment information, and source-record hashes. The package does not separately include the reference images, model weights, or the complete patch set, so it is a traceable report with supporting data, not a fully self-contained reproduction package.
Checkpoint SHA-256:
551915097b8727537a82f3a2c5acec965165ec84e780b3e9a5f28ce867fddf08G80 video SHA-256:
6753fd5e620dfabf5f354f99832d79546843452260b75dcb7980a7234a8e62d3The execution log confirms that Kitchen ran on CUDA, that 50 dispatches executed with 30 full and 20 reuse passes, and that the effective attention configuration was active. The hashes of the measurement records are stored in the accompanying JSON for source-data verification.
Community sources are credited by role: MiniMax provides the base model; the Singularity author provides the checkpoint; Wan2GP/MMGP provide the pipeline and offload system; Comfy Kitchen provides kernels; and community H3 optimization authors provide reference code and ideas. The project's contribution consists of selecting, adapting, combining, testing, and measuring these components on this machine. All timing figures in this report are local measurements and are not taken from advertising claims or converted from benchmarks on other hardware.