Inaccurate 'Actual' row counts in parallel plan
Rows are passed across exchanges internally from producer to consumer thread in packets (hence CXPACKET - class exchange packet), rather than a row-at-a-time.  There is a certain amount of buffering inside the exchange.  Also, the call to shut down the pipeline from the consumer side of the Gather Streams has to be passed in a control packet back to the producer threads.  Scheduling and other internal considerations mean that parallel plans always have a certain 'stopping distance'.

As a consequence, you will often see this sort of row count difference where less than the whole potential rowset of a sub-tree is actually required.  In this case, the TOP brings execution to an 'early end'.

More information:


Parallel Execution Plans Suck
Understanding and Using Parallelism in SQL Server.