Los benchmarks de CPU AGI de Arm presionan a AMD, pero la ventaja de 1,99x es modelada
Arm afirma que su nuevo procesador completa casi el doble de trabajo por rack que el EPYC 9755 de AMD en siete cargas de trabajo seleccionadas. Los benchmarks de CPU AGI de Arm informan de una ventaja media de 1,99x después de escalar los resultados medidos de los chips mediante supuestos de potencia de los servidores.
Ese titular parece una derrota decisiva para AMD. Los resultados subyacentes cuentan una historia con más matices. Arm promedió una ventaja de 1,20x por chip, mientras que su ventaja mucho mayor por rack provino principalmente de poder instalar más servidores dentro de un presupuesto eléctrico fijo.
Signal65 revisó las pruebas mediante un análisis encargado por Arm. Sin embargo, no volvió a ejecutar de forma independiente toda la comparación en hardware distinto. El benchmark también evalúa trabajo de CPU alrededor de agentes de IA, no la inteligencia del modelo ni la inferencia mediante aceleradores.
Por tanto, el resultado importa por una razón concreta. Arm pide a los compradores de infraestructura que juzguen las CPU para IA agéntica por el trabajo completado por rack, en lugar de considerar el rendimiento por socket como la respuesta definitiva.
Los benchmarks de CPU AGI de Arm trasladan la contienda al rack
La afirmación central de Arm no es que cada CPU AGI supere a cada procesador AMD casi por dos veces a nivel de socket.
El análisis a escala de rack comparó el procesador de Arm con el EPYC 9755 de AMD de quinta generación. Cubrió siete cargas de trabajo relacionadas con la ejecución de herramientas, recuperación, servicio web, ingeniería de software y soporte para servicio de modelos.
Signal65 informó de una relación media de rendimiento por rack modelado de 1,99x para Arm. Los resultados individuales por rack oscilaron entre 1,43x y 3,19x, según la carga de trabajo.
Las siete pruebas fueron MySQL, NGINX, Milvus, Terminal-Bench 2, una repetición de SWE-bench, fastText y sobrecarga de CPU de vLLM. Representan diferentes partes de la ruta de software que rodea a un modelo de IA.
MySQL mide el rendimiento de bases de datos transaccionales. NGINX cubre la gestión de solicitudes web y de API, mientras que Milvus representa la recuperación vectorial para la memoria y búsqueda de los agentes.
Terminal-Bench 2 examina el trabajo realizado dentro de entornos aislados de línea de comandos. La prueba utilizó 72 tipos de tareas y ejecutó 128 copias simultáneamente.
La repetición de SWE-bench cubrió 259 tareas de ingeniería de software. En lugar de pedir a un modelo que eligiera acciones diferentes durante cada ejecución, el benchmark reprodujo un flujo de trabajo fijo.
Ese enfoque de repetición importa porque los agentes de IA no son deterministas. Dos ejecuciones pueden involucrar comandos distintos, retrasos de servicios remotos o planes generados por el modelo, incluso cuando la tarea solicitada es idéntica.
fastText midió el entrenamiento de representaciones de palabras en CPU. La prueba de vLLM midió la sobrecarga del procesador alrededor del servicio de modelos, omitiendo el trabajo computacional principal del modelo.
Esta última distinción evita una interpretación errónea habitual. El resultado de vLLM no muestra con qué rapidez la CPU AGI ejecuta inferencia de modelos de lenguaje grandes frente a una GPU.
El chip de Arm ganó cinco de las siete comparaciones por chip. Superó a AMD en un 9% en Terminal-Bench, un 13% en la repetición de SWE-bench y un 97% en fastText.
AMD mantuvo la ventaja en dos cargas de trabajo de infraestructura consolidadas. El EPYC 9755 fue un 12% más rápido en MySQL y un 5% más rápido en Milvus a nivel de chip medido.
NGINX produjo una relación de 1,20x para Arm. La carga de trabajo de sobrecarga de CPU de vLLM otorgó a Arm un resultado de 1,16x.
En las siete relaciones normalizadas, Arm promedió una ventaja por chip de 1,20x. Ese resultado es significativo, pero es mucho menor que la cifra de 1,99x asociada a la afirmación a nivel de rack.
El modelo de rack transformó la comparación al tener en cuenta la potencia nominal de los servidores. Supuso entre 950 y 1.050 vatios para un servidor Arm de dos sockets, según la configuración de CPU AGI.
Al sistema AMD se le asignó una estimación de potencia nominal de 1.700 vatios. Ambos cálculos incluyeron memoria y otros componentes del servidor, no solo la potencia de diseño térmico del procesador.
Después de reservar aproximadamente un 8% de un presupuesto de rack de 24 kilovatios para redes y distribución eléctrica, el modelo instaló 21 o 23 servidores Arm. Instaló 13 servidores AMD dentro del mismo presupuesto.
Eso produjo entre 5.712 y 5.888 núcleos físicos Arm por rack modelado. El rack de AMD contenía 3.328 núcleos físicos.
El multiplicador de densidad resultante elevó cada carga de trabajo de Arm por encima de AMD a nivel de rack. Incluso MySQL, que favorecía a AMD por chip, se convirtió en un resultado modelado de 1,43x para Arm por rack.
Milvus pasó de 0,95x por chip a 1,54x por rack. La repetición de SWE-bench subió de 1,13x a exactamente 2,00x bajo el modelo de rack.
fastText generó la relación más alta. Su resultado medido de 1,97x por chip se convirtió en un resultado modelado de 3,19x por rack.
Estas cifras respaldan el argumento de Arm de que los centros de datos limitados por la potencia deberían evaluar el trabajo útil total. No muestran dos racks operativos completando esas cargas de trabajo bajo potencia de pared medida directamente.
Por qué la IA agéntica hace más visible el trabajo de CPU
Los agentes de IA desplazan un trabajo sustancial fuera del acelerador, haciendo que la capacidad de CPU forme parte de la experiencia visible para el usuario.
Una solicitud convencional de IA generativa puede parecer centrada en la inferencia del modelo. Un agente de producción realiza una secuencia más larga que incluye planificación, recuperación, llamadas a herramientas, validación y gestión del estado.
La GPU u otro acelerador sigue realizando los cálculos densos de la red neuronal. La CPU coordina gran parte de la ruta de ejecución circundante y ejecuta muchas herramientas que el agente selecciona.
Un agente de programación ofrece un ejemplo práctico. Puede inspeccionar un repositorio, iniciar un entorno aislado, instalar dependencias, compilar código, ejecutar pruebas y analizar fallos.
Cada llamada al modelo puede desencadenar otra ronda de trabajo de CPU. Ejecutar miles de agentes simultáneamente multiplica la demanda sobre contenedores, bases de datos, API, almacenamiento y sistemas de planificación.
Los agentes empresariales crean un perfil diferente. Pueden consultar registros, llamar a servicios internos, aplicar políticas de acceso, serializar respuestas, actualizar el estado del flujo de trabajo y escribir registros de auditoría.
La recuperación añade operaciones de indexación y búsqueda vectorial. El servicio de modelos añade tokenización, planificación de solicitudes, agrupación por lotes, transmisión y gestión de metadatos de caché alrededor del acelerador.
El marco de evaluación de Arm separa este trabajo en funciones del marco de agentes y herramientas específicas para cada caso de uso. También separa los benchmarks de componentes de las mediciones de tareas de extremo a extremo.
Las pruebas de componentes ayudan a aislar el comportamiento del procesador. Las pruebas de extremo a extremo muestran si un componente más rápido produce una tarea completada más rápida o fiable.
Ninguno de los dos enfoques es suficiente por sí solo. Un procesador puede liderar un benchmark de base de datos sin acortar el flujo de trabajo total de un agente, especialmente cuando domina la latencia del modelo.
Un resultado de extremo a extremo también puede ocultar la causa de una brecha de rendimiento. Diferentes modelos, redes, herramientas o decisiones de agentes pueden eclipsar la diferencia subyacente entre procesadores.
Arm propone trayectorias de agentes reproducibles como un puente entre esos enfoques. Una trayectoria registra las operaciones producidas durante una sesión de agente y ejecuta la misma secuencia en cada sistema.
La técnica reduce la variación derivada de las decisiones del modelo. También hace que la comparación sea más repetible porque ambos procesadores reciben un flujo de trabajo equivalente.
Sin embargo, la repetición elimina parte del sistema en vivo. Mide la rapidez con la que la infraestructura ejecuta una ruta predeterminada, no si una pila completa de agentes encuentra una ruta mejor.
Este límite explica por qué la etiqueta de razonamiento y planificación requiere cautela. Las pruebas relevantes miden el soporte de CPU para esos flujos de trabajo, en lugar de la calidad del razonamiento automático.
La misma cautela se aplica a la concurrencia. Un servidor que inicia más entornos de agentes no es automáticamente mejor si los tiempos de respuesta se desploman bajo una utilización sostenida.
La metodología de Arm enfatiza el trabajo útil completado manteniendo la capacidad de respuesta. Este enfoque vincula el rendimiento con los límites físicos a los que se enfrentan los centros de datos.
La entrega de energía se ha convertido en uno de esos límites. La capacidad de refrigeración y el espacio en rack también restringen cuántos procesadores puede desplegar un operador, independientemente de la disponibilidad de chips.
En esas condiciones, el liderazgo por socket no siempre produce el mejor resultado a nivel de instalación. Un procesador moderadamente más rápido puede perder a escala de rack si el servidor que lo respalda consume mucha más energía.
Por el contrario, un servidor más eficiente puede crear mayor capacidad total incluso cuando pierde determinadas pruebas a nivel de chip. Los resultados de MySQL y Milvus de Arm ilustran esa posibilidad dentro de su modelo.
Arm desarrolló la metodología con el apoyo de Fujitsu, Meta y OpenAI. Su apoyo indica interés en mediciones de CPU más representativas, pero no convierte el marco en un estándar de la industria.
Meta dijo que los agentes de producción requieren una mayor visibilidad de cómo las cargas de trabajo utilizan la infraestructura subyacente. OpenAI destacó la orquestación y la ejecución de herramientas como áreas que necesitan benchmarks representativos.
Fujitsu vinculó el esfuerzo con su desarrollo de un procesador Arm de alto rendimiento. Las tres perspectivas respaldan una mejor medición, aunque cada organización también tiene interés en infraestructura basada en Arm.
El propio marco reconoce que no es una suite de benchmarks terminada. Define categorías de cargas de trabajo y límites de medición, mientras deja sin resolver la puntuación y un acuerdo más amplio.
Esa distinción es esencial. Arm ha propuesto una forma de estructurar el debate y luego ha publicado resultados favorables utilizando pruebas alineadas con esa propuesta.
El resultado de 1,99x proviene de la densidad, no de una victoria de 2x del chip
La historia del rendimiento de CPU AGI de Arm depende más de la densidad de despliegue modelada que de un rendimiento abrumador a nivel de socket.
Arm probó dos configuraciones de CPU AGI porque el mismo hardware no estaba disponible para todas las cargas de trabajo. Terminal-Bench 2 y SWE-bench utilizaron un chip de 128 núcleos a 2,8 GHz con memoria DDR5-7200.
Las otras cinco cargas de trabajo utilizaron una CPU AGI de 136 núcleos a 3,2 GHz con DDR5-8000. El sistema de comparación de AMD utilizó un socket EPYC 9755 de 128 núcleos con DDR5-6400.
Ambas plataformas ejecutaron los mismos scripts de benchmark. No ejecutaron entornos de software idénticos.
La mayoría de las pruebas de Arm utilizaron Ubuntu 24.04 con una compilación personalizada de Linux 7.1.3. La prueba de SWE-bench utilizó Ubuntu 26.04.
La configuración principal registrada de AMD utilizó Ubuntu 24.04 y Linux 6.8. Algunos ajustes también variaron según la prueba.
Las diferencias de software pueden afectar al comportamiento del compilador, la planificación, los controladores y el rendimiento de las aplicaciones. Hacen más difícil atribuir cada diferencia exclusivamente a la arquitectura del procesador.
El modelo de potencia del servidor crea otra distinción importante. Signal65 y Arm utilizaron cifras nominales en lugar de medir racks de producción completos bajo carga.
La potencia nominal sigue siendo útil para la planificación de capacidad. Los operadores no pueden instalar equipos que excedan el diseño eléctrico y de refrigeración de un rack, aunque el consumo típico sea menor.
Sin embargo, la potencia nominal puede diferir del consumo específico de una carga de trabajo. Un sistema podría consumir menos que su máximo nominal durante una aplicación y acercarse a él durante otra.
La potencia real también depende de la configuración de memoria, el almacenamiento, las redes, la refrigeración, las fuentes de alimentación, el firmware y las políticas de gestión del sistema. Esas variables cobran importancia cuando el número de servidores impulsa el titular.
Los supuestos de memoria modificaron la ventaja reportada. El modelo principal de Arm asignó 4 GB por hilo de hardware.
El multihilo simultáneo de AMD expone dos hilos de hardware por núcleo físico. El diseño probado de Arm utiliza un hilo por núcleo.
Esa elección dio a los servidores AMD modelados aproximadamente 2 TB de memoria y a los servidores Arm cerca de 1 TB. Asignó 336 vatios para la memoria de AMD y 192 vatios para la de Arm.
Signal65 también calculó un escenario que asignaba memoria por núcleo físico. Con esa alternativa, AMD necesitaba menos potencia de memoria y la ventaja media de Arm por rack descendía de 1,99x a aproximadamente 1,81x.
Arm aún mantenía una ventaja sustancial en el modelo. La reducción muestra cómo una elección razonable de planificación de capacidad puede modificar de forma significativa la cifra final.
La capacidad de memoria no es solo un detalle de benchmarking. Algunas implementaciones de agentes mantienen índices grandes, cachés, almacenes de estado o entornos de ejecución simultáneos.
Un servidor con más memoria puede admitir cargas de trabajo que una configuración más densa pero de menor capacidad no puede alojar de manera eficiente. Por lo tanto, los compradores deben comparar la capacidad útil del sistema, no solo el rendimiento normalizado.
El EPYC 9755 de AMD admite 128 núcleos físicos y 256 hilos. También forma parte de una amplia plataforma de servidores utilizada en cargas de trabajo de propósito general, bases de datos, virtualización y alojamiento de IA.
El CPU AGI de Arm apunta a una propuesta más específica. Combina núcleos Arm densos con un ancho de banda de memoria e I/O considerables para infraestructura de IA.
Esa especialización no convierte a ninguna de las dos arquitecturas en universalmente superior. Cambia qué limitaciones determinan la mejor elección.
Un operador de nube con un límite fijo de potencia podría priorizar los trabajos completados por rack. Un comprador de bases de datos podría dar más importancia al rendimiento por socket, la madurez del software, la capacidad de memoria o el comportamiento de las licencias.
Un operador de clústeres de IA puede preocuparse por mantener ocupados aceleradores costosos. Una preparación y orquestación más rápidas en el lado de la CPU pueden reducir el tiempo de inactividad de los aceleradores, pero estas pruebas no midieron un flujo de trabajo completo respaldado por aceleradores.
Eso deja la comparación entre el CPU AGI de Arm y AMD en un terreno más limitado de lo que sugiere el titular. Es una comparación de tareas seleccionadas visibles para la CPU y de un escenario de implementación modelado.
No es un estudio de coste total. Los resultados publicados no ofrecen una comparación completa de costes de adquisición, migración de software, soporte operativo, redes o cambios en las instalaciones.
Tampoco comparan Arm con todos los procesadores x86 relevantes. AMD dispone de otras configuraciones EPYC, mientras que Intel compite con plataformas Xeon en implementaciones empresariales y de nube.
El procesador Vera de Nvidia añade una segunda vía basada en Arm. Un estudio independiente de cargas de trabajo de Vera informó de sólidos resultados por núcleo frente al EPYC 9755 en tareas similares a las de agentes.
Ese estudio no midió la potencia ni el rendimiento de todo el servidor. Su resultado más limitado refuerza la necesidad de distinguir entre afirmaciones por núcleo, por socket, por rack y de extremo a extremo.
AMD también está promocionando las CPU como componentes críticos de los sistemas de IA agéntica. Su propio argumento sobre las CPU agénticas hace hincapié en la orquestación, el procesamiento de datos, la seguridad y el soporte para aceleradores.
Por tanto, el verdadero desacuerdo no es si las CPU importan. Se trata de cómo deben los compradores definir la carga de trabajo, normalizar los sistemas y convertir las mediciones de componentes en decisiones de implementación.
Lo que la afirmación de rendimiento del CPU AGI de Arm no establece
Signal65 validó los registros y cálculos de Arm, pero ese proceso no equivalía a una repetición independiente en laboratorio.
Signal65 observó remotamente las ejecuciones de pruebas de Arm. Examinó registros originales, archivos de resultados, scripts y registros de configuración.
Un equipo de revisión independiente reconstruyó los cálculos usando su propio código. Según el análisis, reprodujo los siete resultados con una diferencia inferior al 0,5 %.
Ese trabajo aporta más escrutinio que un gráfico de proveedor sin revisar. Comprueba si las proporciones comunicadas se derivan de los resultados capturados y del modelo de rack.
Aun así, Arm encargó el análisis y proporcionó los sistemas probados. Signal65 no adquirió hardware equivalente ni repitió de forma independiente el experimento completo en su propio laboratorio.
La revisión también afrontó lagunas de configuración. Signal65 pudo confirmar de forma independiente la configuración de BIOS y memoria únicamente de un sistema EPYC 9965 utilizado en una comparación separada en un entorno aislado.
No pudo verificar de forma independiente todas las configuraciones de BIOS y memoria de los sistemas con CPU AGI y EPYC 9755. Eso limita la certeza sobre el origen de diferencias de rendimiento más pequeñas.
La distinción importa especialmente en resultados ajustados. Es poco probable que una ventaja del 97 % en fastText desaparezca por un cambio menor de configuración, pero una brecha del 5 % o del 9 % merece un escrutinio más detallado.
La media aritmética crea otra limitación. Promediar proporciones normalizadas da a cada carga de trabajo la misma influencia, independientemente de la frecuencia con la que una implementación real realiza esa operación.
Una empresa podría ejecutar transacciones de bases de datos constantemente y entrenar modelos fastText en raras ocasiones. Otra podría operar miles de entornos aislados de programación y contar con poca infraestructura transaccional.
Por tanto, la media publicada de 1,99x no predice la ganancia de capacidad de todos los compradores. Cada operador necesita un resultado ponderado por carga de trabajo según su propio perfil de ejecución.
La suite de pruebas también mezcla aplicaciones consolidadas con proxies emergentes de agentes. MySQL y NGINX tienen una larga trayectoria, mientras que los benchmarks de agentes basados en reproducciones siguen siendo comparativamente jóvenes.
Esa combinación es útil porque los agentes invocan infraestructura conocida. También es debatible porque la combinación seleccionada determina qué recibe el mismo peso.
El reportaje original señaló que el resultado no establece un liderazgo general en IA agéntica. Los procesadores, las cargas de trabajo, las configuraciones y la metodología desarrollada por Arm definen su alcance.
No se incluyó inferencia completa de GPU en el resultado de vLLM. La categoría de razonamiento y planificación no probó si un modelo razonaba con mayor precisión.
El cálculo por rack no incluyó una implementación de 24 kilovatios medida directamente. Modeló el número de servidores a partir de la potencia nominal del sistema tras reservar capacidad para la infraestructura del rack.
El precio no formó parte de la comparación pública. Tampoco se incluyeron las licencias de aplicaciones, el trabajo de migración, la formación del personal ni la compatibilidad con las herramientas de implementación existentes.
Estas omisiones no invalidan el benchmark. Definen qué puede respaldar el resultado.
Arm puede afirmar razonablemente que sus sistemas probados produjeron un mayor rendimiento modelado por rack bajo los supuestos documentados. No puede convertir esa afirmación en un liderazgo universal en IA agéntica.
AMD puede señalar razonablemente las dos victorias por chip y el efecto de los supuestos de memoria. Esos puntos no eliminan la ventaja de densidad de Arm dentro del modelo publicado.
La interpretación más productiva se sitúa entre ambas posiciones. Arm ha presentado una hipótesis creíble que justifica pruebas más amplias e independientes con hardware de producción.
La hipótesis es que la potencia por rack y el rendimiento sostenido de herramientas de agentes deberían tener más peso que las comparaciones tradicionales por socket. El resultado de 1,99x es un primer estudio de caso para ese argumento.
Para los compradores, el método podría resultar tan influyente como el ganador actual. Una suite común y transparente permitiría a los operadores comparar Arm, AMD, Intel y Nvidia dentro de límites idénticos.
Una suite de este tipo necesitaría potencia del sistema medida, software equivalente, firmware documentado, ponderación por carga de trabajo y validación reproducible de extremo a extremo.
También debería informar de varias perspectivas en lugar de comprimirlo todo en una sola proporción. Los resultados por núcleo, por socket, por vatio, por rack y por dólar responden a preguntas operativas distintas.
El éxito y la latencia de las tareas deben mantenerse separados del rendimiento de infraestructura. Un sistema que completa más acciones reproducidas podría no ofrecer mejores resultados de agentes si predominan los retrasos del modelo o la red.
Tres señales decidirán si se sostiene la afirmación de Arm por rack
El hardware de producción, pruebas más amplias frente a competidores e implementaciones de clientes determinarán si la ventaja modelada de Arm se convierte en una ventaja operativa.
La primera señal son las pruebas independientes en sistemas finales de producción con CPU AGI. Signal65 indicó que los resultados actuales reflejan sistemas iniciales y que se prevé un trabajo de seguimiento más amplio.
Un seguimiento convincente debería medir la potencia completa del servidor durante cada carga de trabajo. Debería emplear sistemas operativos, configuraciones de compilador, capacidad de memoria, firmware y condiciones de refrigeración comparables.
La prueba más sólida instalaría varios servidores y validaría experimentalmente el cálculo por rack. Eso mostraría si la densidad, las redes, las condiciones térmicas y la utilización sostenida se comportan como se modeló.
Si las pruebas de producción se mantienen cerca de la media de 1,99x, la posición de Arm se reforzará considerablemente. Una caída importante mostraría que el modelado de potencia nominal sobreestimó la capacidad implementable.
La segunda señal es la comparación con un campo más amplio de procesadores. El AMD EPYC 9755 es importante, pero un único procesador x86 no puede representar todo el mercado.
Las opciones más nuevas y de mayor número de núcleos de AMD podrían cambiar el cálculo de densidad. Intel puede rendir de forma distinta en servicios web, bases de datos, recuperación de información y ejecución de herramientas.
Nvidia Vera también merece una comparación directa porque utiliza núcleos compatibles con Arm, pero apunta a la infraestructura de IA mediante un diseño de sistema diferente. Su conectividad con aceleradores crea otra vía de implementación.
Las pruebas más amplias deberían utilizar las mismas cargas de trabajo y una puntuación transparente. Las selecciones de benchmarks específicas de cada proveedor dejarían a los compradores comparando afirmaciones incompatibles.
Si Arm mantiene una ventaja por rack frente a varios competidores, su metodología ganará credibilidad más allá de un emparejamiento favorable. Si el liderazgo varía mucho, la selección de cargas de trabajo se convertirá en la historia más importante.
La tercera señal es la adopción real por clientes con datos operativos divulgados. Arm ha posicionado el CPU AGI para hyperscalers y otros grandes operadores de infraestructura de IA.
Una implementación pública debería informar del trabajo completado, la latencia, la potencia y la utilización antes y después de la migración. También debería explicar cualquier cambio de software necesario para la arquitectura Arm.
La evidencia operativa puede revelar problemas que los benchmarks no detectan. Entre ellos se encuentran la compatibilidad de dependencias, la observabilidad, la disponibilidad de imágenes de contenedor, la asignación de cargas de trabajo, la recuperación ante fallos y el esfuerzo administrativo.
Los resultados de clientes importarán más cuando cubran tráfico de producción sostenido. Las demostraciones breves no pueden reproducir el patrón de demanda de miles de agentes persistentes.
El anuncio de benchmarks de Arm de octubre de 2026 presenta un argumento claro a favor de evaluar la infraestructura a escala de rack. También afirma que la metodología debe evolucionar a medida que cambian las arquitecturas de agentes.
Esa admisión es apropiada. El software agéntico sigue siendo dinámico, y la secuencia de herramientas representativa de hoy puede convertirse mañana en un proxy obsoleto.
Los equipos de infraestructura deberían utilizar los benchmarks del CPU AGI de Arm como motivo para examinar sus propios cuellos de botella, no como un veredicto universal de adquisición.
Empiece por rastrear dónde invierte su tiempo un agente. Separe la inferencia del modelo de la recuperación, el inicio de entornos aislados, la ejecución de herramientas, el acceso a bases de datos, la orquestación y la validación.
Después, asigne esas etapas a la limitación real. Un clúster puede enfrentarse a un límite de potencia, una limitación de capacidad de memoria, falta de trabajo para los aceleradores o una latencia de tareas inaceptable.
Ese proceso puede transformar una afirmación amplia de un proveedor en una pregunta local comprobable. También evita que una media de benchmark sustituya la planificación de capacidad específica de cada carga de trabajo.
Los equipos de ingeniería que evalúan infraestructura de agentes pueden conservar notas de benchmarks, registros de configuración y hallazgos de implementación en una base de conocimiento con búsqueda. Ese registro se vuelve valioso cuando cambios de software o hardware invalidan una comparación anterior.
Arm ha establecido la posición inicial: su procesador promedió 1,20x por chip y 1,99x por rack modelado en siete cargas de trabajo seleccionadas. AMD aún ganó dos pruebas a nivel de chip, y varios supuestos determinaron la proporción más elevada.
La próxima decisión corresponde a los evaluadores independientes y a los compradores de infraestructura. ¿Reproducirán los racks de producción medidos la ventaja de densidad de Arm, o las cargas de trabajo reales reducirán la brecha?
