LLM de difusión: Mercury 2.5 y el enrutamiento de modelos

El 2026-09-08 Inception Labs lanzó Mercury 2.5, el mayor LLM de difusión entrenado hasta la fecha, con 40% más de inteligencia que Mercury 2, 1.107 tokens por segundo en GPUs NVIDIA y un precio de US$0,20 por millón de tokens de entrada y US$0,75 por millón de salida, según el anuncio oficial: Introducing Mercury 2.5. La fecha sigue el pie del anuncio; la página se consultó el 2026-09-15. La implicación que importa: una arquitectura de difusión que gana en tokens por segundo por dólar cambia qué modelo debe recibir cada tipo de tráfico.

Qué anunció Inception Labs con Mercury 2.5

Mercury 2.5 es un modelo de difusión, no un transformer autorregresivo, y es la mayor variante entrenada en esa clase. En lugar de emitir un token por vez, de izquierda a derecha, un LLM de difusión genera un bloque entero de tokens enmascarados en paralelo y refina todas las posiciones a lo largo de un número fijo de pasos de denoising. La ganancia de throughput y latencia viene de esa generación paralela por paso, no de un proceso iterativo genérico. Inception Labs posiciona el resultado como comparable, en inteligencia, a modelos de frontera optimizados para costo: GPT-5.6 Luna (Low), Gemini 3.5 Flash-Lite y Claude Haiku 4.5. El throughput es lo que separa la línea: 1.107 tokens por segundo en GPUs NVIDIA.

La arquitectura es el punto de partida. Difusión y transformer autorregresivo producen texto por caminos distintos, y de ahí viene la diferencia de velocidad. La cifra de 1.107 tokens por segundo se mide en GPUs NVIDIA, por solicitud y en flujo único. Vale calificar: los modelos autorregresivos servidos con batching continuo y hardware acelerado, en la clase de Cerebras y Groq, ya alcanzan cuatro dígitos de tokens por segundo por solicitud. La diferenciación de Mercury no es la velocidad bruta aislada, es la economía de servir una arquitectura de difusión. La ventana de contexto llega a 260 mil tokens.

El precio de lanzamiento es US$0,20 por millón de tokens de entrada y US$0,75 por millón de salida. Durante la promoción de lanzamiento, Inception Labs cobra US$0,04 y US$0,15. Dos productos se anunciaron en previa el mismo día: Mercury Voice y Mercury Router. El Router coloca a un proveedor de modelos dentro de la capa que decide qué modelo atiende cada llamada, algo que hasta aquí era territorio de gateways independientes o de decisiones tomadas por la propia aplicación.

Las pruebas de cliente llegaron junto. Augment Code reportó una reducción de 82% en la latencia de compactación, de 150 segundos a 27, y un recorte de 90% en el costo de esa etapa. OpenCall llevó el P99 de minutos a cerca de un segundo. Son casos de un proveedor divulgando casos de clientes, así que vale leerlos como relato de la fuente primaria, no como auditoría independiente.

Por qué el costo por tarea cambia la decisión de ruta

La métrica que decide el presupuesto de inferencia no es el precio por millón de tokens, es el costo por tarea completada. Si la arquitectura de difusión entrega respuestas útiles con más throughput por GPU, cada minuto de GPU produce más trabajo, y la cuenta por solicitud puede caer aun con un precio nominal parecido al de un competidor. Solo que el costo por tarea no es precio por token por velocidad: la inferencia por difusión gasta GPU en pasos iterativos de denoising, y el resultado depende del tamaño de batch, del número de pasos y de la eficiencia de tokens, nada de eso divulgado por la fuente. La cifra de 1.107 tokens por segundo la mide el proveedor, en una configuración de serving no especificada, así que la cuenta real de costo por tarea debe medirse en la carga de quien compra.

Considere el caso de la compactación. Augment Code reportó que el mismo paso cayó de 150 segundos a 27, con 90% menos costo. Un ingeniero que corre compactación decenas de veces por día siente la diferencia en minutos, no en fracción de centavo.

Ese es el punto.

El eje de la disputa salió del precio por token y se fue a tokens por segundo por dólar. Quien enruta solo por costo de tabla está midiendo la variable equivocada en cargas interactivas.

Hay un límite honesto en esta lectura. La empresa no publicó, en el anuncio, una comparación independiente de calidad tarea a tarea contra los modelos de frontera que ella misma nombra. Lo que existe es la afirmación de paridad de inteligencia y un puñado de casos de cliente. Inception Labs es la fuente de esos números, y la lectura correcta es tratar la paridad como alegato de proveedor hasta que aparezcan comparativos de terceros. Nada de esto quita el valor del lanzamiento: el precio y la velocidad ya cambian la aritmética aun con la paridad en abierto.

Dónde entra un modelo speed-first en la política de enrutamiento

Un modelo rápido y barato no sustituye la frontera en todo. Sustituye la frontera en tráfico de alto volumen y baja ambigüedad, donde la tarea tiene un formato previsible y el costo del error es bajo. Es donde el volumen come inflación de cuenta y donde la latencia aparece para el usuario final.

Vale la contraposición honesta: una franja barata y rápida para producción no es novedad, y ya existe en los modelos optimizados para costo que la propia Inception Labs nombra. Quien enruta por costo y latencia ya manda tráfico a esa clase. Lo que Mercury 2.5 trae de nuevo no es el concepto de tier no-frontera en producción, es la arquitectura de difusión y el punto de precio y velocidad donde llega.

La lista de candidatos es previsible: clasificación, extracción de campos, resumen de fragmento, reescritura corta, llenado de plantilla y triaje de primera línea. Es rutina.

El tráfico de razonamiento profundo sigue en la frontera. Análisis con múltiples saltos, código con dependencias largas, decisión regulatoria, todo lo que exige la última milla de calidad justifica pagar más por token y esperar más por respuesta. La frontera de inteligencia medida por índices independientes muestra dónde está hoy, sin afirmar una posición específica de Mercury 2.5 en ese índice, y una buena política de ruta no elige un ganador: escribe la regla de qué tráfico va a qué clase.

El Mercury Router anunciado por Inception Labs es la señal de mercado aquí. Cuando quien entrena el modelo también lanza la capa que decide qué modelo atiende cada llamada, el enrutamiento deja de ser un detalle de implementación y pasa a ser un plano de control. También cambia la relación de poder: el proveedor empieza a querer controlar la decisión de ruta que antes quedaba con el comprador.

• Alto volumen, baja ambigüedad, tolerancia al error: candidato natural al modelo difusión, por la velocidad y por el costo por tarea.
• Razonamiento profundo, pocas llamadas, alto costo de error: sigue en la frontera, aceptando precio y latencia mayores.
• Interactivo con límite de tiempo en el P99: el modelo rápido es el que salva la experiencia, y el número de OpenCall muestra el tamaño de la ganancia.

Qué cambia en la práctica

El eje cambió. La tabla de abajo compara cómo se tomaba la decisión de ruta antes de que la clase difusión entrara en producción y cómo queda después, con la variable de costo por tarea completada en la cuenta y el precio por token rebajado a uno de los factores. Las filas de enrutamiento dinámico y de proveedor en la capa de ruta son tendencia a observar, no capacidad en producción: el Mercury Router se anunció solo en previa.

La tabla resume el desplazamiento. El precio por token sigue existiendo y sigue importando, pero dejó de ser el criterio único. Quien compra inferencia pasa a necesitar tres números por candidato: costo por millón de tokens, tokens por segundo y latencia de punta a punta en el P99.

Cómo evaluar sin engañarse con el benchmark

El error clásico es elegir por la tabla de precio y solo descubrir la cuenta real cuando aparece en la factura de GPU, en el desborde del presupuesto mensual o en el límite de tiempo que el usuario tolera. El camino correcto es medir por tarea, en su propio tráfico, con la tasa de acierto de su aplicación.

1. Defina la tarea y el criterio de aceptación antes de comparar modelos. "Respondió" no es criterio, "pasó la prueba de extracción en 96% de los casos" sí lo es.
2. Mida costo por tarea completada, no precio por token. Divida el costo total por el número de tareas que pasaron el criterio. El costo de contexto como vector de decisión entra en esta cuenta, no solo el precio de tabla.
3. Mida latencia de punta a punta, y mire el P99, no el promedio. El promedio esconde exactamente la cola que derrumba la experiencia interactiva.
4. Corra el mismo prompt en paralelo en los candidatos y compare los tres números lado a lado. El ranking de modelos sirve para elegir a los finalistas, nunca para cerrar la decisión.
5. Reevalúe la ruta cuando cambian el precio, la velocidad o un modelo nuevo. Cambian cada semana.

La regla vale para quien enruta más de algunos cientos de millones de tokens por mes. Por debajo de eso, la ganancia de optimizar la ruta suele no pagar el trabajo de medir y mantener la política. Por encima, se paga en el primer trimestre de uso.

FAQ

Mercury 2.5 es un LLM de difusión, y qué cambia eso en la práctica? La difusión genera un bloque entero de tokens enmascarados en paralelo y refina todas las posiciones en pasos de denoising, en lugar de emitir token a token de izquierda a derecha como el transformer autorregresivo. En la práctica, la ganancia aparece en throughput por solicitud: 1.107 tokens por segundo, según Inception Labs, lo que reduce costo por tarea y latencia en cargas interactivas de alto volumen, con la salvedad de que la medición es del proveedor, en una configuración no especificada.

¿Mercury 2.5 sustituye modelos de frontera como GPT-5.6 Luna (Low) o Claude Haiku 4.5? No. Es comparable en inteligencia a modelos optimizados para costo, según la propia Inception Labs, y entra como candidato para alto volumen y baja ambigüedad. El razonamiento profundo y las decisiones de alto costo de error siguen en la frontera. La política de ruta combina las dos clases.

¿Cuál es el precio de Mercury 2.5 y qué cambia en el presupuesto? US$0,20 por millón de tokens de entrada y US$0,75 por millón de salida, con promoción de lanzamiento en US$0,04 y US$0,15. El efecto en el presupuesto no viene solo del precio, viene del costo por tarea completada. Un modelo con más throughput por GPU puede costar menos por solicitud aun con un precio por token parecido, pero esa cuenta depende de su volumen, del batch y del número de pasos de denoising, y solo la medición en su carga cierra el número.

¿Qué es el Mercury Router y por qué importa? Es un enrutador anunciado en previa por Inception Labs, junto con Mercury Voice, y todavía sin fecha de disponibilidad general. Importa porque coloca a un proveedor de modelos en la capa que decide qué modelo atiende cada llamada, encaminando prompts a modelos abiertos y cerrados. Eso confirma el enrutamiento como plano de control del stack de IA, y no como un detalle de la aplicación.

¿Se auditaron los números de Augment Code y OpenCall? No de forma independiente. Los dos casos vienen del anuncio de Inception Labs. La reducción de 82% en la latencia de compactación y el recorte de 90% en el costo son reportes de cliente publicados por la fuente primaria. El P99 de OpenCall, de minutos a cerca de un segundo, sigue el mismo origen.

Referencias y Lectura Complementaria

• Introducing Mercury 2.5, Inception Labs, fuente primaria, publicada el 2026-09-08 según el pie del anuncio; página consultada el 2026-09-15.
• Seis laboratorios por encima de 50 en el Intelligence Index, dónde está la frontera de inteligencia y qué cambia en la ruta (lectura de referencia, no la posición de Mercury 2.5).
• Qwen3.8-Max: costo de contexto y qué cambia en el enrutamiento, el costo de contexto como vector de decisión de ruta.
• Nexforce Router, la capa de enrutamiento multimodelo con una sola API.

Qué hacer ahora con la nueva clase en la ruta

El plazo corto es claro: Inception Labs prometió Mercury Voice y Mercury Router como previas, sin fecha de disponibilidad general en el anuncio, así que el comprador que quiere prepararse trabaja con lo que ya está fechado. Mercury 2.5, su precio y su velocidad ya son decisión de arquitectura, no de espera.

La pregunta que queda para el próximo trimestre no es cuál modelo es el mejor, sino quién controla la decisión de qué modelo atiende cada llamada. Un proveedor de modelos lanzando su propio enrutador responde esa pregunta desde un lado. Del lado del comprador, la respuesta es mantener la capa de ruta bajo control propio, con un criterio explícito y observable.

El Nexforce Router existe para eso: más de 300 modelos detrás de una única API compatible con OpenAI, con enrutamiento por costo, performance, latencia y contexto, failover automático entre proveedores, presupuesto por key y observabilidad centralizada de cada llamada. Cuando una clase nueva de arquitectura entra en producción, como los LLM de difusión ahora, la política de ruta es lo que decide cuánto de eso se convierte en ahorro real y cuánto en complejidad sin dueño.