Los chips ARM personalizados para servidores están ganando terreno al dominio de x86 en los centros de datos en la nube.

Durante dos décadas, "servidor" significó x86 — un chip de Intel o AMD, ejecutando el mismo conjunto de instrucciones tanto si estaba en el centro de datos de un banco como en el rack de una startup en una instalación de colocación. Esa premisa se está desmoronando dentro de los tres grandes proveedores de nube. AWS, Google Cloud y Microsoft Azure han dedicado cada uno los últimos años a diseñar sus propios CPUs de servidor basados en Arm, y a mediados de 2026 esos chips representan una parte lo suficientemente grande de la nueva capacidad de cómputo de los hyperscalers que x86 ya no es el estándar predeterminado automático que solía ser.

Las cifras detrás del cambio

La penetración de Arm en los envíos de CPUs para servidores escaló de aproximadamente un 5% en 2020 a un rango de entre el 15% y el 23% en 2025, según analistas de semiconductores que hacen seguimiento de la categoría. La cifra más llamativa surgió de las sesiones de Computex 2026: la investigación presentada allí situó los chips basados en Arm en cerca de la mitad de la capacidad de cómputo de los hyperscalers — no el recuento de envíos, sino la capacidad desplegada real en AWS, Google y Microsoft de forma combinada. El mercado de servidores basados en Arm ha crecido de aproximadamente 5.800 millones de dólares en 2023 a una estimación de 8.200 millones en 2026.

Ese crecimiento no ha llegado a expensas de AMD, curiosamente. Las estimaciones de crecimiento en envíos de CPUs para servidores de AMD se revisaron al alza del 14% al 23% para 2026, y la propia proyección de Intel pasó de un descenso del 3% a un crecimiento del 3%. El mercado crece con suficiente rapidez como para que las ganancias de Arm y las de AMD ocurran al mismo tiempo — es la cuota de mercado heredada de Intel x86, no la arquitectura x86 en términos generales, la que más terreno está perdiendo.

Tres chips, tres apuestas distintas

AWS fue quien más lejos llegó primero. Graviton5, disponible de forma general desde el 10 de junio de 2026, integra 192 núcleos Arm Neoverse V3 distribuidos en cuatro chiplets fabricados con el proceso de 3nm de TSMC, con 192MB de caché L3, memoria DDR5 y PCIe Gen 6 — un incremento de caché cinco veces mayor que el de Graviton4 y una mejora de rendimiento declarada del 25%. AWS lo diseñó explícitamente para las cargas de trabajo de la "era de la IA agéntica": servicio de inferencia, pipelines de recuperación de información y los patrones de solicitudes intermitentes y con alta demanda de memoria que generan los agentes de IA, en lugar del cómputo por lotes clásico.

Google Axion adopta un enfoque distinto, posicionado como la mitad CPU de un par complementario junto con los racks TPU v8 de Google. Google afirma que Axion ofrece un 30% más de rendimiento que las instancias de nube Arm de la competencia y un 60% más de eficiencia energética que instancias x86 comparables — siendo la eficiencia la palabra clave, ya que la función de Axion es fundamentalmente alimentar datos hacia y desde los TPUs sin convertirse en el cuello de botella de consumo eléctrico o térmico de ese pipeline.

Microsoft Cobalt es el más discreto de los tres, pero posiblemente el más probado en producción en este momento: está ejecutando cargas de trabajo reales en regiones de Azure hoy en día, con clientes como Databricks que corren plataformas de datos en producción sobre él, no solo despliegues piloto. A diferencia de Graviton y Axion, que se apoyan en un enfoque orientado a la IA, Microsoft ha comercializado Cobalt de forma más directa como una propuesta de reducción de costes y eficiencia de uso general para el cómputo ordinario de Azure.

Por qué los hyperscalers controlan ahora su propio silicon

Diseñar un CPU para servidores desde cero no es una decisión que los proveedores de nube tomaron a la ligera — requiere años de inversión en ingeniería de chips que la mayoría de las empresas de software nunca llegan a afrontar. El beneficio es el control sobre una variable que antes residía por completo en las hojas de ruta de productos de Intel y AMD: el rendimiento por vatio a escala de centro de datos. La energía es ahora la restricción fundamental sobre cuánta capacidad de cómputo puede desplegar físicamente un hyperscaler, dados los límites de interconexión a la red eléctrica y el enorme consumo de los clústeres de entrenamiento e inferencia de IA. Un CPU diseñado internamente puede ajustarse específicamente para la combinación de cargas de trabajo que ese proveedor realmente ejecuta, en lugar del perfil de uso general al que un fabricante de chips de mercado tiene que apuntar para servir a todos.

Por eso el Grace CPU de Nvidia — un chip basado en Arm diseñado para situarse directamente junto a los GPUs de Nvidia en la misma placa — también importa aquí, aunque Nvidia no sea un proveedor de nube. Es la evidencia más clara de que la ventaja de Arm en este ciclo no es realmente una cuestión de costes de licencia del conjunto de instrucciones; se trata de qué arquitectura permite a un diseñador de chips construir exactamente la combinación de CPU, memoria e interconexión que su acelerador o carga de trabajo específica necesita, en lugar de comprar lo que Intel o AMD lanzaron ese año.

Qué significa esto para AMD, Intel y los fabricantes independientes de Arm

La aceleración del crecimiento en servidores de AMD sugiere que ha capturado cuota a costa de Intel en lugar de perder terreno frente a Arm — EPYC sigue siendo la opción x86 de mercado predeterminada para cargas de trabajo que no son ejecutadas por un hyperscaler con su propio programa de silicon. El retorno de Intel a un crecimiento positivo es una victoria menor, pero real, después de años de erosión de su cuota en servidores. La empresa que queda fuera de la tendencia del silicon cautivo de los hyperscalers es Ampere Computing, el diseñador independiente de chips Arm para servidores cuyos procesadores AmpereOne compiten directamente con Graviton y Axion por los clientes que no quieren construir su propio chip — proveedores de nube por debajo de los tres grandes, y empresas que ejecutan cargas de trabajo Arm en instalaciones de colocación en lugar de nubes hyperscaler.

Qué significa esto si estás eligiendo dónde ejecutar tus cargas de trabajo

Para los equipos de ingeniería que evalúan tipos de instancias en la nube, la pregunta práctica ha pasado de "¿es Arm lo suficientemente maduro?" a "¿qué cargas de trabajo deberían migrar primero?". Los servicios sin estado con escalado horizontal — capas web, API gateways, servicio de inferencia — tienden a obtener las ganancias más claras en precio-rendimiento sobre instancias Graviton o Axion, a menudo con un coste entre un 20% y un 40% menor para un rendimiento equivalente, siempre que tu pipeline de compilación ya produzca binarios Arm64 o tu entorno de ejecución de lenguaje abstraiga la diferencia (Go, Java y la mayoría de los lenguajes interpretados migran con cambios mínimos; las bases de código en C/C++ con intrínsecos específicos de arquitectura requieren trabajo real de portabilidad). Los chips que solían ser una optimización de costes para un subconjunto de cargas de trabajo son ahora el estándar predeterminado sobre el que AWS, Google y Microsoft quieren que se ejecute la nueva capacidad — lo que significa que hacer benchmarking de tu propia carga de trabajo sobre instancias Arm ya no es una diligencia debida opcional, sino ponerse al día con el punto en el que la infraestructura ya se encuentra.