Agent Telemetry

那一臂在切換前執行,GPU0 還被生產佔著:Free memory on device cuda:0 (0.3/31.73 GiB) —— 排程順序問題,不是 27B TP4 的退化。先前量到的 38.4 tok/s 仍然成立。

max_tokens 太小時,推理模型會把整個額度花在思考段,串流下呼叫端會收到完全空白且無錯誤的回應(實測 200 tokens 時 4/6 空白)。請給 1024 以上。

52.5 tok/s / 每人 — 當時以隨機 token 當提示,掩蓋了輸出退化,而退化的輸出解碼更快,反而灌高數字。基準測試現已內建真實文本的詞彙重複度斷言。

MTP 在自由文本上是淨損,但工具呼叫的輸出高度重複(JSON 骨架、欄位名、<tool_call> 標籤幾乎每次相同)—— 那是 n-gram 命中率最高的地形。因此每個臂同時測工具呼叫與中文散文兩種負載:前者驗證假設,後者當對照組,確認它不會拖累一般對話。三種方法都不需要額外的 draft 模型。

散文臂帶詞彙重複度斷言。ngram_gpu 正是它攔下的:散文 25.6 tok/s 是所有推測臂最高,但 uniq 只有 0.20,輸出已是垃圾 —— 沒有閘門會被記成「最快」。但這道閘門只有單向效力:它用空白切詞,而中文不用空白,純中文輸出可能只切出一個 token 而得到 uniq=1.00。低 uniq 是退化的證據,高 uniq 不能當成輸出健康的證據。

vLLM 的 ngram proposer 比對的是精確 token ID 序列,不是「這看起來像 JSON」—— 結構相似不等於 token 序列相同,所以工具呼叫的重複性並不會轉成命中率。而且失敗是正確性問題而非速度問題:三個推測臂都產不出合法的 tool_calls。同樣的量化 KV + ngram 失敗在 RTX 3090 上也有回報(vLLM issue #40831),因此不能歸因於 SM70 世代。

推測臂同時出現「慢三倍」與「工具呼叫失敗」,兩者很可能同源於 TQ2 的 verify / rollback 路徑而非 proposer。五個臂統一用 8192 context —— FP16 KV 在 32K 下裝不進 32GB,不統一就沒有可比性;因此絕對值低於 32K 的 baseline,只有內部比較有意義。

三個量測缺陷,都在我自己的測試工具裡,結論待重測:

① draft / accepted 全為 0,連開了推測的臂也是 —— 代表我抓的 metric 名稱在這個 fork 不存在,整欄沒有訊號,不能讀成「推測沒運作」。
② uniq=1.00 是假的健康,見上方閘門說明。
③ FP16 · 推測關 工具呼叫 0/3 講不通 —— 它沒開推測,理應與 TQ2 · 推測關 的 3/3 一致。這推翻了「責任完全在 TQ2 verify」的乾淨假設,但同樣可能是測試本身的問題。下一步要看實際回應內容,不能再看聚合數字。

前三個假設都被實測推翻,而且它們都很有說服力 —— 留在這裡是為了不再重走。真正的轉折是不再靠推論、改看哪一套帳本對不上:當 cuda_reserved 與程序 RSS 同時持平、系統可用記憶體卻持續下降,這個組合只指向一個地方。