6 min. de lectura
Hasta dos tercios mejor relación precio-rendimiento, menos energía por operación de cálculo, hardware propio sin recargo de Nvidia: Con estas promesas impulsan AWS, Microsoft y Google sus chips en la nube de desarrollo propio. La ventaja es real y medible. Lo que oculta el cálculo es el precio del camino de vuelta.
Lo más importante en resumen
- La ventaja de precio es real: Los chips ARM propios de los hiperscalers ofrecen, según la carga de trabajo, una relación precio-rendimiento notablemente mejor que las instancias x86 clásicas, en el mejor de los casos hasta dos tercios. En los servicios scale-out, la diferencia es mayor.
- No se aplica a todo: El software x86 heredado, las cargas de trabajo HPC con bibliotecas especializadas y los productos de ISV sin licencia ARM anulan la ventaja. El descuento está sujeto a condiciones.
- El lock-in se desplaza: Cada chip es propietario. Una carga de trabajo optimizada para Graviton no funciona exactamente igual en Axion o Cobalt. Quien quiera cambiar, debe desarrollar y probar de nuevo.
Relacionado:Repatriación de la nube: cuándo compensa recuperar los datos / Corriente continua de 800 voltios en el centro de datos
Por qué los hiperscalers construyen de repente sus propios chips
Quien hoy reserva una instancia de cómputo, ya no decide únicamente entre proveedores. Decide entre arquitecturas de procesador que ningún competidor comparte: Graviton en AWS, Cobalt en Azure, Axion en Google Cloud. Tres diseños ARM propios, tres ecosistemas propios. Para los arquitectos de nube, esto desplaza una vieja pregunta a un nuevo lugar, un nivel más abajo en el stack.
El motivo detrás de los desarrollos propios es puramente empresarial. El silicio personalizado reduce la dependencia de Intel, AMD y, sobre todo, Nvidia, cuyo margen de beneficio de otro modo se incorpora al cálculo de la nube. Ahorra energía por operación de cálculo y, en centros de datos llenos, la energía es desde hace tiempo el cuello de botella más crítico que el capital. Y retiene a los clientes en tipos de instancia que solo ofrece un único proveedor. En AWS, el negocio de chips propios ha alcanzado, según estimaciones del sector, una facturación anual de dos dígitos en miles de millones.
Las generaciones se suceden a ritmo anual. AWS lanzó en junio Graviton5, un procesador ARM con 192 núcleos fabricado en el proceso de 3 nanómetros de TSMC y, según el proveedor, aproximadamente un 25 % más rápido que su predecesor. Para el entrenamiento de IA, AWS posiciona además Trainium2 como alternativa a las GPUs de Nvidia y, para ello, opera sus propios grandes conjuntos en el rango de los cientos de miles de chips.
Microsoft apuesta con Maia 200 por un acelerador de IA propio con 216 gigabytes de memoria HBM3e y, con Cobalt 200, por una CPU ARM para cargas de servidor clásicas. Google ha puesto en producción con Axion su primer procesador ARM propio en las familias de instancias C4A y N4A. Tres proveedores, la misma lógica: controlar todo por sí mismos, desde el silicio hasta el servicio.
Silicio personalizado en cifras
192 núcleos ofrece AWS Graviton5 en fabricación de 3 nanómetros, aproximadamente un 25 % más rápido que su predecesor.
hasta 2x mejor relación precio-rendimiento señala Google para la variante Axion N4A frente a instancias x86 comparables.
alrededor de un 60 % mejor eficiencia energética reporta Google para Axion frente a x86.
Dónde el descuento es real y dónde se pierde
El efecto de ahorro no es un descuento fijo. Surge allí donde el software se compila limpiamente para ARM y se escala horizontalmente. En servidores web, microservicios, cargas de trabajo de Java y MySQL, sidecars de contenedores y servicios sin estado, ARM gana en casi todas las mediciones. Google menciona hasta un 50 % más de rendimiento y una eficiencia energética un 60 % mejor frente a máquinas x86 comparables. SAP informó de ganancias significativas en el rendimiento de su base de datos HANA al usar Graviton.
El otro lado rara vez aparece en los materiales publicitarios. Bibliotecas especializadas de HPC, binarios antiguos de x86 sin compilación para ARM y software comercial de ISV cuya licencia no cubre la arquitectura devoran nuevamente el beneficio. Quien utilice una base de datos con licencia exclusiva para x86 ahorra en la instancia, pero paga por el soporte.
Además de la decisión y el ahorro hay una fase de transición que no aparece en ninguna factura. Quien migra opera ambas arquitecturas durante un tiempo paralelo: matriz de pruebas doble, imágenes base dobles, perfiles de monitoreo dobles. Esta duplicación es temporal, pero retrasa el punto de equilibrio. Los equipos que lo planifican indican el efecto de ahorro honestamente a partir del trimestre en el que se apague la carga antigua de x86.
| Tipo de carga de trabajo | Aptitud para ARM | Ventaja real de coste |
|---|---|---|
| Web, Microservicios, Sidecars | Muy alta | Máxima |
| Java, MySQL, Capa de caché | Alta | Total, tras reconstrucción |
| Binarios legados de x86 | Baja | Negativo sin portación |
| HPC con bibliotecas especializadas | Selectiva | Evaluar caso por caso |
| Software de ISV sin licencia para ARM | Bloqueado | La ventaja se pierde en el soporte |
Antes de cualquier migración, por tanto, está la inventariación de las cargas de trabajo, no una tabla de precios. ¿Cuál servicio es sin estado y listo para ARM, cuál depende de una dependencia de x86 que nadie documentó? Sobre el caso empresarial decide esta clasificación, no el precio unitario por vCPU.
El bloqueo que no figura en el contrato
Aquí está la verdadera baza. El bloqueo ya no solo está en el contrato, sino en el build. La antigua dependencia de la nube era una cuestión de transferencia de datos y servicios gestionados. El silicio personalizado introduce una segunda capa de dependencia, un nivel más profundo en el stack. Una imagen optimizada para Graviton puede funcionar en Axion o Cobalt, pero rara vez con la misma eficiencia. Los tres diseños de ARM difieren en extensiones vectoriales, jerarquía de caché y conexión de memoria. Las banderas del compilador, bibliotecas optimizadas y perfiles de carga están calibrados por familia de chips.
Quien cambia de proveedor debe reconstruir, medir de nuevo y ajustar el tuning otra vez. En la práctica, esto ocupa a un pequeño equipo durante semanas, al final la misma aplicación funciona como antes, solo en otro silicio. Exactamente estos costes de cambio le dan al proveedor la posición de negociación que parece ceder al descuento inicial.
El chip de ahorro no cuesta nada al inicio. Cuesta al salir.
El ARM en la nube sigue siendo la opción correcta para gran parte del portafolio. Peligroso es únicamente pensar que más barato sea automáticamente más libre. Quien acepta el descuento sin calcular los costes de salida intercambia una dependencia de Nvidia por una dependencia arquitectónica. Cómo esta transición se agudiza en el lado de la capacidad, lo muestra el despliegue paralelo en GPUs, que pone bajo presión a todo el equipo de plataforma.
Cómo los equipos garantizan el ahorro sin verse atados
La solución es la disciplina en la pipeline. Cinco pasos separan el caso de negocio soportable del costoso fracaso.
- Incorporar la compatibilidad con ARM temprano en la CI. Los builds multiarquitectura deben incluirse en la pipeline antes de migrar el primer trabajo productivo. Quien lo añade después paga el doble.
- Clasificar los workloads en lugar de moverlos de forma generalizada. Los stateless y listos para ARM primero, los legados y dependientes de ISV al final o incluso no.
- Incluir los costes de salida en el caso de negocio. No solo la ahorro mensual, sino también el esfuerzo necesario para migrar el workload posteriormente a otro chip o volver a x86.
- Etiquetado FinOps por arquitectura. Sin una asignación clara de costes por tipo de instancia, el efecto real permanece oculto en el postre.
- Mantener las imágenes estándar portables. Escribir contenedores e infraestructura como código de manera que el cambio de arquitectura sea una decisión de configuración, no un rebuild desde cero.
Para la mayoría de los equipos la cuestión es clara: las instancias ARM son rentables para la parte de scale-out del portafolio desde el principio, y el ahorro justifica la portabilidad. Quien planea la migración como una calle de sentido único pierde exactamente la capacidad de negociación que el competidor de los hyperscaler le debería dar.
Preguntas frecuentes
¿Qué es el silicio personalizado en la nube?
Se refiere a los procesadores que un proveedor de la nube diseña por sí mismo, en lugar de comprarlos a Intel, AMD o Nvidia. Algunos ejemplos son AWS Graviton, Microsoft Cobalt y Google Axion en el caso de las CPU, así como AWS Trainium y Microsoft Maia en los aceleradores de IA.
¿Son siempre más baratos los chips ARM en la nube?
No. La mencionada ventaja de precio solo se aplica a cargas de trabajo compatibles con ARM, como servidores web, microservicios y Java. El software x86 heredado, el HPC con bibliotecas especializadas y los productos ISV sin licencia ARM pueden resultar más caros, ya que la migración o el soporte consumen el descuento.
¿Cuánto cuesta el cambio entre Graviton, Axion y Cobalt?
Cada chip es propietario. Una carga de trabajo optimizada para una familia necesita nuevas compilaciones, nuevas pruebas y, a menudo, un nuevo ajuste de rendimiento al cambiar. El esfuerzo equivale a un pequeño proyecto de migración, no a un simple cambio de configuración.
¿Merece la pena el silicio personalizado para las pymes?
Para los servicios modernos y en contenedores, por lo general sí, ya que la migración a ARM es mínima y el ahorro se nota rápidamente. En los entornos x86 consolidados, primero merece la pena hacer un inventario de cargas de trabajo que muestre qué proporción se puede migrar sin problemas.
¿Desaparece así el x86 de la nube?
No a corto plazo. Para las cargas scale-out, ARM se convertirá en el estándar, mientras que para las cargas de trabajo especializadas de HPC y heredadas, el x86 seguirá siendo la primera opción. La mayoría de las empresas operarán ambas arquitecturas en paralelo en un futuro previsible.
Más de la red de MBF Media
Fuente de la imagen: generada por IA (Juni 2026)
