The 40.23 GB BF16 checkpoint becomes either a 12.53 GB NVFP4 or 20.96 GB FP8 single-file ComfyUI diffusion model. Both were baked and inference-tested on one 16 GB NVIDIA Blackwell GPU.

This is the merged Turbo-hybrid beta3 model, not a LoRA. Do not apply the raw H3 Turbo LoRA again.

Files

Quant	File	Size	SHA-256
NVFP4	`10Eros_Max_h3_TURBO-hybrid_beta3_nvfp4.safetensors`	12,531,404,184 bytes	`f5706760e77efc4713661de968f08d31330c9cb4b270bc51d837bd6faa588438`
FP8 E4M3FN	`10Eros_Max_h3_TURBO-hybrid_beta3_fp8_e4m3fn.safetensors`	20,960,951,848 bytes	`6d0512d428e201254dfd00967cd558c4070581079692c2c685a5486216b1c0d3`

Choose NVFP4 first for a 16 GB Blackwell card. The FP8 file is provided for comparison, other hardware/software configurations, and future kernel improvements; it requires model offloading on a 16 GB card in the tested configuration.

The safetensors metadata contains only format and quantization descriptors. No prompts, local paths, generation data, or user metadata are embedded.

Quantization recipes

NVFP4

The conversion follows the native ComfyUI layout published for sakamakismile/10Eros-Max-beta2-NVFP4:

read the 200 layers carrying .comfy_quant from the known-good beta2 NVFP4 layout;
quantize exactly those corresponding BF16 Turbo-beta3 matrices with ComfyUI's TensorCoreNVFP4Layout;
retain the remaining tensors without quantization;
preserve TenStrip's Turbo graft tensors: adaln_basis, adaln_mean, and silu_t_emb_grid.

Structural verification of this file:

200/200 target matrices quantized;
1,135 tensors total;
zero missing tensors versus the beta2 NVFP4 reference;
zero dtype or shape mismatches among the 1,132 shared tensors;
three expected Turbo graft tensors in addition to the reference layout.

FP8 E4M3FN

The FP8 conversion uses the same 200-matrix layer policy as the NVFP4 file and ComfyUI's native TensorCoreFP8E4M3Layout:

200/200 target matrices stored as FP8 E4M3FN;
200 FP32 per-matrix weight scales;
335 remaining tensors preserved as BF16;
935 tensors total;
no runtime BF16-to-FP8 cast is required when loading this file with weight_dtype=default.

Source checkpoint revision: 6669e9c91c31a2d4400592a9f5599d9a305b1f57

Source BF16 SHA-256: ea0df6670a84dfe594fe12c1202dfd82a497dbf2a75d6f06279a6b6993ab64b2

ComfyUI installation

Place the model in:

text

ComfyUI/models/diffusion_models/
├── 10Eros_Max_h3_TURBO-hybrid_beta3_nvfp4.safetensors
└── 10Eros_Max_h3_TURBO-hybrid_beta3_fp8_e4m3fn.safetensors

Only one diffusion checkpoint is required. Load the chosen file with ComfyUI's UNETLoader and leave weight_dtype at default.

The H3 text encoder and VAEs are not duplicated here. Download the companion files from Comfy-Org/MiniMax-H3:

text

ComfyUI/models/text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
ComfyUI/models/vae/minimax_h3_video_vae_fp16.safetensors
ComfyUI/models/vae/minimax_h3_audio_vae_fp32.safetensors

Use ComfyUI's native MiniMax H3 nodes. The official I2V workflow is a suitable starting point.

Recommended Turbo settings

For longer I2V clips, start with the following six-step recipe:

Setting	Value
Model loader	`UNETLoader`
CLIP loader type	`minimax`
Video sigma shift	`12.0`
Audio sigma shift	`3.0`
Sampler	`er_sde`
Scheduler	`simple`
Steps	6
Runtime video LoRA	None

TenStrip also documents multires/simple at six steps and a custom seven-transition sigma schedule. The custom schedule produced a good 124-frame smoke test here, but progressive hue drift and anatomy instability appeared in multiple 243-frame clips. Switching the same merged checkpoint to er_sde/simple at six steps removed those recurring failures in a 28-scene local batch. Treat this as hardware- and prompt-specific field evidence, not a universal benchmark. See the 10Eros-Max model card for all upstream recipes.

Validation

The initial local quality gate used:

NVIDIA GeForce RTX 5070 Ti, 16 GB;
ComfyUI native H3 workflow;
768 × 1344 first-frame I2V;
124 generated frames at 24 FPS with native stereo audio;
seven denoising transitions;
151.961 seconds of prompt execution.

The resulting clip was structurally coherent across a 10-frame temporal contact sheet and did not show the mosaic/crawling failure observed when a raw Turbo adapter was incorrectly patched onto an already-quantized beta2 checkpoint. This is a limited single-clip smoke test, not a broad quality benchmark.

A subsequent longer-form I2V batch used:

the same RTX 5070 Ti and merged NVFP4 checkpoint;
28 independent scenes at 768 x 1344 and 24 FPS;
one 243-frame H3 generation per scene, trimmed to 240 frames (10 seconds);
er_sde with the simple scheduler at six steps;
no runtime video LoRA.

All 28 generations completed. Median per-scene generation time was 276.9 seconds; the 95th percentile was 354.2 seconds. The assembled result contained 6,720 video frames (280 seconds). Midpoint and near-end contact sheets did not show the project-wide progressive red-hue failure seen with the custom seven-transition schedule. Visual judgments remain subjective and prompt-dependent.

A second independent 28-scene project completed with the same profile. Its H3 calls ranged from 170.36 to 308.39 seconds and averaged 244.11 seconds. Across the first project, calls ranged from 172.54 to 435.42 seconds. These end-to-end times include model initialization and VAE decode, not just denoising. Initialization varied from roughly 15 to 177 seconds; once initialized, NVFP4 denoising generally held near 14 seconds per step. Video VAE decode was the largest and most variable phase because components spilled into shared system memory.

Resolution, duration, and recipe findings

Configuration	Scope	Result
768 x 1344, 243 generated frames, trim to 240 / 10 seconds, `er_sde/simple`, 6 steps, NVFP4	Two full 28-scene projects	Worked: 56/56 scenes completed; no project-wide red-hue failure in sampled midpoint/end frames
768 x 1344, 124 frames, custom seven-transition schedule, NVFP4	One short smoke test	Worked as a smoke test: visually clean, 151.961 seconds end-to-end; did not predict longer-clip stability
768 x 1344, longer 243-frame clips, custom seven-transition schedule, NVFP4	Multiple diagnostic clips	Did not work reliably: progressive red hue, unnaturally fast motion, and anatomy instability appeared
Same longer custom-schedule test with default PyTorch attention	Diagnostic control	Did not fix the issue: established that attention selection was not the root cause
768 x 1344, 243 frames, `er_sde/simple`, 6 steps, FP8	One controlled 10-second render	Worked: completed and remained coherent in sampled frames; slower than NVFP4 and not batch-validated
Other resolutions or single H3 calls longer than 243 frames	Not controlled here	Untested: do not infer failure or compatibility from this card

MiniMax H3 uses a 17k+5 frame grid. Generating 243 frames and trimming to 240 produced an exact 10.000-second delivery at 24 FPS while keeping the model request on that grid. The only extensively validated resolution in this test is vertical 768 x 1344; this is not evidence that other H3-supported resolutions are worse.

Controlled attention benchmark (NVFP4)

Each arm below used a fresh ComfyUI process and the same image, prompt, seed, 768 x 1344 resolution, 243-frame request, er_sde/simple six-step schedule, text encoder, and VAEs.

Rank	Attention configuration	Diffusion	End-to-end	Relative to default	Result
1	Sol + Sage fallback, tau 1.25	84 s	182.964 s	3.53x faster	Completed
2	Sol + Kitchen fallback, tau 1.25	84 s	185.119 s	3.49x faster	Completed
3	Native Kitchen	224 s	332.745 s	1.94x faster	Completed
4	Default PyTorch	542 s	646.328 s	baseline	Completed
5	Native Sage	264.60 s for step 1	Not continued	Worse than default	Bounded after one step

Native Sage projected approximately 26:28 for diffusion if its measured first-step rate held, so the remaining five steps were not run. Both Sol arms routed all 251 attention calls through Sol with zero fallback calls. Their 2.155-second end-to-end difference is ordinary single-run variation, not evidence that Sage fallback is faster. Kitchen is the recommended fallback because native Kitchen completed while native Sage was impractical on this setup.

Controlled NVFP4 versus FP8 speed check

A controlled 243-frame comparison reused the same starting image, prompt, seed, 768 x 1344 resolution, six-step schedule, text encoder, VAEs, and Sol+Kitchen attention configuration. The delivered outputs were trimmed to exactly 240 frames / 10 seconds.

Quant	Diffusion	End-to-end	Comfy staged model size
NVFP4	84 seconds	185.119 seconds	11,944 MB
FP8 E4M3FN	138 seconds	247.722 seconds	19,983 MB

The FP8 checkpoint loaded directly in its baked mixed-precision layout. On this 16 GB system it was slower because its approximately 20 GB staged footprint required substantially more offloading. This is a practical single-system result, not a claim that NVFP4 kernels are universally faster than FP8.

For this exact hardware/software profile, the practical recommendation is NVFP4 + Sol with Kitchen fallback, tau 1.25. FP8 is functional and may behave differently on cards with more VRAM or under future kernels, but it offered no speed advantage on the tested 16 GB card.

Hardware compatibility

The NVFP4 file is a native Tensor Core layout intended for NVIDIA Blackwell GPUs. The FP8 file uses ComfyUI's native E4M3FN layout. Both were tested only on an RTX 5070 Ti with a CUDA 13 / PyTorch 2.11 ComfyUI environment. Other GPU architectures and software versions are untested.

Limitations and responsible use

This repository contains only the quantized diffusion model; the encoder and VAEs are separate downloads.
Quantization can change output details relative to BF16.
The upstream model is adult-capable and may produce explicit material. Follow applicable law, platform rules, consent requirements, and the upstream licenses. Never use it for abusive, exploitative, deceptive, or non-consensual content.
No training data, generated media, prompts, or personal information are included in this repository.

Licenses and attribution

The MiniMax H3 Community License Agreement applies.

This is a quantization of TenStrip/10Eros-Max. As stated by TenStrip, the applicable community licenses for the character donor models (LTX 2.3, Wan 2.2, and Krea 2) also apply to the portions transferred from those models. Quantization does not alter those terms.

Credits:

MiniMaxAI/MiniMax-H3 — base architecture and weights;
TenStrip/10Eros-Max — 10Eros-Max and merged Turbo-hybrid beta3 checkpoint;
silveroxides/MiniMax-H3_tests — upstream Turbo work credited by TenStrip;
sakamakismile/10Eros-Max-beta2-NVFP4 — native NVFP4 layer-layout recipe.

JCorcho/10Eros-Max-TURBO-hybrid-beta3-NVFP4

10Eros-Max TURBO-hybrid beta3 — ComfyUI quants