--- title: "Google acelera el salto a Arm: 30.000 apps internas ya corren en Axion y x86 a la vez gracias a automatización y IA" description: "Google ha dado un paso de gigante en su estrategia multi-arquitectura . Tras el anuncio de Axion , sus primeros CPUs Arm® diseñados a medida , la compañía ha explicado cómo ha conseguido que decenas d..." url: https://revistacloud.com/google-acelera-el-salto-a-arm-30-000-apps-internas-ya-corren-en-axion-y-x86-a-la-vez-gracias-a-automatizacion-y-ia/ date: 2025-10-24 modified: 2025-10-24 author: "Nota de Prensa" image: https://revistacloud.com/wp-content/uploads/2024/04/google-axion-arm-chip.jpg categories: ["Seguridad"] tags: ["AMD", "Arm", "Axion", "eficiencia", "google cloud", "intel", "x86"] type: post lang: es --- # Google acelera el salto a Arm: 30.000 apps internas ya corren en Axion y x86 a la vez gracias a automatización y IA Google ha dado un paso de gigante en su estrategia **multi-arquitectura**. Tras el anuncio de **[Axion](https://revistacloud.com/google-chip-axion-arm/)**, sus primeros **CPUs Arm® diseñados a medida**, la compañía ha explicado cómo ha conseguido que **decenas de miles de aplicaciones internas** se compilen y se ejecuten **simultáneamente en x86 y en ARM** dentro de sus clústeres de producción. No es un experimento: **YouTube, Gmail o BigQuery** ya sirven tráfico en **ambas ISAs** en paralelo, con **hardware Arm saturado de uso** y **más servidores desplegándose cada mes**. El incentivo es claro. Según datos de Google, las instancias basadas en Axion ofrecen **hasta un 65 %** mejor **precio-rendimiento** y son **hasta un 60 %** **más eficientes energéticamente** frente a instancias comparables dentro de Google Cloud. Llevado a escala de centro de datos, esa mejora multiplica el impacto: menor factura energética y **más capacidad utilizable por vatio** para clientes y servicios de primera parte. ## Migrar a “multiarch” a escala de almacén: lo que *no* fue el problema El relato técnico desmonta algunas suposiciones frecuentes. Antes de empezar, tanto el equipo **multiarch** como los equipos de aplicación asumían que las grandes piedras serían las **diferencias de arquitectura**: deriva en **coma flotante**, **concurrencia**, **intrinsics** vectoriales, operadores específicos, o brechas de **rendimiento** difíciles de cerrar. No fue así —o, al menos, no en la magnitud esperada—. En las primeras migraciones de servicios **“top”** (como **F1**, **Spanner** o **Bigtable**), los ingenieros encontraron casos reales de esas diferencias, pero **muchos menos de lo previsto**. Las herramientas modernas —**compiladores** y **sanitizers**— habían “sacado a la luz” una buena parte de los sustos con el paso de los años. **La mayor fricción estaba en otro sitio**: - **Tests sobreajustados a x86** que asumían timings o detalles de plataforma. - **Sistemas de build y release muy antiguos** que no contemplaban variantes Arm. - **Configuraciones** de despliegue que no entendían un **mismo servicio** corriendo en dos ISAs. - **Riesgo operativo** al tocar **sistemas críticos** en producción. Un ingeniero lo sintetizó así: *“Todo el mundo se obsesionó con la toolchain totalmente diferente, y ‘seguro que todo se rompe’. La mayor parte de la dificultad fue **configs** y cosas aburridas”*. ## El reto no era migrar “los grandes”: era el **long tail** Mover una docena de *jobs* críticos con squads dedicados y reuniones semanales **funciona**, pero **no escala**. Aunque aproximadamente **el 60 %** del cómputo en ejecución está en las **50 aplicaciones** más grandes, en un monorepo con **más de 100.000 aplicaciones** el uso del resto queda en una **“larga cola”** bastante plana. Si la meta es que **Borg** (el orquestador interno) **encaje los trabajos eficientemente** en **celdas** con x86 y Arm, **cuantos más jobs sean multiarch, mejor**. La única forma viable: **automatización**. Google lo aborda con un conjunto de **herramientas** —algunas ya muy usadas antes del proyecto— y con un **agente de IA** de nueva hornada para cerrar la brecha. ### Automatización: commits masivos, validación y despliegues sin “mano humana” - **Rosie**: genera **commits a gran escala** y los “pastorea” por el flujo de revisión. Ejemplo: activar el **modo Arm** en el *Blueprint* de un *job* con una línea de configuración. - **Sanitizers y fuzzers**: detectan **diferencias de ejecución** entre x86 y Arm antes de llegar a producción (por ejemplo, **data races** ocultas por el modelo de memoria **TSO** de x86), evitando comportamientos **no deterministas** en la recompilación. - **CHAMP (Continuous Health Monitoring Platform)**: marco automatizado para **desplegar y monitorizar** *jobs* multiarch. Si un *job* **crashea** en Arm o baja el throughput, **se evacua automáticamente** para afinado *offline*, sin arriesgar la salud del clúster. Con estos mimbres, el equipo empezó a “industrializar” la migración. ## 38.156 commits y tres fases: tooling, código, configuración Para entender **qué clase de cambios** exigía la migración a escala, Google analizó **38.156 commits** en su monorepo **Google3** —en total, **unos 700.000** líneas cambiadas—. Con **Gemini Flash** y una ventana de **1 millón de tokens**, clasificó los cambios en **16 categorías** agrupadas en cuatro grandes bloques y trazó su **evolución temporal**: 1. **Herramientas y adaptación de tests**: al poner en marcha la *toolchain* multiarch, la **gran mayoría** de commits fueron ajustes de **tooling** y **tests**. 2. **Adaptación de código**: en la migración de las primeras aplicaciones grandes, creció el peso de **cambios de código** (correcciones en dependencias compartidas, *ifdefs* por plataforma, representación de datos, etc.). 3. **Configuración y procesos**: en la fase final, **casi todo** eran **archivos de configuración** y **procesos de soporte**; además, el número de commits **se disparó**, señal del **escalado** al resto del repositorio. Un detalle relevante: **la mayoría** de commits relacionados con la migración fueron **pequeños**. Los más voluminosos se debían, sobre todo, a **listas o configuraciones** grandes, no a cambios intrincados en un único fichero. ## La IA entra en escena: CogniPort, un agente para “arreglar” builds y tests Para atacar el **remanente** —ese **long tail** de apps que aún no compilan o no pasan sus tests en Arm— Google ha construido **CogniPort**, un agente de **IA generativa** orientado a **automatizar** el resto de la migración. **Cómo funciona**: CogniPort opera sobre los **errores de build y de test**. Si una librería, binario o test **no compila** o **falla**, el agente **interviene** e intenta **arreglarlo** sin intervención humana. Por dentro, implementa **tres bucles agénticos anidados**: - Un **orquestador** que invoca a los otros dos agentes. - Un **build-fixer** que compila un objetivo y **modifica archivos** hasta que **construye** (o se da por vencido). - Un **test-fixer** que ejecuta un test y **modifica archivos** hasta que **pasa** (y, si hace falta, llama al **build-fixer**). En pruebas con **commits históricos** (245 casos de *Code & Test Adaptation* revertidos a propósito), **sin *prompts* especiales**, el agente fue capaz de **arreglar fallos de test en un 30 %** de los casos. Sus puntos fuertes: **tests**, **condicionales por plataforma** y **ajustes de representación de datos**. Es un punto de partida: la compañía espera **mejorar** con optimizaciones adicionales. ## Axion + multiarch: implicaciones para Google… y para el sector - **Elasticidad a otra escala**: si el *scheduler* puede **colocar la misma carga** en **x86 o Arm** según disponibilidad y coste, **sube la ocupación media** de los clústeres y **baja el coste efectivo** por servicio. - **Sostenibilidad**: con **hasta un 60 %** de mejora en **eficiencia energética** frente a instancias comparables, el impacto agregado en **consumo** y **emisiones** es significativo. - **Menos dependencia ISA-proveedor**: diseñar aplicaciones **multiarch por defecto** reduce el **riesgo tecnológico** y **abre el abanico** de hardware posible (Axion hoy, otros Arm mañana), sin rehacer software. - **Cambios culturales**: la migración ha mostrado que la **fricción** real estaba en **tests, *builds* y *pipelines***. Esa capa —a menudo “invisible”— es la que conviene **diseñar para la portabilidad**. ## ¿Qué significa para clientes de Google Cloud? Aunque el post se centra en **infraestructura interna**, las conclusiones **sí** salpican al cliente: - **Más opciones de instancia** con mejor **precio-rendimiento** y **eficiencia** (Axion), sin sacrificar compatibilidad si el software está **multiarch-ready**. - **Mejor TCO** en cargas elásticas, *microservicios* y *data plane* que aprovechen la **flexibilidad de scheduler** entre ISAs. - Una **guía** de cómo abordar migraciones realistas en **organizaciones grandes**: empezar por **tooling/tests**, automatizar *builds* y *rollouts*, y usar IA **como multiplicador**, no como sustituto de ingeniería. ## Qué viene ahora: “multiarch por defecto” Google planea usar **automación** para atacar **decenas de miles** de apps pendientes y ha fijado la política de **“multiarch by default”** para **nuevas aplicaciones**. Las piezas estructurales —**monorepo visible**, *tooling* multiarch, **automatismos** como Rosie y **CHAMP**— están en su sitio. Con **CogniPort** tomando el relevo del “último kilómetro”, el objetivo declarado es llevar los **servicios en producción** hacia una **neutralidad de arquitectura** más estricta. La lectura de fondo para el sector es clara: **la migración de ISA ya no es ciencia ficción**, es **operación industrial**. El foco —al menos en esta experiencia— no está en “traducir” vectores o ajustar ensamblador, sino en **domesticar la periferia**: **tests, *builds*, *configs*, *pipelines***. Y ahí la **IA generativa** puede ser el **obrero incansable** que faltaba. --- ## Preguntas frecuentes **¿Qué son los procesadores Google Axion y qué aportan frente a instancias comparables?** **Axion** son CPUs **Arm** diseñadas por Google para sus centros de datos. Según la compañía, ofrecen **hasta un 65 %** mejor **precio-rendimiento** y **hasta un 60 %** más de **eficiencia energética** que **instancias comparables** en Google Cloud, manteniendo compatibilidad de software cuando las aplicaciones son **multiarch**. **¿Cómo funciona CogniPort, el agente de IA para portabilidad de ISA?** **CogniPort** se activa cuando **falla** una **compilación** o un **test** en Arm. A través de **bucles agénticos** (orquestador, *build-fixer* y *test-fixer*), **edita** archivos de código, *build scripts* o *configs* y **reintenta** hasta que el objetivo **compila** o el test **pasa**. En pruebas iniciales con commits históricos, **solucionó** un **30 %** de fallos de test sin *prompting* adicional. **¿Cuántas aplicaciones ha portado Google y cuáles corren ya en producción multiarch?** Google afirma haber migrado **más de 30.000 aplicaciones** a **Arm**, con servicios como **YouTube**, **Gmail** o **BigQuery** **sirviendo tráfico** en **x86 y Arm** **a la vez**. El **hardware Arm** está **plenamente utilizado** y se **despliega** más capacidad mes a mes. **¿Dónde estuvieron los mayores problemas de la migración multiarch?** Contra lo esperado, **no** en las diferencias “profundas” de ISA, sino en **tests sobreajustados a x86**, **sistemas de *build* antiguos** y **configuraciones** que no contemplaban **variantes por arquitectura**. La **automatización** —Rosie, **sanitizers/fuzzers**, **CHAMP**— y la **IA** han sido clave para **industrializar** el proceso. --- **Fuentes**: Entrada técnica de **Google Cloud** (“Using AI and automation to migrate between instruction sets”) y preprint “Instruction Set Migration at Warehouse Scale”; cobertura divulgativa en **El Chapuzas Informático** sobre la migración a **Axion/Arm** y el uso de **IA** en el proceso. vía: [cloud.google](https://cloud.google.com/blog/topics/systems/using-ai-and-automation-to-migrate-between-instruction-sets/)