
Vérifier qu'une API LLM fournit réellement son modèle
Les modèles ne peuvent pas générer de nombres aléatoires. Ce défaut crée une empreinte stable pour vérifier si l'API fournit le modèle qu'elle annonce.
Demandez à un modèle de langage de choisir un nombre aléatoire entre 1 et 100 suffisamment de fois et quelque chose d'étrange se produit : les réponses ne sont pas aléatoires. Un modèle atterrit régulièrement sur 42 et 73. Un autre favorise 47 et 57. Le motif est stable, reproductible, et différent pour chaque modèle.
Un article de juillet 2026 a transformé cette bizarrerie en méthode de vérification. One Token Is Enough: Fingerprinting and Verifying Large Language Models from Single-Token Output Distributions montre que ces distributions de réponses forment une empreinte comportementale fiable, suffisante pour vérifier de l'extérieur si un point de terminaison API fournit réellement le modèle qu'il prétend[1]. Pas de poids, pas de logits, pas d'accès interne. Quelques centaines de réponses d'un mot.
Ce guide explique pourquoi le champ model est une affirmation plutôt qu'une garantie, comment fonctionne le fingerprinting à un seul token, ce que les chiffres signifient, et où les limites de cette méthode se situent.
Résumé rapide
- Le champ
modeldans une réponse API ne peut pas être vérifié par le protocole. Rien ne prouve que votre demande pour un modèle phare a été traitée par lui[1]. - Les modèles de langage ne peuvent pas produire de l'aléatoire uniforme. Sur l'ensemble des probes de l'étude, la distribution médiane des réponses ne porte qu'environ 1,0 bit d'entropie contre les 6,64 bits qu'un choix uniforme entre 1 et 100 aurait[1].
- Cet échec est cohérent, donc il fonctionne comme une signature. Même modèle, même asymétrie, chaque fois.
- L'échelle offre un contraste utilisable : le même modèle comparé à lui-même donne une JSD près de 0,14, le même modèle chez deux fournisseurs près de 0,23, deux modèles véritablement différents près de 0,46[1].
- La précision est forte, pas parfaite. Le taux d'erreur égale est de 10,6 % avec 8 unités de probe et 7,3 % à l'ensemble complet de 40, avec une AUC de 0,971[1].
- Une discordance est une preuve, non une preuve définitive. La quantification, une mise à jour silencieuse de version ou une invite système cachée peuvent tous décaler une distribution sans malhonnêteté.
Vous ne pouvez pas voir ce qui se trouve derrière une API
Quand vous appelez un point de terminaison de complétions de chat, vous envoyez du texte et recevez du texte. Le champ model dans la réponse dit ce que le serveur choisit d'y mettre. Rien dans le protocole ne prouve que la demande a été traitée par le modèle nommé, plutôt que par quelque chose dix fois moins cher[1].
Cet écart devient plus important à mesure que davantage de parts du marché s'assoient derrière des intermédiaires : des agrégateurs revendant des centaines de modèles via un point de terminaison, des revendeurs régionaux offrant un accès aux modèles phares sous les prix officiels, et des hôtes tiers servant des modèles de poids ouvert avec des choix de quantification et de pile d'exécution que vous ne voyez jamais[1].
La plupart de ces entreprises sont légitimes. L'incitation à tricher reste évidente, et un audit indépendant de 17 opérateurs d'API fantôme a trouvé plusieurs points de terminaison qui n'ont pas réussi la vérification face aux modèles annoncés[2].
Ce n'est pas seulement une question de fraude. Un fournisseur peut quantifier un modèle pour réduire les coûts d'exécution, déployer une mise à jour silencieuse de version ou acheminer le trafic sur des backends mixtes. Si la qualité de votre produit dépend d'un modèle spécifique, « Que vais-je réellement obtenir ? » devrait être répondable par des preuves plutôt que par la confiance.
Pourquoi les nombres aléatoires livrent le secret
La méthode repose sur une faiblesse bien documentée. Les modèles de langage ne calculent pas, ils prédisent, donc quand on leur demande un nombre aléatoire, ils reproduisent les biais de leurs données d'entraînement et du réglage des préférences[1].

Trois groupes dominent :
- 42 est massivement surreprésenté, la réponse du Guide du Voyageur Galactique résonnant à travers des décennies de texte internet.
- 7 porte le poids séculaire de la chance, le choix que les humains saisissent naturellement.
- 37, 47, 73 et autres nombres premiers à deux chiffres semblent aléatoires aux humains, ils dominent donc les exemples « aléatoires » générés par l'homme à partir desquels le modèle a appris.
L'article quantifie l'effondrement : la distribution médiane des réponses porte environ 1,0 bit d'entropie, où un choix équitable entre 1 et 100 porterait 6,64 bits[1]. Un dé à cent faces devient une pièce légèrement chargée.
Le coup clé est que l'échec est cohérent. Le même modèle produit la même distribution asymétrique chaque fois, et les modèles différents, y compris les versions frères dans une même famille, produisent des distributions mesurément différentes. Un bug devient une signature.
Le protocole, en quatre étapes
1. Sonder. Interrogez le point de terminaison avec un ensemble de questions d'un seul mot : choisir un nombre aléatoire entre 1 et 100, nommer une couleur aléatoire, tirer une pièce. L'article utilise 10 tâches sur 4 langues pour 40 unités de probe, en échantillonnant chacune 30 fois à température 1.0 avec max_tokens=16 et le raisonnement désactivé[1].
2. Empreinte. Pour chaque unité de probe, compilez les réponses dans une distribution empirique. L'ensemble de ces distributions est l'empreinte comportementale du point de terminaison.
3. Comparer. Mesurez la distance entre cette empreinte et une référence fiable pour le modèle annoncé, en utilisant la divergence de Jensen-Shannon en base 2, pour que l'échelle aille de 0 (identique) à 1 (disjoint).
4. Décider. Une petite distance signifie cohérent avec l'affirmation. Une grande distance signifie que le point de terminaison est comportementalement un animal différent.
Deux propriétés rendent cela difficile à contourner. Cela n'exige pas d'accès spécial, puisque n'importe quoi répondant à complétions de chat peut être empreinte. Et il n'y a pas de chaîne magique à filtrer, car chaque probe est une question ordinaire inoffensive tirée de pools de paraphrase, donc un intermédiaire malhonnête ne peut pas traiter le test en cas spécial sans casser le trafic normal[1].
Lire le nombre de distance
Une valeur de divergence ne signifie rien sans les points de référence, c'est là que la méthode devient pratique.

| Comparaison | JSD typique |
|---|---|
| Même modèle comparé à lui-même | ~0.14 |
| Même modèle, deux fournisseurs différents | ~0.23 |
| Deux modèles véritablement différents | ~0.46 |
Il y a un vrai contraste entre « identique » et « différent »[1]. Remarquez ce que la ligne du milieu implique : même un déploiement honnête du même modèle par un hôte différent s'écarte de manière mesurable, car la quantification, la pile d'exécution et les invites système cachées laissent toutes des traces.
La précision augmente avec le nombre de probes. À 8 unités de probe, le taux d'erreur égale est 10,6% ; au complet de 40, il tombe à 7,3%, avec une AUC de 0,971[1].
Ce que l'étude a trouvé à l'état sauvage
Le cas palmyra-x5. Le résultat le plus frappant de l'article concerne un modèle offert comme un produit phare propriétaire dont l'empreinte était à une JSD de 0,141 d'un modèle de poids ouvert de 235B, statistiquement indiscernable du ~0.140 que vous obtenez en comparant un modèle à lui-même. Comportementalement, conclut l'article, le point de terminaison servait quelque chose fonctionnellement identique au modèle open-source[1].
Même modèle, fournisseurs différents, parfois suspecte d'être différent. Des 34 paires de même modèle servies sur différents fournisseurs, 10 se sont écartées au-delà du 5e percentile de la distribution d'imposteur[1]. Certains déploiements tiers de modèles officiels dérivent assez loin pour ressembler à des modèles différents. La vérification n'est pas de la paranoïa même quand personne ne ment sur le nom.
Les artefacts de recherche sont ouverts : l'ensemble de données d'empreinte est publié sous CC-BY-4.0 et le code de reproduction sous MIT, tous deux sur Zenodo[3][4].
Exécuter le contrôle vous-même
Le protocole est assez simple pour être implémenté directement. La forme de celui-ci :
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)Quatre notes pratiques sur la façon de faire cela correctement.
Gardez les conditions d'échantillonnage fixes. Température 1.0, un petit max_tokens, raisonnement désactivé. Une empreinte recueillie dans des conditions différentes n'est pas comparable à une recueillie dans le cadre de l'étude.
Utilisez plus d'une probe. Une seule question est bruyante. Le taux d'erreur diminue approximativement de moitié en passant de 8 unités de probe à 40.
Comparez à une référence recueillie de la même manière. La référence la plus propre est le point de terminaison officiel du même modèle, empreinte dans la même session dans des conditions identiques, plutôt qu'un tableau publié recueilli des mois plus tôt.
Regardez aussi les signaux auxiliaires. Une empreinte qui ne concorde pas avec ses propres halves de division suggère un routage multi-backends. Des réponses d'un mot qui facturent des centaines de tokens de complétion suggèrent du rembourrage. Les comptages de tokens de prompt gonflés suggèrent une grande invite système cachée.
Un contrôle standard de 8 unités de probe à 25 échantillons représente environ 200 petites demandes, ce qui coûte une fraction de cent sur un petit modèle.
Ce qu'un résultat signifie et ne signifie pas
Soyez précis sur les affirmations que cette méthode supporte.
Une discordance est une preuve, non une certitude. La méthode a un taux d'erreur inhérent, autour de 10,6 % EER à 8 unités de probe. Une quantification agressive, une mise à jour silencieuse du modèle, une référence obsolète ou une invite système côté serveur peuvent toutes décaler les distributions sans intention de tromper. Traitez un résultat rouge comme une raison de relancer avec plus de probes, de tester une deuxième référence et de poser des questions[1].
Une correspondance est forte mais pas absolue. Un imposteur sophistiqué pourrait en principe mimer les distributions d'un autre modèle, bien que le faire sur des dizaines de probes multiples paraphrasées et multilingues tout en servant correctement le trafic normal soit plus difficile qu'il n'y paraît.
Les modèles de raisonnement ont besoin de prudence. Les empreintes sont recueillies avec le raisonnement désactivé. Quand un point de terminaison ne peut pas le désactiver, la confiance baisse.
Une distance est une propriété d'un point de terminaison à un moment donné, pas un jugement sur une entreprise.
FAQ
Qu'est-ce que le fingerprinting LLM?
Mesurer la distribution des réponses d'un modèle à un ensemble de questions d'un seul mot, puis comparer cette distribution à une référence pour le modèle qu'un point de terminaison prétend servir[1].
Pourquoi les modèles de langage ne peuvent pas produire de nombres aléatoires ?
Ils prédisent plutôt que de calculer, donc une demande de caractère aléatoire retourne les biais des données d'entraînement et du réglage des préférences. Les valeurs culturellement significatives comme 42 et 7 dominent, effondrant la distribution à environ 1,0 bit d'entropie par rapport à l'idéal uniforme de 6,64[1].
Quelle différence compte comme une discordance?
Utilisez les bases de référence de l'étude plutôt qu'un seuil fixe : environ 0,14 pour un modèle comparé à lui-même, 0,23 pour le même modèle chez les fournisseurs, et 0,46 pour les modèles véritablement différents[1].
Combien de demandes un contrôle a-t-il besoin ?
Le protocole complet de l'étude est 40 unités de probe échantillonnées 30 fois chacune. Un contrôle plus léger de 8 unités à 25 échantillons est environ 200 demandes et élève le taux d'erreur égale de 7,3 % à 10,6 %[1].
Un fournisseur peut-il détecter et contourner le test?
Pas facilement. Les probes sont des questions ordinaires inoffensives tirées de pools de paraphrase, donc les traiter en cas spécial sans casser le trafic normal est difficile[1].
L'échec d'un contrôle signifie-t-il qu'un fournisseur triche ?
Non. La quantification, les mises à jour silencieuses de version, les invites système cachées et les références obsolètes produisent toutes une dérive sans tromperie. Une distance est une observation statistique justifiant un examen plus attentif.
L'ensemble de données est-il disponible ?
Oui. L'ensemble de données d'empreinte est sur Zenodo sous CC-BY-4.0 et le code de reproduction sous MIT[3][4].
Traiter le champ model comme une affirmation
Le changement utile ici est petit et spécifique. Le champ model dans une réponse API est une affirmation, et il existe maintenant un moyen peu coûteux, ouvert et statistiquement fondé de vérifier cette affirmation de l'extérieur, construit sur rien de plus exotique que le fait que les modèles de langage ne peuvent pas dire un nombre aléatoire pour sauver leur vie.
Si vous achetez de la capacité via un intermédiaire, le bon endroit pour cela est à côté de la surveillance de la disponibilité : une vérification régulière contre une référence que vous avez recueillie vous-même, avec les signaux auxiliaires observés aux côtés de la distance principale. Et la bonne façon de lire un résultat rouge est comme le début d'une conversation, non pas la fin d'une. Vérifier une API LLM c'est recueillir des preuves sur un point de terminaison à un moment donné, ce qui vaut la peine de faire précisément parce que l'alternative est l'hypothèse.
Références
- 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
- CISPA researchers. Real Money, Fake Models — an audit of shadow LLM API operators. arXiv. arxiv.org/abs/2603.01919
- LLM fingerprint dataset (models × tasks × languages). Zenodo, CC-BY-4.0. zenodo.org
- Reproduction code for One Token Is Enough. Zenodo, MIT License. zenodo.org
Lectures complémentaires
- 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
Auteur

Catégories
Plus d'articles

Seedance 2.0 ou Happyhorse 1.0 : quel modèle choisir en 2026 ?
Comparatif Seedance 2.0 et Happyhorse 1.0 en 2026 : multi-plans, montage, audio natif, prix et raisons du classement #1.


Arrêt de l'API Sora 2 : guide de migration et coûts réels
L'API Sora 2 ferme le 24 septembre 2026 sans remplacement. Export de bibliothèque, réécriture d'appels et comparaison des coûts de migration par tier tarifaire.


Comment utiliser Claude Fable 5 : refus, secours et coût
Comment utiliser Claude Fable 5 : benchmarks complets, le contrat de refus et de secours, rétention obligatoire et impact d'Opus 5 sur le coût.
