Cómo medir la latencia de Mercury 3 más allá de los tokens por segundo

Mide Mercury 3 desde el momento en que comienza una tarea hasta que su resultado está listo para usarse. Registra el tiempo hasta la primera respuesta, el tiempo hasta la respuesta completa y el tiempo total, incluidas las herramientas. Los tokens por segundo describen una parte de la generación; pueden pasar por alto la espera antes de que aparezca el resultado y el trabajo necesario después de que el modelo termine.

Usa un único caso de prueba pequeño con criterios de aceptación explícitos y registra el prompt, los archivos de entrada, el entorno de las herramientas y los ajustes del modelo. Eso basta para establecer el comportamiento básico y detectar cuellos de botella. Amplía la prueba solo si un fallo o una decisión difícil requieren más datos.

¿Qué marcas de tiempo debería recopilar?

Usa un temporizador monotónico del cliente para medir las duraciones y anota si la transmisión está habilitada. Mantén constantes las condiciones de establecimiento de la conexión y de reutilización de la conexión al comparar proveedores. No deduzcas el comportamiento del primer token a partir de una solicitud sin transmisión.

¿Cómo elijo un prompt de prueba justo?

Elige una tarea real y acotada: extraer campos específicos de un documento autorizado o realizar un pequeño cambio en un repositorio copiado. Mantén la misma entrada y la misma salida requerida en todas las ejecuciones. Registra el identificador del modelo, el ajuste de esfuerzo y el límite de salida para que los resultados sigan siendo interpretables.

La descripción general de Mercury 3 explica por qué las cifras de rendimiento de los proveedores no sustituyen esta medición a nivel de tarea.

¿Cómo afectan las herramientas al resultado?

Separa el tiempo de espera del modelo de la ejecución de las herramientas. Una lectura lenta del NAS, la navegación entre páginas o una búsqueda externa pueden dominar una tarea de varios pasos. Cuenta los reintentos, los argumentos de herramientas incorrectos y las lecturas repetidas de archivos, en lugar de ignorar el tiempo que consumen los intentos fallidos.

Usa la lista de comprobación del arnés del agente para identificar qué componente causa cada demora. Si la llamada al modelo representa una pequeña parte del trabajo, mejorar el acceso al almacenamiento o el diseño de la tarea puede ser más importante que cambiar la arquitectura de generación.

¿Cuántas ejecuciones necesito?

Una ejecución sirve para comprobar la conectividad y detectar problemas evidentes de corrección. Unas pocas repeticiones consistentes pueden revelar grandes diferencias prácticas, pero no justifican afirmaciones precisas sobre la fiabilidad ni percentiles de cola estables. Recopila más observaciones solo si la importancia de la implementación o una decisión de rendimiento reñida lo justifican.

Mantén siempre visibles los fallos. Una ejecución rápida y exitosa elegida entre varios intentos fallidos no constituye evidencia representativa. La guía de comprobación específica del flujo de trabajo ofrece un método ligero de aceptación.

¿Qué debo informar además de la latencia?

Indica si el resultado superó la revisión, los cargos de uso pertinentes, las llamadas a herramientas y las correcciones manuales. Incluye el entorno y la fecha. Si se agotó el tiempo de espera de una ejecución, regístrala como tal en lugar de asignarle una puntuación de velocidad atractiva.

Para los archivos NAS, conserva el conjunto de prueba y el resultado aceptado en directorios separados. Usa la comparación de arquitecturas para decidir qué significan las mediciones, y la guía de preparación de archivos para mantener acotada la exposición de datos del piloto.

Preguntas frecuentes

¿Puedo comparar directamente los tokens por segundo de distintos tokenizadores?

Interpreta esas cifras con cautela. Las definiciones de tokens, el contenido de salida y las condiciones de medición pueden variar entre proveedores.

¿Qué pasa si la API no transmite la respuesta en flujo?

Mide la duración de la respuesta completa y la finalización de la tarea. No afirmes un resultado de primer token que tu cliente no pueda observar.

¿Se deben excluir las ejecuciones fallidas?

No. Registra los tiempos de espera agotados, los reintentos y los resultados rechazados, ya que afectan al tiempo y al coste prácticos de completar la tarea.

¿Necesito una prueba de referencia amplia antes de un piloto?

No. Empieza con una tarea pequeña y representativa, y amplía las mediciones solo cuando una incertidumbre relevante lo requiera.

Lecturas relacionadas

• Mercury 3 explicado: por qué importan los modelos de lenguaje de difusión para los flujos de trabajo de IA rápidos
• Modelos de lenguaje de difusión frente a autorregresivos: ¿cuál se adapta mejor a tu flujo de trabajo de IA personal?

Fuentes

• Anuncio oficial y documentación del modelo — www.inceptionlabs.ai
• Documentación técnica y referencia — docs.inceptionlabs.ai

Portada: imagen oficial del anuncio de Mercury 3. Fuente de la imagen.