[mjevans]

My copy of that manual page has additional text:

  "" note : at the time of this writing, --adapt can  remain  stuck  at  low speed when combined with multiple worker threads (>=2). ""

There are some ADVANCED COMPRESSION OPTIONS --zstd tunables that might help.

Leave wlog alone unless you're willing to store the value out of band and pass it in again during decompression.

hashLog, bigger number uses more memory to compress but is often faster.

chainLog smaller number compresses faster, but worse ratio.

In your use case monitoring general system utilization to identify bottlenecks might also help. My gut instinct is that you might already have hit a memory bandwidth limit for the platform, at which point REDUCING the hashLog until it fits within your intended performance budget might yield better bandwidth results. Reducing the chainLog value might have the same effect.