Cómo verificar que una API de LLM sirve el modelo correcto

Pídele a un modelo de lenguaje que escoja un número aleatorio entre 1 y 100 suficientes veces y algo extraño sucede: las respuestas no son aleatorias. Un modelo siempre cae en 42 y 73. Otro favorece 47 y 57. El patrón es estable, reproducible, y diferente para cada modelo.

Un artículo de julio de 2026 convirtió ese defecto en un método de verificación. One Token Is Enough: Fingerprinting and Verifying Large Language Models from Single-Token Output Distributions demuestra que estas distribuciones de respuestas forman una huella digital comportamental fiable, suficiente para comprobar desde fuera si el endpoint de una API sirve el modelo que asegura^[1]. Sin pesos, sin logits, sin acceso privilegiado. Solo algunos cientos de respuestas de una palabra.

Esta guía explica por qué el campo model es una afirmación más que una garantía, cómo funciona el fingerprinting de un solo token, qué significan los números, y dónde está el límite del método.

TL;DR

• El campo model en una respuesta de API es inverificable por protocolo. Nada demuestra que tu solicitud de un modelo estrella fue servida por él^[1].
• Los modelos de lenguaje no pueden producir aleatoriedad uniforme. Entre el conjunto de pruebas del artículo, la distribución mediana de respuestas tiene alrededor de 1.0 bit de entropía contra los 6.64 bits que tendría una selección uniforme de 1 a 100^[1].
• Ese defecto es consistente, así que funciona como firma. Mismo modelo, mismo sesgo, cada vez.
• La escala tiene margen de diferenciación: el mismo modelo contra sí mismo cae cerca de JSD 0.14, el mismo modelo en dos proveedores cerca de 0.23, dos modelos genuinamente distintos cerca de 0.46^[1].
• La precisión es fuerte, no perfecta. La tasa de error equitativa es 10.6% con 8 unidades de prueba y 7.3% con el conjunto completo de 40, con AUC de 0.971^[1].
• Una falta de coincidencia es evidencia, no prueba. La cuantificación, una actualización silenciosa de versión, o un prompt del sistema oculto pueden todos sesgar una distribución sin que nadie mienta.

No puedes ver qué hay detrás de una API

Cuando llamas a un endpoint de chat-completions envías texto y recibes texto. El campo model en la respuesta dice lo que el servidor decide poner ahí. Nada en el protocolo prueba que la solicitud fue servida por el modelo nombrado, en lugar de por algo que cuesta una décima parte^[1].

Esa brecha importa más conforme más del mercado se sienta detrás de intermediarios: agregadores revendiendo cientos de modelos a través de un endpoint, revendedores regionales ofreciendo acceso a modelos estrella por debajo del precio oficial, y proveedores terceros sirviendo modelos de pesos abiertos con opciones de cuantificación y pila de servidor que nunca ves^[1].

La mayoría de estos negocios son legítimos. El incentivo para engañar es obvio, y una auditoría separada de 17 operadores de shadow-API encontró varios endpoints que no pasaban verificación contra los modelos que se anunciaban^[2].

También no es solo sobre fraude. Un proveedor puede cuantificar un modelo para cortar costos de servicio, desplegar una actualización de versión silenciosa, o enrutar tráfico entre backends mixtos. Si la calidad de tu producto depende de un modelo específico, "¿qué estoy obteniendo realmente?" debería ser respondible con evidencia en lugar de confianza.

Por qué los números aleatorios traicionan el juego

El método descansa en una debilidad bien documentada. Los modelos de lenguaje no calculan, predicen, así que cuando se les pide un número aleatorio reproducen los sesgos de sus datos de entrenamiento y ajuste de preferencias^[1].

Tres clusters dominan:

• 42 está masivamente sobrerepresentado, la respuesta de Guía del Autoestopista resonando a través de décadas de texto de internet.
• 7 carga siglos de peso cultural como la selección afortunada por la que los humanos van.
• 37, 47, 73 y otros números primos de dos dígitos se sienten aleatorios para los humanos, así que dominan los ejemplos "aleatorios" generados por humanos que el modelo aprendió.

El artículo cuantifica el colapso: la distribución mediana de respuestas lleva aproximadamente 1.0 bit de entropía, donde una selección justa de 1 a 100 llevaría 6.64 bits^[1]. Donde un dado justo tiene cien caras, la mayoría de modelos se comportan como una moneda ligeramente sesgada.

El movimiento clave es que el defecto es consistente. El mismo modelo produce la misma distribución sesgada cada vez, y diferentes modelos, incluyendo versiones hermanas en una familia, producen unos mediblemente diferentes. Un bug se convierte en una firma.

El protocolo, en cuatro pasos

1. Prueba. Pregunta al endpoint una batería de preguntas de una palabra: escoge un número aleatorio entre 1 y 100, nombra un color aleatorio, lanza una moneda. El artículo usa 10 tareas en 4 idiomas para 40 unidades de prueba, muestreando cada una 30 veces a temperatura 1.0 con max_tokens=16 y razonamiento deshabilitado^[1].

2. Huella digital. Para cada unidad de prueba, tabula las respuestas en una distribución empírica. La colección de esas distribuciones es la huella digital comportamental del endpoint.

3. Compara. Mide la distancia entre esa huella digital y una referencia de confianza para el modelo reclamado, usando divergencia de Jensen-Shannon en base 2, así la escala va de 0 (idéntica) a 1 (disjunta).

4. Decide. Pequeña distancia significa consistente con la afirmación. Grande significa que el endpoint es comportamentalmente un animal diferente.

Dos propiedades hacen esto difícil de eludir. No necesita acceso especial, ya que cualquier cosa respondiendo chat completions puede ser huelladigitalizada. Y no hay cadena mágica para filtrar, porque cada prueba es una pregunta ordinaria e inofensiva extraída de piscinas de paráfrasis, así un middlebox deshonesto no puede hacer casos especiales de la prueba sin romper tráfico normal^[1].

Lectura del número de distancia

Un valor de divergencia no significa nada sin los puntos de referencia, y aquí es donde el método se vuelve práctico.

Hay luz real entre "igual" y "diferente"^[1]. Nota lo que la fila del medio implica: incluso un despliegue honesto del mismo modelo por un host diferente se desplaza mediblemente, porque cuantificación, pila de servidor, y prompts del sistema ocultos dejan marcas.

La precisión escala con el número de pruebas. Con 8 unidades de prueba la tasa de error equitativa es 10.6%; con 40 completas cae a 7.3%, con AUC de 0.971^[1].

Lo que el artículo encontró en el mundo real

El caso palmyra-x5. El resultado más sorprendente del artículo concierne un modelo ofrecido como un flagship propietario cuya huella digital se sentó a JSD 0.141 de un modelo de pesos abiertos de 235B, estadísticamente indistinguible de ~0.140 que obtienes comparando un modelo contra sí mismo. Comportamentalmente, concluye el artículo, el endpoint estaba sirviendo algo funcionalmente idéntico al modelo de código abierto^[1].

Mismo modelo, diferentes proveedores, a veces sospechosamente diferentes. De 34 pares del mismo modelo servidos entre proveedores diferentes, 10 se desviaron más allá del percentil 5 de la distribución del impostor^[1]. Algunos despliegues oficiales de modelos terceros se desplazan lo suficientemente lejos para parecer modelos diferentes. La verificación no es paranoia incluso cuando nadie miente sobre el nombre.

Los artefactos de investigación son abiertos: el conjunto de datos de huella digital está publicado bajo CC-BY-4.0 y el código de reproducción bajo MIT, ambos en Zenodo^[3][4].

Ejecuta la verificación tú mismo

El protocolo es simple suficiente para implementar directamente. La forma de él:

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)

Cuatro notas prácticas sobre hacerlo correctamente.

Mantén fijas las condiciones de muestreo. Temperatura 1.0, un pequeño max_tokens, razonamiento deshabilitado. Una huella digital recolectada bajo diferentes ajustes no es comparable a una recolectada bajo la del artículo.

Usa más de una prueba. Una sola pregunta es ruidosa. La tasa de error se reduce aproximadamente a la mitad yendo de 8 unidades de prueba a 40.

Compara contra una referencia recolectada de la misma manera. La referencia más limpia es el endpoint oficial para el mismo modelo, huelladigitalizado en la misma sesión bajo ajustes idénticos, en lugar de una tabla publicada reunida meses antes.

Observa también las señales auxiliares. Una huella digital que está en desacuerdo con sus propias mitades divididas sugiere enrutamiento multi-backend. Respuestas de una palabra que facturen cientos de tokens de conclusión sugieren relleno. Conteos de token de prompt inflados sugieren un prompt del sistema oculto grande.

Una verificación estándar de 8 unidades de prueba a 25 muestras es alrededor de 200 solicitudes diminutas, que cuesta una fracción de centavo en un modelo pequeño.

Lo que un resultado hace y no hace

Sé preciso sobre los reclamos que este método soporta.

Una falta de coincidencia es evidencia, no prueba. El método tiene una tasa de error inherente, alrededor de 10.6% EER con 8 unidades de prueba. Cuantificación agresiva, una actualización de modelo silenciosa, una referencia anticuada, o un prompt del sistema del lado del servidor pueden todos cambiar distribuciones sin intención de engañar. Trata un resultado rojo como una razón para reejecutar con más pruebas, probar una segunda referencia, y hacer preguntas^[1].

Una coincidencia es fuerte pero no absoluta. Un impostor sofisticado podría en principio imitar las distribuciones de otro modelo, aunque hacerlo en docenas de pruebas parafraseadas multilingües mientras sirve tráfico normal correctamente es más difícil de lo que suena.

Los modelos de razonamiento necesitan cuidado. Las huellas digitales se recolectan con razonamiento deshabilitado. Donde un endpoint no puede deshabilitarlo, la confianza cae.

Una distancia es una propiedad de un endpoint en un momento en el tiempo, no un veredicto sobre un negocio.

FAQ

¿Qué es fingerprinting de LLM?

Medir la distribución de respuestas de un modelo a una batería de preguntas de una palabra, luego comparar esa distribución contra una referencia para el modelo que un endpoint dice servir^[1].

¿Por qué los modelos de lenguaje no pueden producir números aleatorios?

Predicen en lugar de calcular, así una solicitud de aleatoriedad retorna los sesgos de datos de entrenamiento y ajuste de preferencias. Valores culturalmente cargados como 42 y 7 dominan, colapsando la distribución a alrededor de 1.0 bit de entropía contra un ideal uniforme de 6.64^[1].

¿Cuánta diferencia cuenta como falta de coincidencia?

Usa los baselines del artículo en lugar de un umbral fijo: alrededor de 0.14 para un modelo contra sí mismo, 0.23 para el mismo modelo entre proveedores, y 0.46 para modelos genuinamente diferentes^[1].

¿Cuántas solicitudes necesita una verificación?

El protocolo completo del artículo es 40 unidades de prueba muestreadas 30 veces cada una. Una verificación más ligera de 8 unidades a 25 muestras es aproximadamente 200 solicitudes y eleva la tasa de error equitativa de 7.3% a 10.6%^[1].

¿Puede un proveedor detectar y eludir la prueba?

No fácilmente. Las pruebas son preguntas ordinarias inofensivas extraídas de piscinas de paráfrasis, así hacer casos especiales de ellas sin romper tráfico normal es difícil^[1].

¿Significa una verificación fallida que un proveedor está engañando?

No. Cuantificación, actualizaciones de versión silenciosas, prompts del sistema ocultos, y referencias anticuadas todos producen desplazamiento sin engaño. Una distancia es una observación estadística garantizando inspección más cercana.

¿Está disponible el conjunto de datos?

Sí. El conjunto de datos de huella digital está en Zenodo bajo CC-BY-4.0 y el código de reproducción bajo MIT^[3][4].

Tratando el campo del modelo como una afirmación

El cambio útil aquí es pequeño y específico. El campo model en una respuesta de API es una afirmación, y ahora hay una forma barata, abierta, estadísticamente fundamentada de verificar esa afirmación desde fuera, construida en nada más exótico que el hecho de que los modelos de lenguaje no pueden decir un número aleatorio para salvar sus vidas.

Si compras capacidad a través de cualquier intermediario, el lugar correcto para esto es al lado del monitoreo de tiempo de actividad: una verificación periódica contra una referencia que recolectaste tú mismo, con las señales auxiliares observadas junto a la distancia de titular. Y la forma correcta de leer un resultado rojo es como el inicio de una conversación, no el fin de una. Verificar una API de LLM es reunir evidencia sobre un endpoint en un momento en el tiempo, que vale la pena hacer precisamente porque la alternativa es asumir.

Referencias

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

Further reading

• 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