跳到正文
vLLM Blog· Raphaël Rialland (Mistral), Simon Veitner (Red Hat), and Tomas Ruiz (Red Hat)·· 24 天前AI 评分58

vLLM 支持基于 Gumbel-max 的无失真文本水印

Watermarking in vLLM

AI 导读

vLLM 现已支持基于 Gumbel-max 算法的无失真文本水印,并集成到 Model Runner v2 的采样管线中,同时兼容投机解码。实现将伪随机数生成、Gumbel 变换与 argmax 归约融合进单个 GPU kernel,在 Qwen3.5-27B 上跨 batch size 1–256 的吞吐变化在 −1.1% 到 +2.0% 之间。

正文 · AI 翻译

译文尚不完整,完整内容请切换到原文。

什么是文本溯源,为什么它充满挑战?

建立数字内容的溯源对于在我们分享的信息中建立信任和问责制至关重要。水印提供了一种解决方案:它通过修改作品来嵌入关于它的信息 [1],例如其来源。图像和音频可以以微妙的扰动方式嵌入水印,但由于文本的离散性质,这些技术不适用于文本。我们不是试图扰动文本本身,而是以一种可检测但不改变预期输出分布的方式影响生成过程。

对文本加水印既是一项科学挑战,也是一项工程挑战,为了获得实用的解决方案,我们必须平衡若干要求:

非失真

添加水印不应改变模型的预期输出分布 [2]:它不应系统性地偏向某些词语、写作风格或问题的解决方案。

鲁棒性

生成的文本可能以多种方式被改动:被缩短、编辑、与其他语料混合,甚至被另一个 LLM 改写。一个好的水印系统旨在即使在这种修改下也能保留其溯源信号。

速度

水印应为生成和检测增加最小的延迟和内存开销。这在诸如 vLLM 这样的高吞吐量服务引擎中尤为重要。当服务小型模型(对调度延迟变化敏感)和词汇量大的模型时,都会出现速度下降。

最小的检测依赖

检测文本水印应需要尽可能少的信息:试图确定某篇文字来源的用户不一定拥有关于其来源的额外信息,例如其创建日期或可能用于生成它的语言模型。

这些期望的特性彼此拉扯:一个易于检测的强信号可能需要我们显著改变模型的输出,而避免依赖额外信息则限制了我们可用的算法。

例如:

  • 附加到文件的元数据可以被剥离,并且当数据被复制到新文件时它们不会保留。
  • 红绿列表 [3] 和直接数据水印可能导致输出分布的失真。
  • Unicode 替换容易被移除和篡改。
  • 文本建模技术(例如查看句子长度、不寻常的词语和表达)不可靠。
  • 锦标赛采样 [2] 需要多轮处理,在不影响推理速度的情况下难以高效实现。

为了满足这些标准,我们利用了语言模型生成的一个自然属性:随机性。

利用 LLM 中的随机性

在每个生成步骤中,语言模型为每个可能的下一个 token 分配一个概率,然后采样一个。这个过程在可能延续的树中描绘出一条路径:其中一些路径比其他路径更可能,但许多都是有效的最终输出。

普通的随机采样在每一步抽取并丢弃新的随机值。水印则从最近的上下文和每个候选 token 中派生出可复现的带密钥值。由于上下文和选定的 token 保留在输出中,拥有密钥的检测器可以在生成后重建这些值。带水印的文本将系统性地与这些值对齐,从而产生一个在足够长的序列上累积的信号。

下一节将讨论我们如何在实现这一过程的同时,仍然保留模型最初的采样分布,从而有效地让我们能够可复现地选择模型可能的最终输出之一。

Gumbel-max 技巧

Gumbel-max 技巧是一种从类别分布中采样的技术。假设模型为每个候选 token 分配一个概率 :对于每个 token,我们抽取独立的均匀随机变量 并将它们转换为 Gumbel 随机变量:

被采样的 token 则为:

这一变换的一个显著结果是:

换句话说,将 Gumbel 噪声加到 token 的对数概率上并取它们的 argmax,产生的类别分布与普通随机采样完全相同:事实上,Model Runner v2 的标准采样路径已经使用了这一过程。在实践中,我们可以直接将 Gumbel 噪声应用于 logits,从而避免 softmax 并使计算更易于并行化。

Gumbel-max sampling example: model probabilities for table, mat, and chair are combined with Gumbel noise. “mat” wins one draw, while 20,000 repetitions come close to recovering the original 18%, 57%, and 25% distribution.
Gumbel-max 采样示例:table、mat 和 chair 的模型概率与 Gumbel 噪声相结合。“mat”在一次抽取中胜出,而 20,000 次重复则接近恢复原始的 18%、57% 和 25% 分布。

为了使这些随机抽取可复现,我们使用伪随机函数(PRF)[4]。PRF 确定性地将一个密钥和一个输入映射为一个表现得像随机均匀抽取的值:由于相同的输入总是产生相同的输出,检测器可以重建生成过程中使用的值。我们将每个独立的均匀抽取 替换为:

其中 是秘密水印密钥, 是最近的水印上下文(最后 个 token)。

包含 token ID 很重要,因为它允许每个 token 接收到不同的噪声;最近的上下文(默认情况下,我们使用最后 4 个 token)意味着我们施加的随机噪声在几乎每个生成步骤都不同;而秘密密钥则使这一模式对任何没有密钥的人来说都是不可预测的。

生成器为每个候选 token 计算这些带密钥的值,并选择带噪声对数概率最大的 token。给定相同的密钥和上下文,这一选择可以被复现,但如果没有密钥,它看起来就像普通的随机采样。

Bar chart comparing Qwen3.5-27B quality with and without dual-key watermarking: GSM8K 93.0% versus 94.2%, MBPP 79.2% versus 77.2%, and IFEval 90.7% versus 91.9%, with overlapping error bars.
柱状图比较了 Qwen3.5-27B 在使用和不使用双密钥水印时的质量:GSM8K 93.0% 对 94.2%,MBPP 79.2% 对 77.2%,IFEval 90.7% 对 91.9%,误差线重叠。

这为该方法是供了精确的无失真保证:在密钥的期望上,选择 token 的概率仍然恰好是 。然而,仅凭这一点并不能保证完整序列是无失真的。我们将在“保持输出多样性”中进一步讨论这一局限及其解决方案。

检测水印

在检测时,我们逆转生成过程中使用的过程。它不需要访问模型的权重或 logits,但确实需要知道秘密密钥和分词器。

用户将向检测器提供一段来源未知的文本序列。该检测器将把文本序列转换回 token ID。对于每个 token ,检测器将使用前面的上下文和秘密密钥重新计算其伪随机值:

对于未加水印的文本,观察到的 token 与其带密钥的值相互独立,因此 表现得像一个均匀随机变量。而加水印的生成则会偏向具有较大值的 token。我们将每个值转换为 token 级别的分数:

Because repeated contexts reproduce the same keyed values, the detector scores each context only once. If the text is not watermarked, the scores follow an exponential distribution with mean . Their sum,

therefore follows a Gamma distribution with shape and scale . This lets us compute a one-sided p-value: the probability that unwatermarked text would produce a score at least as large as . A small p-value is evidence that the text is consistent with the watermark.

Animation of watermark detection: each token's key and preceding context reconstruct keyed noise, which becomes a token score. Scores are summed and compared with the unwatermarked Gamma distribution to obtain a p-value.
Animation of watermark detection: each token's key and preceding context reconstruct keyed noise, which becomes a token score. Scores are summed and compared with the unwatermarked Gamma distribution to obtain a p-value.

Choosing a threshold trades false positives against false negatives. For a calibrated test, will flag approximately 1% of unwatermarked sequences as positives. In practice, we might also test against several keys, tokenizers, or watermarking configurations. This increases the chance of finding a large score by accident, requiring us to apply a multiple-testing correction. As the number of candidates grows, the threshold becomes smaller and our detection power falls.

Watermark detection power at 1% FPR versus distinct scored tokens for 1, 10, and 100 candidate tests. Creative writing approaches 100% TPR by about 100 tokens; MBPP rises more slowly and reaches about 69%, 49%, and 43% at 400 tokens.
Watermark detection power at 1% FPR versus distinct scored tokens for 1, 10, and 100 candidate tests. Creative writing approaches 100% TPR by about 100 tokens; MBPP rises more slowly and reaches about 69%, 49%, and 43% at 400 tokens.

Detection becomes stronger as independent evidence accumulates: long outputs provide more tokens to score, and high entropy steps give the watermark more opportunities to influence token selection. Short or predictable outputs therefore provide less signal.

Since the signal is encoded into the token choices themselves, copying and pasting a sufficiently long passage will preserve its evidence. Modifying the text will disrupt scores around the modified tokens, but the signal remains intact once these tokens are no longer in the recent context of following tokens.

How this was implemented in vLLM

The implementation was initially presented in the watermarking RFC, which highlighted that watermarking must integrate with final token sampling and speculative decoding. We therefore integrated it directly into Model Runner v2’s sampling pipeline. The initial implementation (PR #54053) connects GPUWatermarkSampler to an algorithm-specific Watermarker, allowing different schemes to share the same request and batch handling.

A naïve implementation would materialize a [batch, vocabulary] noise tensor, creating substantial temporary storage and memory traffic. vLLM instead fuses pseudorandom-number generation, the Gumbel transformation, and argmax reduction into a single GPU kernel. Philox generates four values per invocation, allowing the kernel to process four consecutive token IDs together.

A per-row mask lets the same fused sampler use keyed noise for watermarked requests and ordinary randomness for unwatermarked requests or repeated contexts.

Decode throughput for Qwen3.5-27B with MTP-3 across batch sizes 1–256. The watermarked and unwatermarked curves closely overlap throughout, showing no consistent throughput change.
Decode throughput for Qwen3.5-27B with MTP-3 across batch sizes 1–256. The watermarked and unwatermarked curves closely overlap throughout, showing no consistent throughput change.

Across eight keys, mean matched throughput changes ranged from −1.1% to +2.0% across batch sizes, with no significant slowdown.

Challenges

There are some major challenges with watermarking that required particularly interesting solutions. We will discuss two of the most important below: interaction with speculative decoding, and reduction in output diversity.

Speculative decoding

推测解码从草稿分布中提出 token,并根据目标分布接受它们。对两个分布应用相同的水印可以分别保留它们,但会减少它们的重叠并降低接受率。vLLM 则使用 双密钥实现(PR #56122): 用于被接受的草稿 token,而 用于目标残差和奖励 token。分离密钥可保持普通接受率,并使目标采样独立于被拒绝的草稿提议。

最终文本将包含由其中一个密钥加水印的 token,因此我们必须在评分时使用两个密钥并合并它们的分数。不幸的是,这会稀释两个密钥的信号,并导致检测信号减弱。

这种加权可以校准,以反映每个 token 的预期来源以及它携带多少信号。例如,当草稿 token“容易”且因此熵较低时,它们可能更常被接受,这意味着它们携带的水印信号较少。

保持输出多样性

单 token 非失真只保证每个生成步骤的分布,而不是完整序列上的分布。如果上下文重复,其键控噪声也会重复,从而使普通采样本应独立做出的 token 选择产生相关性(见下方示例)。单序列非失真是一个更强的保证,即完整序列上的分布也保持不变。

例如,想象一个固定密钥使模型生成以下序列:

1 + 1 +       -> 1   context: (1, +, 1, +)
1 + 1 + 1     -> +   context: (+, 1, +, 1)
1 + 1 + 1 +   -> 1   context: (1, +, 1, +)

在再次生成 1 之后,上下文 (1, +, 1, +) 已经重复。因此,固定密钥会产生与之前有利于生成 1 相同的伪随机值。如果模型的概率也相似,或者偏差足够强,它很可能会再次选择 1:在这种情况下,生成可能会进入无限重复循环。

1 + 1 + 1 + 1 + 1 + (...)

这是最坏情况,但这种跨上下文相关性的影响通常可能导致序列内多样性降低、退化行为发生率增加、生成时间变长以及输出质量下降。

Output-length survival on Qwen3.5-2B math prompts: plain watermarking produces many capped long outputs, dual-key reduces the excess, and context deduplication matches unwatermarked decoding.
Qwen3.5-2B 数学提示上的输出长度存活情况:普通水印会产生许多达到上限的长输出,双密钥减少了超出部分,而上下文去重则与未加水印的解码相匹配。

vLLM 通过 生成时上下文去重(PR #56233) 解决了这个问题,它在上下文重复时跳过水印,并保持单序列非失真。尽管在每一步都检查前序生成中是否有重复上下文,但它在 Qwen3.5-27B 上将端到端吞吐量最多降低了 0.19%。

我们还可以利用前面讨论的双密钥水印方案,因为 token 来自目标分布还是草稿分布的随机性减轻了这种不良行为的影响,并提高了跨序列的多样性。更一般地,我们可以在没有推测解码的情况下使用双密钥路由 [5],即在生成过程中随机选择使用哪个密钥。

开始使用

你可以在启动 vLLM 服务器时启用 Gumbel-max 水印:

vllm serve mistralai/Mistral-7B-Instruct-v0.3 \
  --watermark-config '{"algorithm":"gumbel","key":42}'

vLLM 还提供了一个最小 HTTP 检测服务器示例,用于使用匹配的分词器和水印密钥检查文本。有关配置和检测示例,请参阅水印文档。

结论

vLLM 现已支持使用 Gumbel-max 算法的无失真水印,具备高效的 GPU 生成和投机解码支持。我们的评估表明,在保持输出质量和多样性的同时,性能开销极小。

致谢

我们感谢 Wassim Bouaziz、Andy Lo、Nicolò Lucchesi、Victor Paltz、Leila Saidi 和 Mickaël Seznec 对本文的悉心审阅和反馈,并感谢 Lucas Wilkinson 对实现和审阅的贡献。

附录

吞吐量测量

测量使用 Qwen3.5-27B,在单块 H100 上运行,采用 MTP-3 和 512 个输出 token。吞吐量数值为八个加水印密钥和四个未加水印对照的中位数。

批次大小未加水印中位数(tok/s)加水印中位数(tok/s)平均匹配变化95% CI
1113.9113.9−0.23%[−1.00%, +0.53%]
2218.2218.5−0.30%[−2.87%, +1.08%]
4420.5413.7−1.11%[−2.36%, +0.14%]
8753.9767.3+0.77%[−0.99%, +2.72%]
161364.81358.7+0.02%[−1.06%, +1.61%]
321378.81407.9+2.03%[+0.59%, +3.46%]
641439.91427.3−1.10%[−2.59%, +0.77%]
1281568.51574.5+0.36%[−1.14%, +2.04%]
2561590.71586.5−0.58%[−1.92%, +0.77%]

参考文献

1. Ingemar J. Cox, Matthew L. Miller, Jeffrey A. Bloom, Jessica Fridrich, and Ton Kalker. “Digital Watermarking and Steganography.” 2nd ed., Morgan Kaufmann (2008).

2. Sumanth Dathathri et al. “Scalable watermarking for identifying large language model outputs.” Nature 634, 818–823 (2024). Supplementary information, §G.3.

3. John Kirchenbauer, Jonas Geiping, Yuxin Wen, Jonathan Katz, Ian Miers, and Tom Goldstein. “A Watermark for Large Language Models.” Proceedings of the 40th International Conference on Machine Learning (2023).

4. Scott Aaronson and Hendrik Kirchner. “Watermarking GPT outputs,” 2023.

5. Tom Sander et al. “TextSeal: A Localized LLM Watermark for Provenance & Distillation Protection.” arXiv:2605.12456 (2026).

来源:vLLM Blog · vllm.ai