Krea2-Turbo-int8-ConvRot.safetensors vs released official
If this uses the official method, why is there such a large discrepancy versus the officially released version?
TL;DR: The 14.1 GB vs 13.5 GB difference has almost nothing to do with the quantization itself. Both files use the exact same int8-ConvRot recipe on the exact same layers. The size gap comes entirely from which precision the non-quantized layers were stored in.
1. The quantized payload is identical in both files
Compare any transformer block: both files quantize the same 8 linears per block (attn.wq/wk/wv/wo/gate, mlp.up/gate/down) across all 28 blocks, with identical shapes, I8 weights, and per-output-row F32 weight_scale tensors of identical shape (e.g. [6144, 1]). Both leave the txtfusion blocks, mod.lin, and norms unquantized. Same method, same coverage — that part of the file is byte-for-byte the same size.
2. The 0.6 GB comes from FP32 vs BF16 on the unquantized "shell" layers
My upload keeps the input/output projections and time/text embedding MLPs in FP32, while Kijai's official file stores them in BF16. Those tensors are big, and FP32 costs 2 extra bytes per parameter:
| Tensor | Params | FP32 vs BF16 overhead |
|---|---|---|
tproj.1.weight (36864×6144) |
226.5M | ~453 MB |
tmlp.2.weight (6144×6144) |
37.7M | ~75 MB |
txtmlp.3.weight (6144×6144) |
37.7M | ~75 MB |
txtmlp.1.weight (6144×2560) |
15.7M | ~31 MB |
tmlp.0, first, last, biases |
~3.5M | ~7 MB |
| Total | ~640 MB ≈ 0.6 GB |
That matches the 14.1 − 13.5 GB difference exactly. Interestingly, the tradeoff goes the other way on the tiny tensors: Kijai's file keeps all the RMSNorm/qknorm scales in FP32 while mine has them in BF16 — but those are only a few KB each, so they don't move the needle. Neither choice meaningfully affects quality; these layers are numerically cheap either way, though keeping tproj/tmlp at FP32 is the more conservative option since modulation layers are precision-sensitive.
3. Other (cosmetic/metadata) differences you can see in the dump
- Key prefix: mine uses checkpoint-style
model.diffusion_model.*keys; the official file uses bare keys. ComfyUI's loader strips/handles both — zero effect on size or output. comfy_quantblob length ([67] vs [72] bytes): that tensor is just a small serialized JSON config describing the quant layout for ComfyUI's native int8/ConvRot loader. The 5-byte difference reflects slightly different config strings from different converter versions, not a different algorithm.egg_*entries in mine are embedded preview-image metadata written by the conversion tool — not model weights.
4. Why the SHA256 hashes differ (and always will)
Even if two people quantize with the identical official ConvRot method, the files won't be bit-identical: ConvRot applies a rotation (QuaRot-style) to weights/activations before quantizing, and rotation construction, rounding, and the FP32→BF16 casts of the shell layers all introduce differences. Different hashes ≠ different method.
Bottom line: it's the same model, same int8-ConvRot quantization on the same layers. Mine is ~0.6 GB larger because it preserves the embedding/projection MLPs at FP32 instead of BF16. If you're seeing a quality discrepancy rather than just a size one, share seeds/workflow and I'll compare — but structurally these two files should behave near-identically.