Most fine-tunes are a checkpoint and a paragraph. Kromoss, published to Hugging Face at 01:34 UTC on 19 October 2026, is a checkpoint, a turbo LoRA, two quantised builds, a converter, a quantiser, and a claim you can verify — that its tooling reproduces ComfyUI’s own reference files byte for byte.
It is a full fine-tune of MOSS-Image-Base at 1024px, under Apache 2.0, from the author of the widely used MOSS-Image DMD distillations.
What it changes, and what it deliberately does not
The README is unusually direct about scope: “The fine-tune mainly fixes the Base model’s blurriness.”
Everything else is held constant on purpose:
| Component | Kromoss |
|---|---|
| Architecture | same as MOSS-Image-SFT |
| Inference pipeline | same |
| Text encoder | Qwen3.5-9B |
| VAE | FLUX.2 small decoder |
| Repo layout | same as MOSS-Image-SFT |
| Checkpoint | update 5000, EMA weights, 320k training images |
That last row in the layout table is the whole value proposition. Because the repo layout matches, Kromoss is “a drop-in replacement” — kromoss_bf16.safetensors substitutes for moss_image_sft_bf16.safetensors in the existing Comfy-Org workflows at 50 steps, CFG 3, and nothing else needs to change.
Releasing a fine-tune that is interchangeable with the thing it improves on is a small act of discipline. The alternative — a new pipeline class, a new loader, a new workflow JSON — is how the ecosystem accumulates friction.
Two speeds
The repo ships 8-steps-dmd-lora.safetensors, an 8-step turbo LoRA produced by data-space DMD distillation of MOSS-Image-Base. It runs at 8 steps, CFG 1, with no negative branch — the README includes a side-by-side against the 50-step CFG 3 path.
Dropping the negative branch at CFG 1 is what actually buys the speed: classifier-free guidance evaluates the model twice per step, so 8 steps without it is roughly a twelfth of the work of 50 steps with it.
In ComfyUI, the LoRA wants KSampler with euler / simple, 8 steps, CFG 1, loaded through LoraLoaderModelOnly at strength 1. ComfyUI maps the LoRA’s separate q/k/v tensors onto the model’s fused qkv slices, so the two layouts coexist without a manual merge.
The int8 build, and what ConvRot means
kromoss_int8_convrot.safetensors is 5.4 GB — small enough to matter on a 8–12 GB card. The format is ConvRot W8A8, matching Comfy-Org’s own int8 file, and the README explains the mechanism rather than just naming it:
The 168 block linears — proj.qkv, proj.o, proj.ffn_up_gate, proj.ffn_down — are stored as int8 with per-row scales, after a 256-wide regular Hadamard rotation of the input dimension. ComfyUI rebuilds the rotation at load time and applies it to activations online, “so no rotation matrices are stored.” Each block also selects ComfyUI’s int8 attention.
The rotation is the trick worth understanding. Quantising a tensor to 8 bits goes badly when a few channels carry much larger magnitudes than the rest, because the scale has to accommodate the outliers and everything else loses precision. A Hadamard rotation mixes the channels so the energy spreads out, and the outliers stop dominating. Doing it with a regular Hadamard matrix means it can be regenerated from its size, which is why nothing has to be shipped.
The claim you can check
Two scripts come with the model, and both make falsifiable claims.
convert_to_comfy.py turns any MOSS-Image diffusers transformer/ folder — including your own fine-tune — into the single-file format, needing only torch and safetensors:
python convert_to_comfy.py path/to/transformer my_model_bf16.safetensors
The README states that run on MOSS-Image-SFT’s transformer/ folder, “it reproduces Comfy-Org’s moss_image_sft_bf16.safetensors byte for byte.” There is a --compare FILE flag that checks keys, shapes and dtypes against a reference.
quantize_convrot.py makes the int8 file from a bf16 single file, and the README makes the same byte-for-byte claim against Comfy-Org’s int8 build.
Byte-for-byte reproduction is a strong form of documentation. It means the conversion is deterministic and that someone else’s artefact can be regenerated from source rather than trusted — and it means these scripts work on your fine-tune of MOSS-Image, not just on this one.
Running it
pip install "diffusers>=0.38" "transformers>=5.3" "accelerate>=1.10" "safetensors>=0.6" "Pillow>=10"
import torch
from diffusers import DiffusionPipeline
pipe = DiffusionPipeline.from_pretrained(
"lodestones/Kromoss",
custom_pipeline="pipeline_moss_image",
trust_remote_code=True,
torch_dtype={"default": torch.bfloat16, "vae": torch.float32},
)
pipe.scheduler = type(pipe.scheduler).from_config(pipe.scheduler.config)
pipe.to("cuda")
image = pipe(
"a tabby cat holding a sign that says KROMOSS",
height=1024, width=1024,
num_inference_steps=50,
guidance_scale=3.0,
uncond_skip_layers=[22],
generator=torch.Generator("cpu").manual_seed(42),
).images[0]
image.save("kromoss.png")
Note trust_remote_code=True — the pipeline is custom code fetched from the repo, so you are executing the author’s Python. That is normal for custom_pipeline models and worth knowing you have agreed to.
The dtype split is specified: transformer and text encoder in bfloat16, VAE and initial noise in float32. Running the VAE in bf16 to save memory is the usual cause of colour banding in decoded output, so this is a deliberate instruction rather than an oversight.
For ComfyUI, four files go in four places — diffusion_models/, text_encoders/ (Load CLIP, type moss_image), vae/ (flux2-vae_small.safetensors) and models/loras/. Native MOSS-Image support is in current ComfyUI master.
Worth watching, not yet proven
This is a day-old repository with 264 downloads and 57 likes at the time of writing, and no published evaluation beyond the README’s own comparison grid. “Fixes the blurriness” is a subjective claim about a base model, and update 5000 of a fine-tune on 320k images is a modest training run by current standards.
What makes it notable is not that it is better — that is untested — but that it is complete. The checkpoint, the fast path, the quantised path, the tooling that produced them, and a reproducibility claim anyone can falsify, all under Apache 2.0, on day one.
Sources
- lodestones/Kromoss on Hugging Face
- Kromoss README
- OpenMOSS-Team/MOSS-Image-Base
- Comfy-Org/MOSS-Image