Should I calculate capacity per team or per developer?

In my experience, if you start to measure story points by developer, the developers start to change their estimates to make themselves look better.  It will become a competition to complete more points than everyone else.  This breaks down team work and introduces siloed work efforts. 

A Scrum Team is a self-managed, self-organized group of individuals.  The completion of work is owned by the team not individuals.  That is why these statements are made in the Scrum Guide:

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. 

My general stance is that the team is deserving of all accolades, not individuals on the team.  Team members should work together to get work to "done".  If your developers are assigning themselves work before the Sprint begins by "owning a story", then they are not actually working as a team who shares work.  It might be possible for more than one person on the team to do the same work but if the work is preassigned, that doesn't always happen.  For example, at the end of Sprint Planning Developer A has 8 items, Developer B has 6, and Developer C has 9.  Developer B finishes their 6 items by day 7 of a 2 week Sprint but since there are no other items, they sit idle for the rest of the Sprint.  At the end of the Sprint Developer C has only completed 7 of their 9 items. Now consider an alternative.  Each day in the Daily Scrum, each Developer chooses an item to work on.  When the work for that item is completed, they discuss with the rest of the Developers which item would be best for them to start on next.  This takes place every day of the Sprint.  Some days the Developers might decide not to start anything new and have more than one Developer work on a single item based upon new information gained the previous day. 

If I was on this team, I would work with them to realize that they may be doing themselves a disservice by following their current practice and see if they would like to experiment with other ways that could help them be even more productive.  But in the end, it is entirely up to the team to decide how they want to work, measure their work completion, and make visible the work that is being accomplished. 

what I've seen is some developers taking too much work on their own while others chilling for 1/3 of a 2 week sprint.

That's the problem. The story point issue is just a symptom. What teamwork are they demonstrating? Perhaps the Sprint Goals they choose, even if they are met, don't give them enough reason to work together on a complex challenge.

In my experience, doing anything on the individual level moves the team's focus away from the whole-team to individuals. For example, the whole team commits to the Sprint Goal. So if you're using estimates and forecast capacity to check to see if it is reasonable for the team to commit to the Sprint Goal based on the amount of work associated with the Sprint Goal, then you'd want to look at the team's capacity and ability to get work done.

For me, I'd be curious as to why some Developers are "chilling" rather than seeking out the opportunity to pair with others. From what I've seen in the past, this usually happens when Developers feel that they don't necessarily have the knowledge or skills needed to help out. But pairing up can help them learn so they can be more effective in the future. Perhaps there are other problems, but understanding why there's not a team-centric focus on pitching in to help get work done would be my focus.

Thanks for all answers!