Cómo medir un modelo para que tu número valga algo

Cualquiera puede sacar un número. Un script manda un prompt, mira el reloj y sale “41,7 tok/s”. Ese número no vale nada, y te lo digo por experiencia: en nuestro propio registro tuvimos una fila con una temperatura de 2,22 °C en una carga de siete minutos que era falsa, y otra con un prefill de 1476 tok/s etiquetado como generación. Ninguna de las dos era mentira: eran errores de registro.

La diferencia entre un dato y una anécdota no es la precisión del cronómetro. Es si otra persona, mañana, puede reproducir lo que tú viste. Este es el protocolo.

La regla que decide si publicas

Una medida es publicable cuando tiene modelo, versión, runtime, carga y condiciones. Si falta una, la medida sigue siendo útil para ti, pero no para nadie más.

Eso tiene una consecuencia incómoda y necesaria: de todas nuestras medidas, solo unas cuantas se convierten en fichas de benchmark. El resto sigue siendo útil para nosotros, pero una cifra que no cumple la regla no se maquilla para que parezca publicable.

Paso 1: Abre un experimento antes de medir

No al revés. Un experimento abierto tiene un ID, un objetivo y una hipótesis escrita antes de tocar nada.

• Objetivo: qué quieres saber. “¿Cuánto sube el decode con KV en FP8?” es un objetivo. “Probar cosillas” no lo es.
• Hipótesis: qué esperas observar. Se escribe antes, no después de ver el número.
• Baseline: contra qué comparas. Sin baseline, una mejora no es demostrable.

Si el experimento sale mal, se queda registrado igual. Un fallo documentado vale más que un éxito inventado, y casi siempre vale más: te dice qué no repetir.

Paso 2: Fija las condiciones y anótalas todas

Estas son las columnas que usamos, y por qué cada una existe:

Campo	Por qué sin él el número no vale
date	Los runtimes cambian; un número de mayo no describe tu build de septiembre
hardware	El mismo modelo varía enormemente entre máquinas
model + quantization	“Qwen” no es una versión. El cuantizado es otro modelo
runtime + runtime_commit	Con el mismo modelo y el mismo cuantizado, dos commits dan cifras distintas
context	Un contexto de 8K y uno de 256K no son la misma prueba
parallel	Una fila con paralelismo 1 y una con 2 no son comparables
speculative	Un drafter puede triplicar el decode. Si no lo anotas, parece magia
prompt_tokens / output_tokens	200 tokens de salida no miden lo mismo que 4000
prefill_tps / decode_tps / ttft_ms	Son tres cosas distintas; mezclarlas es el error más común
ram_available_gib / swap_used_gib	Con swap activo, lo que mides es el disco
temperature_c	Detecta estrangulamiento térmico: si está caliente, el número no es sostenible
result	verified solo si la prueba de salida fue correcta
notes	El contexto que dentro de tres meses no vas a recordar

runtime_commit no es opcional. Si solo guardas “vLLM”, dentro de seis meses no podrás repetir nada.

Paso 3: Mide con una carga definida

Seis peticiones consecutivas como mínimo. Menos de eso es una anécdota con un solo decimal.

Lo que se mide en cada ejecución:

1. Prefill (tok/s de entrada) y decode (tok/s de salida). Son fases distintas; un servidor con caché de prefijo puede mostrarte un prefill altísimo en la segunda pasada que no tiene nada que ver con el primero.
2. TTFT (tiempo hasta el primer token). Es lo que el usuario percibe como “tarda”.
3. Memoria disponible y swap durante la carga, no antes.
4. Temperatura durante la carga.
5. Que la salida sea correcta. Un modelo que escupe !!!!!! puede tener un tok/s magnífico. Marca verified solo si comprobaste el contenido.

En frío y en caliente son dos medidas distintas y se anotan como tales. No las mezcles en la misma fila.

Paso 4: Registra sin borrar

Escribe una fila por ejecución, no una por modelo. Y no sobrescribas filas antiguas: si un resultado viejo estaba mal, se corrige con una nota que diga qué estaba mal y por qué, no borrándolo.

Un detalle que solo se aprende rompiendo cosas: si tu registro es un CSV, una sola fila con el número de comas equivocado desplaza todas las columnas siguientes. En nuestro caso, una fila con 22 campos bajo una cabecera de 21 convirtió una temperatura real de 56 °C en un result de “56” y una temperatura fantasma de 2,22. El parser no se queja: simplemente lee mal y te fías.

Valida la estructura de tu registro con un script, no a ojo: que cada fila tenga tantos campos como la cabecera. Son cinco líneas y te ahorran semanas de números falsos.

Paso 5: Etiqueta lo que no has probado

Cuando compares con cifras de internet —de NVIDIA, de un foro, de la ficha del modelo—, márcalo como referencia externa hasta que lo reproduzcas en tu máquina. Es la diferencia entre “anuncia 1M de contexto” y “a 960K arrancó y reservó 987.330 tokens de KV; a 1M no cabe con margen en esta máquina”. Las dos frases parecen la misma y una de las dos es falsa.

Lo que te llevas

Un protocolo aburrido, doce columnas y un ID por experimento. No mola tanto como publicar un número grande, pero es lo único que hace que dentro de seis meses puedas decir “esto lo medí así, y puedes repetirlo”.

Si quieres ver el resultado de aplicar esto, el registro de medidas tiene todas las tomas verificadas del laboratorio, y la tabla de Benchmarks las compara.