I've noticed on my team the developers are very busy toward the beginning of the sprint with the QA people having little to do, while the opposite is true toward the end of the sprint.

This seems inefficient... is there any way to smooth it out?
['https://pm.stackexchange.com/questions/32922', 'https://pm.stackexchange.com', 'https://pm.stackexchange.com/users/597/']
It sounds like you are doing something very common in teams - a 2-week waterfall project. Things likely move from some requirements conversations before the sprint or in the early days of it to coding, then QA at the end. There are a few things you can do to change this up which will also have the impact of smoothing out workload:

1. Smaller pieces of work. Break things down into small features that can be designed, coded, and tested in 2 - 3 days. Lessons learned many decades ago from Lean: small batches lead to better flow.
2. Test-first development. Using techniques like TDD and BDD (as examples) can bring a lot of the testing early in the process instead of later. (this doesn't completely eliminate exploratory testing btw). This also really helps with...
3. Invest in test automation. Unit tests, integration tests, automated acceptance tests. This is all part of the build it process. Also, this requires both the coders and testers to work together. The testers are good at knowing what to test and the developers can help automate them and build the application to be more easily testable. This also gives you a large suite of regression tests that make it easier and safer to do #1.
Switch to Kanban so that you can balance the flow of work without the cold-start at the beginning of every sprint.

Once you start optimizing for delivery, look at how developers can help with the QA to finish the work instead of starting new items.

Over time, this might reveal team imbalance and drive some staffing decisions and/or tooling improvements.