How OpenGL implementations manage memory is going to be very implementation-dependent. The OpenGL spec makes virtually no guarantees about memory aside from some cases where a GL_OUT_OF_MEMORY error may be raised.
You should never get the impression that there is an exact one-to-one correspondence between memory requirements and memory allocated. This is as true of your OpenGL implementation as it is of your OS. It’s not 1973 any more.
With that in mind, it’s perfectly legal for an OpenGL implementation to allocate any arbitrarily-larger block of memory than what is required. If we assume that allocating memory is potentially a slow and expensive operation, whereas just drawing down from already allocated memory is fast (both reasonable assumptions) this makes perfect sense. The implementation can use it’s own internal heuristics to determine that once you’ve created your context, on average you’ll need an initial block of ~300mb, and just allocate it up-front so that it’s already there and available when the time comes that you do need it. And that’s a perfectly reasonable thing to do, and highly desirable under most common circumstances.