For file encryption it does make sense to stream ciphertext or to use a memory map of a file. Buffering the whole file is definitely not the way to do things.
If you want to use parallelization then you need to split the file into chunks and encrypt / decrypt separately. That will give you authentication tags (and possibly nonces) for each encrypted chunk though. So you would expand your file with e.g. 28 bytes per chunk, rather than 28 bytes per file. Probably you're also going to need a separate file specific key (which can be derived from a master key, if that's required).
It is also to actually perform online encryption and decryption for GCM. You can even split encryption and tag creation and verification and decryption of the entire file so that they can be performed in parallel. Of course the latter will mean that you should not use the decrypted file before the verification has actually performed.
Now splitting the ciphertext in chunks is easy once you see that they are just chunks of CTR encrypted plaintext. Putting the separate GMAC of the ciphertext together is a lot harder and requires modular exponentiation.
Probably best start by just encrypting a file with GCM and deliver the ciphertext and plaintext in chunks. Preferably use an API where the authentication tag is considered separate from the plaintext (i.e. provides the online property talked about above).
Python is not very fast when it comes to crypto; it mainly requires the use of C-based libraries to perform encryption smoothly. I would suggest that for low level functions such as file encryption, C is actually vastly superior to Python for this kind of functionality (and vastly superior to Java - my fave language - for this kind of usage, in case you think I'm biased).