開源推理框架vLLM於9月24日在官方部落格宣布，框架內加入了基於Gumbel-max方法的文字浮水印，伺服器端只要一個啟動參數就能開啟。文章署名三位作者，一位來自Mistral，兩位來自Red Hat。
開啟方式很簡單，在vllm serve指令後面加上--watermark-config，指定演算法為gumbel、再給一把金鑰即可。之後這台伺服器產生的所有文字都會帶上肉眼看不見的統計訊號。
浮水印怎麼藏進去
大型模型每產生一個詞，都會先為所有候選詞打一個機率，再從中抽出一個。Gumbel-max浮水印動手腳的就是「抽取」這一步。
具體做法是：用金鑰、最近幾個詞的上下文與候選詞編號，算出一組看起來完全隨機、但只要知道金鑰就能重現的數字，把它轉換成Gumbel雜訊加到模型的分數上，取最大值的候選作為輸出。從數學上看，這樣抽出來的結果分布與一般隨機取樣完全一致，因此作者稱之為「無失真」：模型不會因此偏好某些詞彙、某種文體或某類解法。
偵測端不需要模型權重，只要金鑰和分詞器即可。把文字還原成token，用同一把金鑰重新算出那組偽隨機數，逐一打分後加總，再與沒有浮水印時應有的分布相比，得出一個p值。依作者提供的校準基準，沒有浮水印的文字大約有1%機率會被誤判。
代價與效果的兩組數字
效能方面，作者在單張H100上用Qwen3.5-27B測試輸出512個token的情境：批次大小為1時吞吐量變化-0.23%，批次大小32時為+2.03%，各組平均落在-1.1%到+2.0%之間，作者的結論是沒有一致的吞吐量變化。為了節省顯示卡記憶體，vLLM把偽隨機數產生、Gumbel轉換與取最大值合併成一個GPU核心。
模型品質方面，同樣以Qwen3.5-27B測試，加浮水印與不加浮水印的對比為：GSM8K 93.0%對94.2%，MBPP 79.2%對77.2%，IFEval 90.7%對91.9%，作者認為差異都在誤差範圍內。
偵測率的差距就大得多。在1%誤判率的標準下，創意寫作大約100個token就能全數偵測出來；但MBPP程式碼題目寫到400個token，偵測率也只有43%。原因就在原理裡：像程式碼這類輸出，模型對下一個詞往往很有把握，能讓浮水印操作的隨機性本來就少。短文字同樣訊號偏弱。文字一旦被人工修改，修改處附近的分數會被打亂，但離開那段上下文之後訊號還能恢復。
實作上還有兩個坑。一個是推測解碼（speculative decoding），作者用兩把金鑰分別處理草稿token與目標模型的殘差取樣，以保住接受率，代價是偵測訊號被分散到兩把金鑰上。另一個是重複的上下文會產生同一組隨機數，可能讓模型陷入無限重複，解法是遇到重複上下文就跳過浮水印處理，這一步對吞吐量的影響最多0.19%。
對中國部署方意味著什麼
中國《人工智慧生成合成內容標識辦法》自去年9月起施行，要求生成內容加上明示或隱含標識。落到文字上，隱含標識目前多靠中繼資料，統計浮水印則能直接嵌進文字本身，vLLM這次等於把它做成了一個開關，中國大量用vLLM自建推理服務的團隊可以直接嘗試。
但這套方案的邊界也很清楚：偵測靠金鑰，誰部署誰持有，第三方無法獨立驗證；程式碼和短回覆的偵測率偏低；遇到人工大幅改寫，訊號會被削弱。能否滿足監管單位對「隱含標識」的具體要求，還要看後續有沒有配套的偵測標準，目前沒有公開的口徑。
參考來源：vLLM官方部落格、CocoLoop、《人工智慧生成合成內容標識辦法》；吞吐量、基準分數與偵測率均為作者在Qwen3.5-27B與單張H100上的測試口徑。