Tokens por segundo: qué cambia al comparar LLM

La tasa del panel de Artificial Analysis cambió de base el 03/11/2026: la versión 3.0.0 incluyó el tiempo hasta el primer token, pasó la ventana de 72 horas a cinco días y alteró conteo de tokens y reglas de fallo. Nexforce no hizo benchmark propio.

Datos clave Evento: metodología 3.0.0 de Artificial Analysis, del 03/11/2026. Qué cambia: el tiempo hasta el primer token entra en la tasa, la ventana pasa a cinco días y el fallo de endpoint cuenta como cero. Fuente: metodología 3.0.0, consultada el 12/11/2026; sin medición de Nexforce.

¿Qué cambió en la medición de tokens por segundo?

En Artificial Analysis, la velocidad de salida va del envío al último bloque con token, incluida la espera inicial, y la ventana pasó de 72 horas a cinco días el 03/11/2026. Dos lecturas separadas por la revisión no forman serie comparable.

La unidad sigue siendo tokens por segundo, pero la métrica no es la misma. No hay conversión fiable entre agregados publicados con solo los números del panel; por llamada, el recálculo depende de hitos y conteos. Frontera del reloj, ventana y población cambiaron a la vez; comparar proveedores exige la misma definición en ambos lados. Tratar paneles distintos como si midieran lo mismo da una conclusión que los datos no sostienen; lo honesto es declarar la definición de cada número. Dos capturas no se suman: mediana de una carga y promedio de medianas de cinco días describen poblaciones distintas. El histórico no atribuye la variación de un modelo a los cambios de método; Nexforce tampoco. El tamaño del efecto no se midió.

¿Qué ocurrió?

La versión 3.0.0, del 03/11/2026, redefinió velocidad de salida, ventana, cargas y tratamiento de fallos del panel de Artificial Analysis. El histórico describe cada cambio sin atribuirle la variación de un modelo.

Artificial Analysis mide del envío al último bloque con token, intervalo que incluye la espera del primer token y el razonamiento contabilizado por el proveedor. Con t0 en el envío, t1 en el primer token y tf en el último bloque, la tasa es tokens de respuesta y razonamiento sobre tf - t0. En la variante que empieza en t1, el primer token queda fuera del intervalo y del numerador. La fórmula histórica completa, su numerador y excepciones no se verificaron aquí. El numerador no es solo texto visible: entra el razonamiento reportado; sin reporte de la API, el conteo sale del texto. En sesiones con varias llamadas el tiempo de herramientas queda fuera: no mide la duración de una tarea. Un error del endpoint cuenta como velocidad cero, y una sesión incompleta considera solo las respuestas obtenidas.

Figura: la barra de arriba va del envío (t0) al último bloque (tf); la barra de abajo va del primer token (t1) al último bloque (tf), con el tramo t0-t1 marcado. Intervalos de tiempo, sin escala. Fuente: metodología 3.0.0, 03/11/2026.

¿Por qué importa esto a quien contrata inferencia?

El cambio impide tratar lecturas de regímenes distintos como serie homogénea. Quien compara proveedores debe declarar frontera, ventana y población de cada número, porque una tasa con la espera inicial no es intercambiable con otra que empieza en el primer token.

El histórico registra el cambio: antes, el número principal era la mediana de la carga de 10 mil tokens de entrada de las últimas 72 horas; ahora, el promedio de las medianas por carga en cinco días. No es ganancia de velocidad, sino definición. Cinco días son 120 horas, 48 más que la ventana anterior: 66,7% de periodo adicional. El agregado también cambió: cargas distintas entran en el número principal, y una carga sin medición en ese endpoint queda fuera del promedio. La división no da tasa comparable: dividir dos agregados de fechas distintas no reconstruye una llamada. Un p95 solo sobre éxitos esconde a quienes quedaron fuera, como detalla el artículo sobre latencia de gateway y contexto.

¿Qué cambia en la práctica?

Para quien lee el panel cambia la regla, no el proveedor. La tabla separa el régimen anterior del actual en cinco puntos que alteran las comparaciones entre fechas; la última columna registra el efecto.

Cuatro filas describen cambios documentados por la metodología 3.0.0 y una describe una laguna de la fuente actual. No hay conversión retroactiva. Quien arma un comparativo rehace la medición en su carga o acepta que el número del panel vale para la definición publicada ese día, y desplaza la pregunta de la renovación: no es qué endpoint tiene el número más alto, sino qué definición de velocidad necesita la operación. La columna de efecto describe la consecuencia de cada cambio, no una medición de desempeño. Un comparativo serio fija frontera, ventana y población antes del resultado; la guía de métricas de enrutadores detalla criterios para esa elección. Quien registra fecha, versión y configuración compara lo medido; la conversión queda con quien mide.

¿Qué hacer ahora?

Cinco decisiones reducen el riesgo de contratar inferencia por un número de panel que no mide lo que la operación necesita. Valen para la renovación, el cambio de ruta y el primer test de un proveedor nuevo, sin depender de ninguno.

La prueba que sostiene una decisión de ruta repite las mismas tareas en los endpoints candidatos, en orden alternado, registrando concurrencia, región, versión y fecha. Tiempo hasta el primer token, duración total y percentiles de éxito entran separados, con población declarada y conteo de fallos en la misma ventana, porque un p95 solo sobre éxitos esconde los timeouts. La evaluación por tarea cubre la elección por calidad, y la medición de desempeño orienta la comparación de cargas. Ninguna sustituye la prueba en tu carga: el resultado útil es una tabla con frontera, ventana y numerador declarados. Repetir la carga en horarios distintos expone variación de desempeño, y la porción de cola solo aparece con instrumentación que mida la espera; sin ese registro, la comparación es opinión.

1. Fija la frontera en el contrato. Declara frontera, numerador y ventana.
2. Pide p50 y p95 por métrica. Exige TTFT, duración total y tasa de error con población declarada.
3. Mide en tu propia carga. Repite las tareas, con orden alternado y región.
4. Conserva los fallos. Error sobre intentos, y percentiles solo de éxito aparte.
5. Registra el tokenizador. El razonamiento no reportado entra como limitación, nunca como equivalencia.

Preguntas frecuentes sobre tokens por segundo

Tokens por segundo mide la tasa de salida de una solicitud, y el número cambia según la frontera del reloj, la ventana y lo que cuenta el numerador. En Artificial Analysis, la espera inicial entró en ese divisor con la versión 3.0.0, del 03/11/2026.

Artificial Analysis muestra lecturas recientes bajo la metodología 3.0.0, del 03/11/2026; las capturas del 19/10 y del 09/11 de 2026 no se reprodujeron. Como fórmula, ventana y población cambiaron en el mismo intervalo, la diferencia entre una lectura antigua y la actual no separa método de desempeño. Publica promedio por endpoint y carga en cinco días, y no comprueba el desempeño en la operación del comprador. Las muestras detrás del promedio no aparecieron en la consulta: el agregado no se rehace. Medir un endpoint exige repetir la carga y registrar definición, ventana y fecha. El agregado describe su definición, no la latencia de tu carga; una comparación operacional completa pide población de intentos, tasa de fallos y percentiles sobre éxitos.

¿Los tokens por segundo incluyen el tiempo hasta el primer token?

En la metodología actual de Artificial Analysis, sí. La duración va del envío de la solicitud al último bloque con token, así que la espera inicial entra en el divisor. Una tasa calculada desde el primer token declara otra frontera de medición.

¿TTFT es lo mismo que tiempo hasta el primer token de respuesta?

No necesariamente. En un modelo que razona, el primer token que llega puede ser de razonamiento y anteceder al de respuesta visible. Cuando el protocolo no distingue los dos, registra la limitación y no trates los tiempos de ambos proveedores como equivalentes.

¿El p95 sustituye a la tasa de fallos?

No. El p95 describe una distribución de tiempos para la población definida; la tasa de fallos usa el total de intentos como denominador. Si solo los éxitos entran en el percentil, errores y timeouts desaparecen del resultado, y una ruta que falla parece estable.

¿Una velocidad menor en el panel prueba que el endpoint se volvió más lento?

No por sí solo. La comparación exige capturas verificadas, configuraciones equivalentes y conocimiento de los cambios de fórmula, carga y agregación. Sin esa base, la diferencia no separa método de desempeño real, y el camino es repetir la carga en la operación.

Referencias y Lectura Complementaria

La referencia principal es la metodología de desempeño de Artificial Analysis, versión 3.0.0, publicada el 03/11/2026 y consultada el 12/11/2026. Cada definición citada sale de ella; las fuentes siguientes permiten conferir frontera, cargas y reglas de agregación.

La metodología de desempeño describe la frontera de la solicitud, las cargas y las reglas de agregación y fallo que sustentan los hallazgos. La página del K2 Horizon 375B A23B y el panel de proveedores son fuentes dinámicas, no capturas. La cuenta es de ventana: sumar lecturas de ventanas distintas no reconstruye una llamada. La conversión es aritmética: 120 horas menos 72, dividido por 72. Reproducir el valor de un endpoint dependería de datos individuales, cargas, configuración y ejecuciones del agregado, además de las reglas de fallo y la ventana. Una lectura dinámica no confirma una captura antigua: conserva la fecha de consulta e identifica cambios de alcance. El rastreo de llamadas de LLM complementa la lectura sobre registros individuales.

Qué observar en los próximos días

La próxima versión de la metodología de Artificial Analysis es el evento a seguir, no la diferencia entre dos números de panel. Hasta entonces, cada lectura publicada es un retrato fechado de una definición específica, con fuente, límites explícitos y fecha.

Vale observar tres señales: nueva versión del histórico, cambio en las cargas y cómo presenta fallos el panel. El Nexforce Router ofrece prueba de un prompt en varios modelos, rastreo de llamadas, logs y métricas, y sirve de instrumentación para una política de ruta basada en medición comparable, sujeta a lo validado en el entorno. Ningún número de panel se convierte en SLA por una página pública. La observabilidad de LLMs ayuda a planificar la recolección que sustenta esa decisión. Cada versión fechada define la regla; mientras no cambie, la práctica es comparar solo lecturas bajo la misma definición, con el número junto a la frontera que usa, porque la página pública no recrea la captura antigua.

La decisión del comprador es medir cargas equivalentes, calidad y fallos antes de renovar una ruta, con el Router como instrumento.