There's no exact answer, and here's why:
We start with a 128-bit symmetric key. Assuming the algorithm (e.g. AES) isn't yet broken, we have to look at power consumption. Assuming 100% efficient computation devices whose technology far exceeds any computer, ASIC, graphics card, or other key-cracking device you can dream up, there's a minimum energy requirement for just flipping the bits to count that high. Wikipedia has done the math for us, and it comes out to, for a 128-bit key, the minimum energy requirement demanded by physics is approximately 1018 joules, or 30 Gigawatts for one year. Obviously with "real" hardware, the requirement would be several hundred thousand times that; more than the energy production of the entire world. So that's well outside the capability of any existing terrestrial body.
But if we move to a 256-bit key, the math gets more serious. Schneier did the math on this one in Applied Cryptography, and it's been discussed here before. To avoid boring you with repeated details, I'll simply cut to the conclusion: our sun does not produce enough power to accomplish this task.
Theoretically reversible computing (which may be possible with quantum computers) could cut the effective bit length by half, making such a project merely beyond the reach of any existing power, rather than beyond the reach of physics entirely. But that's all academic.
The take-away is this: brute-forcing a reasonably-sized symmetric key cannot be done. Not by you, not by anyone.
So, how many rounds of PBKDF2? If the attacker has to choose between waiting 10 years for the key derivation complete versus building a Dyson sphere around the sun, the PBKDF2 route is still faster. By any practical metric, adding more time to your key derivation means adding more time to the attack, and at no point does trying to brute-force the key ever become an option (unless the PBKDF2 route also requires an extraterrestrial construction project).
So, where's the equivalence point? When does brute-forcing PBKDF2 require the whole Dyson Sphere setup? The answer is: it depends. See, the whole point to using the hash process in your attack instead of guessing the key itself is so that you try fewer password. If you know the password is either "monkey" or "123456", then you'd rather guess only twice, instead of trying to by luck hit the correct hash in a sequential scan.
So the answer depends on the size of the dictionary your attacker will use in his attack. If he knows the password exact, then he only guesses once. And therefore, the brute-force attack will take exactly as long as the correct login. However long you make that out to be. If he expects to get it in two guesses, then the his brute force will take exactly twice as long as your correct login. If he has a dictionary of 100 words to try, then exactly 100 times as long as your correct login, and if your password isn't on his dictionary, then he cannot ever succeed, ever.
Some Practical Math
So to guarantee that his brute-force attack will be impossible, you also have to guarantee that your successful login will be impossible, because you have to account for the possibility that your password is the only candidate on his list.
If on the other hand, you want to go for a reasonable average, just do some simple division. Lets say you want the brute-force attack to take 1 trillion years. And let's say our password is 14 characters alphanumeric (so 1 out of 1025). Assuming his dictionary is all alphanumeric passwords, that's 1025 password guesses in 1012 years (short-scale trillion), or 1013 guesses per year, or about 316900 guesses per second. That's for a fully-exhaustive pass through the list. Some password will be guessed first and some will be guessed last, we probably care about the average, not the max, so lets drop our guess rate in half. About 150000 guesses per second gets us half way through the list in the same amount of time.
So as long as we tune PBKDF2 such that it takes more than 1/150,000th of a second to guess each password, and we can guarantee that the smallest dictionary our password will appear in is the list of all 14-letter possibilities, then 1 trillion years it is.
Of course, 14 character random passwords are hard to come by. With 13 characters that shrinks our password list from from 1025 entries down to 1023, requiring about a 100x slowdown in cracking speed (1500 passwords per second) to keep our 1 trillion year average (technically that 100x is actually a 62x, because that's how many alphanumeric characters there are, but I'm rounding to powers of 10). Dropping another character off your length changes your numbers by another 62x each time.
The moral of the story is that what you're hashing matters so much more than how you're hashing. For example, a 22-character alphanumeric password is a 131-bit key, which even without using PBKDF2 at all is well beyond reason for trying to crack.
Bear in mind that if the underlying crypto is ever broken, such that it can be attacked without guessing the key, then that will probably become the attack method of choice. But we know of no such attack in AES, nor do we expect one to ever exist.