It could be helpful if you provide the full phpinfo() output of
the OPcache extension.  Also, which SAPI do you use?

Right, this is on nginx + php-fpm.

Here is the phpinfo() output:
Opcode Caching 	 	 	Up and Running
Optimization 	 	 	Enabled
SHM Cache 	 	 	Enabled
File Cache 	 	 	Disabled
Startup 	 	 	OK
Shared memory model 	 	mmap
Cache hits 	 	 	0
Cache misses 	 	 	1
Used memory 	 	 	76277336
Free memory 	 	 	125049256
Wasted memory 	 	 	0
Interned Strings Used memory 	237144
Interned Strings Free memory 	6053864
Cached scripts 	 	 	1
Cached keys 	 	 	1
Max keys 	 	 	16229
OOM restarts 	 	 	0
Hash keys restarts 	 	0
Manual restarts 	 	0

opcache.blacklist_filename 	 	no value
opcache.consistency_checks 	 	0
opcache.dups_fix 	 	 	Off
opcache.enable 	 	 	 	On
opcache.enable_cli 	 	 	Off
opcache.enable_file_override 	 	Off
opcache.error_log 	 	 	no value
opcache.file_cache 	 	 	no value
opcache.file_cache_consistency_checks	On
opcache.file_cache_only 	 	Off
opcache.file_update_protection 	 	2
opcache.force_restart_timeout 	 	180
opcache.huge_code_pages 	 	Off
opcache.interned_strings_buffer 	8
opcache.lockfile_path 	 	 	/tmp
opcache.log_verbosity_level 	 	1
opcache.max_accelerated_files 	 	10000
opcache.max_file_size 	 	 	0
opcache.max_wasted_percentage 	 	5
opcache.memory_consumption 	 	192
opcache.opt_debug_level 	 	0
opcache.optimization_level 	 	0x7FFEBFFF
opcache.preferred_memory_model 	 	no value
opcache.preload	no value 	 	no value
opcache.preload_user 	 	 	no value
opcache.protect_memory 	 	 	Off
opcache.restrict_api 	 	 	no value
opcache.revalidate_freq 	 	2
opcache.revalidate_path 	 	Off
opcache.save_comments 	 	 	On
opcache.use_cwd 	 	 	On
opcache.validate_permission 	 	Off
opcache.validate_root 	 	 	Off
opcache.validate_timestamps 	 	On

Local Values are exactly the same as Master Values.

Can't reproduce this on cli at least, free memory changes as memory_consumption changes.

First guess is that opcache.memory_consumption gets set in a place that still allows setting PHP_INI_SYSTEM settings, but after opcache has already started up and the shared memory segment has been allocated (this would also be consistent with the negative "used memory" you see in one case, as that is calculated from the value of opcache.memory_consumption and the free and wasted memory).

Which mechanism do you use to set opcache.memory_consumption? Is it anything other than a system-wide php.ini file?

Yep, that seems to be it.

I've been setting the opcache.memory_consumption in an external opcache.ini as well as the fpm pool config but not in the php.ini itself.
Tried it just now, and everything is reported correctly.

So, the takeaway is: don't try to set opcache.memory_consumption outside of the php.ini.

We should probably make setting of opcache.memory_consumption (and certain other settings) fail if opcache is already started up. That way it would at least be obvious from phpinfo output that the value did not change.

Not sure what to do here.  On Windows, the situation is even
worse, since one could change INI settings for future FCGI
processes in php.ini.  Still, likely a documentation issue.

Please put some info in the logs, if you decide to ignore certain external settings.
I'd hate to waste time trying to find a mistake in a config that gets silently ignored.

I also think that a remark in the documentation would be good.
This applies all php versions I've tested, 5.6-8.0, and I'm unlikely to be the last one to think that you could override any php.ini setting in the fpm pool config.

> I'm unlikely to be the last one to think that 
> you could override any php.ini setting in the 
> fpm pool config

something si common sense, of course you can override "session.gc_maxlifetime" as example even per directory, but it won#t help you to increase it when it's using the same directory and "session.gc_probability" from a script with a lower value hits

the same for *shared memory* segments

Yeah, I realize that now.
But looking at the config I was under the impression that the opcache could be configured per pool and that it was then shared between worker processes thereof. 
The pool config already had a memory_limit and opcache.file_cache overrides after all, so just adding an opcache.memory_consumption override seemed logical.

For this be a common sense, you'd actually have to know about the scope of shared memory in this context, which I freely admit I did not.