The modeling and quantization method called INT8 ConvRot, which was natively supported in ComfyUI v0.27.0 released on July 1, 2026, is a hot topic.
It is particularly beneficial for the GeForce RTX 20/30 series, but it has also been reported to provide performance exceeding the previously standard FP8 and FP8 Scaled formats on the GeForce RTX 40/50 series as well.
Because of this, it is said that INT8 ConvRot will become the standard for all 8-bit quantized models, and support is actually being advanced by Comfy-Org.
Since information has not yet spread widely and many people are misunderstanding or confusing it, I will organize and explain it in this article.
2026/7/7: Added that Forge Neo now supports INT8 ConvRot
2026/7/6: Added information regarding Kimama-san's INT8 ConvRot evaluation results
2026/7/5: Added information about GGUF in "Classification of Modeling Methods and Formats"
2026/7/5: Added information about Triton and PyTorch in "How to use INT8 ConvRot"
AI Model Storage Formats
Before explaining INT8 ConvRot, I will explain the basics of AI model storage formats.
Modeling and Quantization
AI models are modeled in FP32, a 32-bit FLOAT type, for maximum precision in a general range, but since even SDXL results in a large file size of 12GB, they are converted to reduce the bit count to 16-bit, 8-bit, or in some cases 4-bit.
The smaller the bit count, the smaller the file size, making it easier to handle and faster to process. However, because the number of representable values decreases and precision drops, methods and formats to minimize the impact on precision and results are used as much as possible.
Classification of Modeling Methods and Formats
The table below roughly classifies the modeling methods and formats of AI models.
$$
\begin{array}
{l|l|l}
\bf{階層} & \bf{例} & \bf{役割} \\
\hline
\text{ファイル形式} & \text{safetensors, GGUF,} & \text{保存するコンテナ} \\
& \text{ONNX} & \\
\hline
\text{符号化方式} & \text{FP16, BF16,} & \text{数値をbit列で表現する方法} \\
& \text{INT8, FP8, FP4} & \\
\hline
\text{スケーリング} & \text{なし, Tensor-wise,} & \text{値の範囲を調整する方法} \\
\text{方式} & \text{Row-wise} & \\
\hline
\text{量子化方式} & \text{RTN, AWQ,} & \text{低精度へ変換するアルゴリズム} \\
& \text{GPTQ, ConvRot} & \\
\end{array}
$$
I searched for such a classification table on the Web but could not find one, so I created it while Q&A-ing with ChatGPT for my own understanding. It might be rough or have inappropriate terminology, but since I had it corrected many times, I believe the general classification is correct.
2026/7/5 update: GGUF is not just a file format but also specifies a storage method for quantized data such as Q4_K_M, so it cannot be organized in the classification table above.
Since this article does not touch on GGUF, I will stick to the classification in the table above so as not to complicate the organization.
By the way, in a broad sense, modeling with these methods and formats is sometimes collectively called "quantization," but in this article, I will call it "modeling" and refer to the algorithm for converting to low precision as a "quantization method."
Note that there are countless sites that explain individual methods and formats in detail, so I will not explain them in this article. If necessary, please look them up elsewhere or ask an AI.
Regarding FLOAT types, Kimama-san's article is detailed.
Representative Model Formats and INT8 ConvRot
Based on the classification table mentioned above, representative model formats including INT8 ConvRot are organized as follows.
16-bit models
$$
\begin{array}
{l|l|l}
\bf{階層} & \bf{FP16} & \bf{BF16} \\
\hline
\text{符号化方式} & \text{FP16} & \text{BF16} \\
& & \text{(Brain FP16)} \\
\hline
\text{スケーリング} & \text{なし（固定）} & \text{なし（固定）} \\
\text{方式} & & \\
\hline
\text{量子化方式} & \text{RTN} & \text{RTN} \\
\\
\end{array}
$$
8-bit INT type models
$$
\begin{array}
{l|l|l|l}
\bf{Layer} & \bf{INT8} & \bf{INT8} & \bf{INT8} \\
& & \bf{Tensor} \text{-} \bf{wise} & \bf{ConvRot} \\
\hline
\text{Encoding Method} & \text{INT8} & \text{INT8} & \text{INT8} \\
\\
\hline
\text{Scaling} & \text{None (Fixed)} & \text{Tensor-wise} & \text{Row-wise} \\
\text{Method} & & & \\
\hline
\text{Quantization Method} & \text{RTN} & \text{RTN} & \text{ConvRot} \\
\\
\end{array}
$$
8-bit FLOAT model
$$
\begin{array}
{l|l|l|l}
\bf{Layer} & \bf{FP8} & \bf{FP8\ Scaled} & \bf{MXFP8} \\
\hline
\text{Encoding Method} & \text{FP8} & \text{FP8} & \text{FP8} \\
& \text{(E4M3/E5M2)} & \text{(E4M3/E5M2)} & \text{(E4M3/E5M2)} \\
\hline
\text{Scaling} & \text{None (Fixed)} & \text{Tensor-wise, etc.} & \text{Single-layer} \\
\text{Method} & & & \text{Microscaling} \\
\hline
\text{Quantization Method} & \text{RTN} & \text{RTN} & \text{RTN} \\
\\
\end{array}
$$
4-bit model
$$
\begin{array}
{l|l|l}
\bf{Layer} & \bf{NVFP4} & \bf{MXFP4} \\
\hline
\text{Encoding Method} & \text{FP4 (E2M1)} & \text{FP4 (E2M1)} \\
\\
\hline
\text{Scaling} & \text{Layered} & \text{Single-layer} \\
\text{Method} & \text{Microscaling} & \text{Microscaling} & \\
\hline
\text{Quantization Method} & \text{RTN} & \text{RTN} \\
\\
\end{array}
$$
INT8 ConvRot is a format modeled using INT8 encoding and a quantization method called ConvRot By comparing it with tables of other formats, you should be able to understand the differences in methods for each layer.
And just as FP8, FP8 Scaled, and MXFP8 are different, INT8 ConvRot is also a different format from existing model formats like INT8 or INT8 Tensor-Wise. Many people confuse these.
Note that this classification is rough, and there are even more detailed classifications and methods. Multiple formats are also distributed for INT8 ConvRot. (Described later)
What is INT8 ConvRot?
ConvRot is a model format that uses the technology from the following paper published on 2025/12/3.
Technically, it can be combined with FLOAT types as well as INT types, but it is specifically aimed at solving the weaknesses of INT types in AI modeling.
In the first place, INT types (integer types) have a narrower range of representable values compared to FLOAT types (floating-point types), and there was a problem where "outliers" in AI model processing degraded accuracy. This is why INT8 format models have hardly been used until now, and FP8 format has been used instead.
In simple terms, ConvRot is a method of Convolution (local block processing like convolution) and Rotation (group-based rotation transformation) to distribute outliers across multiple dimensions, converting them into a value distribution that is not problematic even for INT types.
As a result, it has achieved performance that not only avoids problems but actually surpasses FLOAT model formats.
How to use INT8 ConvRot
INT8 ConvRot can be used in ComfyUI or Forge Neo.
Added on 2026/7/5: Information is confusing and requirements are unclear, but installing Triton might be necessary to obtain the best processing speed. It is also recommended to update Nvidia drivers and PyTorch to the latest versions possible, and it seems better to use cu130 rather than cu128 for PyTorch.
ComfyUI native nodes and Comfy-Org official models
ComfyUI has native support for INT8 ConvRot from v0.27.0 onwards. Additionally, comfy-kitchen 0.2.16 or later is required, so please update using "pip install -r requirements.txt" or similar. After that, you can handle INT8 ConvRot format models normally using Load Diffusion Model, Load CLIP, etc.
Regarding models, https://huggingface.co/Comfy-Org/models has added the INT8 ConvRot format to its major models over the past few days. As of this writing, I have confirmed that the INT8 ConvRot format has been added to Ideogram-4, Krea-2, Boogu-Image, QIE-2511, SeedVR2, Z-Image-Turbo, Z-Image, Wan_2.2.
Let's use int8_convrotComfyUI-INT8-Fast and dedicated models
There is also a way to use a custom node called ComfyUI-INT8-Fast, which has been released since before ComfyUI v0.27.0.
Regarding ComfyUI native nodes, there were reports that this custom node was faster due to issues with LoRA in commits during development before the v0.27.0 release. However, since this has been addressed in ComfyUI v0.27.0, we recommend using native nodes unless there is a specific need not to.
As a feature not found in native nodes, you can convert models other than the INT8 ConvRot format to the INT8 ConvRot format on-the-fly for use, or save them directly to a file. For example, if the official source does not distribute the INT8 ConvRot format, you can use a workflow called int8_save_convrot_model.json to convert and create it yourself.
Model format conversion using int8_save_convrot_modelHowever, the INT8 ConvRot format created this way is not compatible with the native ComfyUI format, so it must be converted using a tool called convert_to_comfy.py.
The same applies to INT8 ConvRot format models distributed on HuggingFace for ComfyUI-INT8-Fast.
If you intend to use them, please read their respective READMEs carefully.
Forge Neo
Forge Neo did not support INT8 ConvRot at the time this article was written, but it added support for INT8 ConvRot in commit 6d0bc6e on 2026/7/7. It will be supported in the release version 2.27.
No difficult settings or operations are required; you can use it simply by specifying the ComfyOrg official INT8 ConvRot format model in the Checkpoint.
Performance of INT8 ConvRot
Hardware support for Nvidia GPUs
The processing performance for FLOAT and INT types of each bit varies depending on the GPU model. Basically, newer GPU models have hardware support for more formats and can process them faster.
The table below is a list of hardware support for Nvidia GPUs for encoding and scaling methods.
Even if a model format is not supported, it will basically not result in an error because it is software-converted to a processable format, but it will be slower than when hardware support is available.
$$
\begin{array}
{l|c|c|c|c}
& \bf{RTX 20} & \bf{RTX 30} & \bf{RTX 40} & \bf{RTX 50} \\
& \bf{Series} & \bf{Series} & \bf{Series} & \bf{Series} \\
\hline
\text{FP16} & \text{✓} & \text{✓} & \text{✓} & \text{✓} \\
\\
\hline
\text{INT8} & \text{✓} & \text{✓} & \text{✓} & \text{✓} \\
\\
\hline
\text{BF16} & & \text{✓} & \text{✓} & \text{✓} \\
\\
\hline
\text{FP8} & & & \text{✓} & \text{✓} \\
\\
\hline
\text{FP8 Scaled} & & & \text{✓} & \text{✓} \\
\\
\hline
\text{MXFP8} & & & & \text{✓} \\
\text{(Microscaling)} \\
\hline
\text{FP4} & & & & \text{✓} \\
\\
\hline
\text{NVFP4} & & & & \text{✓} \\
\text{(Microscaling)} \\
\hline
\text{INT4} & \text{✓} & \text{✓} & \text{✓} \\
\\
\end{array}
$$
FP8, which has been used as the standard until now, was only supported by the RTX 40/50 series.
In contrast, INT8 ConvRot is attracting attention because it can benefit from hardware support even on the RTX 20/30 series.
By the way, the FP8 ConvRot format is technically possible, but it is not used because it has almost no advantages in accuracy or performance compared to INT8 ConvRot.
Regarding 4-bit, the developer of ConvRot seems to have made statements about INT4 and FP4, but personally, I have never used NVFP4, and I would not consider using a model with such reduced accuracy for the sake of speed. This is probably because I use an RTX 5090 and rarely feel dissatisfied with the speed.
Performance reports on reddit
On reddit, the performance of INT8 ConvRot is reported as follows.
Processing speed
INT8 ConvRot > NVFP4 > MXFP8 ≒ FP8 Scaled > GGUF Q8 > FP16 ≒ BF16Inference accuracy
FP16 ≒ BF16 > GGUF Q8 > INT8 ConvRot > MXFP8 > FP8 Scaled > FP8 > NVFP4
Originally, 8-bit INT types were fast regardless of accuracy, but INT8 ConvRot even outperforms NVFP4 in speed on the RTX 50 series, and its inference accuracy approaches that of GGUF Q8.
For the RTX 20/30 series, which lacked hardware support for FP8 and were slow, the benefits are even greater than for the RTX 40/50 series.
reddit sources:
https://www.reddit.com/r/StableDiffusion/comments/1tazxqz/
https://www.reddit.com/r/comfyui/comments/1uk6q5m/
I was surprised that INT8 ConvRot is faster than NVFP4, which has a smaller bit count, but after repeated Q&A with ChatGPT, I believe it is due to the following factors.
ConvRot is a processing method optimized for INT types
Performance differences in hardware and libraries for INT8 and FP4 on the RTX 50xx
Overhead of NVFP4 Hierarchical Microscaling Processing
Comparison of Krea2 generation speed on actual hardware
I also measured and compared the image generation speed of Krea2 in my own environment using the following setup.
GPU: RTX 5090
Driver: Game Ready 610.62 WHQL (2026/6/16)
Python: Python 3.12.12, torch 2.12.1+cu130, triton-windows 3.7.1.post27, sageattention 2.2.0+cu130torch2.9.0andhigher.post4
Soft: ComfyUI v0.27.0 (2026/7/1)
--reserve-lvram 0.9 --preview-method auto --use-sage-attentionWF: ComfyUI template Krea-2: Text to Image
prompt_enhance=false
enable_lora?=false
1024 x 1024, 8Steps, cfg=1.0, euler simpleDiT: 5 official Comfy-Org Krea2 Turbo models
TE: qwen3vl_4b_fp8_scaled
VAE: qwen_image_vae
$$
\begin{array}
{l|r|r|r}
\bf{DiTモデル} & \bf{DiT, TE, VAE} & \bf{起動直後} & \bf{2回目以降} \\
\bf{形式} & \bf{合計サイズ} & \bf{cold start} & \bf{warm start} \\
\hline
\text{int8\_convrot} & \text{15.24GB} & \text{5.14s} & \text{2.56s} \\
& & \text{(-18\%)} & \text{(-35\%)} \\
\hline
\text{nvfp4} & \text{9.82GB} & \text{5.68s} & \text{3.29s} \\
& & \text{(-9\%)} & \text{(-16\%)} \\
\hline
\text{fp8\_scaled} & \text{14.91GB} & \text{6.25s} & \text{3.91s} \\
\\
\hline
\text{mxfp8} & \text{15.28GB} & \text{6.47s} & \text{4.07s} \\
& & \text{(+4\%)} & \text{(+4\%)} \\
\hline
\text{bf16} & \text{27.15GB} & \text{9.19s} & \text{4.84s} \\
& & \text{(+47\%)} & \text{(+24\%)} \\
\end{array}
$$
"Cold start" is measured after restarting ComfyUI.
The values in parentheses are the percentage change relative to fp8_scaled.
My results were consistent with the reports on Reddit. Even on an RTX 5090, which has hardware support for FP8 Scaled, the generation time was
reduced by as much as 35%. For RTX 20/30 series cards that lack hardware support for FP8 Scaled, the reduction should be even greater. This is amazing!
I wanted to compare performance and generated images when using LoRA, but I will omit that as this post has become long.
Updated 2026/7/6: The aforementioned article by Kimama-san has been updated with evaluation results for INT8 ConvRot generation time and accuracy. The accuracy evaluation using generated images is very easy to understand, so please refer to it.
Summary
I explained the INT8 ConvRot modeling method and measured and compared the processing speeds. The reports on Reddit are very positive regarding both speed and accuracy, and while I only measured processing speed in my environment, it performed exactly as reported. I am certain that it will replace FP8 and FP8 Scaled as the standard for 8-bit model formats in the future.
By the way, it seems some people are converting models like Illustrious or Anima—which are already compact and fast enough in FP16 or BF16—into INT8 ConvRot, but unless you are extremely dissatisfied with the speed, I think it is better to avoid doing so.
In this way, I provide easy-to-understand, free explanations of technical content that is not very systematically organized or understood. Please support me with a 'Like,' 'Follow,' or 'Tip'.
