For years, most of my work with technology has been about making systems dependable. Artificial intelligence has changed the kinds of systems I want to understand, but it has not changed the way I prefer to learn. I would rather build something, break it, repair it, and see exactly what is happening than rely entirely on a hosted service that hides the machinery.
That is why I installed ComfyUI.
I was not looking for another website that could turn a sentence into a picture. I wanted a local environment where I could see how a diffusion workflow is assembled, change individual pieces, compare models, and use the hardware sitting in my own workstation. I also wanted the freedom to experiment without sending every prompt and source image to somebody else’s server.
This is the beginning of that journey rather than a claim that I have mastered ComfyUI. My first few sessions included missing models, unfamiliar graphs, duplicate workflow tabs, and more than one moment when the interface assumed I already knew something I did not. That is precisely what makes the experience worth documenting.
the machine behind the experiment
My AI workstation is separate from my gaming machine. The gaming system has a GeForce RTX 5090, while this machine uses an NVIDIA L40 with 48 GB of memory. The L40 is a data-center GPU that I adapted for workstation use under Windows 11, including an active cooling shroud printed in ASA GF and a driver configuration that allows it to operate with a physical display.
The L40 conversion deserves its own article, and I have already documented that process separately. For ComfyUI, the important part is the amount of available GPU memory. Forty-eight gigabytes gives me room to test larger models and more ambitious workflows locally without immediately designing everything around a small memory ceiling.
This is not the only reason to run locally. The machine is also becoming a general AI lab. I am testing diffusion models now, plan to experiment with computer-vision inference, and intend to explore local language models with Hermes. ComfyUI is one part of a broader effort to understand what these tools can do when the hardware, software, models, and data remain under my control.
why comfyui instead of a simpler image generator
ComfyUI is not the easiest possible introduction to image generation. Its node graph can look like someone spilled a wiring diagram across the screen. A simpler application may be faster when the only goal is to enter a prompt and receive a picture.
The graph is also the reason I chose it.
A ComfyUI workflow exposes the route from model loading to text conditioning, sampling, decoding, upscaling, and saving the result. When an image changes, I can trace the change back to a model, prompt, sampler, resolution, seed, or another node. When a workflow fails, the failure usually points toward a specific missing model or broken connection instead of disappearing behind a generic service error.
That visibility fits the way I work. I am less interested in pressing a magic button than in understanding why one workflow produces a believable photograph while another leans toward illustration, why a change consumes more memory, or why an apparently minor node can alter the final image.
the initial installation
I installed ComfyUI Desktop on Windows and selected the stable instance. I kept the application under D:\AI\ComfyUI and used D:\AI\ComfyUI-models for the model collection.
Separating the models from the application was deliberate. Model downloads can quickly become the largest part of an AI installation. Keeping them in a dedicated location makes the layout easier to understand, reduces confusion when the application is updated, and gives me a more obvious place to manage capacity as the collection grows.
The first lesson arrived almost immediately: installing ComfyUI is not the same thing as having every dependency required by somebody else’s workflow. A workflow is a recipe, not a self-contained appliance. It can refer to checkpoints, encoders, VAEs, LoRAs, control models, or custom nodes that are not present on a new system.
That distinction matters. When ComfyUI says a workflow is missing models, downloading everything without looking may get the graph running, but it can also fill a drive with files whose purpose is still unclear. I wanted to understand what each missing component contributed, confirm where it belonged, and then install only what the workflow actually required.
learning from the tenofas workflows
Starting with an empty graph would have taught me the interface slowly, but it would not have shown me what a thoughtfully assembled production workflow looks like. I began with workflows published by Tenofas because they provided complete examples that I could inspect, run, and adapt.
Opening one of those workflows was like opening a working automation project written by someone else. The graph showed the intended model path and the sequence of processing stages, but my environment did not initially have every referenced component. ComfyUI reported the missing pieces, which gave me a practical map of what the workflow expected.
Our first changes were about making the imported workflow belong to my installation rather than treating it as an untouchable demo. We resolved the missing model references, checked that the workflow was using the intended local model folders, and saved a working copy before making creative changes. That last step sounds mundane, but it matters. Imported examples should remain a known reference point while experiments happen in a separate copy.
Once the graph could run, I changed the subject and prompting instead of rebuilding the entire pipeline. I used a NieR: Automata-inspired 2B concept as an early style test and later worked with a real-world political portrait subject to see how the workflow handled a more photographic result. Changing the content while preserving the processing chain made it easier to judge what the existing workflow was doing before changing several technical variables at once.
One of the working image-generation graphs used z_image_turbo_bf16.safetensors as the diffusion model, qwen_3_4b.safetensors for text encoding, and ae.safetensors as the VAE. The latent canvas was set to 2048 by 1152, while the sampler used eight steps with res_multistep, the simple scheduler, CFG 1.0, and full denoising. Recording those details matters because the model name alone does not reproduce a result. The model, text encoder, VAE, sampler, resolution, prompts, and graph connections all participate.
Another experiment used a Qwen Image Edit 2509 workflow with an eight-step Lightning LoRA to generate a grid of instructed head positions and expressions from a reference portrait. The point was not merely to make nine pictures. It was to see how well the workflow could preserve a recognizable subject while changing pose and expression. The results were not identical, but the overall identity and clothing remained surprisingly consistent across the grid. Any published example using a recognizable person should be labeled clearly as AI-generated, which is how I am presenting it here.
The screenshots also captured a useful mistake. An Upscale Image node was visible in the graph but was not connected to the decode and save path. I could change its width, height, or interpolation method all day and it would have no effect on the saved image. In a node-based tool, a setting is only meaningful when the node is actually part of the execution path. That sounds obvious after the fact, but it is exactly the kind of detail a polished example workflow can hide from a beginner.
We also dealt with a very ordinary problem that becomes confusing in a node application: multiple open workflows, including unsaved tabs and the original Tenofas graph. Learning how to identify the saved copy and close the unused tabs was part of making the environment usable. A graph-based tool becomes much less intimidating once every open tab has a clear purpose.
what the first results showed
The first successful images answered the most basic question: could this unusual Windows workstation run a serious local diffusion workflow reliably? It could.
One 4K image completed in roughly thirteen seconds. That is not offered as a universal benchmark because generation time depends heavily on the workflow, model, step count, resolution, upscaling method, and other settings. It was still an encouraging result. The L40 was not merely detected by Windows and ComfyUI; its memory and compute capability were being used for work that would have been much more constrained on a smaller card.
The visual results also demonstrated why a workflow is more than its prompt. A prompt describes the subject, but the selected model and the processing graph determine how that description is interpreted. The same basic idea can become a stylized character study, a highly polished illustration, or something approaching a photograph depending on the model and the route through the graph.
diffusion models are not interchangeable paint buckets
It is tempting to describe diffusion models as collections of visual styles, but that explanation is incomplete. A model has learned relationships between language and visual patterns from its training. Different model families, checkpoints, and supporting components can respond differently to the same words, produce different kinds of detail, and place very different demands on memory and processing time.
The workflow determines how those components are used. A checkpoint that excels at realistic people may not be the best choice for an anime-inspired character. An upscaler can improve apparent detail, but it cannot rescue every weakness in the original generation. A LoRA can steer a compatible base model toward a person, costume, object, or style, but it also introduces another strength setting and another possible source of artifacts.
This is where ComfyUI becomes valuable as a learning environment. I can change one part, keep the rest of the graph constant, and compare the result. That is a slower way to produce a single image, but a much better way to understand a system.
what I would do differently on a fresh installation
I would still begin with a proven workflow, but I would treat every external graph as documentation that needs to be validated against my own environment. Before downloading models, I would inventory the missing components and note which node uses each one. I would keep the application and model storage separated from the beginning. I would save an untouched reference copy of every imported workflow and give each experimental version a name that explains what changed.
I would also resist the urge to change the prompt, checkpoint, sampler, resolution, and upscale path in the same run. When everything changes, a better or worse image teaches very little. Changing one meaningful variable at a time produces slower gratification and faster understanding.
where this goes next
The next stage is to document the Tenofas workflow more precisely, including the models it expects, the nodes we changed, the reason for each change, and the effect on the output. I also want to compare several diffusion models using the same subject and as much of the same workflow as compatibility allows. That should make the differences more useful than a collection of unrelated images.
Video generation is another obvious direction, although it introduces a different set of memory, storage, and consistency problems. Beyond ComfyUI, I plan to use this workstation for local language models with Hermes and for computer-vision inference. The goal is not to turn the machine into a one-purpose image generator. It is to build a local AI environment where I can learn how these workloads behave and document the useful parts honestly.
For now, the most satisfying result is not a single image. It is that the entire path, from an unconventional L40 workstation to a reusable ComfyUI workflow, is local, visible, and under my control.
Comments
Post a Comment