September 2025 archive: verifying ComfyUI hardware compatibility
Hardware compatibility has several separate meanings: the application can start, its model components can execute, and the required workload can finish. This archive provides a device-specific acceptance process instead of treating a GPU brand or headline memory figure as proof of all three.
Identify the exact device and execution route
Record the accelerator model, operating system, driver and ComfyUI installation method. Check the maintained system requirements for that combination. Do not infer support for an entire product family from one working demonstration or from a system that uses a different backend.
For reference, NVIDIA specifies 24GB GDDR6X for the standard RTX 4090 and 32GB GDDR7 for the RTX 5090. These physical capacities do not establish how much memory a particular graph needs. They also do not turn system RAM into additional physical graphics memory.
Separate capability from workload size
Begin with an official basic example and required model components. A successful small output confirms only that tested route. It does not establish that a larger image, longer video or optional enhancement stage will fit or finish within your delivery deadline.
Write the real output requirements before testing: dimensions, model identity, format and acceptable quality. Keep the workload unchanged when comparing devices. If one route changes precision or reduces the output size, report that as a different condition rather than an equivalent result.
Measure without mixing resource categories
Use device diagnostics to identify the installed hardware and its reported memory. Keep units and tool names alongside readings. Device-wide memory, framework allocations and operating-system shared-memory figures represent different things and should not be summed into a new capacity claim.
Record where failure occurs and whether other applications occupy the accelerator. Preserve logs for unsuccessful attempts as well as the final output. Offloading may allow completion with a time penalty; evaluate that as a changed execution strategy, not a physical hardware upgrade.
Make acceptance conditional and repeatable
Repeat important cases after restarting the application and check the saved files. Distinguish cold-start setup from subsequent runs. A stable acceptance record includes the graph, dependencies, permitted inputs, conditions and observed limitations, allowing another operator to understand what passed.
This archive does not publish a new accelerator ranking or claim a measured increase in adoption across vendors. Use the linked manufacturer and maintainer documentation for current specifications, then test your actual task. Recheck acceptance after a driver, application or model change instead of carrying a previous success forward indefinitely.