By the prime number theorem, the average (asymptotic) distance from a prime $p$ to the next prime is $\log p $. So, on average, one must test $\log p$ integers for primality before finding the next prime. However, $\log p$ grows very, very slowly: even for 1024-bit numbers, $\log p \approx 710$.
Primality testing is well-understood, and very fast algorithms exist. For example, per AKS primality test, there exists a deterministic primality test with runtime $\tilde{O}(\log^6 p)$. Since we would have to run this test for (on average) $\log p$ integers, the runtime ends up becoming $\tilde{O}(\log^7 p)$. That's if you want an asymptotically-fast, deterministic test; in practice something like Miller-Rabin will do better, with a runtime of $\tilde{O}(k\cdot\log^3 p)$.
I guess the answer is "not much CPU time at all," but how much exactly depends on the CPU, memory speed, algorithm chosen, system load/usage, ... etc. All of those messy details are abstracted away with the use of Big-O notation (as above), so I think that's a more useful viewpoint.