How ProsGrow Reached 59,881 FLUX.2 Image Variants per Hour

The whole image service sets capacity

A catalog team needs approved image variants delivered to its workflow. The service combines prompt encoding, denoising, decoding, API handling, PNG encoding, and output saves. Faster model execution changes which stage limits delivery.

ProsGrow measured that complete path with FLUX.2 Klein 4B. Native NVFP4 raised throughput by 32.5% in a matched single-GPU comparison. The next challenge was shared infrastructure: the profile that made one GPU fastest became slower when deployed across the node. Profiling that reversal led to a service configuration delivering a measured rate of 59,881 image variants/hour.

A controlled precision comparison

The official NVFP4 checkpoint comes from Black Forest Labs, and ComfyUI supplies the native quantized execution path. ProsGrow validated that the intended precision path was active, held the workflow constant, and measured through PNG save. The result was 24.5% lower request latency alongside the throughput improvement.

Lower memory use created room to overlap work, but precision alone did not fill the node. The first NVFP4 deployment sampled only 52.5% activity in the GPU compute units. That motivated a closer look at scheduling and the host stages between GPU operations.

The local optimum lost at node scale

ComfyUI serializes a workflow queue. Overlapping independent resident workers allowed GPU work to continue while other requests handled API traffic, PNG encoding, or filesystem output. On an isolated GPU, more overlap improved utilization and throughput.

The same direction did not hold at node scale. The fastest isolated-GPU profile delivered only 46,759 images/hour when every GPU competed for the same host resources. A less crowded service topology delivered 57,540 images/hour in its conservative repeat. Low-power plateaus were consistent with stalls in host, API, PNG, or filesystem stages; the traces did not isolate a single component as the sole cause.

This is the central systems lesson: the local optimum is not the node-level optimum. Higher isolated GPU utilization can create more contention elsewhere. ProsGrow selected the service topology from synchronized node measurements, considering completed outputs, memory use, and variation between runs together.

Capacity for a defined creative workflow

A creative workflow often asks for several versions of one asset. For that service contract, ProsGrow evaluated producing two variants of one prompt per request. The selected profile reached 59,881 variants/hour, using the lowest of three synchronized node runs. That was 4.07% above the previous conservative node rate, with a 1.61% run-to-run spread.

The capacity unit matters: generated variants are not distinct prompts. The client reused a controlled prompt and varied noise seeds, and ComfyUI caching remained available. The result does not measure a diverse stream of new prompts or fresh prompt encoding on every request.

All 2,880 measured outputs were accounted for, with no selected error-marker hits. Each run lasted about 57 seconds. This supplies a measured starting point for a customer pilot; sustained arrivals, queueing, and customer acceptance still determine usable capacity.

What the capacity means for cost

Capacity can inform a cost study once demand and service requirements are explicit. Under the existing $100,000 node scenario at 10% paid demand, the measured rate corresponds to 52.46 million sold variants per year. Modeled annual infrastructure cost of about $40,058 gives $0.000764 per sold variant.

That scenario assumes three-year amortization, 5% annual maintenance, an 8,760-hour year, electricity at $0.10/kWh, a 1.30 power-usage multiplier, and server power of 1.016 kW idle and 6 kW active. It excludes labor, business operations, networking, storage, and service reserves. Demand and accepted-output rate must be validated before using it for a purchase decision.

The selected profile also measured 0.0571 Wh of GPU-board energy per image, excluding the host and cooling. Both figures are tied to the repeated-prompt, two-variant contract. They do not establish hosted-service quality or cost equivalence.

Choosing a production operating point

For a batch creative workflow, accepted variants per hour can be the useful target. An interactive tool also needs low request latency and room for bursts. Worker overlap consumes memory and shared host capacity, so the selected configuration must leave headroom for input processing, storage, retries, and the intended arrival rate.

The measured process connects precision validation to service profiling and node-level verification. It makes the next customer decision concrete: does the representative prompt mix retain the capacity gain at the required quality and delivery deadline? That is the basis for sizing a private endpoint.

Methodology and limitations

• Hardware and software: one eight-GPU RTX PRO 6000 Blackwell node, 96 GB nominal memory per GPU; ComfyUI 0.32.0, comfy-kitchen 0.2.30, PyTorch 2.11.0, CUDA 13.0. The NVFP4 checkpoint revision was 1db2b2f7.
• Workload: FLUX.2 Klein 4B, 1024×1024 output, four Euler steps, and a controlled studio product-photo prompt. The matched precision comparison produced one image per request; the selected node profile produced two variants per request. Repeated prompts and available caching limit inference about diverse customer traffic.
• Timing: models were loaded and warmed before timing. The matched ComfyUI comparison includes API queue/poll overhead, prompt encoding, denoising, VAE decode, PNG encoding, and save, with 30 measured requests per precision. An earlier Diffusers result excludes PNG encoding and is not the precision baseline.
• Node aggregation and repetition: selected rates divide total outputs by the common window from the first measured client start to the last completion. The selected rate is the minimum of three short runs of 960 outputs each, with 92.49% scaling efficiency relative to eight times its isolated-GPU rate. Earlier summed-worker rates are not used as a matched node baseline. These measurements do not establish a sustained production SLA.
• Quality: eight selected outputs were visually inspected. All were coherent product photos with a legible requested label; six had a clean exact label, one added small text, and one added a punctuation artifact. This smoke test does not establish broad quantization quality, prompt adherence, typography, moderation, or customer acceptance.

Measurements were collected August 12–21, 2026. Hosted API quality, operational reliability, and total cost were not tested for equivalence.