Metodología de AA-AgentPerf

Resumen

AA-AgentPerf es un benchmark de hardware que mide cuántos agentes activos puede soportar un despliegue de inferencia con cargas agénticas realistas mientras cumple objetivos de rendimiento por agente (tiempo hasta el primer token y velocidad de salida).

• 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 — agentes simulados mantienen solicitudes en curso de forma continua, estresando la reutilización de KV cache, el speculative decoding y el comportamiento del scheduler.
• Niveles de SLO derivados del mercado — umbrales de rendimiento basados en datos de benchmarking de APIs serverless de Artificial Analysis, que reflejan niveles de calidad de servicio observados entre proveedores.
• Actualización continua — los resultados se actualizan de forma continua a medida que hay nuevo hardware, stacks de software y versiones de modelos disponibles.
• Listo para producción — los modelos se prueban con optimizaciones realistas habilitadas y topologías de despliegue a escala de producción.

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. Las trayectorias se generaron en el harness agéntico OpenCode usando tres modelos de código abierto líderes con razonamiento habilitado — DeepSeek V3.2, GLM 4.7 y Kimi K2.5 — con la instrucción de resolver 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, el tiempo de procesamiento se simula 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.

Se proporciona a los participantes una submuestra representativa de ajuste — 500 trayectorias únicas con 18.997 prompts en total — 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.

Objetivos de nivel de servicio

Los SLO de rendimiento se determinan a partir de datos de benchmarking de APIs serverless de Artificial Analysis. Para cada modelo probado se han identificado los niveles de servicio actualmente disponibles en el mercado. Los proveedores apuntan a cada nivel por separado, maximizando el número de agentes concurrentes que pueden soportar en ese nivel de servicio.

La velocidad y la latencia se calculan a nivel de solicitud. Debido al gran número de solicitudes con OSL pequeño en cargas agénticas, se usa la velocidad de salida P25, con percentiles calculados sobre todas las solicitudes enviadas durante una fase.

Cada modelo se prueba con los parámetros de muestreo recomendados por su creador y el máximo esfuerzo de razonamiento disponible: esfuerzo de razonamiento max para DeepSeek V4 Pro y high para gpt-oss-120b, con el resto de parámetros en sus valores por defecto.

Ejecución de la prueba

El número de agentes soportados para cada SLO se determina mediante búsqueda binaria después de una rampa exponencial inicial. Las métricas se calculan usando información de tiempo de los tokens en estado estable. Cuando una fase termina y las métricas se han calculado, el sistema determina si se han incumplido los SLO y luego avanza al siguiente nivel de concurrencia objetivo. 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.

Métricas y resultados

Durante cada fase de prueba se calculan las siguientes métricas de tiempo:

• 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.
• Capacidad de salida del sistema: Tokens de salida agregados por segundo en todos los agentes concurrentes.

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. El consumo de energía se mide en cada acelerador durante la prueba en vivo. Los resultados principales — agentes concurrentes máximos y capacidad de salida en cada nivel de SLO — se normalizan por acelerador, por sistema y por MW para permitir una comparación justa entre configuraciones de hardware. 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 resultados se publican en la clasificación de Artificial Analysis con las configuraciones completas del sistema según las declara el 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.