CUDA and OptiX are not two speeds of the same backend. In Blender’s Cycles renderer, CUDA is a general-purpose compute API, while OptiX is a domain-specific ray-tracing API that dispatches BVH traversal and denoising to RT cores and tensor cores through a path a hand-written CUDA kernel cannot reach. Picking whichever one renders a single benchmark scene faster answers a narrower question than most people think they are asking.

Why isn’t OptiX just a faster CUDA?

Because the two APIs do not describe the same work. A CUDA kernel expresses arbitrary parallel compute: you own the memory layout, the dispatch, the traversal loop. OptiX expresses a ray-tracing pipeline — you hand it acceleration structures and shader programs, and the driver decides how to walk them. On RT-core GPUs that decision routes ray/box and ray/triangle intersection into fixed-function silicon, and the OptiX denoiser runs on tensor hardware. That is where the render-time delta on heavy path-traced geometry comes from: work moved off the shader cores, not code that happens to be better optimised.

The corollary matters more than the benchmark. A general-purpose CUDA kernel cannot be retargeted to a domain-specific API by translation alone, because the specialised path only accepts work shaped the way it expects — its own acceleration structures, its own program model. The rework is structural, not syntactic.

When CUDA is still the correct Cycles backend

Situation	Correct backend	Why
RT-core GPU, heavy path-traced geometry, many samples	OptiX	Intersection and denoising move into fixed-function and tensor hardware
Pre-RTX NVIDIA card	CUDA	No RT cores to dispatch to; OptiX support is limited or absent
A Cycles feature the OptiX path does not support in your build	CUDA	Correctness before speed — a faster wrong render is not a render
Non-rendering GPU compute (training, inference, simulation)	CUDA	OptiX describes ray tracing, not general compute
AMD or Intel hardware	HIP / oneAPI	These are the vendor equivalents of the CUDA path, not of OptiX

Render time improvements vary wildly by scene complexity

OptiX delivers steeper speedups in path-traced scenes with deep bounce counts and heavy denoising, while CUDA remains competitive in simpler shading networks or when debugging custom kernel code. Same scene file, same sample count, same denoiser setting, same driver version, same thermal state — then measure wall-clock minutes per frame on each backend. Anything less and you are attributing scene or driver variance to the backend. For production work, express the result as node-hours per shot rather than seconds per benchmark frame; that is the number that survives contact with a budget.

We apply the same discipline outside rendering, because the underlying question is identical: is the current API structurally suited to the workload, or is specialised hardware sitting idle behind a general-purpose code path? Our GPU engineering practice treats that as an audit question, not a preference.

Where this gets misused: a Cycles benchmark result is a statement about one renderer on one GPU class. It is not a general verdict on general-purpose versus specialised GPU APIs for engineering workloads, and reading it that way transfers a consumer rendering conclusion to a workload it never described.

So the sharper question is not which backend wins — it is whether your workload has a fixed-function path at all, and what it would cost to reshape the code to reach it.