Covering Your Article Images Locally — ComfyUI, FLUX, and Reading the Licence Right

One article needs a dozen illustrations. On a metered generation service, the working method of producing ten and keeping one means paying for the nine you discard. That structure is why images are usually the first workload people move onto their own hardware. The unit price is higher than text and the hit rate is lower.

There is something to settle before moving, though, and it is not hardware. It is the licence. Get it wrong and you may not be able to use the images — or, worse, running the model at all may be outside the terms. With FLUX.1 in particular, reading only the summary on the model card leads you to the wrong conclusion. So that is where this starts.

Read commercial use as two separate questions

FLUX.1 comes in two lines with fundamentally different licences.

The first row is the problem, because model use and output use are governed by different clauses.

Section 2(b) of the FLUX.1 [dev] licence reads: You may only access, use, Distribute, or create Derivatives of the FLUX.1 [dev] Model or Derivatives for Non-Commercial Purposes. Access, use, distribution and derivative work are all confined to non-commercial purposes.

Section 2(d) reads: You may use Output for any purpose (including for commercial purposes), except as expressly prohibited herein. The images are yours to sell.

So the picture can go on a product page while the act of running the model is restricted. Read the two as one and you will decide wrongly.

Reading the definition of non-commercial

Section 1(c) defines it: use for which you receive no payment, directly or indirectly. It expressly includes personal use for research, experiment and testing that contributes to public knowledge, and testing, evaluation and non-commercial research and development by a commercial entity in a non-production environment.

That last part is worth noting — a company evaluating the model internally is inside the non-commercial boundary.

The exclusions are where it bites. Section 1(c) explicitly excludes (a) use for revenue-generating activity, (b) use involving direct interaction with, or effect on, end users, and (c) use to train, fine-tune or distil other models for commercial purposes.

(a) is the one that matters here. Generating images for a site carrying advertising or affiliate links can be revenue-generating activity. Running it to evaluate and running it to earn are not the same case.

A commercial route exists. Section 2(b) states you must request a license from Company, granted at the rights holder discretion and potentially subject to fees, royalties or revenue share. Requests go to bfl.ai.

I am not a lawyer and I will not rule on where any particular use falls. What I can do is show you what the clauses say. If you need a determination, ask the rights holder or a professional.

schnell as the alternative

For anything with revenue attached, the choice is uncomplicated. The FLUX.1 [schnell] card states: Released under the apache-2.0 licence, the model can be used for personal, scientific, and commercial purposes. Apache 2.0, commercial use of the model itself permitted. Twelve billion parameters, same as dev. The question simply disappears, which is reason enough to start here if you are hesitating.

There is a structural difference to respect. The official description says schnell can generate high-quality images in only 1 to 4 steps, and the official example uses four. Handing a four-step model fifty steps mostly takes ten times as long without getting better. The reverse holds too: run a many-step model at four steps and the output falls apart.

I later moved again, to Z-Image-Turbo, also Apache 2.0. The reason was memory rather than licensing — as the measurements below show, the schnell configuration was sitting above ninety percent VRAM utilisation. Those two moves ended up walking straight into the conclusion of this article.

What ComfyUI is actually doing

At the centre is a visual node graph for building and reusing image, video, audio, 3D and text workflows without writing code. The part that matters for production work is that the pieces are separable: model, text encoder, sampler and post-processing are distinct nodes. A tool where everything lives in one box cannot give you that, and it is the difference between swapping one file when you change models and rebuilding the pipeline. The licence is GPL-3.0.

Driving it from the API

Here is the real subject. Opening the interface and generating one image at a time does not scale to twelve per article. The official description mentions reusable subgraphs, workflow templates, App Mode, and a local API for integrating workflows into applications. There is a local API, and workflows can be embedded in your own programs.

1. Build the workflow in the interface and export it in API format.
2. Turn the parts you want to vary into placeholders — prompt, seed, model name.
3. Substitute the placeholders and submit for each generation.
4. Wait for completion and collect the images.

With that in place, you can generate prompts from an article outline and submit the whole set at once. No per-image clicking.

Memory handling is documented too: asynchronous queueing, partial graph re-execution, smart VRAM and RAM management, model offloading, and support for quantized models. Asynchronous queueing is what lets you stack the batch and walk away.

The item that matters most in practice is partial graph re-execution. Re-running only part of the graph means that changing the prompt alone does not reload the model. Across twelve consecutive images that difference decides most of the wall-clock time; get it wrong and loading takes longer than generating.

Model offloading deserves a note as well. Spilling what does not fit in VRAM into system memory is why you can run slightly over your limit. The moment spilling starts, speed drops. Running is not the same as being correctly configured.

Design it as a long-running job

Submitting a batch turns generation into a long job, which brings its own concerns.

First, do not make it fight another process for the GPU. If a language model is resident at the same time, both slow down and the failure looks like a model problem rather than a scheduling one.

Second, decide the unit of failure before you start. Making ninety-four images one job means asking what survives when it dies at image eighty. If each image is written to disk as it completes, the finished ones remain. That is the same principle as the chunked design in turning long articles into audio with local TTS.

Quantisation to bring VRAM down

Loading a 12B model at full precision is expensive. GGUF quantisations of FLUX.1 are published at these sizes:

The same arithmetic as language models applies, and it is spelled out in estimating what fits in your VRAM. The trap specific to image generation is below.

The trap in comparing generation times

Measured under conditions I can state: NVIDIA GeForce RTX 5070 Ti, 16 GB of VRAM (16,303 MiB), output at 1280×720.

Two readings. First, step count dominates the time. Four steps against nine steps twice is a four-fold difference. On identical hardware, changing steps moves the duration proportionally.

Which means a generation time quoted without a step count is useless for comparison. When you read someone reporting how many seconds it took, look for the step count first; if it is missing, the number cannot inform your decision. By the same standard, the seconds in my table only mean something alongside the GPU model and the output resolution.

Second, VRAM. The schnell configuration used 15.4 GB of 16, leaving 890 MiB free at peak. The whole desktop gets sluggish during generation in that state. The cause is that the T5XXL text encoder adds about 4.9 GB on top of the 8.26 GB model, so shrinking the model alone does not fix it — the encoder has to be part of the reconsideration.

This connects straight back to hardware choice. Narrow the options by licence, and then the final decision is whether it fits the memory you have. Image generation is where the text encoder is easiest to forget: judge by model file size alone, conclude that 16 GB is enough, and you end up technically fitting with no room to work in. The card-by-card figures are in what to buy first for local AI.

Fixing a style is a production decision

Twelve images that do not look related do not read as one article. Two mechanisms handle it. Freeze the shared part of the prompt — palette, compositional policy, prohibitions — with identical wording across every prompt; the image prompts on this site all share one style sentence across sections. And freeze the seed where you want variation to come only from the subject.

Both are trivial once generation runs through the API and impossible to hold consistently when you are typing into a window twelve times.

What it is worth in 3D printing work

Product photography for a listing is the obvious one, and the compositional side of that is in deciding what to sell before you print it. Less obvious but more useful day to day: assembly diagrams and step illustrations for a build guide, generated as a consistent set rather than photographed one at a time.

If what you need is geometry rather than pictures, that is a different stack — the open-source 3D generation piece covers it.

Summary — licence first, seconds later

• FLUX.1 [dev] restricts use of the model to non-commercial purposes while permitting commercial use of the output. The two clauses are separate.
• Revenue-generating activity is expressly excluded from the non-commercial definition; a commercial licence is requested from the rights holder.
• FLUX.1 [schnell] is Apache 2.0, so the question does not arise. Twelve billion parameters, designed for 1 to 4 steps.
• ComfyUI (GPL-3.0) exposes a local API; partial graph re-execution is what makes a twelve-image batch fast.
• Design batches so each image lands on disk as it finishes, and keep other GPU work off the machine.
• Step count dominates generation time. A time quoted without steps, GPU and resolution is not comparable.
• The text encoder is part of the VRAM budget. Shrinking the model alone will not create headroom.

Sources

• Black Forest Labs — FLUX.1 [dev] model card and Non-Commercial License
• Black Forest Labs — FLUX.1 [schnell] model card (Apache 2.0, 1 to 4 steps)
• ComfyUI on GitHub (GPL-3.0)

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.