Le framework d'inférence open source vLLM a annoncé le 24 septembre, sur son blog officiel, l'intégration d'un filigrane textuel basé sur la méthode Gumbel-max, activable côté serveur avec un simple paramètre de démarrage. L'article est signé par trois auteurs, l'un chez Mistral, les deux autres chez Red Hat.
L'activation est simple : il suffit d'ajouter --watermark-config à la commande vllm serve, de préciser l'algorithme gumbel et de fournir une clé. Dès lors, tout le texte généré par ce serveur porte un signal statistique invisible à l'œil nu.
Comment le filigrane est dissimulé
À chaque mot généré, un grand modèle attribue d'abord une probabilité à tous les mots candidats, puis en tire un au sort. C'est précisément sur cette étape de « tirage » que le filigrane Gumbel-max intervient.
Concrètement, la clé, le contexte des derniers mots et l'indice du mot candidat servent à calculer une suite de nombres qui paraît totalement aléatoire mais reste reproductible dès lors qu'on connaît la clé ; cette suite est transformée en bruit de Gumbel puis ajoutée au score du modèle, la valeur maximale étant retenue comme sortie. Mathématiquement, le résultat de ce tirage suit une distribution identique à celle d'un échantillonnage aléatoire ordinaire, ce qui permet aux auteurs de le qualifier de « sans distorsion » : le modèle ne se met pas à privilégier certains mots, un style d'écriture ou un type de solution.
Côté détection, aucun besoin des poids du modèle : seuls la clé et le tokenizer suffisent. Le texte est reconverti en tokens, la même clé permet de recalculer la même suite pseudo-aléatoire, chaque token est noté puis les scores sont additionnés et comparés à la distribution attendue en l'absence de filigrane, ce qui donne une valeur p. Selon l'étalonnage fourni par les auteurs, environ 1% des textes sans filigrane sont signalés à tort.
Deux séries de chiffres, entre coût et efficacité
Côté performance, les auteurs ont testé sur un seul GPU H100 avec Qwen3.5-27B, pour une génération de 512 tokens : à taille de batch 1, le débit varie de -0,23% ; à taille de batch 32, de +2,03% ; les moyennes par groupe se situent entre -1,1% et +2,0%, et les auteurs concluent qu'il n'y a pas de variation de débit constante. Pour économiser la mémoire GPU, vLLM a fusionné la génération des nombres pseudo-aléatoires, la transformation de Gumbel et le calcul du maximum en un seul noyau GPU.
Côté qualité du modèle, toujours avec Qwen3.5-27B, la comparaison avec et sans filigrane donne : GSM8K 93,0% contre 94,2%, MBPP 79,2% contre 77,2%, IFEval 90,7% contre 91,9%, des écarts que les auteurs jugent compris dans la marge d'erreur.
L'écart se creuse nettement sur le taux de détection. À un taux de faux positifs de 1%, un texte créatif est détecté à 100% dès une centaine de tokens ; pour les exercices de code MBPP, le taux de détection plafonne à 43% même à 400 tokens. La raison tient au principe même : pour une sortie de type code, le modèle est souvent très sûr du mot suivant, ce qui laisse peu d'aléa exploitable pour le filigrane. Les textes courts souffrent du même signal faible. Lorsqu'un texte est retouché par un humain, les scores autour de la zone modifiée sont brouillés, mais le signal se rétablit en dehors de ce passage.
La mise en œuvre comporte encore deux pièges. Le premier concerne le décodage spéculatif : les auteurs utilisent deux clés distinctes pour les tokens de brouillon et pour l'échantillonnage résiduel du modèle cible, afin de préserver le taux d'acceptation, au prix d'un signal de détection réparti entre deux clés. Le second tient au fait qu'un contexte répété produit la même suite de nombres aléatoires, ce qui peut faire tomber le modèle dans une répétition infinie ; la parade consiste à ignorer le filigrane en cas de contexte répété, une mesure qui affecte le débit d'au plus 0,19%.
Ce que cela signifie pour les déploiements en Chine
Les Mesures relatives à l'étiquetage des contenus générés et synthétiques par IA, en vigueur en Chine depuis septembre de l'an dernier, exigent que tout contenu généré porte un marquage explicite ou implicite. Appliqué au texte, le marquage implicite repose aujourd'hui surtout sur les métadonnées, alors qu'un filigrane statistique peut s'incruster directement dans le texte lui-même ; avec cette nouveauté, vLLM en a fait un simple interrupteur, que de nombreuses équipes chinoises exploitant leurs propres services d'inférence sous vLLM peuvent tester directement.
Mais les limites de cette solution sont tout aussi nettes : la détection dépend d'une clé détenue par celui qui déploie le système, sans vérification indépendante possible par un tiers ; le taux de détection reste faible pour le code et les réponses courtes ; et une réécriture humaine importante affaiblit le signal. Reste à savoir si cela suffira à satisfaire les exigences précises des régulateurs en matière de « marquage implicite » : tout dépendra de l'existence future de normes de détection associées, sur lesquelles aucune position publique n'a encore été formulée.
Sources : blog officiel de vLLM, CocoLoop, Mesures relatives à l'étiquetage des contenus générés et synthétiques par IA ; les chiffres de débit, de benchmarks et de taux de détection suivent les conditions de test des auteurs avec Qwen3.5-27B sur un seul GPU H100.