Metodología de AA-AgentPerf

Resumen

AA-AgentPerf es un benchmark de hardware que mide el equilibrio entre el rendimiento total de un despliegue de inferencia y la velocidad que recibe cada agente con cargas agénticas realistas.

  • Trayectorias agénticas reales: Sesiones de programación multi-turno con razonamiento intercalado, llamadas a herramientas y longitudes de contexto variables (no prompts uniformes sintéticos).
  • Carga concurrente sostenida: Cada agente simulado permanece activo durante toda la fase de prueba, lo que estresa la reutilización de KV cache, el speculative decoding y el comportamiento del scheduler.
  • Clasificación en vivo: Publicamos resultados de forma continua, incorporando hardware a medida que está disponible y volviendo a medir los sistemas con nuevos stacks de software y versiones de modelos.
  • Listo para producción: Probamos los modelos con optimizaciones realistas habilitadas y topologías de despliegue a escala de producción.
agentes concurrentes0/ 9SISTEMA DEINFERENCIAAGENTE 1AGENTE 2AGENTE 3AGENTE 4AGENTE 5AGENTE 6AGENTE 7AGENTE 8AGENTE 9rendimiento del sistemavelocidad de salida por agente

Cada agente simulado trabaja secuencialmente en trayectorias agénticas de programación (razonando, llamando a herramientas y editando código) mientras el sistema escala para soportar una concurrencia creciente.

Conjunto de datos

El conjunto de datos de AA-AgentPerf contiene trayectorias agénticas reales que cubren varios casos de uso, lenguajes de programación y modelos. Generamos las trayectorias en el harness agéntico OpenCode indicando a tres modelos de código abierto líderes con razonamiento habilitado (DeepSeek V3.2, GLM 4.7 y Kimi K2.5) que resolvieran issues en repositorios de código públicos reales. Todas las trayectorias incluyen razonamiento intercalado y llamadas a herramientas.

  • Input Sequence Length (ISL): Va de ~5K a ~131K tokens, con una media de aproximadamente 27K tokens. Las trayectorias se truncan para encajar dentro de la longitud de contexto máxima recomendada de los modelos bajo prueba.
  • Output Sequence Length (OSL): Las longitudes de salida varían mucho entre turnos. Algunos turnos producen salidas cortas, como llamadas a herramientas simples, mientras que otros implican un razonamiento extenso antes de que el modelo responda o actúe.
  • Lenguajes: Se representan más de 12 lenguajes de programación, según el lenguaje principal del repositorio de origen. Los repositorios de Python son la fuente más frecuente, seguidos de TypeScript y Go.
  • Retrasos de llamadas a herramientas: Después de cada llamada a herramienta, simulamos el tiempo de procesamiento con un retraso fijo por mensaje, muestreado de una distribución de duraciones reales de llamadas, particionada según la herramienta invocada. Los retrasos van desde menos de 0,1 s hasta 5 s, con una mediana de aproximadamente 1 segundo.

Proporcionamos a los participantes una submuestra representativa de ajuste de 500 trayectorias únicas (18.997 prompts) para validar la configuración y optimizar el rendimiento. El conjunto de datos completo de prueba se mantiene privado para evitar optimizaciones dirigidas al benchmark.

Frontera de Pareto

Para cada sistema, publicamos los resultados como una frontera de Pareto del rendimiento total del servidor frente a la velocidad de salida por solicitud. Cada punto corresponde a una configuración de servicio en un nivel de concurrencia, y la frontera conserva los puntos que ninguna otra configuración del mismo sistema supera tanto en rendimiento como en velocidad.

Calculamos la velocidad y la latencia por solicitud. Como las cargas agénticas contienen muchas solicitudes con OSL pequeño, los gráficos usan por defecto la velocidad de salida P25, con percentiles calculados sobre todas las solicitudes enviadas durante una fase.

Ejecución de la prueba

Medimos cada despliegue en un conjunto fijo de niveles de concurrencia, con una fase por nivel, y calculamos las métricas a partir de la información de tiempo de los tokens en estado estable. Cada fase se ejecuta hasta que se han completado al menos 30 trayectorias, cada agente simulado ha completado al menos 3 trayectorias y han transcurrido al menos 10 minutos de medición en estado estable. Las asignaciones de trayectorias a agentes son deterministas entre fases, y se añaden prefijos generados dinámicamente al inicio de cada trayectoria en cada fase para romper el prefix caching entre fases. Un valor de max_tokens de 16K evita que solicitudes individuales en las que un modelo queda atascado en un bucle de repetición distorsionen los resultados.

Probamos cada modelo con los parámetros de muestreo recomendados por su creador y el máximo esfuerzo de razonamiento disponible (max para DeepSeek V4.1 Flash, DeepSeek V4 Pro 0813, Kimi K3, GLM-5.2 y GLM-5.3), con el resto de parámetros en sus valores por defecto.

Métricas y resultados

En cada fase de prueba calculamos las siguientes métricas:

  • Time to First Token (TTFT): Latencia por solicitud desde que se envía la solicitud hasta que se recibe el primer token de salida.
  • Velocidad de salida: Tokens de salida por segundo por solicitud, medidos después de recibir el primer token.
  • Rendimiento total del servidor: Tokens de entrada y de salida por segundo en todos los agentes concurrentes, según los informa el servidor. La entrada incluye los tokens del prompt servidos desde la caché KV.

Todas las métricas se filtran a períodos de estado estable en los que todos los agentes han estado activos durante al menos 30 segundos en la concurrencia objetivo. Las métricas de velocidad usan recuentos de tokens del lado del servidor, tomados de los metadatos de uso devueltos por el framework de inferencia y verificados mediante tokenización local con el tokenizador nativo del modelo candidato. Medimos el consumo de energía de cada acelerador durante la prueba en vivo. Normalizamos el resultado principal, el rendimiento total del servidor, por MW, por acelerador y por dólar por hora de alquiler de aceleradores. Las cifras por MW se basan en la potencia del acelerador medida bajo carga (die de la GPU + HBM), en lugar del TDP nominal. Los precios de alquiler provienen de Silicon Data, con estimaciones propias para los chips que Silicon Data no cotiza.

Publicamos los resultados en la clasificación de Artificial Analysis con la configuración completa del sistema que declara cada proveedor. Los proveedores pueden revisar sus resultados para comprobar la exactitud factual antes de la publicación.

Envíos

Si eres un proveedor de hardware interesado en enviar tu sistema para una evaluación de AA-AgentPerf y aún no estás en contacto, escríbenos a agentperf@artificialanalysis.ai.