LLM API verifizieren: Modell-Fingerabdruck prüfen

Frag ein Sprachmodell oft genug, eine Zufallszahl zwischen 1 und 100 zu wählen, und es passiert etwas Seltsames: Die Antworten sind nicht zufällig. Ein Modell landet ständig bei 42 und 73. Ein anderes bevorzugt 47 und 57. Das Muster ist stabil, reproduzierbar und unterscheidet sich für jedes Modell.

Ein Papier vom Juli 2026 wandelte diese Eigenheit in eine Verifikationsmethode um. One Token Is Enough: Fingerprinting and Verifying Large Language Models from Single-Token Output Distributions zeigt, dass diese Antwortverteilungen einen zuverlässigen Verhaltens-Fingerabdruck bilden, genug um von außen zu überprüfen, ob ein API-Endpoint das Modell bereitstellt, das er behauptet^[1]. Keine Gewichte, keine Logits, kein Insider-Zugang. Ein paar hundert Ein-Wort-Antworten.

Dieser Leitfaden erklärt, warum das model-Feld eine Behauptung und keine Garantie ist, wie Fingerabdrücke aus einem Token funktionieren, was die Zahlen bedeuten und wo die Grenzen der Methode liegen.

TL;DR

• Das model-Feld in einer API-Antwort ist nach dem Protokoll nicht überprüfbar. Nichts beweist, dass deine Anfrage vom angeforderten Modell bedient wurde^[1].
• Sprachmodelle können keine gleichmäßige Zufälligkeit erzeugen. Im Prüfset trägt die mittlere Antwortverteilung etwa 1,0 Bit Entropie, während eine faire Auswahl von 1 bis 100 6,64 Bits hätte^[1].
• Dieser Fehler ist konsistent, daher funktioniert er als Signatur. Gleiche Modelle, gleiche Schiefe, jedes Mal.
• Es gibt messbaren Abstand: Gleiche Modelle gegeneinander liegen bei JSD ~0,14, gleiche Modelle über zwei Provider bei ~0,23, zwei wirklich verschiedene Modelle bei ~0,46^[1].
• Die Genauigkeit ist stark, nicht perfekt. Die Fehlerquote beträgt 10,6% bei 8 Prüfeinheiten und 7,3% bei vollen 40, mit AUC 0,971^[1].
• Eine Abweichung ist Indiz, nicht Beweis. Quantisierung, ein stiller Version-Update oder ein verborgener System-Prompt können Verteilungen verschieben ohne dass jemand lügt.

Was hinter einer API passiert, siehst du nicht

Wenn du einen Chat-Completions-Endpoint rufst, sendest du Text und bekommst Text zurück. Das model-Feld in der Antwort sagt, was der Server eintragen möchte. Nichts im Protokoll beweist, dass die Anfrage vom genannten Modell bedient wurde, nicht von etwas, das ein Zehntel kostet^[1].

Diese Lücke wird wichtiger, je mehr des Markts hinter Intermediären sitzt: Aggregatoren, die Hunderte Modelle durch einen Endpoint weiterverkaufen, regionale Wiederverkäufer, die Flaggschiff-Zugang unter offiziellen Preisen anbieten, und Drittanbieter, die quelloffene Modelle mit Quantisierung und Serving-Stacks bereitstellen, die du nie siehst^[1].

Die meisten dieser Geschäfte sind legitim. Der Anreiz zu betrügen ist trotzdem offensichtlich, und eine Audit von 17 Shadow-API-Operatoren fand mehrere Endpoints, die gegen die beworbenen Modelle nicht durchkamen^[2].

Es geht auch nicht nur um Betrug. Ein Provider kann ein Modell quantisieren um Kosten zu senken, einen stillen Version-Update ausrollen oder Traffic über gemischte Backends routen. Falls die Qualität deines Produkts von einem bestimmten Modell abhängt, sollte „Was krieg ich wirklich?" anhand von Belegen, nicht Vertrauen beantwortbar sein.

Warum Zufallszahlen das Spiel verraten

Die Methode beruht auf einer gut dokumentierten Schwäche. Sprachmodelle berechnen nicht, sie vorhersagen, also wenn man sie um eine Zufallszahl bittet, reproduzieren sie die Biases der Trainingsdaten und Preference Tuning^[1].

Drei Cluster dominieren:

• 42 ist massiv überrepräsentiert, die Antwort aus dem Hitchhiker's Guide hallt durch Jahrzehnte Internet-Text.
• 7 trägt Jahrhunderte kulturelles Gewicht als die Glückszahl, die Menschen wählen.
• 37, 47, 73 und andere zweistellige Primzahlen fühlen sich für Menschen zufällig an, daher dominieren sie die von Menschen generierten „Zufalls"-Beispiele, die das Modell lernte.

Das Papier quantifiziert den Kollaps: die mittlere Antwortverteilung trägt rund 1,0 Bit Entropie, während eine faire Auswahl von 1 bis 100 6,64 Bits hätte^[1]. Wo ein fairer Würfel hundert Seiten hat, benehmen sich die meisten Modelle wie eine leicht gewichtete Münze.

Der Schlüssel ist, dass der Fehler konsistent ist. Dasselbe Modell produziert jedes Mal die gleiche verzerrte Verteilung, und unterschiedliche Modelle, einschließlich Schwesterversionen in einer Familie, produzieren messbar unterschiedliche. Ein Bug wird zur Signatur.

Das Protokoll in vier Schritten

1. Prüfung. Stelle dem Endpoint eine Batterie von Ein-Wort-Fragen: wähle eine Zufallszahl zwischen 1 und 100, nenne eine zufällige Farbe, wirf eine Münze. Das Papier nutzt 10 Aufgaben über 4 Sprachen für 40 Prüfeinheiten, sampelt jede 30-mal bei Temperatur 1,0 mit max_tokens=16 und Reasoning deaktiviert^[1].

2. Fingerabdruck. Für jede Prüfeinheit tally die Antworten in eine empirische Verteilung. Die Sammlung dieser Verteilungen ist der Verhaltens-Fingerabdruck des Endpoints.

3. Vergleich. Miss die Entfernung zwischen diesem Fingerabdruck und einer vertrauenswürdigen Referenz für das behauptete Modell, nutze Jensen-Shannon-Divergenz in Basis 2, damit die Skala von 0 (identisch) bis 1 (disjunkt) läuft.

4. Entscheidung. Kleine Entfernung bedeutet konsistent mit der Behauptung. Große Entfernung bedeutet der Endpoint ist verhaltenstechnisch ein anderes Tier.

Zwei Eigenschaften machen das schwer zu fälschen. Es braucht keinen speziellen Zugang, da alles, was auf Chat Completions antwortet, fingerabdrückbar ist. Und es gibt keine magische Zeichenkette zum Filtern, weil jede Prüfung eine normale harmlose Frage aus Umschreibungs-Pools ist, so ein unehrliches Middlebox kann den Test nicht special-casen ohne den normalen Traffic zu brechen^[1].

Die Divergenz-Zahl lesen

Ein Divergenz-Wert bedeutet ohne Referenzpunkte nichts, und hier wird die Methode praktisch.

Es gibt echten Raum zwischen „gleich" und „unterschiedlich"^[1]. Beachte, was die mittlere Reihe impliziert: selbst eine ehrliche Deployment desselben Modells von einem anderen Host driftet messbar, weil Quantisierung, Serving-Stack und verborgene System-Prompts alle Spuren hinterlassen.

Die Genauigkeit skaliert mit der Prüfanzahl. Bei 8 Prüfeinheiten beträgt die Fehlerquote 10,6%; bei vollen 40 fällt sie auf 7,3%, mit AUC 0,971^[1].

Was das Papier in der Wildnis fand

Der Palmyra-X5-Fall. Das auffälligste Ergebnis des Papiers betrifft ein Modell, das als proprietäres Flaggschiff angeboten wird, dessen Fingerabdruck bei JSD 0,141 von einem quelloffenen 235B-Modell saß, statistisch nicht unterscheidbar von den ~0,140, die du erhältst wenn du ein Modell gegen sich selbst vergleichst. Verhaltenstechnisch, folgert das Papier, bediente der Endpoint etwas funktional identisch mit dem Open-Source-Modell^[1].

Gleiche Modelle, verschiedene Provider, manchmal verdächtig unterschiedlich. Von 34 gleichen Modell-Paaren über verschiedene Provider bedient, 10 divergierten über das 5. Perzentil der Impostor-Verteilung^[1]. Manche offiziellen Modell-Drittanbieter-Deployments driften weit genug um wie verschiedene Modelle auszusehen. Verifikation ist nicht Paranoia selbst wenn niemand über den Namen lügt.

Die Forschungs-Artefakte sind offen: Der Fingerabdruck-Datensatz ist auf Zenodo unter CC-BY-4.0 und der Reproduktionscode unter MIT, beide auf Zenodo^[3][4].

Die Prüfung selbst durchführen

Das Protokoll ist einfach genug um direkt zu implementieren. Die Form davon:

import collections, math
from openai import OpenAI

client = OpenAI(api_key="...", base_url="https://your-endpoint/v1")

def probe(model, prompt, n=25):
    counts = collections.Counter()
    for _ in range(n):
        r = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": prompt}],
            temperature=1.0,
            max_tokens=16,
        )
        counts[r.choices[0].message.content.strip()] += 1
    total = sum(counts.values())
    return {k: v / total for k, v in counts.items()}

def jsd(p, q):
    keys = set(p) | set(q)
    m = {k: 0.5 * (p.get(k, 0) + q.get(k, 0)) for k in keys}
    def kl(a):
        return sum(a[k] * math.log2(a[k] / m[k]) for k in a if a[k] > 0)
    return 0.5 * kl(p) + 0.5 * kl(q)

Vier praktische Anmerkungen um das richtig zu machen.

Halte die Sampling-Bedingungen fest. Temperatur 1,0, kleines max_tokens, Reasoning deaktiviert. Ein Fingerabdruck unter anderen Einstellungen gesammelt ist nicht vergleichbar mit einem unter dem Papiers.

Nutze mehr als eine Prüfung. Eine einzelne Frage ist verrauscht. Die Fehlerquote halbiert sich ungefähr von 8 Prüfeinheiten zu 40.

Vergleiche gegen eine Referenz, die genauso gesammelt wurde. Die sauberste Referenz ist der offizielle Endpoint für dasselbe Modell, im gleichen Termin unter identischen Einstellungen fingerabdruckbar, statt einer veröffentlichten Tabelle von vor Monaten.

Beobachte auch die Hilfssignale. Ein Fingerabdruck der mit seinen eigenen Split-Hälften uneins ist deutet auf Multi-Backend-Routing. Ein-Wort-Antworten, die hunderte Completion-Tokens berechnen deuten auf Padding. Aufgeblasene Prompt-Token-Zählungen deuten auf einen großen verborgenen System-Prompt.

Eine Standard-Prüfung von 8 Prüfeinheiten bei 25 Samples sind etwa 200 winzige Anfragen, die einen Bruchteil eines Cents bei einem kleinen Modell kosten.

Was ein Ergebnis bedeutet und nicht bedeutet

Sei präzise über die Ansprüche, die diese Methode unterstützt.

Eine Abweichung ist Indiz, nicht Beweis. Die Methode hat eine inhärente Fehlerquote, etwa 10,6% EER bei 8 Prüfeinheiten. Aggressive Quantisierung, ein stiller Modell-Update, eine alte Referenz oder ein Serving-seitiger System-Prompt können Verteilungen verschieben ohne Betrugsvorsatz. Behandle ein rotes Ergebnis als Grund um mit mehr Prüfungen erneut zu testen, eine zweite Referenz zu prüfen und Fragen zu stellen^[1].

Eine Übereinstimmung ist stark aber nicht absolut. Ein raffinerter Impostor könnte im Prinzip die Verteilungen eines anderen Modells nachahmen, obwohl dies über Dutzende umschriebener mehrsprachiger Prüfungen hinweg während normaler Traffic korrekt bedient wird, schwieriger ist als es klingt.

Reasoning-Modelle brauchen Vorsicht. Fingerabdrücke werden mit Reasoning deaktiviert gesammelt. Wo ein Endpoint das nicht kann, sinkt das Vertrauen.

Eine Entfernung ist eine Eigenschaft eines Endpoints in einem Moment, nicht ein Urteil über ein Geschäft.

FAQ

Was ist LLM-Fingerabdrücke?

Die Verteilung der Antworten eines Modells auf eine Batterie von Ein-Wort-Fragen messen, dann diese Verteilung gegen eine Referenz für das Modell vergleichen, das ein Endpoint behauptet zu bedienen^[1].

Warum können Sprachmodelle keine Zufallszahlen produzieren?

Sie sagen vorher, nicht berechnen, daher gibt eine Anfrage nach Zufälligkeit die Biases von Trainingsdaten und Preference Tuning zurück. Kulturell beladene Werte wie 42 und 7 dominieren, kollabieren die Verteilung auf etwa 1,0 Bit Entropie gegen ein einheitliches Ideal von 6,64^[1].

Wie viel Unterschied zählt als Abweichung?

Nutze die Baselines des Papiers statt einer festen Schwelle: etwa 0,14 für ein Modell gegen sich selbst, 0,23 für gleiche Modelle über Provider, und 0,46 für wirklich verschiedene Modelle^[1].

Wie viele Anfragen braucht eine Prüfung?

Das volle Protokoll des Papiers ist 40 Prüfeinheiten zu 30-mal gesampelt. Eine leichtere 8-Einheits-Prüfung bei 25 Samples sind rund 200 Anfragen und erhöhen die Fehlerquote von 7,3% auf 10,6%^[1].

Kann ein Provider den Test erkennen und besiegen?

Nicht leicht. Prüfungen sind normale harmlose Fragen aus Umschreibungs-Pools, daher sie special-casen ohne den normalen Traffic zu brechen ist schwierig^[1].

Bedeutet ein fehlgeschlagener Check dass ein Provider betrügt?

Nein. Quantisierung, stille Version-Updates, verborgene System-Prompts und alte Referenzen produzieren alle Drift ohne Täuschung. Eine Entfernung ist eine statistische Beobachtung, die nähere Untersuchung rechtfertigt.

Ist der Datensatz verfügbar?

Ja. Der Fingerabdruck-Datensatz ist auf Zenodo unter CC-BY-4.0 und der Reproduktionscode unter MIT^[3][4].

Das Model-Feld als Behauptung behandeln

Die nützliche Verschiebung hier ist klein und spezifisch. Das model-Feld in einer API-Antwort ist eine Behauptung, und es gibt nun eine billige, offene, statistisch fundierte Methode um diese Behauptung von außen zu überprüfen, basierend auf nichts Exotischerem als der Tatsache dass Sprachmodelle eine Zufallszahl nicht um ihr Leben sagen können.

Falls du Kapazität durch einen Intermediär kaufst, ist der richtige Ort dafür neben Uptime-Monitoring: eine periodische Prüfung gegen eine Referenz die du selbst gesammelt hast, mit den Hilfssignalen beobachtet neben der Headline-Distanz. Und die richtige Methode ein rotes Ergebnis zu lesen ist als der Anfang eines Gesprächs, nicht das Ende eines. Ein LLM-API zu verifizieren ist um Belege über einen Endpoint in einem Moment Zeit zu sammeln, was genau weil die Alternative das Annehmen ist, wert ist es zu tun.

Referenzen

1. Bruckner, Tomáš. One Token Is Enough: Fingerprinting and Verifying Large Language Models from Single-Token Output Distributions. arXiv, July 2026. arxiv.org/abs/2607.10252
2. CISPA researchers. Real Money, Fake Models — an audit of shadow LLM API operators. arXiv. arxiv.org/abs/2603.01919
3. LLM fingerprint dataset (models × tasks × languages). Zenodo, CC-BY-4.0. zenodo.org
4. Reproduction code for One Token Is Enough. Zenodo, MIT License. zenodo.org

Dazu noch lesenswert

• reAPI. How to use Claude Opus 5. reapi.ai/blog/how-to-use-claude-opus-5
• reAPI. How to use GPT-5.6. reapi.ai/blog/how-to-use-gpt-5-6