El rack de IA agéntica AMD Helion adopta una vía abierta para escalar
AMD presentó el rack de IA agéntica AMD Helion con una respuesta distinta a la carrera por la infraestructura: no todas las tareas de IA pertenecen a una GPU. El nuevo diseño de la compañía puede alojar hasta 32.768 núcleos de CPU en un solo rack. Otra configuración combina CPU y GPU para empresas que desean ejecutar agentes e inferencia de modelos en un mismo sistema.
La distinción importa porque los agentes de IA hacen más que generar tokens. Recuperan registros, invocan herramientas, ejecutan código, consultan bases de datos, gestionan estados y coordinan flujos de trabajo. La inferencia de modelos sigue siendo importante, pero representa solo una parte de esa cadena. AMD apuesta a que una capacidad de CPU densa y configurable merece su propia arquitectura a escala de rack.
La comparación con Nvidia es inevitable. La plataforma Vera Rubin de Nvidia integra CPU, GPU, redes, almacenamiento y software en una fábrica de IA estrechamente coordinada. Helion, en cambio, pone el énfasis en estándares abiertos y componentes específicos para cada carga de trabajo. La cuestión central es si los clientes preferirán la modularidad de AMD o la integración de Nvidia cuando los despliegues de agentes pasen a producción.
El rack de IA agéntica AMD Helion separa la ejecución de la inferencia
Helion convierte el trabajo que rodea a un modelo de IA en un problema de infraestructura de primera clase.
AMD anunció Helion el 12 de octubre de 2026 y lo describió como un diseño abierto de rack para IA agéntica. El diseño utiliza estándares del Open Compute Project y procesadores, aceleradores, redes y software de AMD. Socios del ecosistema están desarrollando sistemas basados en la especificación, cuya disponibilidad está prevista para noviembre de 2026.
El anuncio de AMD Helion describe dos configuraciones principales. Una versión solo con CPU está dirigida a hiperescaladores, neoclouds y operadores de IA soberana. Una versión empresarial combina nodos de CPU, GPU, almacenamiento, bases de datos y computación técnica en un solo rack.
La configuración solo con CPU puede contener hasta 32.768 núcleos de procesadores AMD EPYC 9006 Series de sexta generación. AMD posiciona esos núcleos como capacidad para ejecutar agentes, en lugar de alojar los modelos más grandes. El rack puede conectarse a sistemas de aceleradores independientes que gestionan la inferencia de modelos.
Este diseño desagregado separa distintos tipos de trabajo en infraestructura especializada. La desagregación implica situar la ejecución y la inferencia en sistemas distintos, en lugar de tratarlas como un único bloque de computación inseparable. Los grandes operadores pueden combinar racks de CPU Helion con clústeres de GPU existentes, incluidos los sistemas AMD Helios.
La configuración empresarial de AMD sigue otra vía. Combina blades de CPU EPYC con hasta 16 GPU AMD Instinct MI350P. Esos aceleradores se distribuyen en dos servidores independientes de ocho GPU, en lugar de formar un único dominio de escalado vertical para todo el rack.
Esta diferencia define las expectativas para el producto. Helion no es una alternativa a un clúster de entrenamiento de frontera. Está diseñado para ejecutar agentes, enrutar solicitudes, servir modelos seleccionados y respaldar las bases de datos que utilizan esos agentes.
El rack también puede incluir blades de propósito general para almacenamiento, servicios de datos y computación técnica. Estos sistemas de apoyo son importantes porque un agente de producción rara vez opera únicamente mediante llamadas a modelos. Debe leer permisos, mantener memoria, buscar datos corporativos y registrar acciones.
AMD enumera hasta 102 terabits por segundo de ancho de banda de red para el diseño. Los clientes pueden elegir refrigeración por aire o refrigeración líquida directa, según su configuración. El sistema físico utiliza un rack ORv3 de 21 pulgadas con 44 unidades Open Rack.
Helion también incluye un enrutador de tokens integrado. Un enrutador de tokens dirige una solicitud de modelo hacia un punto de inferencia adecuado. Ese punto puede ser un modelo de frontera en la nube o un modelo abierto ejecutándose dentro del rack.
El enrutador extiende el argumento modular de AMD al software. Una empresa puede reservar modelos costosos para solicitudes difíciles y enviar el trabajo predecible a modelos locales. El concepto resulta atractivo, aunque AMD no ha publicado benchmarks de producción que muestren los efectos del enrutador en coste, latencia o calidad.
Por tanto, Helion cambia la unidad de competencia. AMD no presenta otro procesador de servidor o acelerador individual. Organiza CPU, GPU, redes y servicios de apoyo en torno al ciclo de vida completo de una tarea de agente.
Por qué la IA agéntica está creando un nuevo mercado para las CPU
La carrera por la infraestructura de agentes se está expandiendo más allá de las GPU porque la inferencia de modelos no ejecuta un flujo de trabajo completo.
Un chatbot suele enviar una solicitud a un modelo y devolver una respuesta. Un agente puede generar un plan, buscar en varios sistemas, invocar herramientas externas, evaluar los resultados y revisar su enfoque. Una solicitud de usuario puede desencadenar muchas operaciones independientes.
Esas operaciones generan demanda de CPU. Los contenedores de herramientas deben iniciarse, la lógica de aplicaciones debe ejecutarse y las bases de datos deben responder consultas. Las políticas de seguridad deben comprobarse durante todo el proceso. Un acelerador de modelos puede generar tokens rápidamente sin sustituir esas funciones circundantes.
Los agentes de código ofrecen un ejemplo útil. El modelo propone un cambio, pero otro sistema descarga el repositorio e instala dependencias. Puede compilar software, ejecutar pruebas, inspeccionar registros y enviar un prompt revisado. Estos pasos exigen computación de propósito general, memoria, almacenamiento y acceso a redes.
Los agentes de atención al cliente crean un patrón similar. Pueden recuperar registros de cuentas, comprobar inventario, actualizar tickets de soporte y solicitar autorización para acciones sensibles. El modelo de lenguaje guía la interacción, mientras que los sistemas convencionales realizan gran parte del trabajo real.
AMD clasifica las cargas de trabajo de agentes en categorías personales, empresariales y técnicas. Los agentes personales priorizan el número de agentes por vatio. Los despliegues empresariales necesitan un rendimiento equilibrado entre muchos usuarios simultáneos. Los agentes técnicos necesitan núcleos más rápidos para tareas como compilación y simulación.
Las opciones de blades de CPU de Helion reflejan esas diferencias. Los blades densos utilizan procesadores de 256 núcleos configurados a 400 vatios. Los sistemas equilibrados también ofrecen 256 núcleos, con un punto de operación de 600 vatios. Los blades de rendimiento utilizan 96 núcleos de mayor frecuencia que alcanzan los 5,0 GHz.
Se trata de objetivos de configuración, no de una prueba del rendimiento de las aplicaciones. El número de núcleos por sí solo no puede predecir con qué rapidez un agente completa una tarea. El diseño del software, el acceso a memoria, la latencia de las herramientas, el tiempo de respuesta del modelo y la contención de red pueden dominar el resultado.
Aun así, la arquitectura refleja un cambio más amplio del mercado. Nvidia presentó un rack Vera CPU independiente con 256 procesadores para cargas de trabajo agénticas. La compañía afirma que sus CPU respaldan entornos, aprendizaje por refuerzo, procesamiento de datos y otras tareas que rodean la inferencia de GPU.
Intel también apunta a esta categoría. Su estrategia de 2026 a escala de rack combina procesadores Xeon con aceleradores SambaNova para inferencia y cargas de trabajo de agentes. Por separado, Intel promueve sistemas desagregados que pueden utilizar distintos tipos de aceleradores.
Esta actividad competitiva respalda la premisa de AMD. La IA agéntica está creando un mercado para infraestructura más allá del rack de aceleradores. El desacuerdo se refiere a cuán estrechamente deberían vincular los clientes esos componentes.
La oportunidad para las CPU no reduce la importancia de las GPU. Surge de su uso creciente. Más llamadas a modelos crean más orquestación, movimiento de datos y ejecución de aplicaciones alrededor de esas llamadas.
Para AMD, esto ofrece otra vía hacia los centros de datos de IA. Nvidia ha controlado gran parte del mercado de aceleradores mediante su hardware GPU y el software CUDA. AMD puede competir en aceleradores mientras también defiende la presencia de servidores x86 ya instalada en los sistemas empresariales.
Helion convierte esa ventaja de base instalada en una propuesta a nivel de rack. Los clientes pueden ejecutar una mayor parte del flujo de trabajo circundante en procesadores EPYC. Después pueden dirigir las llamadas a modelos hacia GPU de AMD, otro acelerador local o un servicio externo.
El caso de negocio sigue dependiendo de la carga de trabajo. Una empresa que ejecute asistentes de recuperación simples quizá no necesite un rack dedicado. Un hiperescalador que opere miles de agentes simultáneos se enfrenta a un cálculo diferente. Helion se dirige al punto en el que esas operaciones de fondo se convierten en un problema de planificación de capacidad.
El diseño abierto de AMD desafía la fábrica de IA integrada de Nvidia
La competencia principal no es AMD frente a Nvidia en un solo benchmark; es infraestructura modular frente a una plataforma coordinada verticalmente.
La plataforma Vera Rubin de Nvidia combina varios sistemas diseñados específicamente para este fin. Su cartera incluye racks de GPU Rubin, racks de CPU Vera, redes, unidades de procesamiento de datos e infraestructura de almacenamiento. Nvidia diseña estos elementos para que funcionen juntos como una gran fábrica de IA.
Esta integración puede simplificar la ingeniería de rendimiento. Un proveedor controla los procesadores, las interconexiones, la arquitectura del sistema y gran parte del software. Los clientes obtienen una ruta de despliegue definida y una comunicación optimizada entre componentes.
El mismo enfoque aumenta la dependencia de la plataforma. Sustituir una capa se vuelve más difícil cuando el diseño presupone hardware y software de Nvidia en todo el sistema. Los compradores también tienen menos margen para combinar infraestructura existente con componentes de varios proveedores.
AMD Helion promete lo contrario. Utiliza un formato de rack del Open Compute Project y se presenta como un diseño que los fabricantes pueden adaptar. AMD planea contribuir la especificación a la organización para su desarrollo por parte de la comunidad.
El proyecto Open Rack proporciona especificaciones mecánicas y de alimentación compartidas para equipos de centros de datos. Helion cita ORv3, DC-MHS, DC-SCM, HPRv2, OCP NIC 3.0 y Caliptra en diferentes capas. Estos estándares cubren áreas como dimensiones de rack, hosts modulares, gestión, alimentación, redes y seguridad de hardware.
Este nivel de cumplimiento importa más que añadir una etiqueta de apertura a un gabinete. Las interfaces estandarizadas pueden permitir a los fabricantes construir blades, sistemas de alimentación y componentes de gestión compatibles. También pueden reducir la ingeniería necesaria para adaptar un rack a un cliente específico.
AMD ha reunido a un grupo sustancial de fabricantes. Dell, Foxconn, HPE, Lenovo, QCT, Supermicro y Wiwynn figuran entre los partidarios anunciados. Cisco también respalda el enfoque más amplio de infraestructura.
La amplitud de los socios ayuda a que Helion parezca creíble como diseño. No establece la demanda de los clientes. Muchos de los mismos fabricantes construyen sistemas de Nvidia, y los respaldos públicos no revelan volúmenes de despliegue comprometidos.
Nvidia también describe MGX como una arquitectura de sistema abierta respaldada por una amplia red de fabricantes. Por tanto, la elección es más matizada que AMD abierto frente a Nvidia cerrado. Ambas compañías distribuyen diseños de referencia a través de fabricantes de equipos.
La diferencia reside en dónde concentra cada plataforma el control. Nvidia construye en torno a su tejido de aceleradores, su pila de redes, sus procesadores y su entorno de software. AMD pone mayor énfasis en configuraciones intercambiables e interfaces OCP consolidadas.
La opción de Helion solo con CPU deja esta diferencia especialmente clara. Un hiperescalador puede desplegar capacidad de ejecución de agentes por separado de su flota de inferencia. La flota de aceleradores no necesita ocupar el mismo rack ni utilizar el mismo ciclo de renovación.
Esa separación ofrece flexibilidad operativa. La capacidad de CPU puede crecer cuando la ejecución de herramientas se convierte en un cuello de botella. La capacidad de GPU puede crecer cuando aumenta el tráfico de modelos. Cada grupo puede seleccionarse y sustituirse según su propia economía.
También genera trabajo de coordinación. Los operadores deben gestionar redes, colocación, programación, observabilidad y manejo de fallos entre sistemas separados. Un diseño abierto puede ofrecer más opciones, al tiempo que traslada una mayor responsabilidad de integración al cliente.
La configuración empresarial reduce esa carga al reunir CPU y GPU MI350P. Sin embargo, sus dos nodos GPU operan de forma independiente. Helion carece de la interconexión de escalado vertical para todo el rack utilizada en sistemas diseñados para los modelos más grandes.
AMD afirma que esto es intencional porque el rack está dirigido a agentes empresariales, no al entrenamiento de modelos de frontera. Esa explicación es coherente con la arquitectura. También define un límite que los compradores deben comprender.
Helion puede ejecutar modelos abiertos de forma local, pero no está diseñado para convertir 16 GPU en un único acelerador gigante. Las cargas de trabajo que requieren un dominio GPU unificado corresponden a infraestructuras como AMD Helios o los racks GPU de Nvidia. El papel de Helion es la coordinación, la ejecución y determinadas tareas de inferencia.
Por tanto, el rack de IA agéntica AMD Helion pide a los compradores aceptar una disyuntiva. Obtienen modularidad y varias vías de despliegue. A cambio, deben determinar qué cargas de trabajo corresponden a cada componente y gestionar los límites entre ellos.
Cómo AMD Helion distribuye distintas cargas de trabajo de agentes
El mecanismo clave de Helion es la colocación de cargas de trabajo, que asigna cada etapa de una tarea de agente a un recurso de cómputo adecuado.
Pensemos en un agente empresarial de investigación al que se le pide evaluar a un proveedor. El agente primero interpreta la solicitud y desarrolla un plan. Después busca documentos internos, consulta sistemas empresariales, lee fuentes externas y calcula indicadores de riesgo.
Un modelo en la nube podría encargarse del paso inicial de planificación. Un modelo local podría clasificar documentos recuperados que contienen información confidencial. Los nodos CPU podrían ejecutar servicios de búsqueda, bases de datos, análisis sintáctico y cálculo. Los sistemas de almacenamiento proporcionarían los registros utilizados durante todo el proceso.
El router de tokens puede dirigir solicitudes individuales de modelos entre esos destinos. Se parece a un controlador de tráfico para la inferencia, pero la decisión tiene más peso que un simple equilibrio de carga. Los distintos modelos varían en calidad, latencia, privacidad, capacidad de contexto y coste operativo.
Por ejemplo, una tarea rutinaria de extracción podría dirigirse a un modelo compacto dentro del rack. Una solicitud de razonamiento difícil podría enviarse a un servicio de frontera. Los datos sensibles podrían mantenerse localmente incluso si el modelo local tarda más.
AMD no ha revelado suficientes detalles para evaluar esas decisiones de enrutamiento. El anuncio no proporciona mediciones públicas sobre la precisión o la sobrecarga de selección de rutas. Tampoco explica cómo los administradores auditan una solicitud que pasa entre varios modelos.
Estas cuestiones cobran importancia en entornos regulados. Una capa de enrutamiento debe respetar la ubicación de los datos, los derechos de acceso y las políticas de modelos aprobados. También debe generar registros que expliquen qué endpoint procesó cada solicitud.
El enrutamiento de modelos representa solo una capa de programación. La plataforma también debe colocar las tareas no relacionadas con modelos que lanza un agente. Algunos trabajos favorecen muchos núcleos eficientes, mientras que las tareas técnicas requieren menos núcleos con mayor rendimiento monohilo.
Los tres perfiles de procesador de AMD abordan esta variación. Una blade densa maximiza la capacidad concurrente. Una blade equilibrada proporciona más potencia con el mismo número de núcleos. Una blade de alta frecuencia apunta al código sensible a la latencia y a la computación técnica.
El rack empresarial añade nodos de inferencia MI350P junto a esas opciones de CPU. Por ello, puede respaldar un flujo de trabajo sin enviar cada solicitud de modelo fuera del sistema. Este diseño puede resultar atractivo para organizaciones con requisitos de gobierno de datos o latencia.
Las blades de propósito general completan la arquitectura. Admiten las bases de datos, los servicios de almacenamiento y las aplicaciones técnicas de los que dependen los agentes. Es un reconocimiento práctico de que una plataforma de agentes depende de sistemas empresariales, no solo de modelos.
Los flujos de trabajo intensivos en conocimiento ilustran esta conexión. Un trabajador podría utilizar una base de conocimiento personal para encontrar contexto relevante antes de pedir a un agente que actúe. A escala organizativa, ese mismo patrón requiere controles de identidad, servicios de recuperación, bases de datos y acciones trazables.
Los desarrolladores no deberían asumir que la infraestructura resolverá un diseño deficiente de los agentes. Más núcleos no pueden solucionar permisos poco claros, herramientas poco fiables o un comportamiento de los modelos mal evaluado. Helion puede aportar capacidad, pero las aplicaciones siguen necesitando límites y vías de recuperación.
En su lugar, los compradores deberían mapear el flujo de trabajo completo. Deben medir el tiempo dedicado a la inferencia de modelos, la ejecución de herramientas, la recuperación, la espera y la validación. Esas mediciones determinan si tiene sentido un rack centrado en CPU, un sistema mixto o los servidores existentes.
Aquí es donde el argumento de AMD se vuelve comprobable. Si los agentes en producción pasan un tiempo considerable fuera de la inferencia de modelos, Helion ofrece a los clientes una forma de escalar ese trabajo de manera independiente. Si predomina la inferencia, los sistemas centrados en aceleradores siguen siendo más convincentes.
Lo que las especificaciones no demuestran
Helion es un diseño de referencia en desarrollo, por lo que sus cifras más altas describen capacidad, no resultados de producción verificados.
La cifra destacada de 32.768 núcleos es fácil de entender. No es una métrica del rendimiento de agentes. Un cliente necesita conocer las tareas completadas por vatio, el tiempo por flujo de trabajo, la latencia de los modelos, las tasas de fallo y la utilización bajo tráfico real.
Los materiales de producto de AMD hablan de maximizar los agentes por vatio y el rendimiento por agente. Aún no proporcionan resultados estandarizados para esas medidas. Sin una definición de carga de trabajo, la palabra “agente” no puede funcionar como una unidad de referencia consistente.
Un agente podría clasificar un correo electrónico breve. Otro podría ejecutar una suite de pruebas de software de 30 minutos. Un tercero podría coordinar cientos de llamadas a herramientas y varios modelos. Contar cada uno como un agente ocultaría enormes diferencias de trabajo.
AMD tampoco ha publicado una comparación completa entre Helion y filas convencionales de servidores. La densidad del rack puede reducir las necesidades de espacio, pero concentra los requisitos de energía, refrigeración y red. Los operadores deben evaluar el impacto sobre toda la instalación.
La cifra de red de 102 Tbps necesita un contexto similar. La capacidad agregada de la red no revela el rendimiento de las aplicaciones. Los patrones de tráfico, la configuración de los switches, la sobrecarga de los protocolos, el acceso al almacenamiento y las llamadas a modelos externos afectan al rendimiento observado.
La disponibilidad es otra cuestión abierta. AMD afirma que las configuraciones de sus socios están en desarrollo y se prevén para noviembre de 2026. Eso deja un breve periodo entre el anuncio y el lanzamiento esperado. Los modelos específicos, la disponibilidad regional, los plazos de certificación y los despliegues de clientes siguen sin estar claros.
Una corrección de fecha informada por Tom’s Hardware ilustra esa volatilidad. El medio recibió inicialmente indicaciones que apuntaban a 2027 y luego actualizó el calendario después de que AMD revisara la disponibilidad a noviembre de 2026. Los compradores deberían confirmar directamente los plazos de entrega con los socios de sistemas.
La madurez del software presenta otro riesgo. La apertura del hardware no crea automáticamente una experiencia operativa coherente entre fabricantes. El firmware, las herramientas de orquestación, la observabilidad, los controles de seguridad y las prácticas de soporte pueden variar entre implementaciones.
El router de tokens necesita un escrutinio especial. El enrutamiento entre modelos en la nube y locales puede mejorar el uso de recursos, pero los errores pueden afectar a la calidad o al gobierno de datos. Las empresas necesitan políticas que anulen las decisiones automatizadas cuando la información tenga restricciones de residencia o confidencialidad.
Tampoco existe todavía evidencia pública de que las organizaciones quieran un único rack empresarial mixto para todos los servicios de agentes. Algunos compradores ya operan clústeres GPU compartidos y amplias flotas x86. Podrían preferir la orquestación por software entre esos recursos existentes en lugar de un despliegue dedicado de Helion.
Nvidia genera presión competitiva desde la otra dirección. Vera Rubin entró en producción plena antes del anuncio de Helion. Nvidia afirma que su plataforma conecta racks diseñados específicamente para CPU, GPU, almacenamiento y redes dentro de un sistema coordinado.
Estas son afirmaciones propias de Nvidia sobre rendimiento y adopción, y las comparaciones requieren pruebas reproducidas de forma independiente. Aun así, la disponibilidad del producto y la integración de software pueden pesar más que la flexibilidad arquitectónica. Un cliente no puede desplegar la apertura como una cualidad abstracta.
Intel añade más incertidumbre para AMD. Su base Xeon ya es habitual en los centros de datos, y está promoviendo soluciones de rack agénticas con múltiples aceleradores. Por tanto, Helion debe imponerse tanto a la infraestructura x86 existente como a la plataforma integrada de Nvidia.
La versión más sólida del caso de AMD no depende de afirmar una superioridad universal. Depende de demostrar que una clase medible de cargas de trabajo de agentes se beneficia de una capacidad de ejecución separada. Los resultados públicos de clientes importarán más que el recuento máximo de núcleos.
Tres señales mostrarán si la estrategia de AMD funciona
El éxito de Helion dependerá de sistemas entregados, resultados reproducibles de cargas de trabajo y clientes que usen su diseño modular en la práctica.
La primera señal es la disponibilidad en noviembre. Dell, HPE, Lenovo, Supermicro, QCT, Foxconn y Wiwynn deben convertir sus declaraciones de apoyo en configuraciones que se puedan pedir. Los compradores deberían vigilar las especificaciones completas, las regiones de entrega, los términos de servicio y la orientación de certificación.
Los sistemas entregados a tiempo reforzarían la afirmación de AMD de que la colaboración basada en OCP puede acortar el camino del diseño al producto. Los retrasos o una disponibilidad limitada sugerirían que el anuncio llegó antes de que el ecosistema estuviera preparado.
La segunda señal son las evaluaciones comparativas a nivel de aplicación. AMD y sus socios deben informar sobre tareas de agentes completadas, distribuciones de latencia, consumo energético y utilización en flujos de trabajo realistas. Las pruebas deberían separar el tiempo de modelo de la ejecución de CPU, la recuperación, el almacenamiento y las redes.
Las comparaciones más útiles incluirían servidores convencionales, el rack Helion solo con CPU y su configuración empresarial mixta. También deberían definir claramente cada flujo de trabajo. Un resultado genérico de “agentes por vatio” aportaría poco valor sin complejidad de tareas y controles de calidad.
Las pruebas independientes reforzarían esos resultados. También ayudarían a los compradores a comparar Helion con los racks CPU Nvidia Vera, los despliegues Intel Xeon y la infraestructura orquestada por software que ya está en producción.
La tercera señal es cómo los clientes utilizan la desagregación. Un hyperscaler que combine Helion con varias plataformas de aceleradores validaría el argumento central de AMD. Demostraría que la ejecución de agentes puede convertirse en una capa de infraestructura escalada de forma independiente.
La adopción empresarial pondría a prueba una premisa distinta. Los compradores deben demostrar que combinar la ejecución de CPU y una inferencia GPU limitada dentro de un rack simplifica el despliegue. Si usan Helion solo como cómputo denso de propósito general, su posicionamiento específico para agentes parecerá menos distintivo.
El rack de IA agéntica AMD Helion entra en el mercado con una idea arquitectónica creíble. Los flujos de trabajo de agentes contienen más que inferencia de modelos, y esas operaciones circundantes necesitan una infraestructura considerable. AMD ha diseñado un rack en torno a esa observación.
Sin embargo, el diseño es solo el movimiento inicial. Su valor dependerá de lo bien que los socios integren los componentes y de la claridad con que los clientes midan los resultados. Los estándares abiertos pueden ampliar las opciones, pero no eliminan el trabajo de construir una plataforma de agentes fiable.
Para los desarrolladores y compradores empresariales, la acción inmediata es sencilla. Analicen flujos de trabajo completos antes de seleccionar hardware. Midan dónde invierten tiempo los agentes, qué datos deben permanecer locales y dónde se producen los fallos. Después, comparen el enfoque modular de Helion con alternativas integradas utilizando esos requisitos. Si los sistemas de noviembre llegan con benchmarks transparentes y despliegues reales, AMD contará con evidencia de que la informática agéntica necesita una capa diferenciada a escala de rack.
