When publishing it always makes sense to group as many items as you can together in a single Publish Transaction, to benefit the most from the transaction item caching that is done for you in the background.
One thing to keep in mind here, is that publish actions to different Publication Targets will always be rendered separately (they will show up as a separate transaction in the queue).
So combining this information with your question, you mention you have two CMS servers, so I'm assuming you mean a scaled out CMS with a Publisher service running on each one. Depending on how your Publishers are configured they might have a single rendering thread, but they might also have multiple. Whether you call the publish method with both targets or two times with a single target won't make a difference here, since in the end, you will always end up with two different transactions anyways (one for each separate target).
You have to keep in mind that since you only have two publishers and the CME is also running on that same machine, you might want to leave the settings of those machines as default as possible (single threaded publishing) to always keep some CPU and memory available for the UI and core processes.
If you would have dedicated publisher machines, you could investigate is if it would be worth splitting up the large publish action into smaller transactions. This would be particulairly beneficial, if you have multiple publisher threads configured and notice you still have some CPU power to spare when the publisher is rendering that single large transaction. But that all comes down to tweaking the performance, so fiddling with how many threads for the Publisher seems to work best with the majority of your Publish Transactions (large and small).