Google

Google y Oracle anunciaron el martes que los Tensor Processing Units (TPU) de octava generación de Google —el silicio especializado en IA que impulsa todos los modelos principales de la compañía, desde Gemini hasta sus más recientes desarrollos de frontera— estarán disponibles en Oracle Cloud Infrastructure (OCI) a partir de 2027. Será la primera vez, en los 11 años de historia de este chip, que una empresa podrá acceder a los aceleradores de IA diseñados por Google sin tener que adoptar Google Cloud.

El anuncio, realizado durante Oracle AI World 2026 en el Venetian Convention and Expo Center de Las Vegas, tiene una implicación que va más allá de la novedad del producto: la exclusividad del hardware está dejando de ser la principal ventaja competitiva de Google. El verdadero bloqueo de las plataformas de IA se está trasladando hacia los ecosistemas de software y la concentración de los datos: hacia los equipos que ya dominan JAX o TorchTPU y hacia las empresas cuyos datos de entrenamiento ya están alojados en las bases de datos de Oracle.

El entrenamiento y la inferencia son problemas distintos; por eso Google creó chips diferentes

La cartera de TPU de octava generación de Google se divide en dos arquitecturas, cada una diseñada para una fase específica del ciclo de vida de la IA. Esta separación —el TPU 8t para entrenamiento y el TPU 8i para inferencia— probablemente será la decisión de diseño que más influirá en la forma en que los clientes empresariales implementen estos chips en OCI, ya que ambas opciones implican diferencias importantes en densidad de cómputo, memoria y topología de interconexión.

El TPU 8t está diseñado para el entrenamiento de modelos a gran escala, tanto de arquitecturas densas como de mezcla de expertos (MoE). Un superpod de 9.600 chips ofrece 121 exaFLOPS de cómputo máximo en FP4 y 2 PB (petabytes) de memoria compartida de alto ancho de banda en todo el pod. Cada chip aporta 12,6 petaFLOPS de cómputo FP4, 216 GB de memoria HBM3e con un ancho de banda de 6.528 GB/s y 19,2 Tbps de ancho de banda bidireccional de expansión. Google afirma que el 8t ofrece una relación precio-rendimiento para entrenamiento 2,7 veces superior a Ironwood; como ocurre con todas las afirmaciones de los proveedores, esta cifra debe considerarse no verificada hasta que sea auditada de forma independiente.

El TPU 8i está optimizado para la inferencia en producción, específicamente para el razonamiento de varios pasos, los marcos agénticos y las aplicaciones de contexto largo que definen la manera en que la mayoría de las empresas utiliza los modelos de IA ya terminados. Cada chip ofrece 10,1 petaFLOPS de cómputo FP4 y 288 GB de HBM3e con un ancho de banda de 8.601 GB/s, en una configuración de pod de 1.152 chips y con 384 MB de SRAM integrada para almacenar activaciones rápidamente. Google asegura que el 8i ofrece un rendimiento por dólar 80 % superior para inferencia de baja latencia frente a Ironwood; nuevamente, se trata de una cifra del proveedor que requiere verificación independiente antes de orientar decisiones de compra.

SparseCore apunta al cuello de botella de las incrustaciones que limita a los modelos de mezcla de expertos

El TPU 8t incorpora un componente dedicado en el chip, llamado SparseCore, que aborda uno de los cuellos de botella más persistentes en el entrenamiento de modelos de recomendación y MoE a gran escala: la consulta de tablas de incrustaciones.

Las tablas de incrustaciones —estructuras de datos que asignan tokens o comportamientos de usuarios a vectores numéricos— se consultan mediante patrones irregulares y no secuenciales, difíciles de procesar para las operaciones de matrices densas que normalmente optimizan los TPU. En las arquitecturas MoE, un mecanismo de enrutamiento selecciona qué subconjunto de capas de "expertos" procesa cada entrada, lo que genera patrones de acceso a memoria igualmente irregulares que la memoria HBM estándar maneja con lentitud.

SparseCore procesa las consultas irregulares de incrustaciones en hardware dedicado, en lugar de enviarlas a través del mismo arreglo sistólico que ejecuta las operaciones matemáticas densas. Así, la principal estructura de cómputo queda disponible para las operaciones tensoriales en las que ofrece su mejor rendimiento. Para las empresas que entrenan grandes sistemas de recomendación, modelos publicitarios o arquitecturas MoE avanzadas, la presencia de SparseCore en el 8t es una capacidad de hardware relevante, no un detalle secundario.

La topología Boardfly reduce a la mitad los saltos de red para ofrecer IA agéntica con baja latencia

La característica arquitectónica distintiva del TPU 8i es su topología de interconexión, que Google denomina Boardfly. Mientras el TPU 8t utiliza una topología de toro tridimensional —que conecta los chips en una malla a lo largo, ancho y alto—, el TPU 8i emplea un diseño de bajo diámetro que reduce en 50 % los saltos frente a un toro 3D estándar a la misma escala.

La consecuencia práctica es una menor latencia. En un toro 3D con 1.024 chips, una operación de comunicación colectiva —el all-reduce o all-gather que sincroniza los datos entre chips durante la inferencia— puede requerir 16 saltos de red. Boardfly reduce esa cifra a siete saltos en una configuración de 1.024 chips, disminuyendo la latencia de sincronización que limita el rendimiento en cargas de inferencia de varios pasos.

Esto es importante para la IA agéntica. La inferencia de una sola consulta —un usuario hace una pregunta y el modelo responde— tolera una latencia relativamente alta por token. La inferencia agéntica, en la que un modelo razona en varios pasos, utiliza herramientas, evalúa resultados intermedios y continúa el proceso, es mucho más sensible a la latencia acumulada. Una topología que reduce el costo de sincronización de cada salto se traduce directamente en mayor rendimiento para las cadenas de razonamiento de varios pasos que las empresas están desarrollando.

El 8i también incorpora el Collectives Acceleration Engine (CAE), un bloque dedicado que reduce cinco veces la latencia de sincronización frente a las operaciones colectivas gestionadas por software. En conjunto, Boardfly y CAE otorgan al 8i un perfil de latencia fundamentalmente distinto al del 8t. Por eso los dos chips pertenecen a pods diferentes y una implementación empresarial en OCI podría ejecutar ambos de forma simultánea para cargas de trabajo distintas dentro de la misma organización.

La conmutación óptica de circuitos mantiene operativos los pods de entrenamiento de 9.600 chips pese a fallas de hardware

Un pod de entrenamiento de 9.600 chips es lo suficientemente grande como para que una falla de hardware no sea un caso excepcional, sino un evento previsible. Cualquier chip, cable, transceptor óptico o conmutador de la infraestructura puede fallar durante una ejecución de entrenamiento que dure semanas. Sin recuperación activa ante fallas, un solo componente averiado puede detener todo el trabajo.

Google aborda este problema con la conmutación óptica de circuitos (OCS), una tecnología basada en MEMS que redirige dinámicamente el tráfico de interconexión alrededor de las fallas en tiempo real, sin exigir el reinicio del trabajo. OCS cubre 144 racks y 8.960 TPU dentro de un mismo pod, y la infraestructura de conmutación se reconfigura varias veces al día durante las ejecuciones de entrenamiento en producción. Google informa que los pods equipados con OCS mantienen un goodput de 97 % en las ejecuciones de entrenamiento, lo que significa que más de 97 % del tiempo de cómputo disponible se dedica al entrenamiento efectivo del modelo y no a operaciones de recuperación.

La comunicación entre chips TPU se realiza mediante la Inter-Chip Interconnect (ICI), un protocolo propietario que ofrece a cada chip un ancho de banda equivalente al de un conmutador y elimina la sobrecarga de las pilas de red convencionales. ICI opera dentro del pod; la infraestructura de centros de datos Virgo de Google —una red plana de dos capas y sin bloqueos— gestiona la comunicación entre pods y admite más de 134.000 TPU en un mismo dominio de enrutamiento, con más de 47 Pb/s de ancho de banda de bisección. JAX y el sistema de orquestación Pathways de Google pueden ampliar las ejecuciones de entrenamiento coordinadas a más de un millón de TPU en esta infraestructura.

Oracle aporta energía, refrigeración y redes Zero Trust; Google aporta el silicio

En el acuerdo con OCI, Oracle suministra la capa de infraestructura física: energía, refrigeración y redes de centros de datos. Para los clientes, esto significa que Oracle asume el reto de ingeniería de desplegar chips que requieren refrigeración líquida directa a escala de rack, un compromiso importante de capital.

"Con el tiempo, esto representará para Oracle una inversión en la nube de escala de gigavatios", dijo Karan Batta, vicepresidente sénior de Oracle Cloud Infrastructure, durante Oracle AI World 2026. "Cuando Google lance un nuevo TPU, lo tendremos desde el primer día", añadió Batta, al describir el acuerdo como una alianza de varios años y varios gigavatios.

La plataforma de redes de alto rendimiento de Oracle, Acceleron, conecta los clústeres de TPU con el resto de la infraestructura de cómputo y almacenamiento de OCI. Acceleron utiliza DPU AMD Pensando, aislamiento de usuarios a nivel de hardware, Zero Trust Packet Routing (ZPR) y una infraestructura de alto rendimiento compatible con enlaces de 400G y 800G mediante protocolos ópticos LPO y LRO. La infraestructura se basa en RoCEv2 y permite el acceso remoto directo a memoria para cargas de trabajo de gran ancho de banda.

La proximidad a la infraestructura de bases de datos de Oracle es relevante para los clientes empresariales. Las organizaciones que utilizan Oracle como sistema de registro pueden ejecutar cargas de ajuste fino o inferencia sobre sus datos existentes sin asumir costos de transferencia entre nubes, un gasto real que con frecuencia se subestima en las implementaciones de IA multinube.

La escala de infraestructura existente de OCI ofrece un contexto relevante: OCI Zettascale10 admite 800.000 GPU de NVIDIA y 16 zettaFLOPS de cómputo máximo, y sirve de base para el superclúster Stargate de Oracle y OpenAI. La incorporación de los TPU de Google les da a los clientes de OCI acceso a silicio de IA especializado dentro del mismo perímetro de seguridad y la misma relación de facturación que utilizan para sus cargas de trabajo con GPU.

¿Está listo el ecosistema de software de TPU para equipos que no trabajan con Google Cloud?

El ecosistema de software de los TPU se ha ampliado considerablemente desde que los chips estuvieron disponibles por primera vez en Google Cloud, en 2018. Los TPU de octava generación son compatibles con JAX, vLLM, SGLang y Ray, además de Hugging Face Transformers, TorchTitan y LiteRT.

La integración con PyTorch merece una atención especial. La plataforma TorchTPU de Google, que ofrece una vía nativa de PyTorch para ejecutar cargas en TPU, cuenta con tres modos de ejecución eager: Debug, para desarrollo; Strict, para ejecuciones de producción validadas; y Fused Eager, que ofrece una mejora de rendimiento de entre 50 % y 100 % o más frente a los modos eager básicos. La ruta de compilación estándar pasa por torch.compile, luego por XLA y finalmente por StableHLO, preservando la compatibilidad con el código existente de los modelos de PyTorch.

Es importante señalar que TorchTPU ya está disponible públicamente en GitHub, después de que Google liberara su código como software de código abierto durante PyTorch Conference 2026, el 20 de octubre de 2026. Los equipos que evalúen la compatibilidad de sus bases de código de PyTorch con TPU pueden acceder directamente al repositorio en github.com/google-pytorch/torch_tpu y contribuir a un proyecto bajo licencia Apache 2.0.

Para los equipos que no trabajan con Google Cloud, la barrera restante es práctica más que técnica: el dominio de JAX. Las empresas cuyos equipos de aprendizaje automático tienen experiencia en PyTorch o TensorFlow pueden acceder a los TPU mediante los puentes de frameworks mencionados, pero el potencial completo de rendimiento de la arquitectura —incluidos SparseCore, la infraestructura ICI y la orquestación Pathways— se aprovecha con mayor facilidad mediante JAX. Las organizaciones que planeen inversiones importantes en TPU deberían incluir en sus cálculos el costo de desarrollar esa experiencia.

La llegada de los TPU a una nube rival indica un cambio de una ventaja basada en hardware a otra basada en software

El contexto competitivo del anuncio del martes es relevante. Amazon tiene Trainium e Inferentia. Microsoft cuenta con Maia 200. Meta desarrolla sus aceleradores MTIA. Los tres representan programas de silicio especializado para uso interno: los chips ejecutan cargas de trabajo de esas compañías, pero ninguna empresa externa puede acceder a ellos. Ninguna ha puesto su silicio especializado a disposición del mercado, lo que convierte el acuerdo de Google con OCI en el primero de su tipo entre los grandes hyperscalers.

Por eso, la decisión de Google de llevar sus TPU de octava generación a Oracle Cloud Infrastructure no tiene un precedente directo entre los principales proveedores de nube. La pregunta más interesante para el mercado de infraestructura de IA es qué indica esta decisión sobre el lugar hacia el que se está trasladando la ventaja competitiva de la nube de IA.

Las declaraciones públicas de los directivos de Google Cloud indican que la compañía considera el acceso a los TPU una posible fuente de ingresos más allá de su propia nube. Analistas de Morgan Stanley han estimado que los despliegues externos de TPU podrían representar una expansión significativa de los ingresos de Google, aunque esas cifras siguen siendo especulativas y no han sido verificadas por las divulgaciones de la propia compañía.

La señal más profunda es arquitectónica, no comercial. Durante una década, el TPU fue la ventaja de hardware de Google: las empresas que querían utilizarlo tenían que adoptar Google Cloud, y esa dependencia las acercaba a los datos, las herramientas y los servicios de Google. Llevar el chip a Oracle Cloud no elimina esa atracción —JAX, Pathways y el resto de la pila de software aún requieren conocimientos de Google—, pero desvincula el chip de la nube. Si la ventaja ahora reside en el ecosistema de software y en los equipos que han invertido en él, y no en el hardware físico, la estrategia de Google consiste en ampliar la adopción mediante cualquier canal de distribución disponible, con la certeza de que la familiaridad con el software es más difícil de replicar.

Amin Vahdat, vicepresidente sénior y director tecnológico de IA e infraestructura de Google, es miembro de la ACM y de la NAE. Su trabajo en infraestructura —incluidas sus contribuciones a la arquitectura de redes definidas por software B4 de Google y la coautoría del lenguaje de programación P4 para planos de datos de red programables— sustenta directamente parte de la tecnología de redes ICI y Virgo desplegada en estos pods. "La próxima generación de IA requerirá una gama diversa de capacidades de cómputo", dijo Vahdat en el anuncio del martes. "Llevar los TPU de Google a OCI dará a más organizaciones acceso a esta tecnología y mayor flexibilidad para desarrollar y ejecutar sus aplicaciones de IA más complejas".

Preguntas frecuentes

¿Cuándo estarán disponibles los TPU de Google en Oracle Cloud Infrastructure?

Los TPU de Google estarán disponibles en OCI a partir de 2027, según el anuncio de Oracle durante Oracle AI World 2026. Karan Batta, de Oracle, describió un compromiso de varios años y varios gigavatios, y afirmó que Oracle tendrá disponibles las futuras generaciones de TPU desde el primer día de su lanzamiento. La capacidad inicial de despliegue no se ha especificado públicamente, aunque la referencia de Batta a varios gigavatios indica un compromiso que va mucho más allá de un programa piloto.

¿Tengo que reescribir mi código existente de PyTorch o TensorFlow para ejecutarlo en los TPU de Google?

No necesariamente. La plataforma TorchTPU de Google ofrece una vía nativa de PyTorch para ejecutar cargas en TPU, incluido un modo Fused Eager que proporciona una mejora de rendimiento de entre 50 % y 100 % o más frente a la ejecución eager estándar. También son compatibles Hugging Face Transformers, vLLM, SGLang y Ray. TorchTPU se liberó como código abierto el 20 de octubre de 2026, durante PyTorch Conference 2026, y ahora está disponible públicamente en GitHub. Los flujos de trabajo de mayor rendimiento —en particular los que utilizan SparseCore, la infraestructura ICI y la orquestación entre varios pods— son más accesibles mediante JAX. Los equipos que planeen inversiones importantes en TPU deberían contemplar el desarrollo de conocimientos en JAX.

¿Qué diferencia hay entre el TPU 8i y el TPU 8t, y cómo sé cuál necesita mi carga de trabajo?

El 8t está destinado al entrenamiento: prioriza el rendimiento bruto de cómputo —9.600 chips por superpod y 121 exaFLOPS FP4—, una memoria compartida amplia —2 PB por superpod— y el acelerador SparseCore para entrenar modelos MoE y de recomendación. El 8i está diseñado para la inferencia: prioriza la baja latencia mediante la topología Boardfly, que reduce los saltos de red en más de 50 %, y el Collectives Acceleration Engine, que reduce cinco veces la latencia de sincronización, en un pod de 1.152 chips orientado a servicios de producción. Si su carga de trabajo consiste en desarrollar y entrenar modelos de forma iterativa, necesita el 8t. Si consiste en ofrecer un modelo terminado a escala, especialmente un sistema agéntico o de razonamiento de varios pasos, necesita el 8i.

Si la ventaja competitiva de Google ahora está en el software y no en el hardware, ¿llevar los TPU a Oracle Cloud mejora o empeora mi posición de negociación?

Depende de qué tan profundamente utilice su organización la pila de Google. Las empresas que accedan a los TPU mediante OCI seguirán dependiendo de Google para la infraestructura ICI/Virgo, JAX, Pathways y TorchTPU: la capa de software e interconexión que permite que los TPU rindan a escala. Oracle proporciona la infraestructura física y el perímetro de seguridad. Este acuerdo ofrece a los compradores más opciones en la cadena de suministro —contratos multinube de Oracle frente a contratos de Google Cloud—, pero no elimina las dependencias técnicas de Google. Los equipos que desarrollen un dominio profundo de JAX a cambio de las ventajas de rendimiento de los TPU estarán cambiando una forma de dependencia por otra. Ese intercambio puede valer la pena para cargas de trabajo en las que las ventajas de rendimiento de los TPU sean grandes y duraderas, pero debe asumirse con plena conciencia y no presentarse simplemente como una diversificación de compras.