I don't think you will need to have too many buffer pools for you queried data because the size of the frequently queried data doesn't quite justify it. This does of course depend on the definition of "frequently".
The appropriate documentation you should be referencing the page on innodb buffer pools, here:
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-buffer-pools.html
The numbers I'm focusing on here is
the frequently queried data is ~1.25 gb.
My rule of thumb when trying to keep InnoDB buffers the right size is to keep them at or around 1GB a piece, in order to keep the list of blocks as short as possible but keeping the list of buffers from being too far fetched, this will always depend on your actual needs however.
This is in line with MySQL's recomendations:
For best efficiency, specify a combination of innodb_buffer_pool_instances and innodb_buffer_pool_size so that each buffer pool instance is at least 1 gigabyte.
The point of the multiple buffer pools is to ensure your CPU threads don't meet high contention in accessing the data. Or as they put it:
You might encounter bottlenecks from multiple threads trying to access the buffer pool at once. You can enable multiple buffer pools to minimize this contention.
However this feature is more for larger amounts of data being frequently accessed as opposed to the 1.25GB you're system uses frequently. Ultimately if I were in your position, I wouldn't see a need for having more buffer pools than the number of CPU's assuming all CPU's are only performing MySQL related tasks. I would also look into the affects of using innodb_old_blocks_time to prevent the occasional query of your archived tables from taking the place of a block of data that is used over and over again.
I hope that helps, let me know how everything works out.
