perf(cpu-moe): opt-in AMX tile GEMM for the deduped bf16 pass 1

[gdevenyi]

What this adds

Intel AMX multiplies bf16 tiles in a single instruction against dedicated tile registers. This PR uses it for the deduplicated bf16 pass 1, where the deduplicated walk has already gathered several tokens that share one expert. That gathering is what makes a tile worth filling.

The path is off by default and turns on with FREETOKEN_CPU_MOE_AMX=1. It also requires amx_bf16 and amx_tile, and a successful ARCH_REQ_XCOMP_PERM request. If any of that is missing, the existing AVX-512 path runs.

Stacked on #49, #47 and #46

This PR contains all three. AMX needs several rows of the same expert in one tile, which only exists because those PRs deduplicate the route list. Review them first.

Measurements

Measured on main with this PR alone. Two Xeon Gold 6526Y. ft bench bw --dtype bf16 --reps 5:

	CPU MoE	ratio to PCIe
FREETOKEN_CPU_MOE_AMX=0	67.7 GB/s	2.69x
FREETOKEN_CPU_MOE_AMX=1	72.8 GB/s	2.89x

That is 7.5%.

Why the number is small, and why I think it is still right

The kernel is limited by memory bandwidth, not by multiply throughput. An ISA sweep of the same kernel makes the ceiling visible: avx2 gives 60.7 GB/s, avx512f 64.9, and avx512bf16 67.0. About 10% is all that any arithmetic change can buy on this machine. AMX returns 7.5% of that and nothing more, which is the honest shape of the result rather than a disappointing one.

The test machine has four of eight memory channels populated per socket, which caps measured STREAM read at about 265 GB/s instead of about 530. On a fully populated machine the memory limit sits further out and AMX has more room. I cannot measure that here, so I am not claiming it.

Testing

tests/moe/test_cpu_moe.py on main with this PR: 20 passed, with the flag off.

The AMX path itself has no dedicated test. It is exercised only when the flag is set, so the suite above does not cover it. A test that runs the deduplicated pass 1 with the flag on and off and compares outputs would close that gap. Tell me if you want it before merge.

[gdevenyi]

Independent support for the opt-in default here, from the paper (arXiv:2608.16157 §4.1), describing the CPU worker pool:

Their kernels consume expert weights using architecture-specific SIMD and in-kernel dequantization, which keeps the path bandwidth-bound.

Bandwidth-bound is the design intent, not an accident of this machine — which is the whole reason an arithmetic optimisation measures ~0% here, and why it should stay behind a flag until someone has a part where the balance differs. The local ISA sweep puts a number on the ceiling: avx2 60.7 → avx512f 64.9 → avx512bf16 67.0 GB/s on the DSV4 geometry, so doubling the vector width buys ~7%, and nothing downstream of that can buy more.

§5.3 also shows the balance moving with the host, which is the case for carrying these paths at all:

moving from the many-channel server to a dual-channel consumer desktop costs FreeToken 4% of its decode rate, while llama.cpp keeps only 80% of its rate as its CPU-resident experts starve on two DDR5 channels

The channel count changes how bandwidth-starved the CPU path is by a large factor. This machine has only 4 of 8 channels populated per socket (166 GB/s per socket against a possible 333), so it sits toward the starved end and is close to a worst case for any compute-side optimisation.