We have an issue
Issue for who? Sprints are a completely artificial unit of time usually set up by managers who do not do your work anyway. If you're breaking this artificial deadline but the clients and customers are happy with the product, perhaps it's time to change the way you as a team work.
One problem with the way you seem to work now is that the process eventually creates bottlenecks, which is mostly you as a Tester. That's not optimal, because the whole team becomes slow when developers eventually throw their work over the fence to your garden for testing.
A better way of going about it could be minimizing work in progress and focusing on delivering small amounts fast. That way you as a team have just a few pieces/small features in progress. You get ideally one at a time, you test it and once done, it goes to production. Much more fluid process with fewer bottlenecks. These are the ideas usually described by Kanban method, you can check it out and perhaps think about it with your team. It might work better in your context.
Should we break the PBI into smaller stories?
Well, yes. Small stories are usually more manageable no matter how you work. If your stories are huge and take days to develop, yes, they should be smaller. In Scrum, you estimate how much time work will take, you can't really estimate huge tasks, the error will be huge, only creating more problems for you and the team later on when you're running out of time (it happens surprisingly often).
Another topic to talk about here could be how you and the team test? Do you do TDD, does someone write unit tests, API tests, or do you test everything through the user interface? How fast and focused is your feedback to developers about defects and problems? Do they need to spend hours debugging?
The likely remedy will be somewhere in the intersection of these topics, but you at least can get some ideas to think about.