- Axion, CPU Arm de Google, aporta més rendiment i eficiència al núvol sense reescriptures massives.
- Clústers mixts x86+Arm amb Titanium, Hyperdisk i orquestració avançada optimitzen costos.
- Google ja executa serveis com BigQuery i Spanner a Axion i accelera la migració amb IA.
Google ha mogut fitxa amb Axion, la seva família de CPU personalitzades basades en Arm per a centres de dades, i l'impacte va molt més enllà d'un canvi de silici: afecta rendiment, eficiència, seguretat, costos i com es despleguen aplicacions a escala. En un context on la IA, les dades i els microserveis marquen el pas, l'estratègia no és només tècnica; també és operativa i de negoci.
La companyia està integrant Axion en producció al costat de servidors x86, habilitant clústers de múltiples arquitectures que conviuen en serveis propis (com BigQuery, Spanner o YouTube Ads) i en Google Cloud. Amb xifres ambicioses —fins a un 30% més de rendiment davant instàncies Arm comparables i fins a un 50% sobre x86, a més de fins a un 60% de millora en eficiència energètica—, s'obre una etapa en què l'elecció de CPU s'alinea amb la càrrega, el cost i la sostenibilitat.
Què és Axion i per què ara
Axion és la primera CPU de Google per al data center dissenyada sobre Arm, construïda sobre Arm Neoverse V2 i l'arquitectura Armv9. El seu propòsit és donar servei a càrregues d‟ús general i de dades, així com a treballs d‟IA basats en CPU, reduint la dependència de proveïdors tradicionals i encaixant amb la tendència del sector cap a infraestructures optimitzades.
Google afirma que Axion estarà disponible per a clients de Google Cloud i, de fet, ja l'utilitza internament a BigTable, Spanner, BigQuery, Blobstore, Pub/Sub, Google Earth Engine i la plataforma publicitària de YouTube. La promesa clau és que els clients puguin moure aplicacions a Arm amb canvis mínims gràcies a estàndards i interoperabilitat pensats per al núvol.
Una peça distintiva és titani, un sistema de microcontroladors de silici personalitzat que descarrega operacions de plataforma (xarxa, seguretat) i el processament d'E/S d'emmagatzematge cap a Hyperdisk. Amb aquestes tasques fora del camí, les CPU Axion poden dedicar més recursos al còmput de les càrregues de lusuari, millorant latència i throughput.
El moviment es recolza en un ecosistema Arm que ja està madur al núvol: Android, Kubernetes, TensorFlow o Go han rebut optimitzacions per a Arm, i Google ha contribuït a estàndards com SystemReady VE, que faciliten que sistemes operatius i paquets habituals s'executin en servidors i màquines virtuals Arm sense friccions.
Arquitectura, seguretat i disseny del sistema
Dins del disseny, diverses fonts internes esmenten que Axion es fabrica en 5 nm i que combina nuclis d'alt rendiment i d'eficiència (amb referències a configuracions de fins a 128 nuclis i freqüències de fins a 3.8 GHz en nuclis de rendiment), alineat amb el full de ruta Armv9. La meta: maximitzar el rendiment per watt i el paral·lelisme en càrregues multi-fil.
En vectorització i processament multimèdia/científic, Armv9 aporta instruccions SVE2, amb escalat SIMD flexible per accelerar inferència de ML, analítica i processament de dades. Els toolchains moderns (Clang/LLVM, GCC) generen binaris nadius ARM64, reduint o eliminant la necessitat d'emulació per als contenidors i millorant així el rendiment real.
El pla de seguretat d'Axion és un altre pilar: PAC (Pointer Authentication) i Memory Tagging Extension ajuden a mitigar classes d'atacs com ara overflow o use-after-free, afegint mitigacions a nivell de maquinari. La plataforma integra arrencada verificada (Secure Boot) i suport TPM 2.0, a més de xifrat AES-256 en trànsit i en repòs, amb mòduls que compleixen estàndards com FIPS 140-2.
La xarxa i l'emmagatzematge s'han pensat per donar servei a clústers heterogenis amb backbons d'alta velocitat (fins a 400 Gbps), commutació de baixa latència i el filesystem distribuït Colossus actuant com a capa d'abstracció. A la pràctica, aquestes peces redueixen el “peatge” entre nodes x86 i Arm, mantenint consistència i disponibilitat.
Rendiment i eficiència: números i comparatives
Segons dades compartides per Google, Axion aconsegueix fins a un 30% més de rendiment davant instàncies Arm d'ús general líders al núvol i fins a un 50% més de rendiment que instàncies x86 comparables de generació actual. Tot això amb fins a un 60% de millora en eficiència energètica davant de x86, una palanca clau per a costos i objectius de sostenibilitat.
En mètriques de negoci, en documents recents s'ha citat que moure càrregues a Axion es pot traduir en fins a un 65% de rendiment per preu davant x86 per a determinades càrregues internes, cosa que explica part de l'empenta per migrar aplicacions de producció a Arm dins de Google.
Per ubicar-hi diferències, l'ecosistema x86 aporta AVX-512 en vectorització i un llegat enorme de programari; Arm ofereix SVE2, eficiència superior i un rendiment multifil molt competitiu. La combinació en un mateix clúster permet assignar treballs legacy a x86 i càrregues modernes o altament paral·lelitzables a Arm.
Més enllà de benchmarks sintètics, el canvi es nota a treballs reals dús general (servidors web, microserveis), bases de dades open source, caixets en memòria, analítica de dades i tasques d'IA basades en CPU: compilar codi, preprocessar dades, executar inferències lleugeres i coordinar pipelins de ML.
Clústers multiarquitectura: com conviuen x86 i Arm
El gran salt no és només el xip, és l?operació. Google executa clústers amb nodes x86 i Arm sota un pla de control unificat inspirat en Borg (precursor de Kubernetes). El programador assigna càrregues en funció de cost, latència, CPU disponible i, per descomptat, compatibilitat binària.
A Kubernetes, l'heterogeneïtat es resol amb afinitats de node i selectors, de manera que els pods destinats a Arm es planifiquen en nodes compatibles. Els manifests poden incloure constraints per arquitectura i recursos i l'observabilitat (Prometheus, Grafana) s'adapta per llegir mètriques en entorns mixtos.
Per facilitar desplegaments, es contemplen imatges multi-arquitectura i, quan no hi ha binaris nadius, es pot recórrer a QEMU per emulació dinàmica. Tot i així, la recomanació per a producció amb càrrega sostinguda és compilar nadiu ARM64 per esprémer Axion sense sobrecost.
L'autoescalat aprofita la diversitat: si un microservei d'IA basat en CPU puja en demanda, l'orquestrador el pot moure a nodes Axion i jugar amb instàncies de cost variable (per exemple, espot), mantenint SLOs i reduint factura quan és possible.
Models de preu i serveis: com pagar menys sense complicar-se
Google Cloud ofereix diverses vies per entrar: n'hi ha una opció d'inici gratuït per començar sense cost i provar serveis, cosa que ajuda a validar compatibilitat i rendiment de forma segura.
El model més habitual és pagament per ús (pay-as-you-go): pagues només pel que consumeixes, sense pagaments avançats ni penalitzacions per cancel·lació. Els preus canvien segons configuració, ús i regió, i Google remet a la documentació per al detall.
En còmput, se citen instàncies c4a-highcpu amb un preu de partida al voltant de 0.03787 USD per hora, amb opcions d'estalvi que poden assolir percentatges elevats (p. ex. trams de fins al 55% i fins al 91% en determinats compromisos o modalitats).
En emmagatzematge, hi ha diverses famílies amb preus des del primer GB per mes: Disc persistent a partir de 0.048 USD/GB/mes, Hyperdisk des de 0.125 USD/GB/mes i SSD local des de 0.08 USD/GB/mes. Hyperdisk desacobla rendiment de la mida de la instància i es pot proveir de forma dinàmica en temps real.
En xarxa, el nivell Standard utilitza Internet pública per al trànsit entre els teus serveis i usuaris. Les entrades són gratuïtes i les sortides són gratuïtes fins a 200 GB/mes. El nivell Premium enruta sobre la xarxa troncal de Google i parteix des de 0.08 USD per GB de sortida (les entrades segueixen sense cost).
IA, ciberseguretat i tecnologies distribuïdes
En intel·ligència artificial, Axion accelera inferències i tasques d'entrenament lligades a CPU gràcies a SVE2 ia biblioteques optimitzades (ONNX Runtime sobre Neon, toolchains nadius ARM64). En entorns de grans models, pot reduir latència en pas de dades, preprocessament i orquestració.
En seguretat, la diversitat arquitectònica afegeix defensa en profunditat: un incident en x86 no implica necessàriament exposició a nodes Arm, especialment amb segmentacions VPC, RBAC i controls d'identitat. PAC i MTE sumen mitigacions a baix nivell, i el compliment es recolza en xifratge AES-256 i certificacions de mòduls criptogràfics.
Per blockchain i sistemes distribuïts, la eficiència energètica d'Arm i la seva relació rendiment/watt afavoreixen validadors i nodes complets. En proves internes s'han vist millores de throughput en transaccions de smart contracts compilats per a ARM64, cosa que impacta tant en costos com en sostenibilitat.
En regulatori, Google referència GDPR, HIPAA i NIST SP 800-53 com a marcs sobre els quals articula controls; eines com Binary Authorization verifiquen firmes de contenidors abans del desplegament, i la traçabilitat facilita auditories en entorns híbrids.
La migració massiva interna: 30.000 paquets i una IA anomenada CogniPort
Google ha mogut al voltant de 30.000 paquets de producció cap a Arm i planifica completar la conversió perquè les seves càrregues internes s'executin tant a Axion com a x86. Serveis com YouTube, Gmail i BigQuery ja funcionen sobre les dues arquitectures.
Al preprint «Instruction Set Migration at Warehouse Scale» i publicacions tècniques es detalla el procés: els equips esperaven problemes de punt flotant, concurrència i dependències específiques, però la realitat va ser més manejable gràcies a compiladors moderns i sanititzadors.
Les primeres migracions (F1, Spanner, Bigtable) van tirar de enginyeria metòdica: sprints setmanals, ajustaments de sistemes de build/release i refactor de proves acoblades a suposicions x86. El coll d'ampolla més habitual va estar a test suites envellides i pipelins de desplegament.
Per escalar, Google va desenvolupar CogniPort, una IA que genera commits i corregeix compilacions o proves. En condicions concretes aconsegueix arranjaments automàtics al voltant del 30% dels casos, especialment en proves fràgils, condicionals per plataforma i problemes de representació de dades.
L'objectiu és que Borg pugui programar càrregues segons cost i rendiment entre servidors Arm i x86. Si Axion redueix el cost per unitat de treball i millora l'eficiència, el planificador inclinarà la balança cap a Arm quan tingui sentit sense sacrificar SLOs.
Comparativa tècnica x86 vs Arm al núvol
En nuclis individuals, x86 sol oferir gran rendiment single-thread gràcies a freqüències elevades i àmplia memòria cau; Arm compensa amb més densitat de nuclis i eficiència superior, oferint un multifil molt sòlid per a microserveis i analítica distribuïda.
En instruccions vectorials, x86 aporta AVX-512 en escenaris HPC/ML específics, mentre que Arm SVE2 escala amples SIMD i treu partit de pipelins molt paral·lels. L'elecció depèn del perfil de workload i de si s'optimitza les llibreries natives de cada ISA.
En seguretat de maquinari, x86 compta amb SGX per a enclavaments, mentre que Arm destaca amb PAC/MTE per enfortir memòria i punters. En conviure a la mateixa malla de serveis, la superfície d'atac es diversifica, cosa que complica l'explotació sistemàtica.
En compatibilitat, x86 gaudeix d'un ecosistema legacy molt assentat; Arm creix ràpid en contenidors i Linux, i els artefactes multiarch, més QEMU quan no hi ha binari nadiu, suavitzen l'aterratge.
Casos d'ús en indústria i patrons d'adopció
Empreses intensives en dades en temps real —com Uber o Spotify— han avaluat o mogut càrregues cap a Arm per cost i eficiència, especialment en serveis elàstics i pipelins de streaming que es beneficien de CPU denses i d'alt paral·lelisme.
En ciberseguretat, alguns proveïdors (per exemple, simulacions d'amenaces) aprofiten l'heterogeneïtat per reduir l'evasió basada en fingerprints de maquinari. Canviar d'ISA complica els atacants i aporta senyals addicionals en detecció d'anomalies.
A IA distribuïda, l'aprenentatge federat i els recomanadors de baixa latència treuen partit del mix de CPU eficient, xarxa d'alta velocitat i emmagatzematge desacoblat. Frameworks com Flower s'alineen bé amb clústers híbrids.
Per a equips DevOps, Google documenta rutes de migració i gcloud CLI amb suport per a imatges Arm, a més de compatibilitat preliminar a “Migrate to Virtual Machines” per moure instàncies a la nova arquitectura amb fricció reduïda.
Eines, bones pràctiques i operació diària
La recomanació per a plataformes amb microserveis és afegir proves multi-arquitectura a CI/CD (Jenkins, GitHub Actions) per detectar incompatibilitats d'hora. Matrius per arquitectura/OS redueixen sorpreses en producció.
El profiling amb perf a Linux i traces a eBPF ajuda a identificar serveis candidats per a Arm (alt paral·lelisme, hotspots de CPU) ia mesurar benefici real. Incloure KPIs de cost/latència/consum elèctric als dashboards guia decisions de scheduling.
Per a IA basada en CPU, biblioteques com Arm Compute Library i toolchains LLVM/GCC actualitzats desbloquegen optimitzacions. En contenidors, utilitzar multi-arch manifests i etiquetar imatges adequadament evita estrebades al scheduler.
En compliment i cadena de subministrament, enfortir Binary Authorization, SBOM i firmes de contenidors garanteix que la diversitat d'arquitectures no obri bretxes. Escàners i polítiques d'admissió han d'incloure regles per arquitectura.
La supervisió continua amb Falc o altres motors de seguretat en temps real afegeix una capa dinàmica per detectar anomalies en nodes heterogenis, mantenint una postura coherent entre x86 i Arm.
Amb Axion, Google està marcant una adreça clara: xips Arm personalitzats, offloads com Titanium, xarxes troncals premium i un enfocament pragmàtic de multiarquitectura que barreja el millor de l'ecosistema x86 amb l'eficiència d'Arm. En posar els números sobre la taula —rendiment, cost, energia— i divulgar mètodes (com la IA CogniPort i les guies de migració), el missatge per a equips tècnics és nítid: hi ha un camí realista per aprofitar Arm a gran escala sense reescriure-ho tot i amb eines que escurcen el viatge.