Explanation of INT8 ConvRot (FP8 is no longer needed)

The other CloudFlare post on the front page has an interesting passage in it

> It is compute-bound, and INT4 weights have to be expanded back out before the model can multiply with them, so that extra step makes prefill slower rather than faster, GLM sustains about 10,160 tokens per second of prefill in FP8 versus 8,660 in INT4. As with the KV cache, the disaggregated design turns this into a choice rather than a compromise: we run INT4 for decode, where it wins, and FP8 for prefill, where it wins.

So each of these improvements are useful even if they have a narrow area of applicability, since the systems can be hybridized for performance.

[1] - https://blog.cloudflare.com/smaller-faster-safer-models/

Is there any degradation with INT8 weights quantization? Why would anyone want to apply ConvRot to do 8 bit weights? Note the paper [1] focuses on 4 bit weights and 4 bit activations (W4A4) quant scheme - a much more challenging goal. My understanding is that W8A8 with weights quantized per-output-channel is a solved problem - does not need any fancy methods like GPTQ, SpinQuant etc.

[1] https://arxiv.org/abs/2512.03673

What about AMD? I'm guessing it's not supported, which is a shame, because they're better value for VRAM.

One thing is not obvious to me is how ConvRot can be applicable beyond diffusion models. Especially for LLM decoding, as each ConvRot would be more expensive for a given decoding vector, and it is required now, so you cannot easily get the benefit for prefill only, while maintaining the same decoding performance.

Alternative title: "Our invention makes INT8 better on older consumer cards without FP8 support"

>"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."

Related:

https://blog.comfy.org/p/minimax-h3-day-0-support-in-comfyui