硬件：

• RTX 2080 Ti 22G 魔改卡 ×2（NVLink 橋）
• 模型：Qwen3.8-27B W4A16 AWQ（community quant，~11GB）
• 軟件：weicj/vLLM-2080Ti-Definitive（專為雙 2080 Ti / SM75 Turing 優化的 vLLM fork，感謝作者 weicj 和 upstream vLLM）
• TP=2 · 256K context · MTP speculative decoding · fp16 KV

為什麼從 1 並發改 8 並發：

之前跟 repo 建議跑 1-concurrent + 內建排隊，圖的是單線 decode 最快。但實際 workload 是：

• 讀 PDF / RAG：一般 50K context 以內
• VS Code agent：可控制在 100K context 以內
• 都遠低於 256K 上限 —— 「一條 request 食滿整個 context」的場景根本沒出現過

而 agent 的工作模式是：想一段 → 等 command 跑完 → 再想。等 command 時 GPU 完全 idle，1 並發下這些空檔全部浪費。多並發就是把空檔填滿。

實測數據（同方法對比，真實 token 計數）：

Prefill（現行配置）：~1,600 t/s @8K · ~1,430 t/s @32K · ~1,200 t/s @65K

結論：

• 總吞吐 60.4 → 128.4 t/s（+112%），TTFT 從排隊 30 秒級降到 5 秒級
• 單線只跌 ~3%（54.6 → 52.8，MTP3→MTP2 騰出 batch 空間）
• 對 agent / 多 client 場景是質變：以前第二條 request 要等第一條做完，現在真正並行

代價也要說：8 並發時每條線只有 ~20 t/s，長 context prefill 會互相排隊。所以這是「agents farm」取向，不是「單線跑分」取向。

現行配置（launcher 參數）：

--tensor-parallel-size 2 --max-model-len 262144
--max-num-seqs 8 --max-num-batched-tokens 2048
--quantization compressed-tensors (W4A16)
--speculative-config method=mtp,num_speculative_tokens=2
--enable-chunked-prefill --enable-prefix-caching
temperature 0.6 / reasoning_effort medium