There are a few different ways to approach this problem.
From a Scrum perspective, your Development Team does not have sub-teams. You may have specialists, such as people who specialize in testing, but the whole team should be involved. Rather than putting the QA specialists in a position where they must test everything at the end of the Sprint, the whole team should be involved in testing, whenever that testing occurs. The QA specialists can help train the rest of the team on good testing practices.
Not specific to Scrum, incrementally delivering the work throughout the Sprint and continuously integrating and testing it would also help relieve some of the pressure. Instead of testing at the end of the Sprint, test as work gets finished. If you are waiting until the end of the Sprint to integrate work, try to integrate it sooner. If it looks like you can’t, it could be a sign that your work is not well sized or sliced.
Finally, in some environments, there may be good reasons to have independent QA. The first two points still apply, and the Development Team should be producing a high-quality product. However, any independent integration and test should be moved outside of the Sprint and onto a separate team. If the Development Team has done a good job, this team may have feedback, but shouldn’t regularly find issues that would prevent a Sprint's output from being releasable to the next downstream process.
Since this question is an exact duplicate of a question on the Software Quality Assurance & Testing Stack Exchange, this is an exact duplicate of my answer there as it is equally applicable.