Explanation of INT8 ConvRot (FP8 is no longer needed) (note.com)
18 points by peter_d_sherman 4 hours ago
gopalv 39 minutes ago
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/
randomblock1 2 hours ago
What about AMD? I'm guessing it's not supported, which is a shame, because they're better value for VRAM.
liuliu 3 hours ago
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.
augment_me 3 hours ago
Alternative title: "Our invention makes INT8 better on older consumer cards without FP8 support"
peter_d_sherman 4 hours ago
>"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
spottedmarley 4 hours ago
Just read that before finding this. Makes me feel like we're all on the same brain-wavelength. Im actually in the middle of pulling and setting up H3 locally (int8 convrot)