Downloads · 30 days
0
JCorcho/10Eros-Max-TURBO-hybrid-beta3-ComfyUI-Quants
10Eros-Max-TURBO-hybrid-beta3-ComfyUI-Quants is a image-to-video model from JCorcho. Use it for the image-to-video task on the model card, and read the license before you ship it in a product. It is set up for comfyui. The card lists the license as other.
Native NVFP4 and FP8 conversions of TenStrip's merged 10ErosMaxh3TURBO-hybridbeta3.safetensors.
Downloads · 30 days
0
Access
Public
Updated Aug 26, 2026
Repo size
33.5 GB
Likes
2
Public
Click a slice to open those files.
.safetensors33.5 GB · 100%
From the Hugging Face model README
Native NVFP4 and FP8 conversions of TenStrip's merged
10Eros_Max_h3_TURBO-hybrid_beta3.safetensors.
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.
| 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.
The conversion follows the native ComfyUI layout published for
sakamakismile/10Eros-Max-beta2-NVFP4:
.comfy_quant from the known-good beta2 NVFP4 layout;TensorCoreNVFP4Layout;adaln_basis, adaln_mean, and silu_t_emb_grid.Structural verification of this file:
The FP8 conversion uses the same 200-matrix layer policy as the NVFP4 file and ComfyUI's native TensorCoreFP8E4M3Layout:
weight_dtype=default.Source checkpoint revision: 6669e9c91c31a2d4400592a9f5599d9a305b1f57
Source BF16 SHA-256: ea0df6670a84dfe594fe12c1202dfd82a497dbf2a75d6f06279a6b6993ab64b2
Place the model in:
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:
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.
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.
The initial local quality gate used:
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:
er_sde with the simple scheduler at six steps;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.
| 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.
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.
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.
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.
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.