If you are using the right tool, you will see that no appload (some coders of popular apps seems to live in the dark ages, and disregard NCQ/Queue Depth) uses QD#1. QD#1 is most used when a singel file is accessed in an NCQ supported environment, with no other tasks/queue waiting, therefore you should disregard MB/S or IOPS on QD#1 as they are utterly useless and completely linear, and focus on access time regarding QD#1, and thats all QD#1 is good for..
A good example of how useless QD#1 is, is to look at appload on Mtron SLC, wich are almost twice as fast as the current performance leaders on QD#1 at ~40mb/s. They get left in the dust at appload, even if the Mtron are a very good SSD considering it's age.
There is a tremendous technical difference between QD#1 and QD#4+ aswell, not only the few digits difference between them, and QD#4 is the smallest amount one should measure IOPS in benchmarks to simulate real world loads.
Anandtech measured average QD on an Desktop PC to be #6 if I recall correctly. And bare in mind, as described below, you have to use way different settings in IOMeter/AS SSD to get corresponding real world loads. So if Anand is using IOMeter@QD#6, he is doing it wrong..
Here is a snip from the "holy grale" of storage: "Now a few words on the # of Outstanding I/Os parameter. If you set it to 1, then with the 100% Percent Random/Sequential Distribution we in fact measure a random access time. Value 4 corresponds to a load of an elementary applications like Windows Calculator. According to StorageReview, in average on real applications this parameter takes 30-50. The value more than 100 corresponds to high disc load (e.g. in case of defragmentation)." http://ixbtlabs.com/articles/hddide2k1feb/iometer.html
So in short: QD#1=Access time. QD#30-50=appload of moderate load, QD#50-100=appload of moderate/heavy load, and these last two corresponds to apploads of various load in real world according to StorageReview, and they are the closest thing to fact as you can get..