vLLM 在 9 月 24 日的官方博客中宣布，推理引擎正式支持基于 Gumbel-max 的文本水印功能。这项技术的目标很直接：让模型生成文本的来源可被追溯，同时保证加水印不改变模型的输出分布、不拖慢推理速度。按官方实测，Qwen3.5-27B 开启水印后，各项基准成绩都在误差范围内，吞吐变化在 -1.1% 到 +2.0% 之间，基本可以忽略。
水印怎么做：给随机数"做记号"
语言模型每生成一个 token，都要先给每个候选 token 打分再随机采样。水印的思路不是去改文本，而是在"随机"这个环节做记号：用密钥、最近几个 token 的上下文和候选 token 的 ID，通过伪随机函数算出一组可复现的随机值，加到 logits 上做 Gumbel 噪声，最后取最大值对应的 token。
关键的数学性质是：对 Gumbel 噪声取 argmax，恰好等价于按原始概率分布做普通采样。也就是说，单看某一步，加水印和不加水印选出某个 token 的概率完全一样——输出分布没有被扭曲，模型不会系统性偏爱某些词或某种写法。检测方只要拿着密钥，就能把当初的随机值重算出来；没有密钥的人，看到的只是一次普通的随机采样。
检测时反向验算
检测不需要拿到模型权重和 logits，只需要密钥和分词器。把待测文本转回 token ID，对每个 token 用它前面的上下文和密钥重算伪随机值：没加水印的文本，这些值就是均匀随机；加了水印的文本，选出的 token 会系统性偏向更大的值。把每个 token 的得分累加起来，服从 Gamma 分布，可以算出一个 p-value——p-value 越小，越不可能是"碰巧"。
文本越长、信息熵越高的步骤越多，信号越强：创意写作约 100 个 token 就能接近 100% 检出率。复制粘贴整段文字不会抹掉证据；局部改写会扰动被改 token 附近的分数，但一旦改动滑出上下文窗口，后面的信号依然完整。
两个硬骨头：推测解码与多样性
把论文变成能跑的工程，vLLM 啃了两块硬骨头。第一块是推测解码：草稿模型和目标模型如果用同一套水印，会降低两者的分布重合度，拖低接受率。vLLM 的解法是双密钥（PR #56122）——被接受的草稿 token 用一把密钥，目标模型的残差和奖励 token 用另一把，保住接受率，代价是检测时要合并两把密钥的分数，信号会被稀释。
第二块是输出多样性：单 token 无失真只保证"某一步"的分布不变，不保证整段序列的分布不变。如果某段上下文重复出现，固定的密钥会给出相同的随机值，模型可能被带进无限重复的死循环。vLLM 用"生成时上下文去重"（PR #56233）解决：上下文重复时直接跳过加水印，保住序列级无失真，实测端到端吞吐最多下降 0.19%。
工程实现上，水印直接接进 Model Runner v2 的采样管线（PR #54053），伪随机数生成、Gumbel 变换和 argmax 被融合成单个 GPU kernel，避免了巨大的临时显存开销。
谁会先用上它
最先受益的是自托管 vLLM 的服务商和企业：对外提供 API 时，可以给输出打上可验证的"出生证明"，用于溯源、合规留痕或区分自家模型与仿冒服务。局限也要说清楚：检测依赖密钥持有，做不到公开验证；短文本、模板化严重的输出信号很弱；它防的是"来源抵赖"，防不住决心改写的对手。
文本溯源喊了很多年，vLLM 这次是把它做成了推理引擎里的一个开关——无失真、低开销、可工程化。这一步之后，"AI 生成内容要不要可溯源"的争论，至少在技术上少了一个借口。
