¿Por qué no basta un solo número de latencia por prompt para describir el rendimiento de una carga de trabajo agéntica de código?
Un agente de código no responde un solo prompt aislado y se detiene ahí. Lee una tarea, llama herramientas, recibe su resultado, cambia el repositorio y continúa desde ahí. El trabajo de MLCommons sobre inferencia agéntica trata esto como una trayectoria de turnos dependientes entre sí, no como un solo par de solicitud y respuesta: el contexto crece a lo largo de los turnos, la longitud de las salidas varía, y el sistema tiene que conservar el historial útil bajo presión sobre la caché KV mientras sigue avanzando.
Este artículo revisa documentación pública de MLCommons consultada el 22 de septiembre de 2026. No presenta números de benchmark ejecutados por este sitio.
Un agente de código responde más que un solo prompt
Trata una tarea de un agente de código como la trata MLCommons: como una trayectoria de turnos dependientes. El tiempo hasta el primer token sigue importando para una sola respuesta, pero no te dice si el décimo turno de una tarea larga sigue siendo rápido, si el contexto creciente del agente se está reutilizando de forma eficiente, o si eventualmente llega a un punto de parada correcto. Un sistema que parece rápido en el primer turno puede sentirse lento en la práctica si cada turno posterior reconstruye contexto que debería haber conservado. Una tasa de tokens alta puede esconder un ciclo de llamadas a herramientas genuinamente pobre por debajo.
Qué debería medirse en realidad
Eso redefine qué reporta un benchmark útil. La duración de la tarea de principio a fin y la latencia por turno importan, por separado. También importa el crecimiento del contexto a lo largo de una trayectoria, y si el contexto en caché de verdad se reutiliza en lugar de recalcularse. Los resultados de MLPerf v6.1 extienden este razonamiento a cargas de trabajo específicamente agénticas de borde y de RAG de principio a fin, una señal de que el campo se está moviendo más allá de un solo número de latencia como métrica principal para cualquier cosa agéntica. Si el agente llega a un punto de parada correcto es su propia medición aparte, y necesita una definición de “correcto” decidida antes de mirar un solo resultado.
Construye el benchmark alrededor del producto
El benchmark debería coincidir con el producto. Reproduce un conjunto fijo y representativo de tareas. Registra el modelo exacto y la configuración de servicio usados: los resultados siguen describiendo esa configuración, y no se puede asumir que describan una distinta. Decide la definición de corrección antes de mirar la salida, para evitar calificar sin darte cuenta hacia lo que el sistema haya producido. Mantén la exactitud y el rendimiento como marcadores separados; una respuesta rápida pero incorrecta y una lenta pero correcta fallan de forma distinta, y promediarlas esconde cuál obtuviste en realidad.
El cambio es metodológico
No conviertas el número de benchmark de un solo turno de un proveedor en una promesa implícita sobre cómo se comporta su sistema en trabajo real sobre un repositorio; miden cosas distintas. El cambio interesante aquí es metodológico: a medida que los agentes de código viven más tiempo, la ingeniería de rendimiento tiene que medir cómo progresa una tarea turno a turno, no solo la salida de una solicitud.
Sigue el RSS en español para leer el próximo artículo.
Sobre el autor: conoce mi portfolio y mi agencia, Bimbi Digital.