Issue link: http://digital.copcomm.com/i/1545821
a p r i l • m ay • j u n e 2 0 2 6 c g w 5 Figure 2. The same 38 scenes: speedup vs previous-generation per- frame render time (log scale). A loose positive trend (Spearman p ≈ ≈ 0.34, two-sided p ≈ 0.04 — modest, not predictive): short, over- head-bound frames sit low; heavier, compute-bound frames gain more, with real scatter, including one heavy scene held at 1.6×. A I D E N O I S I N G W A S A L R E A D Y T H E D E F A U LT Ask where AI actually sits in a production rendering pipeline in 2026 and our logs give an unglamorous answer: in the denoiser, qui- etly, on most Cycles jobs. On Blender Cycles, our dominant GPU engine, more than four in five jobs on the 5090 node — about 83% — ran an AI denoising pass as standard, and the rate on our previous-generation nodes is essen- tially identical. Every render-time denoiser Cycles has offered since Blender 3.0 is AI-based — OptiX or Intel Open Image Denoise — and our jobs span Blender 3.6 through 5.1. Read together, the story tells itself: AI denoising was already standard on the old hardware, and stayed standard on the new. The hardware generation didn't change denoising behaviour — it changed the speed of everything around an already-routine step — so for a denoise-heavy pipeline, a new card isn't buying you "AI," which was already there; it is buying path-trac- ing throughput. One scoping note: this is about Cycles. Other engines log denois- ing differently, or not at all, so we won't stretch the number to "all GPU jobs" — and we'd encourage skepticism toward any farm-wide AI percentage not scoped to an engine. Figure 3. Blender Cycles render jobs running an AI denoising pass (Op- tiX / Intel OIDN), April–May 2026 — about 83% on both the RTX 5090 node and the previous-generation nodes. Cycles-scoped. V R A M I N T H E W I L D Cycles writes its peak device-memory figure into the render log — a usable, if humble, proxy for what production demands of VRAM. These are log-derived figures, not per-card telemetry, which we plan to stand up on the newer nodes. Across the Cycles jobs on the 5090 node where that line was recorded — 57 in the window — peak render-device memory was about 5.6 GB at the median and 11.5 GB at the 90th percentile. Our previous-generation cards are 10–12 GB parts, so the median job would have fit; the 90th-percentile job was already brushing their ceiling. And the tail runs further: the heaviest job logged roughly 37 GB — past even the 5090's 32 GB, the kind of scene that on a GPU render means a CPU fallback or no render at all. Operators know the rule: you size VRAM for the tail, not the medi- an. On the day one job wants thirty-plus gigabytes resident, the gap between a 12 GB and a 32 GB card is the gap between rendering and not — the reason both oversized on-card memory and shared render infrastructure exist. Figure 4. Peak render-device memory, Blender Cycles jobs on the RTX 5090 node (57 logged jobs, April–May 2026). Log-derived, not GPU telemetry. The heaviest job exceeded even the 5090's 32 GB. O N E D R I V E R , Z E R O C H U R N The least dramatic finding is the one we'd most want before buy- ing. One driver — 581.80 — ran the entire window, April 1 through May 22, with zero churn: no rollbacks, no mid-window swaps. The stack was CUDA 13.0 throughout; our previous-generation nodes ran 565.90 over the same stretch. For early-cycle hardware on a produc- tion queue, a boring driver log is the compliment. Figure 5. One driver (581.80 / CUDA 13.0) ran the entire first production window (April 1 – May 22, 2026) with zero driver-related churn.