With set system acceleration qat enabled and a working QAT device, every AES-GCM ESP proposal runs entirely in software on the CPU. QAT is never invoked.
AES-CBC and AES-CCM proposals on the same box and in the same session do reach QAT normally. There is no error, no log message, and no CLI indication.

Issue

The kernel ESP layer (esp4) requests the RFC 4106 ESP wrapper, seqiv(rfc4106(gcm(aes))).
From /proc/crypto on the affected system, the only provider of the name ESP asks for:

name         : rfc4106(gcm(aes))          name         : seqiv(rfc4106(gcm(aes)))
driver       : rfc4106-gcm-aesni          driver       : seqiv(rfc4106-gcm-aesni)
module       : aesni_intel                module       : seqiv
priority     : 400                        priority     : 400

and what QAT registers instead:

name         : gcm(aes)
driver       : qat_aes_gcm
module       : intel_qat
priority     : 4001

Because aesni_intel publishes rfc4106(gcm(aes)) directly, the crypto API resolves the ESP request against it and never instantiates an RFC 4106 template over QAT's gcm(aes). QAT's priority 4001 is never compared against AES-NI's 400.
Hence, the two algorithms are not registered under the same name, so they never compete.

show system acceleration qat device qat_dev0 flows and ... interrupts stay flat through the entire GCM run and climb normally through the CBC run.

Impact

The GCM run is pinned to a single core performing crypto in softirq context, leaving a quarter of the link idle. The QAT-accelerated CBC run saturates the 1 GbE port with the CPU largely free.

Something to make note of:

intel/QAT_Engine#237 has been open since March 2023 with no response.
It predates GCM appearing in LKCF at all; the 4.24 driver now registers gcm(aes), but not under the name ESP uses, so the practical outcome is unchanged.