Kromoss: a fully Apache 2.0 text-to-image stack where the 9B text encoder outweighs the 5B model

The Hugging Face account lodestones has published Kromoss: a 5B text-to-image model where the weights, the inference pipeline and two 8-step turbo LoRAs are all Apache 2.0. No research-only clause, no "contact sales for commercial use", no gated download. I have been burned enough times by "open" image models whose licence turned out to be a non-commercial trap that a fully permissive stack is news on its own. The more interesting question for anyone running image generation locally is what the 8-step LoRA actually buys you, and what it costs elsewhere in the pipeline.

What Kromoss is

According to the model card, Kromoss is a full fine-tune of all transformer parameters of OpenMOSS's MOSS-Image-Base. It shares the architecture, text encoder, VAE and inference pipeline with MOSS-Image-SFT, so it is a drop-in replacement for that model. The base comes from the MOSS-Image technical report, submitted on October 16: a 5B single-stream diffusion transformer pretrained from scratch and aimed at dense text and complex layouts, with 96.3% average text coverage on the authors' own LongLongTextBench. The MOSS-Image-Base card is Apache 2.0 too, which is why the licence chain holds all the way down.

The training details are unusually specific. Kromoss was trained at 1024 pixels on 704k images, dropping anything below 896 squared, with a hybrid Muon and AdamW optimiser at a learning rate of 9e-6. The published checkpoint is update 11,000 with EMA weights, and each update uses 64 images. Multiply those two numbers and you get 704,000, so on average the model saw each training image about once. That is a light, single-pass fine-tune, and it shapes what I expect from it: a nudge in style and prompt adherence, not a different model.

One correction to the morning brief, which dated the release to October 24. The commit history shows the model checkpoints and the LoRAs landed on October 19 and 20. The October 24 commit is a ComfyUI workflow file.

Where the 8 steps come from

The full model wants flow-matching Euler at 50 steps, CFG 3, shift 5, and a negative branch. Classifier-free guidance means two transformer passes per step, one conditioned on your prompt and one on the negative, so you are paying for roughly 100 passes per image. The two turbo LoRAs change that contract. Both run at 8 steps with CFG 1 and no negative branch at all, which is 8 passes. My back-of-envelope figure is about a 12x reduction in transformer compute per image, before you count the text encoder and VAE.

The first LoRA, 8-steps-dmd-lora, is data-space DMD distillation trained for 12,000 updates. The recommended one, 8-steps-dmd2-lora, continues that run for 3,000 updates with a DMD2 GAN stage. Both are rank 128, stored in fp32, and the card says 4 steps also works. It also says to apply them unmerged, because merging into bf16 weights is discouraged, which matters if your tooling likes to bake LoRAs into a single file.

The distilled 8-step LoRA scores higher than the 50-step model it was distilled from, on a metric that was never designed to tell you that.

The card's own quality evidence is a CLIP ViT-L/14 score on 100 PartiPrompts. Base MOSS-Image at 50 steps gets 27.19, Kromoss at 50 steps gets 27.90, and Kromoss with the DMD2 LoRA at 8 steps gets 28.13. I would not read much into that. CLIP score measures prompt and image agreement in an embedding space, a hundred prompts is a small sample, and an adversarial distillation stage can sharpen outputs in ways that flatter an embedding metric without pleasing a human. Treat it as "the turbo LoRA did not obviously break anything", not as "8 steps beats 50".

The real memory bill is the text encoder

Here is the limitation the "5B model" framing hides. Kromoss uses Qwen3.5-9B as its text encoder and a FLUX.2 small decoder as its VAE. The card specifies bf16 for both the transformer and the text encoder, and fp32 for the VAE. In bf16 a 9B encoder is about 18 GB of weights by itself, which is more than three times the size of the image model it serves. The int8 ConvRot single-file version of the transformer is 5.4 GB, but that does nothing for the encoder.

The card gives no VRAM figures, and the MOSS-Image-Base card lists an NVIDIA GPU with CUDA as the requirement. ComfyUI has native support with bf16 and int8 files, so running it on a Mac through ComfyUI is plausible, but I have not measured it and nobody upstream claims it. The brief's pitch of "real latency on Apple Silicon" is a hypothesis until someone times it. On a 32 GB machine I would expect the encoder and transformer to fit together; on 16 GB, offloading the encoder after the prompt is embedded is probably mandatory.

What I would do with it

If you have been holding image generation on a paid API because every capable open model came with a licence you could not ship, Kromoss is worth a weekend. Pull the int8 ComfyUI file and the DMD2 LoRA, keep the LoRA unmerged, run 8 steps at CFG 1, and time the encoder separately from the denoiser so you know which one to optimise. Then run your own 50 production prompts through both the 8-step and 50-step paths and look at the images yourself, because the CLIP number will not tell you whether the text on your poster is legible. If the encoder is your bottleneck, cache prompt embeddings for repeated prompts before you buy hardware. For the bigger picture on open image weights that arrive late or not at all, compare this with how FLUX 3 handled its release.