OK, this is clearer, the issue is that running a HammerDB v5.0 workload against SQL Server all of the connections are going to a single processor group, the assumption is that this is a HammerDB issue rather than a Windows/SQL Server one, however there is no data provided so far to back this up and we have some indication of what may be happening.

So back in HammerDB v3.2 there was this issue https://www.n0derunner.com/sql-server-uses-only-one-numa-node-with-hammerdb/ with HammerDB making a double connection, the interesting thing here is that this double connection showed evidence that when processor groups are used SQL Server round-robins connections. The investigation suggested at the time time, this was not configurable and there was no load balancing taking place, SQL Server allocated connections in order. In this scenario with the 2 connections it meant the real connections all went to the same node. (This is almost certainly likely to have changed since then).

However this issue on the HammerDB side was long fixed, and there is not now double connection - you can view the source in the driver script and every connection uses the user chosen ODBC Driver for SQL Server - so from SQL Server's point of view we have a multi-threaded application making multiple ODBC connections to the database and somehow these are being assigned to one processor group. There is nothing specific in the HammerDB use of ODBC that is requesting this.

For troubleshooting - I would recommend using the HammerDB CPU monitor instead of the Windows one:

This is processor group aware and will report the NUMA nodes and processor groups when you run the agent (you can test this manually by running the mpstat tool and see the source code that does this here on GitHub). It also shows the user and sys CPU which is important for database workloads.

Also try testing with changing processor affinity - you can see in the HammerDB CPU monitor that it is not using the deselected CPUs.

Even deselecting auto and selecting all manually can change behaviour.

Also take a look at sys.dm_os_schedulers to see what CPUs are online

 SELECT 
    scheduler_id,
    cpu_id,
    status,
    is_online,
    is_idle,
    current_tasks_count,
    runnable_tasks_count,
    current_workers_count,
    active_workers_count,
    yield_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255
ORDER BY scheduler_id;

If we can identify an issue with the way connections are made to multiple processor groups then that is what is needed to raise an issue. However using process explorer the Ideal Processor is different for the HammerDB threads - i.e. it is not that HammerDB is running on a subset of cores in my tests but I don't have multiple processor groups to test.

However for now it looks like SQL Server has decided to put all of the connections on one processor group rather than HammerDB saying put all the connections on one processor group.

https://techcommunity.microsoft.com/blog/sqlserversupport/how-it-works-sql-server-2012-database-engine-task-scheduling/317778

Any further evidence you can provide can help diagnose the issue.