Not as much as you might think, the iPhone is going to be doing a single decryption and checking action per attempt. If this takes 90 milliseconds because it's also going out to the secure chip to do the key derivation with the device uid so that the cpu and main ram never sees all the information to derive the full key on it's own then once you have both of those pieces of information (as was stated in this hypothetical) then you've eliminated the slow communication and slower processor involved. This could easily mean you can now do the derivation of the key in a much quicker fashion (I'd be surprised if it's not 10s to 100s of microseconds). But that's assuming that the bulk of the time isn't being spent on something like a modern key derivation function from the user's pin which is quite possibly a bad assumption (nobody knows these details outside Apple as far as I know). So let's say it's that, we've now got maybe 80ms of real cpu time on the iphone (not counting the communication to secure chip). This is still going to just be one core of the iphone's cpu doing this (no parallel KDFs that I'm aware of) and it's still trivially parallelizable. I don't know exact specs but lets say a modern intel cpu is going to be only 4x faster at this KDF because apple put in special cpu hardware to help accelerate it and other crypto operations. Now we multiply that by however many cores we can get (RAM isn't going to be an issue here even if it's a memory safe KDF, on a real computer or server we can always add more, terabytes if needed). So at this point we've got ~10-12 checks per second (80ms) times 4 for just the single core speedup, and then we can multiply that by the number of cores/threads we can throw at it, 256 wouldn't be too hard to get at (amd 2x epyc 64 core cpus). That gets us to 10240-12284 password checks per second. Even if that 4x is 2x or 1.5x it's still relatively easy to just throw some more servers at it since the actual check is so trivial to do in parallel. This would be very easy to be within a state actor or even a large corporation's budget if they had the need.
That's why Apple is so hard on making the secure chip they use for the encryption and holding the device uid. It's really the only thing that can keep that from being within a $10k-15k budget to break a bad passcode/pin. If they aren't using a modern KDF that has memory safety, branch safety, and other defenses in it then all the above goes out the window since you can now throw some really cheap GPUs and do it in parallel at a scale that's even more insane.
Have a look at some of the GPU benchmarks for John the Ripper
https://openwall.info/wiki/john/GPU