Notizie IA Logo

AITalk

News and analysis on Artificial Intelligence

Home-Cooked Images with ComfyUI

Generative AIApplicationsE-learning

comfyui.jpg

Generating an image with an online service costs little, but it costs every single time. You pay for it in credits that run out mid-month, in free plans that recharge whenever they feel like it, and in rules about what you can and cannot ask for established by someone else. Midjourney, DALL-E, and Firefly are remarkable tools, but they share the nature of a rental: the house is splendid, but it isn't mine. That's where this experiment started—born as a personal trial and becoming an article along the way. I wanted to see if I could produce images without per-shot costs, without dwindling meters, and without credit limits, using only the computer sitting on my desk.

I had heard about ComfyUI some time ago, then the name drifted off my radar, as often happens with things read only once. It popped back up in front of me a few days ago while querying, in search of inspiration, the LLM wiki I update with Matteo Baccan—an archive where we incorporate daily AI news in the AINews repository. A well-maintained archive serves this exact purpose: it returns what you had forgotten you had forgotten. The promise was seductive: granular control over every step of generation, with no subscriptions and no monthly credits. The real question, however, was another: can my machine handle it?

The rig is the same one described in the first episode on home AI: a Ryzen 7700, 32 GB of DDR5 RAM, and a Radeon RX 9060 XT with 16 GB of video memory. Nothing exotic—hardware many enthusiasts would recognize as their own. It has, however, one characteristic that carries significant weight in these pages: the card is AMD, not NVIDIA, and anyone following this space knows that difference is not a fanboy detail but a technical variable.

Nodes, Errors, and SD 1.5

I installed ComfyUI Desktop on Windows, drawn by its simplicity compared to the portable version. The official documentation lists it for Windows 10 or later with NVIDIA or AMD GPUs, and seeing AMD mentioned as a matter of course was already good news. My initial impression of the interface was one of curious familiarity: a canvas full of blocks connected by wires is the exact grammar of n8n, the automation tool I know and use for certain workflows. The content of the blocks changes, not the underlying concept, because each node receives an input, transforms it, and passes it to the next.

For those unfamiliar, ComfyUI is an open-source program that turns image generation into an assembly line: each phase of the process is a block, and it's up to the user to decide which ones to wire together and in what order.

Not wanting to fly blind, I asked DeepSeek's free tier for a step-by-step guide, from installation to the first workflow. It was helpful but a bit convoluted because it arrived all at once rather than step by step, and it described blocks using English names while my ComfyUI displayed them in Italian. How much of what happened next was the guide's fault and how much mine for swapping similarly named nodes, I couldn't honestly say. Likely a bit of both.

The first concrete hurdle involved models. Where do they go? I looked in the installation folder under Program Files, the seemingly obvious spot, and found it empty. Models live elsewhere, in a shared directory inside the user profile (in my case under LOCAL/APPDATA, inside Comfy-Desktop and then ComfyUI-Shared, under models). A detail logical in hindsight, yet invisible beforehand. The second hurdle was more psychological: faced with thousands of models on Hugging Face and Civitai, I felt like stepping into a library without a catalog. I decided to start with the lightest and most straightforward one, Stable Diffusion 1.5, in the v1-5-pruned-emaonly-fp16.safetensors file. It's a model from 2022, and it shows. The official model card places it under the CreativeML OpenRAIL-M license, and its hosting organization now presents itself essentially as a custodian of legacy Stable Diffusion models.

I built the first workflow one block at a time to grasp the logic. Load Checkpoint loads the model. CLIP Text Encode translates my text into machine-understandable numbers, a sort of simultaneous interpreter. Empty Latent Image is the starting canvas, which isn't blank but filled with noise at the final image dimensions. KSampler is the engine room: it takes that noise and cleans it up step by step until something recognizable emerges—the principle of diffusion I've written about before. VAE Decode translates from the model's internal language into real pixels, and Save Image writes them to disk.

The beginner's mistake arrived right on cue: KeyError: 'g'. The error message cited a field, tokens["g"], that exists only in SDXL models. I had placed CLIPTextEncodeSDXL instead of CLIPTextEncode—two nodes with nearly twin names. It brought to mind Primer, the 2004 Shane Carruth film where two engineers build a time machine in a garage and a single misplaced connection derails everything. My garage was more modest, but the lesson was identical: once I replaced the node with the correct one, everything worked. That was the moment I grasped the software's modular architecture and the importance of pairing the right node with the right model.

Then came the first image, generated from my beyond-banal prompt: "a cat on a windowsill, sunlight", at 1024x1024. A total disaster: a triple overlapping head, garbled details, strange colors. The culprit lay in the model's documentation, which indicates training at 512x512. Reverting to that resolution, I added the usual incantations to the prompt (masterpiece, best quality, detailed fur, soft lighting, photorealistic) and tweaked the KSampler parameters: steps bumped from 20 to 30, CFG adjusted from 8 to 7, scheduler switched from simple to karras. I can't say which ingredient worked the magic—as with any ritual—but the result improved dramatically. gatto1.jpg The image created on the second attempt with stable-diffusion-v1-5

Flux Changes the Game

The real breakthrough came with Flux.1 schnell, chosen after reading about its superior quality. I downloaded the FP8 version as a single file—a so-called all-in-one checkpoint containing model, text encoder, and decoder in one package. It weighs around 17 GB and holds a decisive advantage for experimenters: the Apache 2.0 license, unlike its sibling dev which is restricted to non-commercial use.

The surprise was discovering that the parameters painstakingly learned with SD 1.5 had to be thrown out. With Flux schnell, CFG stays at 1.0 rather than 7, steps are set to 4 rather than 25-30, and the baseline resolution is 1024x1024. The schnell version is distilled—meaning trained to achieve in a handful of steps what other models require dozens for—and operates within a window of one to four steps. First test using the exact same prompt as the previous disaster: remarkably good quality.

Side by side, the difference between SD 1.5 and Flux on the cat in the sun is night and day. Flux grasps natural language far better, needs no magic prompt words, and outputs a much larger image that aligns with a sentence written just as a person would speak it.

There is, however, an aesthetic caveat. Flux tends toward a polished look—almost 3D render-like or stock photography—too clean to feel authentic. I tried dampening the effect with terms like film grain, raw photo, and unedited, with mixed results. I'm not the only one pondering this. Krea focused its presentation of Krea 2 in open release explicitly on aesthetics, pitching their model as the most refined among open-weight options. It's a marketing claim to be taken as such, but it shows that today's race is fought on taste as much as on prompt fidelity.

After about twenty test runs, the limitations of Flux Schnell proved to be less random than I had initially thought. It handles static scenes exceptionally well, and motion doesn't faze it either—a cheetah, a drifting car, and a giant duck all turned out great. The trouble lies with the human body in dynamic action; running, kicking, and skiing result in limbs that either merge or multiply. Another weakness is the text rendering, typical of the diffusion-based approach. These are just my observations, based on a single model and system. gatto2.jpg The image created on the first attempt with Flux.1 schnell

Hitting the VRAM Wall

Then I did what anyone who just discovered a new toy does: I cranked up the resolution. At 1500 pixels, generation took about one minute. At 2048 pixels, it stretched to five or six minutes. The jump isn't proportional: for a square image, total pixels increase by less than double, yet generation time increases five to sixfold. The most plausible explanation—and I emphasize plausible because it's a hypothesis rather than a diagnosis—is that at a certain threshold, the graphics card memory overflows and ComfyUI is forced to shuffle model chunks back and forth between VRAM and system RAM. This suspicion is reinforced by a simple fact: the Flux schnell FP8 file exceeds my card's 16 GB, and an unofficial wiki lists 12 GB as the minimum and 16 GB as the recommended VRAM for this model. Translated: I'm right on the edge, and the edge makes itself felt. The 32 GB of system RAM acts as a buffer, but a slow one.

This was the most concrete realization of the entire experiment. My Radeon is capable, but not bottomless, and with local models, architectural choices are dictated by available memory long before personal taste. The rest comes down to quantized versions—copies of the model using less precise numbers to shrink footprint, like the FP8 format I used or the GGUF formats I'll touch on shortly. Every reduction in precision is a trade-off between disk space, speed, and quality, to be evaluated by eye case by case.

I was struck, by contrast, by another recent experience of mine. With OmniVoice Studio, on this exact same PC, the AMD card under Windows sat on the sidelines and voice synthesis defaulted to the CPU, taking roughly 200 seconds for ten seconds of audio. With ComfyUI, things went much smoother: official documentation lists ROCm packages for AMD on Windows and explicitly cites my card's RDNA 4 architecture, and I ran ROCm without drama. It should be noted that the aforementioned unofficial wiki labels AMD support on Windows as experimental, so it's a rapidly improving yet not entirely settled landscape. The same GPU, two very different outcomes—proof that in local AI, software-hardware communication is everything.

This holds even more true for video, which for now I've only observed from afar. In my previous articles, Ovi demanded at least 24 GB of VRAM, and LongCat-Video wanted around 60 GB, or 18 GB with 8-bit quantization on an RTX 4090. The landscape is shifting. ComfyUI documentation claims that Wan 2.2 in its 5-billion-parameter version fits in about 8 GB with native offloading, whereas the official repo lists 24 GB; its 14-billion sibling requires quantized versions to run on 16 GB according to community reports. And on August 12, 2026, LTX-2.5 arrived on ComfyUI, featuring open weights, synchronized audio and video, and a promise from its creators of fast execution on consumer hardware. A promise to be verified on one's own card, as always.

Editing Is a Different Beast

Satisfied with text-to-image generation, I tried modifying an existing image: a yellow car to be turned red, leaving everything else untouched. The knob governing this is KSampler's denoise parameter. According to the documentation, the system adds noise to the original image data based on that value and lets the model repaint it; thus, low values change little, high values change everything. With SD, it acts as a smooth slider. With Flux schnell, I observed step-function behavior: below 0.8 the image didn't change at all; at 0.81 the model rewrote everything and lost the original car. Zero control, plenty of frustration.

I don't have a definitive explanation. A clue comes from a forum thread on FLUX.2 klein 9B, another 4-step distilled model, where a user describes growing artifacts at low denoise levels and attributes them to few-step sampling. It's not the same scenario nor the same model, so I take it as a suspect rather than a verdict. My working hypothesis is that a model trained to do everything in four moves lacks the fine grain required for a smooth slider, and that img2img operates on the entire image rather than a targeted region anyway. For surgical edits, purpose-built tools exist.

The most promising is FLUX.1 Kontext dev, a 12-billion-parameter model dedicated exclusively to text-guided image editing under the same non-commercial license as Flux dev. It claims to run on consumer hardware, but a quick calculation reveals the math. A 12B model takes around 24 GB in full precision, similar to Flux dev at 23.8 GB, around 12 GB in FP8, and roughly 7 GB in a 4-bit GGUF quantization (rough estimates on my part). On my card, FP8 would be sluggish and GGUF an interesting middle ground. Both remain tests for the future.

Meanwhile, a more convenient path has emerged. Black Forest Labs released the FLUX.2 klein family in early 2026—compact 4B and 9B parameter models designed to run on consumer hardware for both generation and editing. The 4B version falls under Apache 2.0, while the 9B version carries a non-commercial license. Memory requirements vary by source: the repo cites around 8 GB, while official documentation lists about 13 GB. Either way, my card handles it comfortably, and the next experiment is already decided. confyui_cscreenshot_ok.jpg A screenshot of the ComfyUI canvas during testing

Freedom with an Electric Bill

Before tallying the balance, it's worth defining what ComfyUI actually is, as my test barely scratched the surface. The node-based system isn't an interface gimmick; it's the reason for its existence. The exact same workflow concept that generated a cat is used to edit existing images (as attempted with the yellow car) and to produce video, which developers support with dedicated updates for every major model release. You change the task by swapping blocks, not the software. A workflow can be saved, rerun identically, shared, or modified starting from pre-made templates. It's the difference between a home appliance and a workbench: the former does one thing well; the latter requires learning, but lets you build whatever you need. The price, as we'll see, is patience.

If this experiment taught me anything, it's that "free" is a word to handle with care. The benefits of local execution are real and tangible. Every additional image costs nothing marginally, making experimentation effortless—you generate on a whim without a meter running in the background. Data and images remain strictly on my local drive. And control is absolute: every parameter is accessible, and you learn by doing, including making mistakes.

The software architecture helps as well. ComfyUI cleanly separates the core engine, models, and extensions. You can swap models without rebuilding the workflow, or add features without touching the core. A thriving community produces custom nodes, indexed in a public registry and managed via ComfyUI-Manager, which comes pre-installed in the Desktop version (the official docs for this are in Korean). Ready-to-use workflows abound, along with an elegant trick: saved PNGs embed the exact workflow that generated them, meaning you can drag a PNG onto the canvas to reproduce the setup. For anyone wanting to understand rather than merely consume, that reproducibility is a treasure.

The flip side consists of three caveats. First, hardware limitations, as discussed. Second, hidden costs: the card, electricity, disk space, and above all, time spent navigating wrong directories, swapped nodes, and trial-and-error dead ends. Third, licensing fragmentation. Every model carries its own license rules: SD 1.5 uses OpenRAIL-M; Flux dev and Kontext dev use non-commercial licenses; Flux schnell and klein 4B use Apache 2.0; klein 9B returns to non-commercial. Licenses vary, and anyone seeking commercial use must read them carefully rather than relying on summaries.

Then there is a question of perspective. Open-model publishers frequently pair releases with paid API services: Black Forest Labs offers klein via API for cents per image, so the weights I download for free also power a commercial pricing sheet. For experimenters, this is good news—local access remains an open door. The biggest winners are corporations using the community as a testing ground, and GPU manufacturers—specifically NVIDIA, which remains the performance and compatibility benchmark across community wikis. Those left behind are users on aging hardware, for whom local freedom remains purely theoretical. Another open question concerns cloud performance: while I conducted no direct benchmarks, frontier proprietary cloud models remain superior, particularly with human figures. The two approaches represent fundamentally different ways of owning and thinking about a tool. new_york.jpg 1500x1500 image obtained with Flux.1 schnell, using prompt: "A New York street with a view of the Brooklyn Bridge at autumn sunset."

Who Should Try It

I'd recommend this path to anyone seeking privacy and control who doesn't mind spending an afternoon troubleshooting an error message. Anyone with at least 12 GB of VRAM starts in reasonable shape, and with 16 GB like mine, you're set until you push resolutions too high. The ideal user is a curious tinkerer willing to get their hands dirty—someone who appreciates the moment a node snaps into place. I'd discourage it for those wanting a turn-key solution where you type a prompt and get an image without touching a variable, or those with constrained hardware and little patience for render times.

My personal verdict is positive, with a few caveats. I learned that the right node must pair with the right model, that each model family speaks its own parameter vocabulary, and that spec-sheet numbers tell only half the story. I generated high-quality images with Flux from scratch. I measured the limits: memory constraints, complexity, and models still too heavy for certain setups. Img2img and video remain future milestones, as my focus today was local text-to-image creation from scratch—and that part delivered.

It reminds me of Dungeon Meshi, Ryoko Kui's manga where adventurers navigate a dungeon by cooking the monsters they encounter, improvising recipes at their own expense. Local AI shares that exact spirit of self-reliance, along with a healthy dose of trial-and-error risk. It isn't a free alternative to cloud services; it's something else entirely: an ecosystem where customization and learning unfold in ways unimaginable with a monthly subscription. The next step is testing klein 4B and a quantized Kontext, with the cat on the windowsill waiting to change color.


Technical note: Specs, licenses, and requirements were verified against linked sources as of October 2026 and may change. Generation times reflect personal observations on a single machine (Ryzen 7700, 32 GB DDR5, RX 9060 XT 16 GB, Windows, ComfyUI Desktop with ROCm), not formal benchmarks.