---
title: "I ran Krea-2 Turbo on a 16GB Mac. Here's how CLIP, VAE, and the KSampler turned noise into an image."
canonical: "https://agenticup.dev/posts/krea2-comfyui-workflow-local-image-gen/"
pubDate: "2026-06-24T00:00:00.000Z"
description: "I downloaded 12GB of model files, wired them together in ComfyUI, and generated a neon fox on a laptop. The CLIP translated my words. The VAE compressed and decompressed. The KSampler denoised through latent space. Here's what each step actually does."
tags: [krea-2, image-generation, comfyui, clip, vae, ksampler, latent-space, local-ai, 16gb-mac, gguf]
---

**TL;DR:** Image generation on a 16GB Mac is practical now. Krea-2 Turbo in GGUF format runs at 30-60 seconds per image with zero inference cost. The pipeline uses three models: CLIP turns text into conditioning, the UNet denoises a latent toward that conditioning, and VAE compresses/decompresses between pixels and latent space. ComfyUI visualizes this as connected nodes.

I typed "a cyberpunk fox made of neon light trails, dashing through a rain-soaked alley at night" into a text box on my laptop. 45 seconds later, a 1280x720 image appeared. No cloud API call. No GPU rental. No waiting for a queue. Every model file was on my hard drive.

This is not a breakthrough. It is a convergence. The same hardware that runs llama.cpp at 30 tok/s and hosts coding agents can also run image generation. A 16GB Mac Mini with no dedicated GPU is becoming a general-purpose AI appliance.

Krea-2 Turbo is an 8-step distilled image model from [Krea AI](https://www.krea.ai), ranked #1 on [Artificial Analysis](https://artificialanalysis.ai/image/leaderboard/text-to-image) for text-to-image quality among independent labs. It comes in several formats. I ran the GGUF Q4_K_M quant — 7GB on disk, designed for consumer hardware.

This post covers two things. The hands-on experience of getting it running. And the technical pipeline that turns noise into an image.

> **Key takeaways:**
> - Krea-2 Turbo runs on 16GB shared memory at 1024x576 resolution. 30-60 seconds per image. $0 inference cost.
> - Image generation uses three separate models in sequence: CLIP (text → conditioning), UNet (conditioning + noise → latent), VAE (latent ↔ pixels)
> - Latent space makes local inference practical by compressing images ~48x during processing
> - ComfyUI visualizes this pipeline as connected nodes. Each node is one model or one transformation step.
> - The real bottleneck isn't the model size — it's the memory budget for running two VAE passes (encode + decode) alongside diffusion

## What happens when you type a prompt

The pipeline looks simple in ComfyUI. A few boxes connected by wires. But behind each wire is a separate neural network doing a specific job.

The gap between what the user sees and what the machine does is where the learning lives. Here is how it actually breaks down:

```
YOU                       |  MACHINE
──────────────────────────|───────────────────────────
"a cyberpunk fox"         |  CLIP: tokenize → embed → encode
wait for the image        |  KSampler: 8 steps of denoising
                          |  step 1/8 — static noise
                          |  step 3/8 — vague fox shape
                          |  step 5/8 — fur texture forming
                          |  step 8/8 — coherent image
see the result            |  VAE Decode: latent → pixels
save the PNG              |  write file to disk
```

You see one action (type prompt, wait, save). The machine runs three separate neural networks, eight iterative refinement passes, and a compression/decompression cycle — all in the 45 seconds between hitting Enter and seeing the image.

```
Your text prompt
        ↓
CLIP → conditioning (mathematical representation of your prompt)
        ↓
KSampler → takes conditioning + latent noise, denoises over N steps
        ↓
VAE Decode → decompresses latent back to pixels
        ↓
Output image
```

Three models. Three distinct jobs.

## CLIP — the text encoder

CLIP is a language model trained on millions of image-caption pairs. It doesn't predict the next word like an LLM. It maps text to a vector space that aligns with visual concepts. "Fox" in text maps to the same region as fox in images.

In the Krea-2 workflow, CLIP is a 5B Qwen3VL model. It takes your prompt and outputs a conditioning vector — a mathematical description of what the image should look like. This vector gets fed into the KSampler alongside random noise.

The key detail: CLIP doesn't understand images. It understands the *relationship* between text and images. It learned that "neon light trails" corresponds to bright cyan/magenta streaks against dark backgrounds. It learned that "rain-soaked alley" maps to wet reflections and vertical streaks.

Without CLIP, the KSampler has no direction. It would denoise randomly. CLIP provides the target.

## VAE — the compressor and decompressor

The VAE (Variational Autoencoder) is the least flashy but most important component for local inference. It has two jobs:

- **VAE Encode** — compress pixels into latent space
- **VAE Decode** — decompress latent space back to pixels

Latent space is a compressed mathematical representation. A 1024x576 image has roughly 1.8 million pixels. Processing that directly through 8 denoising steps would be expensive. The VAE compresses it to roughly 20x32x64 — about 48x smaller. The diffusion model works in this compressed space, then the VAE decodes the result back to full resolution.

This is why local image generation is practical on 16GB hardware. Without latent compression, the KSampler would need to process 48x more data per step. Each step would take minutes instead of seconds.

The same VAE model file is used at both ends. Encode compresses. Decode decompresses. Same weights, opposite directions.

## KSampler — the denoiser

The KSampler is where the actual image generation happens. It takes three inputs:

- **Model** (the UNet/diffusion model — Krea-2 Turbo in this case)
- **Conditioning** (from CLIP — what to generate)
- **Latent** (starting point — random noise for txt2img, an encoded image for img2img)

It runs N steps (8 for Turbo). Each step removes some noise and adds some structure matching the conditioning. Step 1 is random static. Step 4 shows rough shapes. Step 8 is a coherent image.

The **denoise** parameter controls how much of the original latent is preserved. At denoise 1.0 (default for txt2img), it ignores the starting latent entirely and generates from scratch. At denoise 0.5 (used for img2img), it keeps half the original structure and changes the rest toward the new prompt.

The KSampler is also where the "stuck at 13%" problem lives. Each step increases memory usage. On 16GB shared memory, a 1280x720 img2img run can hit the wall at step 2 of 8. Dropping resolution or denoise brings it back.

## The Cost Math

| Component | Size | Source |
|-----------|------|--------|
| Krea-2 Turbo GGUF (Q4_K_M) | 7.0 GB | HuggingFace |
| CLIP (qwen3vl text encoder) | 5.0 GB | HuggingFace |
| VAE (qwen_image_vae) | 242 MB | HuggingFace |
| ComfyUI + dependencies | ~1 GB | GitHub |
| **Total** | **~13 GB** | |

Every image generated after setup costs $0 in inference fees. The only cost is electricity — roughly 60W for 45 seconds, or about 0.00075 kWh. Near zero in practice.

Compare this to cloud APIs at $0.002-0.04 per image. The breakeven point is roughly 300-600 images. If you generate more than that, local is cheaper. If you generate less, cloud is simpler.

The more important comparison is time. Cloud APIs return an image in 2-5 seconds. Local takes 30-60 seconds. For a single image, the difference is negligible. For batch processing 100 images, cloud saves an hour.

## The actual outputs

The neon fox at 1280x720 came out in 45 seconds with full prompt adherence. The cyberpunk aesthetic — neon trails, rain, wet reflections — all present. The LoRA (krea2_neondrip at 0.8) dominated the style, pushing the colors toward neon-drip instead of photorealistic.

The anime portrait (img2img from a photo at denoise 0.5) took about 90 seconds. The VAE encode step added overhead. The result was recognizable as the source person with anime rendering applied. Comparable to Midjourney's "make it anime" feature, but local and free.

The quality gap vs cloud APIs is visible on photorealistic prompts. Faces have subtle artifacts. Fine details blur at edges. For stylized work (neon, anime, watercolor), the gap narrows to near-invisible. For photorealism, cloud models still win.

## When to use this and when to skip

**Use local image gen when:**
- You need custom illustrations for blog posts or content
- Privacy matters (the image stays on your machine)
- You want to iterate without per-image API costs
- You're generating stylized images where small imperfections don't matter

**Skip local and use cloud when:**
- You need photorealistic output
- Latency matters more than cost
- You're generating hundreds of images
- You don't want to manage 12GB of model files

The post you're reading now — the OG image was generated by Satori at build time, not Krea-2. Because Satori is automatic, consistent, and costs zero setup time. Krea-2 is for the images that need more than styled text on a background.

## FAQ

> **Can I run Krea-2 without ComfyUI?**
> Yes. The official repo at github.com/krea-ai/krea-2 runs via CLI: `uv run inference.py "prompt" --checkpoint oss_turbo`. GGUF variants work with stable-diffusion.cpp directly. ComfyUI is optional — it just visualizes the pipeline.

> **Does this work on Apple Silicon?**
> Yes. The GGUF version runs via MPS backend. Expect 30-60 seconds per image on M1/M2/M3/M4. The FP8 official variant needs 24GB+ and is not recommended for 16GB Macs.

> **How does Krea-2 compare to Midjourney or DALL-E?**
> Krea-2 is competitive on stylized output (neon, watercolor, anime) but behind on photorealism. The gap shrinks with prompt engineering but doesn't close. The advantage is local execution and $0 per-image cost.

> **Can I generate images with readable text?**
> Krea-2 inherits the same text rendering limitations as most diffusion models. For text in images, Ideogram 4 is better suited. Krea-2 handles short text (titles, labels) at high resolution but struggles with longer strings.

> **What resolution should I use on 16GB?**
> 1024x576 for txt2img. 768x768 for img2img (VAE encode adds memory pressure). Avoid 1280x720 or higher on 16GB — the KSampler will stall.

## Related Posts

- [llama.cpp: the local inference engine that changed how developers ship AI](/posts/llama-cpp-local-llm-inference-guide/). The same hardware running local LLMs also runs local image generation. The convergence point is 16GB shared memory.
- [The 16GB Mac Mini taught me more about AI infra than any GPU cluster](/posts/16gb-mac-mini-ai-infra/). Why constrained hardware forces better engineering decisions — applied here to image generation.
- [How to process 1,000-page documents without hitting context limits](/posts/unlimited-ocr-rlm-document-pipeline/). Another local pipeline that pairs extraction (Unlimited-OCR) with analysis (RLM), just like this one pairs CLIP with KSampler.

---

This article was published on Agentic Up (https://agenticup.dev): practical guides for developers and founders building with AI agents. Reach me at hello@agenticup.dev