Velocidad de LLM sin cambio de precio: cuando el precio se congela, la ruta se mueve

Siete modelos se volvieron más rápidos en una semana, ninguno se volvió más caro, y esa combinación es más incómoda de lo que parece para quien decide una ruta de LLM en producción. Son siete modelos con lectura de velocidad, dentro de los diez que el panel rastrea para precio. Artificial Analysis, en el panel leído el 2026-09-21, registra una ganancia de velocidad de salida de entre 13,0% y 26,0% en casi todos los modelos que sigue. En el mismo periodo, el precio por millón de tokens no se movió en ninguno de los diez modelos rastreados. Cuando el costo por token deja de discriminar, el empate deja de resolverse por precio, y la variable que queda es el tiempo de respuesta.

La lectura corriente es que una métrica de velocidad de LLM no cambia ningún contrato. Sí lo cambia, y por una razón contable. Una ruta elegida por precio solo es óptima mientras el precio diferencia las opciones. El día en que dos modelos cuestan lo mismo por millón, la cuenta empata y quien decide es la latencia, medida en horario pico, no en el promedio del panel.

El hallazgo en una frase: con el precio por millón de tokens plano, la latencia y la varianza de respuesta pasan a ser la variable de decisión de la ruta, y un gateway que solo compara precio deja de decidir cualquier cosa.

¿Cómo se recolectaron los datos?

Los números vienen de dos lecturas del panel público de Artificial Analysis en tokens por segundo, una el 2026-09-14 y otra el 2026-09-21, en artificialanalysis.ai/leaderboards/models. Son siete modelos con lectura de velocidad, dentro de los diez que el panel rastrea para precio, y los siete aparecen en ambas lecturas. La variación porcentual compara las dos fotos por modelo, y el precio por millón de tokens se verificó en el mismo panel sin cambio en ninguno de los diez.

Dos fotografías semanales no son una serie temporal. Son una foto contra otra. Un salto simultáneo en casi todos los modelos es igualmente compatible con un cambio en la ventana de medición, un ajuste de método en el panel, o una ronda de optimización de inferencia en los proveedores. Nada aquí distingue esas hipótesis, y la pieza no finge que las distingue. Lo que se puede afirmar con el dato en mano es más estrecho y sigue siendo útil: hubo una ganancia de velocidad de salida medida, el precio quedó plano, y la combinación cambia la pregunta que quien enruta tiene que responder.

Cabe un recorte técnico que el panel no resuelve solo. Tokens por segundo es la velocidad de generación, el tiempo entre el primer y el último token de salida. En una llamada de prompt corto, lo que el usuario siente es otra cosa: el prefill, la cola de espera en el proveedor y la latencia de red dominan el total, y la ganancia de generación aparece diluida. Medir tokens por segundo y llamar a eso latencia es la confusión que hace que una decisión de ruta parezca correcta en el gráfico y equivocada en el producto.

¿Cuánta velocidad ganaron los modelos en una semana?

La respuesta corta es que la ganancia va de 13,0% a 26,0% entre los modelos rastreados, y el mayor salto porcentual no es la mayor ganancia absoluta. GPT-5.6 Sol subió 26,0% sobre una base baja de velocidad. Gemini 3.8 Flash, que ya era el más rápido de la lista, sumó 53,4 tokens por segundo en términos absolutos, casi un segundo modelo entero de diferencia en el mismo intervalo de tiempo.

La tabla de abajo trae el par de valores por modelo. Ninguna fila de precio aparece porque ninguna cambió: la columna de variación sería una secuencia de ceros, y esa es exactamente la información que mueve la tesis.

El patrón que salta de la tabla no es el promedio. Es la asimetría. El modelo más rápido de la lista quedó 19,2% más rápido, y el segundo más rápido, 13,0%, lo que significa que una ruta elegida por velocidad bruta el 14 de septiembre sigue siendo la elección por velocidad bruta el 21 de septiembre, sin que nadie tenga que cambiar nada. La ganancia agregada no redistribuyó el ranking de velocidad. Mantuvo el orden y levantó a todos en la misma dirección, que es el comportamiento que motiva la advertencia sobre la ventana de medición.

¿Por qué un precio plano cambia la lógica de decisión de la ruta?

Porque el criterio de desempate desaparece. Una ruta por costo funciona comparando precio de entrada y de salida por millón de tokens. Si dos modelos cuestan lo mismo, ese criterio devuelve un empate, y el sistema que decide por precio necesita un segundo criterio que quizá nunca implementó. El trabajo que guía la promoción de ruta por evidencia de tráfico ya existe y está descrito en cómo decidir la ruta de LLM con evidencia de tráfico real, pero necesita la métrica correcta para medir. Cuando el precio está plano, esa métrica es el tiempo de respuesta.

El caso opuesto, precio en movimiento, tiene su propio post en este blog: qué hacer cuando el precio del token cambia trata exactamente el caso en que el costo vuelve a discriminar. Los dos regímenes se complementan. Cuando el precio se mueve, la cuenta manda. Cuando se congela, la cuenta empata y la latencia asume. Ninguna empresa opera en uno de los dos regímenes para siempre, y la arquitectura que aguanta el cambio es la que ya mide las dos variables todo el tiempo, en vez de descubrir una el día en que empieza a decidir.

Hay una razón para desconfiar del promedio de velocidad como criterio. La distribución de latencia de un proveedor de LLM tiene cola larga, y el valor que el usuario percibe está en la cola, no en el centro. Un modelo con promedio de 68 tokens por segundo puede tener un p99 de cuatro segundos en una tarde de pico, mientras otro con promedio menor nunca pasa de dos segundos. El promedio esconde justamente el evento que arruina la experiencia. Quien decide una ruta por un número de panel decide por una estadística que el usuario nunca ve.

¿Qué se debe medir exactamente, entonces?

Tres cosas, y ninguna de ellas es el promedio de tokens por segundo del panel. Tiempo hasta el primer token, que define la sensación de respuesta inmediata. Tiempo total hasta el último token, que define si la tarea termina. Y la distribución de esas dos métricas por horario, con p90 y p95 explícitos, porque es en la cola donde la decisión equivocada cuesta caro.

1. Tiempo hasta el primer token (TTFT). El intervalo entre el envío de la solicitud y el primer fragmento de salida. Domina la percepción en prompts cortos y es lo que el promedio de tokens por segundo ignora por construcción.
2. Tiempo total hasta el último token. Lo que decide si una tarea larga, como generar un informe o revisar un archivo de código, termina dentro del presupuesto de tiempo de la operación.
3. p90 y p95 por ventana horaria. La métrica que separa a un proveedor estable de uno que funciona bien a las diez de la mañana y mal a las tres de la tarde, cuando se llena la cola.

El detalle que casi nadie instrumenta es la varianza entre proveedores del mismo modelo. El mismo modelo servido por dos proveedores distintos tiene dos curvas de latencia distintas, porque la configuración de hardware, la política de batching y la carga de la región no son las mismas. Elegir el modelo no es elegir la ruta, del mismo modo que elegir el destino no es elegir el camino. El panel de Artificial Analysis mide un proveedor de referencia, y tratar ese número como si valiera para todos los proveedores es un error que solo aparece en producción.

Vale declarar dónde este texto discrepa de la lectura más común. La lectura corriente trata la latencia como una métrica de experiencia del usuario. Eso subestima el problema. La latencia, cuando el precio es plano, es una métrica de riesgo operativo: una cola larga en un proveedor puede reventar el timeout de un paso de agente, quemar un intento entero y reprocesar la llamada, y el costo de ese reprocesamiento aparece en la factura por un camino que nadie mapeó. El ahorro que el precio plano prometía se devuelve en retrabajo.

¿El gateway que solo compara precio decide algo cuando el precio es igual?

No decide nada. Y ese es el punto en que la capa de gateway deja de ser un detalle de infraestructura y se vuelve la pieza que sostiene la decisión. Nexforce Router es un gateway de LLM que enruta entre más de trescientos modelos por una única API, y su enrutamiento inteligente considera costo, desempeño, latencia y contexto de la solicitud. Cuando el costo empata, es esa combinación la que sigue produciendo una decisión en vez de un empate técnico.

Lo que importa no es la lista de funciones, es el orden en que operan bajo un precio plano. Medir latencia por proveedor y por modelo, aplicar el enrutamiento por desempeño medido, y hacer failover automático cuando un proveedor se pone lento a mitad de la ventana, con fallback configurable a un modelo equivalente. El failover deja de ser una red de seguridad contra una caída y pasa a ser una respuesta a la degradación del tiempo de respuesta, que es un modo de falla más silencioso y más frecuente que la indisponibilidad total. El gateway también mantiene caché de respuestas y embeddings, que ataca la latencia por otro camino: la respuesta más rápida es la que no necesita generarse de nuevo.

Hay un segundo trabajo que el gateway hace cuando la ruta pasa a decidirse por tiempo de respuesta. Tiene que probar después por qué decidió lo que decidió. Una traza auditable de cada llamada, con el proveedor, el modelo y la latencia registrados, es lo que permite responder en una reunión de operación si la ruta se degradó el martes por la tarde o si siempre fue así. Sin ese registro, la decisión de ruta se vuelve folclore. Con él, se vuelve insumo para la próxima promoción de ruta.

Un punto que merece insistencia: agregar latencia como criterio no jubila el control de costo. El techo de gasto sigue vigente y sigue siendo lo que impide que una ruta más rápida y más cara consuma el presupuesto. El presupuesto por unidad, tratado en identidad del llamador en el gateway y presupuesto por unidad, es lo que mantiene la decisión de latencia dentro de un límite económico. Enrutamiento por latencia sin techo de gasto es una forma elegante de cambiar un ahorro de 50% por una factura más alta.

¿Dónde entra el costo por tarea cuando el precio empata?

Entra como la unidad que reconcilia las dos métricas. El precio por millón de tokens es una unidad de insumo. El costo por tarea concluida es una unidad de resultado, y es la que captura el efecto del retrabajo. Un modelo barato y lento que revienta el timeout y obliga a un segundo intento puede costar más por tarea que un modelo caro y rápido que cierra en la primera llamada. El análisis de el costo por tarea decide la ruta profundiza esa unidad, y es el juez final cuando el precio por token empata.

La consecuencia práctica es una inversión de prioridad. La prioridad se invierte. En un panel por precio, el modelo caro es el sospechoso por defecto. En un panel por costo por tarea, con precio plano y latencia en juego, el modelo que parece caro puede ser el más barato de la lista, porque termina la tarea y no devuelve el problema a la cola. Medir por tarea es medir lo que la empresa realmente paga.

¿Cómo decidir la ruta cuando el precio no decide?

Una secuencia concreta, en el orden en que se resuelve la decisión:

1. Confirmar el empate de precio en el panel, por modelo y por proveedor, antes de tratar la latencia como desempate. Si el precio todavía discrimina, la cuenta manda y la latencia es secundaria.
2. Instrumentar TTFT, tiempo total y p95 por horario, por proveedor y por modelo, en el propio tráfico de producción. El número de un panel de terceros es un punto de partida, nunca el criterio final.
3. Definir el límite de tiempo que la tarea tolera antes de fallar. Es ese límite, no el promedio, el que convierte la latencia en regla de ruta.
4. Promover la ruta por evidencia acumulada, con failover configurado al modelo equivalente más rápido disponible en el momento de la degradación.
5. Mantener el techo de gasto activo por clave o por proyecto, para que la ruta por latencia no se vuelva una factura sin freno.

El error más común en esa secuencia es saltarse el paso dos y decidir con el número del panel. El panel no es la empresa. El panel mide un proveedor de referencia en una ventana fija. El tráfico de la empresa mide el proveedor que realmente usa, a la hora en que realmente lo usa, con la carga que ella misma pone sobre ese proveedor a lo largo del día. La diferencia entre los dos es donde vive la decisión.

¿Qué cambia para quien opera LLM en producción?

Cambia la pregunta, no la herramienta. La pregunta deja de ser cuál modelo es el más barato por millón y pasa a ser cuál modelo cierra la tarea dentro del tiempo que la operación tolera, al menor costo por tarea concluida. Esa pregunta no tiene respuesta de panel. Tiene respuesta de medición continua en la propia ruta, y solo existe si la capa que decide está midiendo el tiempo de respuesta todo el tiempo, y no solo cuando alguien abre el gráfico de velocidad.

El dato de la semana refuerza la tesis y la limita al mismo tiempo. Las ganancias de 13,0% a 26,0% son reales como lectura, y la advertencia sobre la ventana de medición sigue en pie. Un equipo que decide una ruta tratando esos números como sentencia trata una foto de siete días como si fuera un régimen permanente. Un equipo que mide su propio tráfico, en cambio, usa la foto solo como señal y el dato propio como criterio de decisión. El segundo equipo no depende de eso. No necesita saber si el salto vino del proveedor o de un ajuste en la ventana de medición, porque su decisión se sostiene en su propio tráfico de todos modos.

Es por eso que la pieza aterriza en el gateway. El enrutamiento por latencia no es una función que se enciende. Es una postura de medir, decidir y revertir sobre un dato que cambia cada semana. El precio plano no es el fin de la optimización de costo. Es el comienzo de la optimización de tiempo, y solo funciona si la capa de decisión está mirando el reloj, no solo la factura.

Preguntas frecuentes

¿Qué significa precio por millón de tokens plano? Significa que los modelos rastreados mantuvieron el mismo precio de entrada y de salida por millón de tokens entre las dos lecturas, el 2026-09-14 y el 2026-09-21. Sin diferencia de precio, el criterio de costo empata entre opciones de velocidad distinta, y el desempate pasa a venir del tiempo de respuesta.

¿La velocidad de salida en tokens por segundo es lo mismo que la latencia? No es lo mismo. Los tokens por segundo miden la velocidad de generación entre el primer y el último token. La latencia percibida incluye el tiempo hasta el primer token, la cola en el proveedor y la red. En prompts cortos, la latencia percibida está dominada por esos otros factores, y la ganancia de generación aparece diluida.

¿Por qué un cambio en la ventana de medición importa para este análisis? Porque dos lecturas semanales no distinguen una ganancia real de velocidad de un ajuste en el método del panel. Un salto simultáneo en casi todos los modelos es compatible con las dos hipótesis, y ninguna empresa debería cambiar la arquitectura de ruta con base en dos fotos. La advertencia es parte del hallazgo, no una nota al pie.

¿El enrutamiento por latencia sustituye el control de costo? No. El techo de gasto por clave, por agente o por proyecto sigue activo y es lo que impide que una ruta rápida y cara consuma el presupuesto. Latencia y costo por tarea operan juntos: la latencia decide entre opciones de mismo precio, y el techo de gasto impone el límite económico de la decisión.

¿Cuántos proveedores puede tener el mismo modelo, y eso afecta la medición? El mismo modelo puede ser servido por varios proveedores, y cada uno tiene su propia curva de latencia por hardware, batching y región. El panel de terceros mide un proveedor de referencia. La medición que decide debe venir del proveedor que la empresa de hecho usa, en el horario en que lo usa.

Referencias y Lectura Complementaria

• Artificial Analysis, leaderboards de modelos, lectura del 2026-09-21, fuente primaria de los datos de tokens por segundo.
• Nexforce Router, gateway de LLM con enrutamiento inteligente, failover automático y observabilidad de llamadas.
• Cómo decidir la ruta de LLM con evidencia de tráfico real, el método de promoción de ruta por dato propio.
• Qué hacer cuando el precio del token cambia, el caso opuesto, con precio en movimiento.
• El costo por tarea decide la ruta, la unidad de decisión cuando el precio por token empata.

Próximo paso: medir el reloj, no solo la factura

El dato del 2026-09-21 dice que el precio se detuvo y la velocidad subió. Lo que no dice, y ningún panel de terceros dice, es el tiempo de respuesta del proveedor que usa tu operación a las tres de la tarde de un martes. Ese número vive en tu tráfico, y la capa que decide la ruta es donde hay que capturarlo y convertirlo en regla. Mientras el precio por millón esté plano, quien mide el tiempo de respuesta decide; quien solo compara precio empata. El reloj decide. Para ver cómo Nexforce Router trata latencia, falla y costo en la misma decisión, la página del producto es el punto de partida.