AI · Fundamentals
Model types overview
SDXL, Flux.1 dev, Flux.2 dev, Ideogram 4 — which model when.
The last article clarified what a checkpoint actually is: the complete, trained model that LoRA, VAE, and ControlNet sit on top of as additions. This article addresses the question that comes up first in practice: which checkpoint do you actually load?
There isn't "the one" image generation model — there are several fundamentally different architectures that vary considerably in size, speed, quality, license, and hardware requirements. The choice isn't purely a matter of taste; it depends on what you have available and what you're trying to achieve.
This overview is deliberately wide-ranging: from models that run on a MacBook Air to models that push even capable hardware to its limits. That reflects this site's audience — from apprentices on a limited budget to professional production setups with the gear to match.
The models compared
SDXL
The most established and accessible entry point. SDXL runs stably with comparatively modest memory requirements — even a MacBook Air with 16 GB of RAM can handle it. Image quality is solid, and the ControlNet ecosystem around SDXL is mature and well documented, since the model has been in broad use for a while now.
The trade-off: SDXL doesn't reach the photorealistic level or prompt fidelity of newer architectures. For fast iteration, learning the fundamentals, and workflows with limited hardware, it's still the most solid choice.
Flux.1 dev
The next step up in quality and prompt understanding, while hardware demands remain reasonable. Flux.1 dev is guidance-distilled — a training technique that makes the model more efficient and changes how it's steered (more on that in the Flux.1 dev setup article). In practice, that means noticeably better results than SDXL without generation time exploding.
ControlNet Canny is already available for Flux.1 dev and works reliably — which currently makes it the most viable model for the RAY-L workflow.
Flux.2 dev
A considerably larger and more capable model than Flux.1 dev — the parameter count sits well above it, and the model combines image synthesis with its own language-understanding system for noticeably more accurate prompt translation, better consistency across multiple reference images, and higher resolution.
The price for that is compute time: on a Mac Studio with an adapted setup, Flux.2 dev runs stably, but with significantly longer generation times than Flux.1 dev — on the order of 40 minutes per image, instead of seconds to a few minutes. That's unsuited to fast iteration, but entirely workable for deliberate, final results.
Currently relevant for RAY-L: a ControlNet Canny implementation for Flux.2 dev doesn't exist yet. But since the existing ControlNet ecosystem around the Flux model family is already mature, extending it to Flux.2 dev is a natural, likely next step — a question of time, not fundamental feasibility.
Ideogram 4
A newer model, trained from scratch with a different focus: outstanding text rendering within images, precise control via bounding boxes (rectangular areas that define where a given element should sit in the image), and structured prompt input instead of pure free-form text.
Relevant for RAY-L, and stated honestly here: Ideogram 4 controls composition natively through this bounding-box system, not primarily through classic ControlNet. Whether and how Blender geometry could be connected to this model via edge maps (Canny) is currently unresolved — that could turn out to be purely a matter of time, or it could require a fundamentally different translation path. More on this once RAY-L integration for this model is concretely investigated.
Decision questions, not just spec sheets
Rather than a plain spec table, these questions tend to help more when choosing a model:
What can your hardware handle? SDXL runs on modest setups, Flux.1 dev needs a bit more, and Flux.2 dev demands capable hardware and patience.
Do you need fast iteration or a single, high-quality result? For many quick test runs, smaller, faster models are the better fit. For one final image, a slower, more capable model can be worth it.
Does your workflow require ControlNet Canny? If Blender geometry is meant to steer the image composition — as in the RAY-L workflow — ControlNet Canny availability for the given model is currently the decisive selection criterion. As of now, that's the case for SDXL and Flux.1 dev, but not yet for Flux.2 dev or Ideogram 4.
Which license fits your project? More on that in the next article — licensing models differ considerably between these models, and "open weights" doesn't automatically mean unrestricted commercial use.
Summary
There's no single right answer to "which model should I use" — only the right answer for your hardware, your time budget, and your workflow. SDXL as an accessible, fast entry point with a mature ControlNet ecosystem. Flux.1 dev as currently the strongest combination of quality and RAY-L readiness. Flux.2 dev as a glimpse of substantially higher quality, requiring patience and (for now) without ControlNet. Ideogram 4 as a distinct path with a different control philosophy, whose RAY-L readiness remains an open question.
For local use with ComfyUI, all four models are already available. On Windows with Nvidia hardware — the typical platform for these workflows — SDXL, Flux.1 dev, Flux.2 dev, and Ideogram 4 run without particular restrictions. Apple Silicon (Mac) is the exception: fp8, the format Ideogram 4 ships in, isn't natively supported there, and a comparable adaptation path doesn't yet exist.
The next article clarifies what "open weights" actually means in licensing terms — a point that's often underestimated when choosing a model.