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.
So as long as we tune PBKDF2 such that it takes more than 1/300,000th of a second to guess each password, and our password is at least 14 letters long, then 1 trillion years it is.
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.