Which is Better: FP8_scaled or MXFP8? A Thorough Comparison of Image Generation AI Model Accuracy and Speed!
- Image Quality: FP32 > FP16 ≒ BF16 > MXFP8 > FP8_scaled > NVFP4 > FP8
- Faster when the model can be loaded into VRAM
- Use formats supported by your GPU
2026.7.6 Update
At the end of the article, I have added a comparison with the newly supported INT8_ConvRot format in ComfyUI.
The INT8_ConvRot format outperforms all existing FP8 and FP4 formats in both accuracy and speed. Therefore, I now recommend using the INT8_ConvRot format instead of FP8 going forward.
Introduction
Hello, this is Easygoing.
This time, we're taking a look at the formats, accuracy, and speed of image generation AI models.
AI Models Process Using Floating-Point Formats
AI models, including image generation AIs, perform massive computations using floating-point formats.
Floating-Point Formats
(-1)sign bit × 2exponent × mantissa
| Format | Sign Bit | Exponent | Mantissa | Significant Digits |
|---|---|---|---|---|
| FP32 | 1 bit | 8 bits | 23 bits | 6–7 digits |
| FP16 | 1 bit | 5 bits | 10 bits | 3–4 digits |
| BF16 | 1 bit | 8 bits | 7 bits | 3 digits |
| FP8 | 1 bit | 4 bits | 3 bits | 1–2 digits |
| FP4 | 1 bit | 2 bits | 1 bit | Less than 1 digit |
Floating-point formats have a wide dynamic range, which makes processing stable. They also allocate more bits to the frequently occurring values near 0, resulting in relatively good precision.
gantt
title Quantization Timeline
dateFormat YYYY-MM-DD
axisFormat %Y
section IEEE 754
FP16 : 2008-08-01, 2026-06-10
section Google
BF16 : 2018-05-01, 2026-06-10
section OCP / NVIDIA
FP8 : 2022-09-01, 2026-06-10
FP8_scaled : 2022-09-01, 2026-06-10
MXFP8 : 2023-10-17, 2026-06-10
NVFP4 : 2024-03-18, 2026-06-10Since its standardization in 1985, the 32-bit floating-point format (FP32) has been the primary format used. However, as AI research advanced in the 2010s, lighter formats like FP16 and BF16 also came into use.
List of Floating-Point Formats Supported by GPUs!
Let's take a look at the floating-point formats supported by NVIDIA, AMD, and Intel GPUs.
gantt
title GPU Series Roadmap
dateFormat YYYY-MM-DD
tickInterval 12month
axisFormat %Y
section NVIDIA
GTX 1000 : 2016-05-27, 2026-06-10
RTX 2000 : 2018-09-20, 2026-06-10
RTX 3000 : 2020-09-17, 2026-06-10
RTX 4000 : 2022-10-12, 2026-06-10
RTX 5000 : 2025-01-30, 2026-06-10
section AMD
RX 5000 : 2019-07-07, 2026-06-10
RX 6000 : 2020-11-18, 2026-06-10
RX 7000 : 2022-12-13, 2026-06-10
RX 9000 : 2025-03-06, 2026-06-10
section Intel
Arc A : 2022-03-30, 2026-06-10
Arc B : 2024-12-13, 2026-06-10| FP32 | FP16 | BF16 | FP8 | FP8_scaled | MXFP8 | FP4 | |
|---|---|---|---|---|---|---|---|
| NVIDIA | |||||||
| RTX 5000(Blackwell) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| RTX 4000(Ada Lovelace) | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
| RTX 3000(Ampere) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| RTX 2000(Turing) | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| GTX 1000(Pascal) | ✅ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ |
| AMD | |||||||
| RX 9000 (RDNA4) | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
| RX 7000 (RDNA3) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| RX 6000 (RDNA2) | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| RX 5000 (RDNA1) | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| Intel | |||||||
| Arc B (Battlemage) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Arc A (Alchemist) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
- FP32: High precision, high cost
- FP16: Good balance between precision and speed
- BF16: More stable than FP16, but slightly lower precision
- FP8: Half the size of FP16/BF16, but significantly lower precision
- FP8_scaled: Uses scaling to mitigate the precision loss of FP8
- MXFP8: Divides data into blocks of 32 and applies scaling per block for further precision improvements
- NVFP4: Uses two-stage scaling to maintain minimum viable precision even with 4-bit
FP32 is a format that can run on all devices.
FP16 uses half the memory of FP32 while maintaining practically usable precision.
BF16 improves stability at the cost of some precision compared to FP16 and is often used during model training or VAE processing.
FP8 uses half the memory of FP16/BF16 but suffers a major drop in precision.
To address this, FP8_scaled applies scaling based on the absolute maximum value per layer to reduce precision loss. It can be used on all GPUs that support FP8.
Furthermore, MXFP8 divides each model layer into blocks of 32 data points and applies finer-grained scaling. This minimizes the impact of outliers and further improves precision, but it is only supported on RTX 5000 series GPUs.
NVFP4 is a new format introduced in 2025. It performs computations with low-precision 4 bits but maintains minimum viable accuracy through two-stage scaling.
Let's Compare Actual Image Quality!
Now, let's compare the actual image quality.
For this comparison, we used the simple UiT architecture model HiDream-O1-Image_clear_v1 without external Text Encoders or VAEs.
About the HiDream-O1-Image_clear_v1 Model
The HiDream-O1-Image series is still not great at anime-style illustrations, so this time we generated realistic-style illustrations.
Actual Generated Images
Let's take a look at the actual images.
FP32
First is the highest-precision FP32 format illustration.
Since the HiDream-O1-Image model uses a VAE-free UiT architecture, it produces more natural color representation compared to conventional models.
We will use this FP32 result as the baseline. On the left is the image generated with the respective format, and on the right is the difference map compared to FP32.
FP16
First up for comparison is the FP16 format.
Compared to FP32, there are differences in the character's outlines and clothing patterns, but the color expression remains good and overall quality is well maintained.
BF16
Next is the BF16 format.
Similar to FP16, there are differences in outlines and clothing patterns, but quality remains high.
MXFP8
Next, let's look at MXFP8, which offers the best precision among 8-bit formats.
Compared to BF16, there are changes in the background flowers, but overall quality is relatively well preserved.
FP8_scaled
Next is FP8_scaled.
FP8_scaled shows more degradation than MXFP8, with lost color depth resulting in a grayish expression.
FP8
Next is plain FP8.
The FP8 format produces a completely different simplified composition and exhibits noticeable block noise, resulting in an unfinished-looking illustration.
NVFP4
Finally, NVFP4.
Compared to plain FP8, the structure is better preserved, but the color tones change dramatically.
Quantifying Differences with MAE and SSIM!
Now let's compare the differences numerically.
This time, we evaluate changes from the FP32 baseline using MAE and SSIM similarity metrics.
- Mean Absolute Error (MAE): Primarily detects color differences
- Structural Similarity Index (SSIM): Detects structural differences in black-and-white (luminance/contrast)
We generated each format 7 times, compared them to the highest-precision FP32, and used the median values.
Image Generation AI Model Size vs. Precision
| vs_FP32 | MAE_Similarity | SSIM_Similarity | Size |
|---|---|---|---|
| FP32 | 100% | 100% | 35.2 GB |
| FP16 | 92.7 % | 87.6 % | 17.6 GB |
| BF16 | 92.6 % | 87.5 % | 17.6 GB |
| MXFP8 | 92.0 % | 83.8 % | 10.3 GB |
| FP8_scaled | 91.6 % | 84.8 % | 10.1 GB |
| FP8 | 85.8 % | 59.1 % | 8.8 GB |
| NVFP4 | 87.2 % | 71.9 % | 6.8 GB |
- Model size and image quality are roughly proportional
- FP16 and BF16 have nearly identical precision
- FP8 shows degraded quality, but MXFP8 and FP8_scaled maintain precision quite well
- NVFP4 offers better quality than plain FP8
Model size and image quality are generally proportional.
From the graph, plain FP8 suffers a major drop in precision, but MXFP8 and FP8_scaled maintain considerable quality by using scaling to preserve important information.
NVFP4 achieves quality comparable to 4-bit, but scaling still helps it outperform plain FP8.
Floating-Point Formats and Precision Ranking
In this measurement, the precision ranking was as follows:
- FP32 > FP16 ≒ BF16 > MXFP8 > FP8_scaled > NVFP4 > FP8
Generation Time Comparison
In the second half, we compare generation times.
First, here are the measurement conditions used this time.
Test Environment
- Linux (Pop!_OS 24.04)
- ComfyUI 0.24.0
- RTX 4060 Ti 16GB
- 2048 x 2048 resolution, 24 steps
Windows vs Linux Generation Speed Comparison
GPU-Supported Floating-Point Formats
| FP32 | FP16 | BF16 | FP8 | FP8_scaled | MXFP8 | FP4 | |
|---|---|---|---|---|---|---|---|
| NVIDIA | |||||||
| RTX 5000(Blackwell) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| RTX 4000(Ada Lovelace) | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
| RTX 3000(Ampere) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| RTX 2000(Turing) | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| GTX 1000(Pascal) | ✅ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ |
| AMD | |||||||
| RX 9000 (RDNA4) | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
| RX 7000 (RDNA3) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| RX 6000 (RDNA2) | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| RX 5000 (RDNA1) | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| Intel | |||||||
| Arc B (Battlemage) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Arc A (Alchemist) | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
The RTX 4060 Ti used in this test supports formats from FP32 down to FP8_scaled. However, it does not support MXFP8 or NVFP4, so it falls back to BF16.
Actual Generation Times
Here are the results.
As before, we ran 7 measurements for each format and used the median.
Illustration Generation Time
| Generation_Time | Time (sec) | Size |
|---|---|---|
| FP32 | 371.2 | 35.2 GB |
| FP16 | 98.6 | 17.6 GB |
| BF16 | 96.0 | 17.6 GB |
| MXFP8 | 112.8 | 10.3 GB |
| FP8_scaled | 73.6 | 10.1 GB |
| FP8 | 92.0 | 8.8 GB |
| NVFP4 | 90.7 | 6.8 GB |
Image generation speed is largely determined by whether the model can be loaded into VRAM.
The HiDream-O1-Image model can be fully loaded into VRAM with FP16 / BF16 and lower formats, enabling fast processing.
For MXFP8 and NVFP4, which the RTX 4000 series does not support, the fallback processing actually made generation slower. There is almost no benefit to running the latest formats on unsupported GPUs.
Additionally, the FP8_scaled used this time is a ComfyUI-specific format, which processed quickly. However, FP8 converted with external tools was not properly recognized by ComfyUI and fell back to BF16, resulting in slower performance.
When ComfyUI-specific FP8_scaled is available, it's recommended to use the FP8_scaled model.
The Optimal Format Depends on Your GPU
On the RTX 4060 Ti 16GB, FP16 and FP8_scaled offered the best balance of image quality and speed.
RTX 5000 series → MXFP8
Illustration generation speed varies greatly depending on VRAM capacity and the floating-point formats your GPU supports. When multiple formats are available, try them out to find your personal optimum.
UiT Architecture Shows Larger Changes
This time we tested with the HiDream-O1-Image model using the UiT architecture. Compared to the previously tested Flux.1 [dev], the changes caused by model format were much more pronounced.
- HiDream-O1-Image: UiT architecture, base model
- Flux.1 [dev]: ViT architecture, distilled model
Flux.1 [dev] Model Format and Precision Comparison
This is likely because HiDream-O1-Image is a base model with the UiT architecture, whereas Flux.1 [dev] is a distilled model with ViT architecture. During distillation, outputs were probably constrained to a certain range to prevent collapsing in VAE post-processing.
The UiT architecture, with its simple structure, allows for various adjustments, making it a model with a flexible "brain".
Summary: Size and Quality Are Proportional
- Image Quality: FP32 > FP16 ≒ BF16 > MXFP8 > FP8_scaled > NVFP4 > FP8
- Faster when the model can be loaded into VRAM
- Use formats supported by your GPU
This time, we compared floating-point formats of models with respect to image quality and generation speed.
There are many floating-point formats, and choosing one can be confusing, but we confirmed that model size and image quality are proportional.
New formats like MXFP8 and NVFP4 offer excellent balance between precision and speed compared to traditional formats. They are great choices for high-speed generation on the latest GPUs.
I plan to continue conducting original tests on image quality and speed in image generation AI.
Thank you for reading until the end!
2026.7.6 Update: Comparison with INT8_ConvRot
On July 1, 2026, ComfyUI officially added support for the INT8_ConvRot format. Let's compare it with previous floating-point formats.
FP32 vs INT8_ConvRot_HQ
Image Quality
| vs_FP32 | MAE_Similarity | SSIM_Similarity | Size |
|---|---|---|---|
| FP32 | 100% | 100% | 35.2 GB |
| FP16 | 92.7 % | 87.6 % | 17.6 GB |
| BF16 | 92.6 % | 87.5 % | 17.6 GB |
| MXFP8 | 92.0 % | 83.8 % | 10.3 GB |
| FP8_scaled | 91.6 % | 84.8 % | 10.1 GB |
| FP8 | 85.8 % | 59.1 % | 8.8 GB |
| NVFP4 | 87.2 % | 71.9 % | 6.8 GB |
| Int8_ConvRot_HQ | 92.6 % | 88.6 % | 10.6 GB |
Generation Speed
| Generation_Time | Time (sec) | Size |
|---|---|---|
| FP32 | 371.2 | 35.2 GB |
| FP16 | 98.6 | 17.6 GB |
| BF16 | 96.0 | 17.6 GB |
| MXFP8 | 112.8 | 10.3 GB |
| FP8_scaled | 73.6 | 10.1 GB |
| FP8 | 92.0 | 8.8 GB |
| NVFP4 | 90.7 | 6.8 GB |
| Int8_ConvRot_HQ | 53.9 | 10.6 GB |
INT8_ConvRot_HQ is a custom model by the author that keeps the first and last layers (which have a large impact on image quality) in FP16 in addition to INT8_ConvRot Format.
The INT8_ConvRot_HQ format is superior in both precision and speed compared to all existing FP8 and FP4 formats. Therefore, I recommend using INT8_ConvRot instead of FP8 going forward.
Library Used for Conversion
Conversion Command
ctq -i HiDream-O1-Image_clear_v1_FP16.safetensors
-o HiDream-O1-Image_clear_v1_INT8_ConvRot_HQ.safetensors
--int8 --scaling_mode row
--convrot --convrot-group-size 64
--calib_samples 8192
--comfy_quant --save-quant-metadata --verbose VERBOSE
--exclude-layers "norm|bias|embed_tokens|pos_embed|patch_embed|t_embedder|x_embedder|lm_head|final_layer2|language_model.layers.(0|1|2|33|34|35).|visual.blocks.(0|1|2|24|25|26).|visual.blocks.d+.mlp.linear_fc2"Workflow & Measurement Data
Workflow
The workflow used for this measurement is here.
Measurement Data
All actual measurement data is summarized on the following page.