vLLM 社群回報 CPU 採樣偏差，固定亂數表可能讓部分 token 無法被選中

vLLM 社群於 10 月 2 日提出 CPU 推論正確性回報：V1 採樣器使用固定亂數表，可能讓生成結果偏離模型輸出的機率分布。回報附上核心層與引擎層重現程式，測試涵蓋 Linux x86_64 與 Apple M1 Pro；目前證據來自主分支的指定提交，不能直接推定所有正式版本均受影響。問題回報

作者指出，fused_gumbel_argmax 從含有 2²⁰ 個元素的固定 Gumbel 表取得擾動，每次以種子決定起點，再按 token 索引連續取值。這讓整列詞彙的亂數組合受限於同一張表的有限視窗。作者枚舉所有視窗，在 151,936 個 token、人工設定的 Zipf 分布下，發現 79,078 個具有非零理論機率的 token 從未勝出；它們合計占原分布約 3.75% 的機率質量。測試方法與結果

引擎層測試使用隨機權重的小型 Llama，透過自訂 logits 處理器固定每步分布，再送出兩萬次單 token 請求。V1 沒有選中上述 token，Model Runner V2 則選中 768 次，接近理論預期的 749 次。這是隔離採樣行為的人工實驗，尚不能解讀為真實模型有一半詞彙永久失效，或生成品質下降固定幅度。端到端對照

官方設計文件提供了兩條路徑的背景：Model Runner V2 採用 Triton Gumbel 核心，依種子在核心內產生無狀態亂數，並避免顯式建立完整 softmax。官方配置程式也要求 V2 必須具備 Triton，因此部署者須先確認平台支援與實際執行路徑，不能把切換 V2 視為通用解法。設計文件、配置驗證

對工程團隊而言，這起回報提示採樣測試應涵蓋實際詞彙規模與長尾機率，而非只檢查輸出是否流暢。作者指出，既有卡方測試將詞彙數限制在一百，未捕捉此案例。後續值得追蹤大詞彙統計測試是否納入上游、亂數生成方式如何調整，以及修補在各 CPU 平台的正確性與效能；目前仍需維護者確認完整影響範圍。測試盲點與修補方向