The CPU values that the DMVs return for sessions is ms of CPU time since login time. Hence sessions that have been connected for a long time (as replication jobs usually are) will usually have a high cumulative CPU because they've been doing bits of work for long periods of time. Doesn't mean they're a problem, just that they've been doing bits of work for a long time.
I don't like using the session/requests DMVs for performance tuning as it requires you poll the DMVs and you can easily miss stuff.
For example, which of these is a bigger problem?
A session that logs in when SQL starts and runs a process every 5 minutes, that process takes 50ms of CPU time. It does not disconnect. After SQL has been running for a week, this process shows a CPU total of 100800.
A session that logs in, runs a process that takes 200ms of CPU time and immediately logs out. It does this every minute.
Which are you more likely to see when querying the DMVs?
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass