ComfyUI Adaptation for New Model Sparks Discussion: Likely Krea 2 with Image Editing Capabilities

Community Buzz: New Model Supports Text-to-Image and Image-to-Image

Recently, the StableDiffusion community on Reddit has been buzzing about an unreleased image generation model. Based on early community findings, the model supports both text-to-image (t2i) and image-to-image (i2i) generation — a combination that has become standard among mainstream open-source image models.

Even more noteworthy is that prominent developer kijai has already begun writing ComfyUI adaptation code for it, with progress trackable at Comfy-Org/ComfyUI PR #16400. As one of the most popular node-based workflow tools in the open-source ecosystem, ComfyUI's rapid adoption of a new model is often a strong signal that it's about to enter mainstream user awareness.

VAE Architecture Becomes a Flashpoint

As discussion deepened, the community split over the model's VAE (Variational Autoencoder) architecture — the most technically dense part of the conversation.

Some users initially inferred from the PR code that the new model reuses the VAE module from Wan 2.2 — a module previously associated with a less-used 5B model, parameterized for single images with all new parameters defaulting to legacy values. Based on this, concerns arose that if the new model still uses the same VAE as Qwen/Wan, it would struggle to improve reconstruction quality, making it feel more like "Krea 2 with editing capabilities" rather than a true step forward.

However, a more precise technical clarification followed: the new model only shares the Python module code from Wan 2.2's VAE — it does not use the same VAE weights. The latent channel counts differ between the two. Some developers further speculated that the new VAE likely matches what was described in the Qwen Image 2.0 technical report. This clarification eased community concerns about a mere rehash.

---

The VAE (Variational Autoencoder) acts as an "encode-decode bridge" in image generation models: it compresses high-resolution pixel images into a low-dimensional latent space representation, where the diffusion model performs noise prediction and denoising, before the VAE decoder reconstructs the final pixel image. VAE quality directly determines detail preservation, color accuracy, and texture sharpness — a weak decoder introduces blurring, color shifts, or artifacts, bottlenecking output quality regardless of how strong the diffusion backbone is. Latent channel count is a key parameter for measuring VAE compression capacity: Stable Diffusion 1.x uses a 4-channel latent space, while newer models like SD3 and FLUX upgraded to 16 channels. More channels allow the latent space to encode richer semantic and detail information, but also increase VRAM usage and computation. Therefore, two models "sharing Python module code but differing in latent channels" essentially means their VAEs may differ fundamentally in compression capability and information density — they do not share the same encoder/decoder weights.

---

Model Scale and VRAM: Practical Concerns

Beyond architecture details, the model's parameter count was the community's most immediate practical concern. One user put it plainly: "Krea 2 with image editing sounds great," but worried the new model might balloon to something like 65B parameters — essentially unusable on consumer-grade GPUs.

A key clarification in the thread addressed this: according to community comparisons, Krea 2 itself is 12B parameters, while this new model is only 7B. A smaller parameter count means a lower VRAM threshold and faster inference — good news for local deployment users.

Of course, some users half-jokingly raised "plot twist" concerns like "58B but not counting the language model" or "a 5GB VAE on top of that," reflecting the community's general anxiety around large model VRAM demands. By contrast, someone praised a certain H3 VAE for being "very compact in size," hinting that lightweight individual components are exactly what local users are hoping for.

---

The relationship between parameter count and actual VRAM usage is not simply linear — it also depends on data precision, quantization method, and architecture design. As a rough guide: a 7B model stored in FP16 requires roughly 14GB of VRAM, INT8 quantization brings it down to about 7GB, and INT4 can compress it to under 4GB — though higher quantization typically trades off some image quality. Inference also requires additional VRAM headroom for intermediate states like activations and attention caches, so peak usage often exceeds the weight size alone. The community's mention of "a 5GB VAE not counted" reflects this component-by-component VRAM stacking — when the backbone network, VAE encoder/decoder, and text encoders all need to be loaded simultaneously, total VRAM demand can far exceed what any single number suggests. This is exactly why lightweight VAEs are so valued in local deployment discussions.

---

Expectations for Future SOTA Models

It's worth noting that while the community is excited about what appears to be "Krea 2 with editing capabilities," some voices have tempered expectations, suggesting it may not be a true state-of-the-art (SOTA) model. One user argued that if it continues down the existing VAE path, a genuinely SOTA model with an excellent VAE might not arrive until Krea 3 or Flux 3.

At its core, this discussion reflects a classic tension in the open-source image generation community: balancing model capabilities (t2i/i2i/editing), reconstruction quality (VAE), and deployment cost (parameter count/VRAM). A 7B model with image editing support — if it truly adopts an improved VAE — could hit a sweet spot between ease of use and quality.

For now, everything awaits official confirmation. As the community put it: "We'll know soon enough." With kijai's adaptation work moving forward, the day when everyday users can get hands-on with this model shouldn't be far off.