January 2026: Hardware support with explicit conditions
January's defensible hardware story is conditional support, not universal parity: the official announcements name software versions, acceleration requirements and workload limits. This corrected archive separates those statements from a test plan for your own system.
Dated announcements
On 6 January, Comfy announced Windows Desktop AMD ROCm support from v0.7.0, based on ROCm 7.1.1 for supported hardware. This is not a claim of support for every AMD device. Comfy: AMD ROCm on Windows (2026-01-06; company announcement).
On 9 January, the maintainer described NVFP4 acceleration on Blackwell with a CUDA 13.0 PyTorch build, and workload-dependent async offloading. It warned that an incompatible build could be slower. Its benchmark results are upstream observations, not 42.uk measurements. Comfy: NVIDIA optimisation conditions (2026-01-09; maintainer technical report).
Funding and valuation status
No additional financing announcement is established for this month by the reviewed sources. This is not proof that no financing occurred. See the dated funding register; past totals and valuations are not new monthly raises.
What this changes: editorial analysis
The useful change is a better-defined compatibility matrix. Application support, accelerator kernels and a particular model's execution path are separate dependencies. A successful installation proves neither speed parity with another vendor nor capacity for an arbitrary video workload. Compare like-for-like conditions rather than replacing the former unsupported ranking with another ranking.
Separate a format that can load from a format that accelerates on the installed device. A fallback may preserve correctness while changing latency substantially. Record the actual backend and build instead of relying on the model filename. Likewise, offloading changes the balance between system memory, transfers and device memory; it does not increase the physical capacity of the card.
The earlier article also presented future migration and hardware forecasts as though they established a new baseline for every user. This revision makes no such promise. Retain a working environment and test one change at a time. If a workflow needs a different model variant or output size to finish, record a different test condition rather than reporting an equivalent result.
Proposed verification scaffold, not executed tests
- Capture the precise device, driver, operating system, application revision and framework build. Confirm the supported installation route before changing it; preserve a recoverable baseline.
- Run the same permitted inputs, model revision and output settings before and after the change. Record cold loading separately from repeated generation, and retain failed attempts alongside successful outputs.
- Inspect the saved deliverable, not only a sampler timer. State measurement tools and units for memory and elapsed time. Publish a bounded result for that graph and machine, not a percentage covering an entire GPU brand.
Record the environment, exact versions, permitted inputs, output location, failures and acceptance decision. No pass result is implied by this checklist. Use the workflow evidence guide and measurement method for the corresponding record formats.
Open questions and next review
- Which workload and backend combinations actually pass on the intended device?
- Does a memory-saving change affect fidelity or complete delivery time?
- Can another operator reproduce the accepted configuration after restart?