換成Gemma 4 31B

./llama-b11946/llama-bench -m gemma-4-31B-it-qat-UD-Q4_K_XL.gguf -ngl 99 -fa 1 -p 512,2048,8192 -n 128 -b 2048 -ub 25$ ,512,1024,2048 -d 0,4096,16384 -r 5 -o md
ggml_cuda_init: found 1 CUDA devices (Total VRAM: 32126 MiB):
Device 0: NVIDIA RTX PRO 4500 Blackwell, compute capability 12.0, VMM: yes, VRAM: 32126 MiB
load_backend: loaded CUDA backend from /home/ryan/llama-b11946/libggml-cuda.so
load_backend: loaded RPC backend from /home/ryan/llama-b11946/libggml-rpc.so
load_backend: loaded CPU backend from /home/ryan/llama-b11946/libggml-cpu-zen4.so

build: 8ca4060b7 (11946)

下面是Claude的分析

結果解讀

這組數據很穩定（標準差多在 1 以內），而且正好回答了你上一個問題。

1. 這個 dense 模型的 tg 已接近頻寬上限

dense 模型每生成 1 個 token 要讀完整份權重：

• 16.09 GiB ≈ 17.3 GB，乘上 42.5 t/s ≈ 734 GB/s
• 約為 896 GB/s 規格頻寬的 82%

實測通常很難到 100%，所以這張卡在這個模型上幾乎沒有再榨的空間。

對照 26B-A4B：我先前粗估它只用到約 390 GB/s（約 4 成多），差距很大。這支持先前的推測：MoE 的 tg 受限於 expert 路由與 kernel 開銷，而非頻寬。不過 390 是粗估值，結論方向可信，數字別當精確值。

2. ub 幾乎沒有影響

pp2048 在 ub 256 到 2048 之間只落在 1885 到 1910 之間，差距在 2% 內。這和 MoE 的結果（ub 256 到 2048 差了 1.86 倍）形成鮮明對比。

合理的解釋是：dense 的矩陣乘法本來就能用很小的 batch 餵飽 Tensor Core，不需要更大的 ub。MoE 則是每個 expert 分到的 token 很少，要靠大 ub 才能湊出足夠的批次。這是推論，但與兩組數據吻合。

在 d16384 時，ub 512 以上（約 1485～1490）比 ub 256（約 1420）略好，但幅度只有 5% 左右，用預設的 512 就夠了。

3. 長上下文衰減

衰減比例和 26B-A4B 很接近（-23% 與 -11%），不過兩者的 attention 結構不同，這份數據不足以判斷原因。

4. 兩個模型並排

MoE 的 tg 領先幅度（3.8x）低於它的活躍參數比（約 8 倍少），也呼應第 1 點：MoE 沒能把省下的頻寬完全轉成速度。

實務建議

• 要速度：26B-A4B 在這張卡上明顯快很多，日常互動與長 prompt 都更舒服。
• 要品質：31B 能以約 42 t/s 跑，對單人互動仍夠用，但長文 prefill（8K 約 4.5 秒）會明顯感覺到等待。
• 31B 想再提速：頻寬已近極限，只剩 speculative decoding 一途。可以用 26B-A4B 當 draft model 試試，兩者同為 Gemma 4 系列，詞表應相容，但接受率需要實測。
• llama-server 設定：31B 用預設 -ub 512 即可，不必像 MoE 那樣特地調到 2048。