Problom about the watermark generation and detection in vLLM

[gogogo66]

When I use the vllm to accelerate the inference of my LLM (chatGLM3-6b), There is a problem that the input tokens in vLLM are not passed to the logits_processor (only ouput tokens will), which seems to align with the logic of watermark detection as well, because during detection, we can only see the output content. However, In the example code of extended_watermark_processor.py, the input tokens are used as random seeds to generate the red and green lists at the beginning. My current solution is not to modify the output tokens if output length is less than context_width. I wonder if this approach has a significant impact on the results theoretically.

In the experiment, it is true that some watermarks can be detected without vLLM architecture, but cannot be detected after using vLLM. However, I am not sure whether it is caused by the processing logic I mentioned above.

[jwkirchenbauer]

So, one way to go about this is to ignore the first few ($h$, context width) tokens because they cannot be seeded properly as you point out. This shouldn't impact the watermark detection score if the output sequence being tested is reasonably long.

That said, based on the precise things you said above, my primary question would be about sequence lengths actually...

My current solution is not to modify the output tokens if output length is less than context_width. I wonder if this approach has a significant impact on the results theoretically.

Are you generating outputs that are often < 10 tokens?

If so, the watermark is not likely to be reliable as there is insufficient evidence built up by that point to be confident that the text is either watermarked or not (both FN and FP rates can be quite high, and TP and TN can be low).

If you are generating long outputs (say > 50 tokens) and are still getting poor detection rates, I'd suspect one of two things.

You might not be seeding the RNG the same way when you run detection. I don't know how the torch RNG behaves inside vLLM, but you need this to run the same way at detection time. One caveat we tried to mention in the readme was that you shouldn't run the watermark processor on GPU at generation time, but then run it on CPU at detection time. This might work in certain scenarios, but to make sure this isn't the problem, match the generation time device to the detection time device to be sure.

Alternately, maybe the logits are not actually being modified when vLLM runs the generation. I would actually make an issue in the vLLM codebase and describe the setup you're using, and how you instantiate the model and add the watermark configuration and see whether the vLLM maintainers actually expect the logits to be modified at runtime in this way. The watermarking processor/operation might not actually be supported even though hf models themselves are generally supported in that library, or there might be some caveats about how to make it play nicely with vLLM.

Feel free to tag me in an issue if you make one in the vLLM repo.

[gogogo66]

你的邮件已收到

[gogogo66]

Thanks for you reply. I agree with

This shouldn't impact the watermark detection score if the output sequence being tested is reasonably long

It is true that the token of my generating outputs are short, but not often < 10 tokens, and not > 50 tokens either. I don't have made an issue in vLLM repo, beacuse I am sure that logits are modified when vLLM runs, It's just not the same as hf.