Server load discrepency in Slave with Master load being low and constant
You will have to look at this from different perspectives

Data / Storage Engine

The InnoDB Storage Engine is constructed to do as little writing as possible. As an ACID-complaint storage engine, InnoDB has mechanisms in place for concurrent manipulation of data. The structures used by the InnoDB Infrastrcuture are the following:


Buffer Pool : Changes to Data and Index Pages that are Cached in RAM
Double-Write Buffer : Backup buffer to prevent data corruption
Insert Buffer : Changes to secondary non-unique indexes
Redo Logs : Playback instructions in the event of Crash Recovery
Undo Logs : Reverse instructions in the event of Crash Recovery/Rollback
See Pictorial Representation


Master

In all likelihood, there are concurrent operations from multiple DB Connections performing


INSERTs
UPDATEs
DELETEs
SELECTs


on the Master. These changes and lookups are cached and managed with the InnoDB Infrastructure. Flushing all recorded changes is serially managed but has no immediate effect on data concurrency. The only discernible bottleneck would be the time an SQL transaction decides to write the SQL Commands into its Binary Logs. The OS is responsible for flushing changes to binary logs to disk.

Slave

Here is where things can get interesting. While the Master handles everything thrown at it, it has to write the SQL Commands into its Binary Logs. The Slave has the responsibility to process what the Master gives it.

Here is the MySQL Replication Paradigm


IO Thread on Slave Connects to Master
The Master Does the Following on a Continuous Basis:


Completes SQL Command
Records SQL Command in its Binary Logs

The Slave Does the Following on a Continuous Basis:


IO Thread from Slave Reads incoming SQL Commands from the Master's Binary Logs
IO Thread Records the SQL into its Relay Logs
SQL Thread from Slave Reads Next SQL Command to Be Executed
SQL Thread Executes the Latest SQL Command From the Relay Logs
If Binary Logging is enabled on the Slave, Slave Records SQL Command in its Binary Logs



If you carefully follow the flow of control from this Paradigm description, you can easily see that all the SQL sent from the Master is serialized. In other words, the SQL commands from the Relay Logs are executed one at a time. This can manifest itself on the Slave as follows:


When you run SHOW SLAVE STATUS\G, you see Seconds_Behind_Master increasing
When you run SHOW PROCESSLIST;, the SQL thread (whose user is 'system user') is executing an SQL statement that is taking a long time on its own.


This can easily happen when a Master is handling hundreds of SQL commands in parallel. It is when the SQL statement are lined up single-file and recorded as a FIFO queue on the Master, that the Slave must then process each command first-come, first serve only without any benefits from parallelism.

Conclusions Drawn

From the roles of Master and Slave given an all-InnoDB database, a Master to could handle multiple SQL transactions and be done with all commands. By design a Slave has no choice but to process commands in a serialized fashion. The background processing performed by a Master would easily get finished a stay quiet for a long time while a rather busy Slave would have process SQL one-by-one and have resources handle processed changes in a similar manner.

Troubleshooting / Resolution

Once you can see this funneling of SQL from Master to Slave, your only recourse would be to consider some of the following options to apply to the Slave and Master


Query Optimization
Create the needed indexes to support Query Optimization
Make adjustments in the networking setup between Master and Slave


Install a 2nd NIC on Master and Slave
Assign IP address to the 2nd NIC (NIC_IP)
Run CHANGE MASTER TO command to assign (NIC_UP) to MASTER_HOST

Upgrade to MySQL 5.5 (if not using MySQL 5.5)
Configure MySQL 5.5


configure InnoDB for multiple core engagement
configure SemiSynch Replication

Upgrade RAM
Change to Individual Tablespaces