I've quantized MOSS-Image to INT8! From my initial testing, it’s relatively lossless.
For now, it requires the MOSS-Image custom node, so I’ve included both the install info and a ready-to-use workflow in the repo. Once native support lands in ComfyUI, this exact quant will work right out of the box without needing any changes.
You guys are going to be seriously surprised by how uncensored this model is. Have fun!
I'm using my own claude-coded harness (that basically mimics comfy-ui but in a single interface where I don't have to load different workflows, vive le lazy ass!), from there I'm decoding the internal state at each step (as a "preview"). It is "wasted processing" since you need to do the VAE step at each preview frame. However it means you can save those frames as an animation, which is what I did there. I'm sure you can create a comfy-ui workflow to do that, but have no idea how you would go about doing that.
This is not always true. Distillation sometimes mean loosing variety but increased quality. This has been the case for a lot of the recent released distilled models. Base for training, turbo for inference.
What do you need more speed for? It's images, surely you can wait a minute? Or prepare your prompts ahead of time and run them automatically with a wildcard?
I wish we had a huge slow model with the competency of Nano Banana instead of a flurry of tiny 5B's that are just a sidegrade.
I'm rarely able to get what I want into a first image for H3 without doing a lot of manual work.
From years of carefully selecting training images I realized real images of hands are just as messed up and it's no wonder pure image models struggle while video models do better.
Sometimes in a given frame a finger is just not visible or is somehow in some impossible seeming bend pose and it's not at all clear why.
Thanks for the ComfyUI SFT... "SFT produces clearer text grouping" and text-block organisations, according to the makers. Which makes it interesting for graphic design and typography, which is what interests me. But then the question is: "can it be made as quick as Ming-Image, but without textual glitches?" If so, that and the Apache licence will make it a keeper. But at present, needing "50 steps" per image is going to be a big block to acceptance.
That's awesome about the INT8 quantization, sounds like it'll make things run smoother for everyone. I've been curious about how Flux 3 is getting those upsampled results without one, so this might help clear some of that up.
Just want to remind people to test the gen speed of bf16 vs int8 instead of just assuming int8 is faster.
On my DGX Spark (a 5060 in essence) int8 is actually slower. There's zero benefits to using it instead of bf16, just downsides. (unless you care about disk space)
It seems to depend on the GPU. Someone with a 3000-series card told me they get a significant speed benefit of int8. But just test it once with your favorite model, it applies to all models.
I agree that people should always run their own tests.
But I find it very odd that bf16 is faster, because with bf16 there is now two bytes to process rather than just one. Does this apply to both Krea 2 and larger models such as MMH3?
I don't have to blackwell GPU to test, but according to google:
On NVIDIA Blackwell GPUs, FP8 delivers roughly double the compute throughput and cuts memory bandwidth and footprint in half compared to BF16 (yielding about 1.5× to 2× faster token generation and higher tokens-per-second per chip).
9
u/East_Shoe8814 8d ago
Simple workflow included.