My question is who should be concerned with not overloading ServiceB? Should ServiceA trust that ServiceB will have some appropriate rate-limiting and be able to deal with a surge of requests? Or should ServiceA implement some limit on its end in terms of how many requests it makes at one time to ServiceB?
Blind reliance is never a good thing. If you only implement one regulation, then the other service will always be stuck with blind reliance, which is never a good thing.
Firstly, the last line of defence argument applies. In other words, your B service needs to be able to protect itself from being DOS attacked. Even if you weren't intentionally sending multiple requests in quick succession, that would be a really good idea.
The specific implementation is more complex than I can pen down here based on the info in your question, but the basic implementation is that service B starts returning HTTP 429 (Too Many Requests) once the limit rate has been reached. Whether that limit is global, per source IP, per JWT; based on active requests, request per specific time period, time since the same requester sent their previous request ... is all up to you to decide.
As a last line of defence, a global request rate is a good idea, though you'll usually want to add some additional rate limits on top of that. For example, you could cap it globally at 10k requests per minute, but cap individual callers (based on IP or JWT) to 500 requests per minute. This ensures that you can fully service 20 consumers (to their full rate limit) at any time, most likely more since not everyone will be using up their rate limit.
Any consumer such as A should then notice these 429 responses and act accordingly. Depending on the context, this could mean waiting a few minutes, waiting a longer period, or simply taking more time inbetween requests. It all depends on how your rate limiting is configured.
That being said, for any non-trivial amount of requests being fired from A to B, I would already expect A to have some degree of staggering (i.e. delay timer) between firing requests. It all depends on how many requests we're talking about here. 5 requests are nothing noteworthy, 500 requests become an issue for below-enterprise-grade software, 50k requests are always going to be an issue.
Assuming you're working asynchronously, in order to receive optimal throughput you'd need to get a rough grip on how many requests your B server can handle, how many tasks your A server can fire off at the same time, and the available bandwidth between them. Depending on the bulk size we're talking about (and the average response time), this fine-grained control may be overkill, but with large bulk requests it may yield decent optimization without unintentionally DOSing the B server for any other consumers.