If you have a central service whose job it is to deploy code, then the best approach is to use one deploy key for that service and control your deployments using that service. However, it doesn't sound like that's what's going on here.
Absent that, you generally want to use one deploy key for each environment that you're deploying to, not each server. For example, if you have code that needs to be deployed to production application servers as well as developer shell servers, then use a separate deploy key for each environment and copy each environment's key to all of the servers in that environment. That way, you can later restrict access to the repository if a certain environment no longer needs it without impacting other environments.
Using a separate key for each environment means that if you have deployment scripts that need to work with multiple deploy keys (for multiple repositories), they'll function in the same way on every server in that deployment.
You should make sure that your deploy keys are well labeled so that future you (or your successor) can figure out at a glance what each key is for.