Artículo
Mercury 3: rapidez con criterio
Inception anunció Mercury 3 el 19 de octubre de 2026: un modelo de lenguaje por difusión con 1.068 tokens por segundo en GPU NVIDIA y contexto de un millón de tokens, según el proveedor.
Las comparaciones y testimonios publicados son del proveedor y sus socios, no validación independiente.
La pregunta para un equipo que evalúa esta propuesta es concreta: ¿cuánto tarda en obtener un resultado que puede usar? Para responder, conviene definir el reloj, el criterio de aceptación y los gastos incluidos antes de comparar alternativas. A continuación proponemos una forma de hacerlo, con un ejercicio inventado y sin atribuirle resultados a ningún producto.
La rapidez tiene más de un reloj
En una prueba, define la latencia inicial como la espera desde el envío de la solicitud hasta el primer contenido útil. Ese contenido puede ayudar a mantener una conversación, pero todavía no demuestra que la respuesta esté completa o resuelva la tarea. Registra aparte el momento en que termina.
Un token es una unidad de texto que emplea el sistema para contar su entrada o salida; no equivale necesariamente a una palabra. Comparar respuestas por su longitud visible puede ocultar diferencias en ese conteo. Usa el registro de consumo correspondiente a cada solicitud.
Para este ejercicio, el tiempo extremo a extremo empieza al enviar la petición y termina cuando la respuesta completa es visible. Incluye las esperas intermedias que ocurran en ese recorrido: red, consultas a herramientas y presentación. La revisión humana viene después y se registra por separado. Así sabes si estás mejorando el ritmo del texto o la experiencia completa.
Calcula el costo de una tarea aceptada
Una respuesta entregada y una tarea aceptada son unidades distintas. Define la aceptación antes de probar: por ejemplo, que un resumen conserve los datos suministrados, identifique información pendiente y no invente una conclusión. Una respuesta breve que omite lo esencial no debería entrar al denominador como un éxito.
Para calcular el gasto de API por tarea aceptada, suma el consumo facturado del lote, incluidos los intentos fallidos y las correcciones, y divídelo entre las tareas que cumplen ese criterio. No dividas únicamente el gasto del último intento correcto: perderías el recorrido necesario para llegar a él.
Ese cálculo todavía no es el costo total del trabajo. Registra aparte el tiempo de revisión y los servicios adicionales. Si quieres incorporarlos como dinero, necesitas una tarifa de trabajo y un alcance acordados. Si no los tienes, conserva minutos y cargos separados; evita presentar un total que parece completo pero deja trabajo fuera.
Ejercicio ficticio: compara dos configuraciones
Imagina diez casos inventados para resumir consultas comerciales y preparar borradores de respuesta. No contienen datos de clientes reales. Dos configuraciones reciben los mismos casos y las mismas instrucciones. Los valores siguientes son cifras creadas para explicar el cálculo: no proceden de una prueba ni corresponden a un proveedor.
| Configuración | Espera mediana completa | Gasto del lote | Tareas aceptadas | API por aceptada |
|---|---|---|---|---|
| A | 2 segundos | US$0,24 | 8 de 10 | US$0,03 |
| B | 3 segundos | US$0,18 | 9 de 10 | US$0,02 |
La división es US$0,24 entre ocho y US$0,18 entre nueve. En este escenario, A termina antes, mientras B tiene menor gasto de API por tarea aceptada. Falta saber cuánto costó revisar cada lote. Si B necesitara más intervención, la comparación económica completa podría cambiar.
También falta aplicar la tolerancia de espera del producto. Si toleras una mediana de hasta tres segundos, ambas podrían seguir en evaluación. Si exiges una mediana inferior a dos, ninguna pasa ese umbral. La mediana resume la posición central, no todas las experiencias: revisa también los casos más lentos antes de decidir.
Haz que el piloto responda una pregunta
Escribe una pregunta que permita actuar: por ejemplo, qué configuración entrega borradores aceptables dentro del tiempo que necesita tu equipo. Selecciona casos que representen ese trabajo, incluidos los que exigen detectar información ausente. Una colección formada solo por consultas cómodas no permite revisar ese borde.
Mantén iguales las instrucciones y el material de entrada. Anota la configuración utilizada, los cambios entre ejecuciones y los instantes que definen tus relojes. Mezclar una instrucción breve en una alternativa con otra mucho más exigente en la segunda dificulta interpretar la diferencia. Si cambias una condición, registra una nueva comparación.
Guarda por caso el tiempo completo, el consumo, los intentos y la decisión de aceptación con su motivo. Pide que la revisión use el criterio escrito, sin premiar una respuesta por llegar antes. Después podrás separar un problema de contenido de una espera en otra parte del recorrido. Este es un diseño propuesto de evaluación, no el protocolo de los benchmarks del anuncio.
Presupuesta con condiciones explícitas
La nota del 19 de octubre lista precios normales por millón de tokens: US$0,20 entrada y US$0,70 salida; lanzamiento: US$0,10 y US$0,35, respectivamente. Sin duración ni elegibilidad indicadas. Anuncia API Inception, OpenRouter, Baseten y Vercel; sin confirmación para Chile.
Para un presupuesto, separa el escenario con tarifa normal de otro condicionado a una oferta confirmada. No extiendas una condición temporal a todo el año sin respaldo contractual. Anota la fecha de la cotización, la moneda y qué consumo se factura. Las condiciones que falten son preguntas para el proveedor, no ceros en la planilla.
Si la decisión incluye responsables y límites de consumo, puedes continuar con la guía sobre gasto y presupuestos de IA. Es un contexto comercial distinto: sirve para formular controles, no para trasladar sus tarifas a esta evaluación.
Preguntas frecuentes
¿Qué pasa si ninguna tarea es aceptable?
El costo por aceptada queda sin definir: no puedes dividir entre cero. Conserva el gasto y las causas de rechazo; revisa el alcance antes de ampliar la prueba.
¿Por qué tokens/s no equivale a espera total?
La tasa mide un ritmo de generación, no todo el recorrido. Para relacionarla con la experiencia de uso, registra cuánto tiempo transcurre antes y después de producir el texto. Así puedes localizar una espera que el conteo de tokens no representa.
¿Un contexto amplio garantiza una respuesta correcta?
No. Es capacidad para incorporar información a una petición, no una nota de exactitud. Prueba preguntas con solución conocida y comprueba si la respuesta usa el dato pertinente, especialmente cuando hay material que no necesita.
¿Cuándo conviene ampliar el piloto?
Cuando puedas explicar qué casos cumplen el objetivo y cuáles no. Amplía el conjunto conservando el criterio inicial; si lo cambias, distingue esa revisión de la comparación anterior.
Fuente: Inception, nota del 19 de octubre de 2026.
Lleva tu pregunta de evaluación y un caso ficticio a la Comunidad IA para discutir qué medir antes de elegir una configuración.
