How to Choose Cloud GPUs for ComfyUI: The VRAM, Bandwidth, and Per-Image Cost Comparison Between RTX 5090 and H100 for FLUX.2 and Video Generation

In 2026, FLUX.2 (a 32B-parameter DiT model) and video generation models like Wan 2.1/2.2 and HunyuanVideo have fully entered production workflows in ComfyUI. The question of how to choose cloud GPUs is no longer “which card has the most compute power,” but rather “under the same workflow, is the 32GB VRAM of the RTX 5090 sufficient? How much slower is it than an H100? What are the actual cost differences per image and per video? When is an 80GB VRAM card a must?” This article uses test data from a fact pack to clarify the three key metrics: VRAM, bandwidth, and cost.

1. The Variables in Choosing Cloud GPUs for ComfyUI Have Changed: Dual Pressure from FLUX.2 and Video Models

In the past, image workflows dominated by SDXL focused on peak VRAM usage for single images. But FLUX.2 and video models have changed the game: on one hand, FLUX.2 is a 32B-parameter DiT model with significantly higher resident weight sizes compared to earlier SD series; on the other hand, video generation requires processing a large number of intermediate tensors over time, easily pushing peak VRAM beyond 32GB. According to test data from March to July 2026, the RTX 5090 (1,792 GB/s GDDR7, 32GB VRAM) achieves about 89% of the throughput of an H100 PCIe (2,000 GB/s HBM2e, 80GB VRAM) in ComfyUI image and video diffusion inference, while its on-demand rental cost is only about 38% of the latter ($0.76/hour vs. $2.01/hour). The above are comparative data from a set of ComfyUI diffusion inference tests from March to July 2026 (RTX 5090 vs. H100 PCIe), not universal conclusions, and they vary with workflow and billing plans. This means the key metrics for choosing cloud GPUs for ComfyUI have shifted from the strict “the more VRAM, the better” to a balance between bandwidth and VRAM residency.

2. Breaking Down the VRAM Usage of a ComfyUI Node Graph: How Much Do Weights, VAE, ControlNet, and Intermediate Tensors Consume?

To determine whether 32GB VRAM is sufficient, you need to first account for who consumes VRAM when running an image or video. The following VRAM breakdown is based on a ComfyUI video workflow test from 2025 to March 2026 (Wan 2.1/2.2 14B, 720p, unquantized); actual usage varies with resolution, frame count, and quantization precision. A typical ComfyUI workflow consumes VRAM primarily in four parts:

1. Persistent model weights: DiT models like FLUX.2 with 32B parameters keep weights resident in VRAM. FP8/GGUF quantization can reduce both resident and peak usage (however, this article does not provide specific weight VRAM numbers, as they are not covered by public test data).
2. VAE encode/decode peaks: The VAE creates high-resolution intermediate tensors when encoding inputs or decoding outputs, and this momentary peak is often the culprit behind OOM errors. The peak rises with output resolution and sequence length; whether it exceeds 32GB must be determined by measuring the peak VRAM usage.
3. ControlNet/LoRA residency: Each additional ControlNet or LoRA increases resident VRAM, and the exact increment depends on your workflow's VRAM monitoring readings. Production workflows often use multiple control tools, and their cumulative impact should not be underestimated.
4. Intermediate tensors for video sequences: Video models (such as Wan 2.1/2.2 14B) need to process the latent representation of each frame during inference. At 720p resolution, unquantized inference requires peak VRAM between 65GB and 80GB, which is beyond the capacity of a 32GB GPU. Even with Temporal Tiling to reduce peak usage, the tiled intermediate tensors may still exceed 32GB, especially with longer frame sequences.

So, for FLUX.2 single-image generation or short-to-medium video sequences, with FP8/GGUF quantization and Temporal Tiling, 32GB VRAM can work. However, for unquantized inference of 14B video models on long 720p sequences, 80GB VRAM is a hard requirement.

3. The Bandwidth-Throughput-Price Triangle: What Do 89% Throughput and 38% Cost Really Mean?

Every diffusion iteration heavily depends on VRAM bandwidth—whether reading model weights or reading/writing intermediate tensors. The RTX 5090's 1,792 GB/s and the H100 PCIe's 2,000 GB/s differ by about 10%, so the theoretical bandwidth ratio is about 89.6%, and the measured throughput ratio is approximately 89%. The closeness of the 89.6% theoretical bandwidth ratio to the 89% measured throughput ratio serves as evidence that diffusion steps in this test are primarily bandwidth-sensitive; this is an inference based on two numbers, not a conclusion from the test provider, and it does not represent all node graphs (including those with VAE decoding or many CPU-side nodes).

Looking at unit-time performance alone, the RTX 5090 is slightly inferior to the H100. But when cost is factored in, the conclusion changes completely. On-demand rental for the RTX 5090 is about 38% of the H100's price, but its throughput reaches 89% of the H100's, so its unit-cost performance (i.e., throughput per dollar) is about 2.34 times higher (89% ÷ 38% ≈ 2.34, calculated from the given ratios, excluding load time and idle time). In other words, if a task fits within 32GB VRAM, the RTX 5090 offers overwhelming cost-effectiveness.

4. Converting Hourly Rate to Per-Image/Per-Video Cost: A Reusable Formula

When choosing a GPU, don't just look at the hourly rate; a better metric is the per-image or per-video cost. The calculation formula is simple:

Per-image cost = hourly rate ÷ (3600 ÷ time per image)

But be careful: you should not only consider the steady-state generation time, but also include the following in the denominator:

• Model loading time (happens every time a workflow is launched, especially when frequently switching models)
• Queue idle time (instance idle but still billed)
• Retry time after failures (e.g., restart after OOM)
• Time to re-run with reduced resolution (when running with lower resolution due to insufficient VRAM, then re-running after quality loss)

Based on the earlier facts, we provide an example calculation (note: this is a proportional estimate, not actual test data): Assume a workflow generates an image in 2 seconds on an H100. Then it can generate 1,800 images per hour, with a per-image cost of about $2.01/1800 = $0.00112. Since the RTX 5090's throughput is 89% of the H100's, its per-image time is about 2.25 seconds, yielding 1,600 images per hour and a per-image cost of about $0.76/1600 = $0.000475. Clearly, the RTX 5090's per-image cost is much lower than the H100's. However, if the workflow requires lower resolution or segmented processing due to insufficient VRAM, leading to a significant increase in time, the cost advantage may be offset.

Similarly, per-video cost = hourly rate × total time per video / 3600. Suppose a video workflow on an H100 takes 60 seconds per segment (including model loading and idle time), then the per-segment cost is about $2.01 × 60/3600 = $0.0335. For the RTX 5090, using the 89% throughput ratio, the time is about 67.4 seconds, and the per-segment cost is about $0.76 × 67.4/3600 = $0.0142. But if you factor in one OOM retry (assuming retry time accounts for 10% of steady-state time), the effective cost rises: the H100's actual cost is about $0.0369, and the RTX 5090's is about $0.0156. These are calculations based on the given ratios and assumed overhead, not actual measurements. Therefore, readers should replace the example numbers with their own workflow times to obtain true comparative conclusions.

5. When 80GB VRAM Is Irreplaceable: High-Resolution Long Videos, Multiple Resident Models, and Concurrent Queues

Despite the RTX 5090's cost-effectiveness, there are three scenarios where 80GB VRAM is irreplaceable, or at least a necessary choice:

1. Unquantized inference of 14B-class video models on high-resolution long sequences: As mentioned, unquantized 720p inference requires 65GB–80GB VRAM, which exceeds the 32GB limit. While Temporal Tiling and quantization can reduce peak usage, the fact pack only covers unquantized 720p inference (65GB–80GB). It's reasonable to infer that 1080p or longer sequences require more VRAM, but there is no public measurement data, so rely on your own peak VRAM measurements.
2. Multiple models resident simultaneously: Production environments may need to load a base model, multiple LoRAs, ControlNets, and VAE copies at the same time, and the cumulative resident VRAM can easily exceed 32GB. Especially in queue scenarios where tasks need to switch quickly, frequent model loading/unloading reduces efficiency, and it may be better to use an 80GB GPU to keep all models resident.
3. Concurrent batch processing queues: AIGC teams often need to process multiple tasks simultaneously, each possibly containing several images or videos. While time-slicing can reduce peak usage, when concurrency increases, total VRAM demand grows with the number of concurrent batches (the increase depends on whether weights are shared and intermediate tensors are reused), and 80GB provides greater flexibility.

It's worth noting that quantization (FP8/GGUF) and Temporal Tiling can bring some video generation cases back into 32GB, but they cannot bring all cases back—especially when dealing with long sequences, high resolutions, and multiple control tools stacked together. In such cases, 80GB is still necessary. Therefore, don't try to completely replace the H100 with the RTX 5090; instead, make choices based on specific task boundaries.

6. Conduct a Cross-GPU Test with On-Demand Resources on the Same Workflow

Theoretical calculations must be validated with real tests. We recommend using on-demand cloud GPU resources to run the same ComfyUI workflow on different GPU types, recording the following data:

• First load time (model + VAE loading)
• Steady-state per-image/per-video time (average over multiple runs)
• Peak VRAM (observed via monitoring tools)
• Failure rate (number of OOM or timeout occurrences)

Then, use this data to back-calculate per-image/per-video costs and decide on the long-term GPU type. NexGPU, as a GPU cloud compute and AI server rental platform, offers various GPU server models, on-demand usage, and pre-built models and application templates that can be used to run the same workflow JSON across different GPU types; specific available models are subject to the platform's actual page. This way, your final choice is not based on advertisements or reviews, but on the real costs of your own workflow.

7. Checklist for Choosing Cloud GPUs for ComfyUI and Common Pitfalls

Finally, here is a practical checklist to help you avoid common pitfalls:

1. Order of debugging VRAM overflow: First check if the VAE decoding peak is too high (try tiled decoding), then see if the video sequence length is too large (try Temporal Tiling), and finally check if there are too many resident nodes (e.g., redundant ControlNets). If peak VRAM consistently exceeds 90%, consider reducing sequence length or decreasing resident nodes.
2. Cost inflation from frequent model loading: If your workflow frequently switches models, the model loading time becomes a significant part of the total time. In that case, it might be more cost-effective to use an 80GB GPU to keep models resident. If model loading time accounts for more than 20% of the total task time, consider a resident-memory solution.
3. Queue idle time and instance idle billing: On-demand instances still incur charges during task gaps. Consider using auto-sleep or shutting down early. If idle time exceeds 10% of total time, enable auto-sleep.
4. Quantization precision vs. image quality: FP8/GGUF can significantly reduce VRAM requirements but may affect quality. Use it within acceptable limits and test output at different precisions. It's advisable to run the same workflow in both FP8 and FP16 to compare quality and time.
5. Decide based on per-image cost, not hourly rate: As shown in Section 4, a higher hourly rate does not necessarily mean a higher per-image cost; the key is throughput and VRAM fit. Use the formula “per-image cost = hourly rate ÷ (3600 ÷ time per image)” and include load and idle times.

In summary, choosing cloud GPUs for ComfyUI is no longer an arms race for computing power, but a balancing act among VRAM, bandwidth, and cost. We recommend that you first run a cross-GPU comparison test on the most representative workflow using on-demand resources to obtain your own per-image/per-video costs before making long-term procurement decisions. If you want to get started quickly, you can begin validation from the platform's pre-built models and application template environments.