llama-quantize: Add MoE chunk queue for faster multi-threaded quant creation

[bartowski1182]

Overview

This changes how experts are chunked and queued into the llama-quantize process

This does NOT speed up running models, so don't get excited.. But MoE model creation speed does go up by a good margin with identical sha256sum

In ideal scenarios, we can see a 5x speedup in creation time for the particularly tricky tensor types when using 192 threads on Qwen3.6-35B-A3B:

type	master (s)	PR (s)	difference
Q4_0	153.36	47.21	-106.15 (-69.2%)
Q4_1	265.71	77.50	-188.21 (-70.8%)
Q5_0	156.00	48.94	-107.06 (-68.6%)
Q5_1	269.04	80.43	-188.61 (-70.1%)
IQ2_XXS	590.17	149.41	-440.76 (-74.7%)
IQ2_XS	791.68	275.75	-515.93 (-65.2%)
IQ2_S	797.29	278.07	-519.22 (-65.1%)
IQ2_M	419.22	93.67	-325.55 (-77.7%)
IQ1_S	314.58	77.56	-237.02 (-75.3%)
IQ1_M	822.69	230.83	-591.86 (-71.9%)
Q2_K	243.53	64.44	-179.09 (-73.5%)
Q2_K_S	284.82	73.42	-211.40 (-74.2%)
IQ3_XXS	665.13	161.75	-503.38 (-75.7%)
IQ3_XS	623.36	144.56	-478.80 (-76.8%)
IQ3_S	578.11	126.46	-451.65 (-78.1%)
IQ3_M	567.43	124.53	-442.90 (-78.1%)
Q3_K_S	167.77	44.97	-122.80 (-73.2%)
Q3_K_M	200.14	56.10	-144.04 (-72.0%)
Q3_K_L	203.06	56.79	-146.27 (-72.0%)
IQ4_NL	372.72	96.15	-276.57 (-74.2%)
IQ4_XS	370.21	94.87	-275.34 (-74.4%)
Q4_K_S	268.32	76.46	-191.86 (-71.5%)
Q4_K_M	250.21	72.93	-177.28 (-70.9%)
Q5_K_S	275.51	80.41	-195.10 (-70.8%)
Q5_K_M	256.68	75.99	-180.69 (-70.4%)
Q6_K	162.85	53.28	-109.57 (-67.3%)
Q8_0	156.70	52.10	-104.60 (-66.8%)

At 48 threads on 24 cores the numbers are more modest, somewhere more like 1.5-2x increase

CPU usage goes from ~60-80% on each provided core to 100%

Additional information

The main change is that we no longer spin up a single thread per-expert, now it handles the whole 3D tensor in one threaded pass

this_nrow = min(nrows - local_row, nrows_per_chunk) guarantees that chunks get truncated at the end of its expert so we don't span expert boundaries (which would have different imatrix data)

ggml_quantize_chunk now receives start = 0 for every call here, instead of using first_row * n_per_row. Since we need the per-expert base pointers anyways, we just increment them all ahead of time.

It also uses better logic for deciding the threads to use per expert, if the matrices were small we'd end up with a low thread count, now it's based on the size of the whole tensor.

Checked the sha256sum of every file with and without this PR and they're identical, also checked on a dense model for sanity and it was the same.

Also compared this PR vs master with a single thread (since it's a different path) and also same sha256sum on https://huggingface.co/hf-internal-testing/Mixtral-tiny (can't afford the days it would take to quantize a 35B on a single thread..), time is same because this is a multi-threaded improvement.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES, this is part of a sweep of quantization creation speedups found by Claude, but this one is byte-identical so the easiest to justify