ComfyUI and Radiant Canvas on a Mac

Inference

Radiant Canvas has a separate inference engine for each supported model path. The Mac app is written in Swift with Objective-C++ and C++ where the model runtime needs them. Depending on the model, the heavy work goes through Metal or MLX. The engine owns its Metal streams, compiled graphs, cancellation state, and caches. It already knows which prompt encoder, denoiser or flow model, decoder, and quantized weights belong together.

So the Generate button is not building a general pipeline at runtime. It is filling in the settings for a pipeline that is already part of the app. Krea 2 Turbo, Z-Image Turbo, FLUX.2 Klein, ERNIE-Image Turbo, and Microsoft Lens Turbo do not all use one generic wrapper. Their paths differ where the models differ.

ComfyUI Core runs a Python server and normally uses PyTorch on Apple silicon. The graph is sent to that server as a prompt, then its execution system works out which nodes are needed to reach an output. A basic text-to-image graph might load a checkpoint, encode the positive and negative prompts, create a latent, run a sampler, decode through a VAE, and save the image. Change those nodes and you have changed the program.

There is a real benefit to that design. ComfyUI can schedule a wide mix of architectures and third-party operations without baking each one into a Mac app. It can re-run only the affected part of a graph, queue prompts asynchronously, and move models in and out of memory. The cost is that more of the pipeline is visible to you because more of it is your responsibility.

Installing and loading models

In Radiant Canvas, a model is an installable choice, not a folder of parts. Model Manager shows the download size and rough memory guidance, then downloads, resumes, checks, and installs the files in app storage. The quantization is part of the listed option. For example, Krea 2 Q8 and Krea 2 INT4 ConvRot appear as different choices. You do not need to find a matching VAE or wonder which text encoder the app expects.

ComfyUI models are files that loader nodes consume. Older checkpoint formats may package several components together. Newer model families often arrive as separate diffusion models, text encoders, VAEs, LoRAs, ControlNets, or upscalers. Each type normally has its own directory. You can also configure extra model paths, which is handy if several tools share a large model library.

This is flexible, but it creates a class of problems that Radiant Canvas mostly avoids. A perfectly good weights file may be in the wrong folder. The loader may expect a different architecture. A workflow may be missing its encoder, or it may depend on a custom node you have not installed. ComfyUI itself warns that not every checkpoint or weights file works out of the box.

The limit on the Radiant side is just as plain: you cannot point it at an arbitrary checkpoint and expect it to work. If a model is not in Model Manager, or an adapter does not match a supported family, the app is probably the wrong tool for that job.

What the graph runs

A ComfyUI graph is a live dataflow program. The links carry typed values, and an output node gives the executor something to work back from. If an upstream value has not changed, ComfyUI can reuse cached results. Partial Execution lets you run only the branch that feeds the output you selected. On a large workflow, that can save a lot of time.

Studio in Radiant Canvas uses typed nodes too, but it pauses at a different point. Before generation begins, the planner walks the graph in dependency order and turns it into a list of actual image jobs. Prompt lists, model sets, seed sweeps, variations, and experiment matrices become rows. You can check the rows and the estimated storage before anything enters the queue.

I chose that design because a batch of 80 images is easier to understand as 80 named rows than as an abstract combination of branches. It also makes accidental combinatorial explosions visible before they eat an afternoon and fill a drive.

Deterministic image-processing steps in Studio use fingerprinted caches. Generation jobs still pass through the same model engines as the Create screen. ComfyUI goes deeper: you can decide where decoding happens, branch before or after sampling, add a second output, or insert a custom operation in latent space. Studio is useful for arranging supported work. It is not meant to expose every tensor that moves through a model.

Unified memory and offloading

Apple silicon has one unified pool of memory. The CPU, GPU, model weights, temporary tensors, decoded image, Radiant Canvas or Python process, and every other open app all draw from it. A 24 GB Mac does not have a separate 24 GB graphics card hiding inside it. No interface can change that.

Radiant Canvas gives memory guidance next to each download and keeps the policy inside the model engine. Only the selected inference path holds heavy model state. When you switch families, the other engines unload their heavy state instead of keeping several checkpoints around. There are fewer knobs because the app has already chosen how that supported model should be loaded.

ComfyUI has a general memory manager. It can unload models, offload components, and reuse cached values as the graph runs. That helps it attempt complicated workflows on many kinds of hardware. It can also make timing hard to predict. A graph that fits in memory may run smoothly, while the same graph at a larger resolution spends much of its time moving model parts around.

For either app, test the job you actually plan to run. Model precision, image dimensions, batch size, adapters, ControlNet models, and other open programs matter more than a broad claim that something runs on Apple silicon.

My rule on a Mac: leave room for the rest of the system, then test the largest job you expect to run.

LoRAs and ControlNet

Radiant Canvas PRO can import up to ten compatible LoRA or LoKr adapters. Presets stay with their model family, because an adapter trained for one base architecture should not casually appear as an option for another. Studio has nodes for masks, image editing, studies, batches, enhancement, and ControlNet guidance, but the list is defined by the app.

ComfyUI exposes these pieces as nodes. You can chain LoRAs, feed strengths from other parts of the graph, schedule them, apply them to regions, or use a community implementation of a technique released last week. If your work depends on a particular research repo or an odd conditioning method, this is usually the better place to try it.

Of course, the graph cannot prove that a random set of files makes sense together. You still need to know the base model family, expected trigger words, preprocessing, node version, and extra Python dependencies. Sometimes an incompatible pair fails loudly. Sometimes it runs and simply makes bad images.

Updates and custom nodes

ComfyUI Desktop has made installation much easier, but a node-based Python system still needs maintenance. Radiant Canvas comes from the Mac App Store. The models download later through Model Manager, so the app bundle does not include tens of gigabytes of weights. There is one application environment, and changes to a supported model path ship with an app update.

ComfyUI Desktop now handles much of the setup on Apple silicon and can manage separate instances. That is genuinely useful. You can leave a production setup alone while testing newer nodes somewhere else. A manual installation is still available if you prefer to manage Python, PyTorch, the repository, and dependencies yourself.

Custom nodes are the reason many people choose ComfyUI, and also the reason some installations become fragile. They are executable Python code with their own packages and update schedules. A Core update can expose an old assumption in a node. Two nodes can want different versions of the same package. An import can fail after an otherwise routine update.

This is normal for an open plugin ecosystem, not a special flaw in ComfyUI. It is still work. ComfyUI recommends reviewing custom nodes and installing them only from authors you trust.

Reopening an old workflow

ComfyUI can save the graph as JSON. Supported image files can also carry workflow metadata, which makes dropping an old result back into the interface surprisingly convenient. You may get the graph and seed back, but not the models, custom nodes, or Python environment. Another machine still needs compatible versions of all of them.

Studio saves a local .radiantstudio package. It contains the graph description and can carry imported assets, cached intermediate work, run plans, history, and references to results. Images also go into the local Gallery with their prompt, seed, model, and settings. The file format is useful only in Radiant Canvas, but there are fewer external pieces for it to describe.

A seed by itself is not a promise of identical pixels. Keep the exact weights and quantization, model mode or sampler, step count, guidance, dimensions, adapters, preprocessing, runtime, and software version if exact reproduction matters. This is true in both tools. Saving the finished image is still the safest part of the archive.

Offline use and network access

Once its model files are installed, Radiant Canvas generates locally. Prompts, outputs, history, metadata, Gallery records, and imported adapters remain in app storage. There is no Radiant Canvas account, analytics package, tracking, developer telemetry, or cloud generation service. You still need a connection for model downloads, App Store purchases, and the optional Apple enhancement-model download.

ComfyUI Core can run completely offline with local models. It also supports optional API and Partner Nodes that call remote services. So the right question is not simply whether ComfyUI is local. Check every node in the graph. ComfyUI has an option to disable API nodes if you want to keep built-in work offline.

Give custom nodes the same security review you would give any locally installed program. They can run code and they may use the network. For sensitive material, read the source or stick to a small set of extensions you understand. Radiant Canvas has a much smaller extension surface, which makes its network boundary easier to explain.

My answer

If I wanted to try a new model architecture on the day community support appeared, build a strange latent-processing chain, automate through an API, or work across image, video, audio, and 3D nodes, I would use ComfyUI. That is what an open graph system is good at. I would also expect to learn how that particular workflow is put together and keep its dependencies working.

If I wanted to sit down at a Mac, install a known model, compare a prompt across several supported engines, run a repeatable batch, and find the results later, I would use Radiant Canvas. That is the work I built it for. It trades model breadth and low-level access for a setup I can test from download to saved image.

You do not have to pick one forever. ComfyUI can live beside Radiant Canvas and cover the experiments the app does not support. For a lot of people, that is probably the honest answer: use the simple tool for ordinary work and open the larger toolbox when the job actually needs it.