It sounds like the team lacks a formal process for code reviews.
I'm not talking about a creating a 350 page Word document, but just some simple bullet points on what the process entails.
The important bits:
Define a core set of reviewers. No general statements. Name people.
These should be your senior developers.
Require more than 1 core reviewer to sign off on the review.
Identify at least 1 other non core reviewer each sprint or release who is a temporary core reviewer. Require their sign off on all code reviews during this time.
Item #3 allows the other devs to rotate in to the core reviewer group. Some weeks they will spend more time on reviews than others. It is a balancing act.
As for rewarding people? Many times acknowledging the effort a person is making during code review in front of the whole team can work, but don't stress yourself out over this.
When in doubt, define the process and tell the team they need to stick to it.
And there is one last thing you can try — controversial as it may be: let the @#$% hit the fan, if I may use an idiom.
Let the team fail, because the code review process is not being followed. Management will get involved, and then people will change. This is really only a good idea in the most extreme cases where you already defined a process and the team refused to abide by it. If you don't have the authority to fire people or discipline them (as most lead developers don't) then you need to get someone involved who can do this stuff.
And there's nothing like failure to get things to change. Despite what people might say, you can steer the Titanic — but not before it hits the ice burg.
Sometimes you just need to let the Titanic hit the ice burg.