In einem Blogbeitrag vom 24. September 2026 hat vLLM angekündigt, dass seine Inference-Engine nun offiziell Gumbel-max-basiertes Text-Watermarking unterstützt. Das Ziel ist direkt: die Herkunft von modellgeneriertem Text nachverfolgbar machen — ohne die Ausgabeverteilung des Modells zu verzerren und ohne die Inferenz zu verlangsamen. Offiziellen Messungen zufolge bleibt Qwen3.5-27B mit aktiviertem Watermarking in allen Benchmarks innerhalb der Fehlerbalken; der Durchsatz ändert sich zwischen −1,1 % und +2,0 % — praktisch vernachlässigbar.
So funktioniert das Watermarking: die Zufälligkeit markieren
Jedes Mal, wenn ein Sprachmodell ein Token erzeugt, bewertet es zunächst jedes Kandidaten-Token und sampelt dann zufällig. Die Watermarking-Idee fasst nicht den Text an — sie markiert den „Zufalls"-Schritt selbst: Ein geheimer Schlüssel, die jüngsten Kontext-Tokens und die ID des Kandidaten-Tokens laufen durch eine Pseudozufallsfunktion, die einen reproduzierbaren Satz Zufallswerte berechnet; diese werden als Gumbel-Noise auf die Logits addiert, und das Token mit dem Maximum wird gewählt.
Die entscheidende mathematische Eigenschaft: Argmax über Gumbel-Noise ist exakt äquivalent zum gewöhnlichen Sampling aus der ursprünglichen Wahrscheinlichkeitsverteilung. Mit anderen Worten: In jedem einzelnen Schritt ist die Wahrscheinlichkeit, dass ein Token gewählt wird, mit oder ohne Watermarking identisch — die Ausgabeverteilung wird nicht verdreht, das Modell bevorzugt nicht systematisch bestimmte Wörter oder Stile. Wer den Schlüssel hält, kann die Zufallswerte von damals neu berechnen; ohne Schlüssel sieht es einfach wie ein gewöhnliches Zufallssampling aus.
Detektion: Verifikation in umgekehrter Richtung
Die Detektion braucht keine Modellgewichte oder Logits — nur den geheimen Schlüssel und den Tokenizer. Der zu prüfende Text wird zurück in Token-IDs verwandelt, und für jedes Token wird der Pseudozufallswert aus seinem Vorgängerkontext und dem Schlüssel neu berechnet: Bei unwatermarked Text sind diese Werte gleichverteilt zufällig; bei watermarked Text sind die gewählten Tokens systematisch zu größeren Werten verzerrt. Die Summierung der Token-Scores folgt einer Gamma-Verteilung und liefert einen p-Wert — je kleiner, desto unwahrscheinlicher ist „Zufall".
Längerer Text mit mehr hochentropischen Schritten gibt ein stärkeres Signal: Kreatives Schreiben erreicht schon bei etwa 100 Tokens eine nahezu 100-prozentige Detektionsrate. Komplettes Copy-and-Paste löscht die Beweise nicht; lokales Umschreiben stört Scores in der Nähe der editierten Tokens, aber sobald die Edits aus dem Kontextfenster rutschen, bleibt das restliche Signal intakt.
Zwei harte Nüsse: Speculative Decoding und Diversität
Aus dem Paper eine lauffähige Engine zu machen, hieß zwei harte Nüsse zu knacken. Die erste ist Speculative Decoding: Teilen sich Draft- und Zielmodell ein Watermarking, sinkt die Verteilungsüberlappung und die Acceptance Rate leidet. vLLMs Antwort sind Dual Keys (PR #56122) — akzeptierte Draft-Tokens nutzen einen Schlüssel, Residual- und Bonus-Tokens des Zielmodells einen anderen — was die Acceptance Rate rettet, zur Detektion aber die Kombination beider Schlüssel-Scores erfordert, was das Signal verdünnt.
Die zweite ist die Ausgabediversität: Verzerrungsfreiheit pro Token garantiert nur die Verteilung „eines Schritts", nicht die der gesamten Sequenz. Wiederholt sich ein Kontext, liefert ein fester Schlüssel identische Zufallswerte, und das Modell kann in eine Endlosschleife kippen. vLLM löst das mit Generation-Time-Kontext-Deduplizierung (PR #56233): Bei wiederholtem Kontext wird das Watermarking übersprungen, was die Verzerrungsfreiheit auf Sequenzebene erhält — gemessen sinkt der End-to-End-Durchsatz um höchstens 0,19 %.
Auf der Engineering-Seite dockt das Watermarking direkt an die Sampling-Pipeline von Model Runner v2 an (PR #54053); Pseudozufalls-Generierung, Gumbel-Transformation und Argmax sind in einem einzigen GPU-Kernel fusioniert, was enormen temporären VRAM-Overhead vermeidet.
Wer wird es zuerst nutzen?
Die ersten Nutznießer sind Unternehmen und Firmen, die vLLM selbst hosten: Bei externem API-Angebot können sie den Ausgaben eine verifizierbare „Geburtsurkunde" stempeln — für Provenienz, Compliance-Spuren oder um das eigene Modell von Imitaten zu unterscheiden. Die Grenzen sind klar zu benennen: Die Detektion hängt am Schlüsselbesitz und ist nicht öffentlich verifizierbar; kurze, stark schablonenhafte Ausgaben geben ein schwaches Signal; und es kontert „Herkunfts-Leugnung", nicht einen entschlossenen Umschreiber.
Textherkunft wird seit Jahren diskutiert; vLLM hat daraus einen Schalter in der Inference-Engine gemacht — verzerrungsfrei, niedriger Overhead, produktionsreif. Nach diesem Schritt hat die Debatte, „ob KI-generierte Inhalte nachverfolgbar sein sollten", mindestens eine technische Ausrede weniger.
