Saltar al contenido

Project Suncatcher ejecuta una inteligencia artificial en órbita: qué demuestra y qué falta

noviembre 6, 2026
Satélite con paneles solares y un módulo de computación de inteligencia artificial comunicándose con una estación terrestre

Google ha conseguido que una TPU de clase centro de datos ejecute un modelo de inteligencia artificial en órbita y envíe su primera respuesta a la Tierra. El hito forma parte de Project Suncatcher, un programa de investigación que estudia si, en el futuro, sería posible construir infraestructura de computación espacial alimentada por energía solar.

La prueba confirma algo concreto pero limitado: el hardware sobrevivió al lanzamiento, se encendió en el espacio y ejecutó una inferencia con Gemma 4. No demuestra todavía que un centro de datos orbital sea viable, rentable o escalable. Quedan por resolver la refrigeración en el vacío, la radiación, las comunicaciones de alta capacidad, el mantenimiento y el coste de enviar equipos a órbita.

Índice

Qué ha conseguido Project Suncatcher

Google informó el 30 de octubre de 2026 de que había completado el primer “Hello World” del proyecto. Durante un contacto con la estación terrestre, el equipo envió una instrucción al satélite, ejecutó Gemma 4 en una TPU instalada a bordo y recibió una respuesta generada en órbita. Según el anuncio oficial del experimento, después se probaron otras instrucciones y consultas sobre la telemetría del sistema.

El prototipo había sido lanzado el 1 de octubre en la misión compartida Transporter-18. Google comunicó entonces que había establecido contacto y que el satélite funcionaba como estaba previsto. Antes de generar la primera respuesta, el equipo completó tareas de puesta en servicio, encendió el ordenador anfitrión y las bandejas de TPU y ejecutó pruebas iniciales de aprendizaje automático.

Este resultado es una demostración de funcionamiento, no una medida de rendimiento. Google no ha publicado todavía latencia completa, consumo por tarea, temperaturas sostenidas, tasa de errores ni comparación con una instalación terrestre equivalente. Tampoco ha demostrado que varios satélites puedan trabajar como un único sistema distribuido. Esos son precisamente algunos de los objetivos de las fases siguientes.

Por qué llevar computación de inteligencia artificial al espacio

Los centros de datos terrestres necesitan grandes cantidades de electricidad, refrigeración, terreno y conexiones de red. En una órbita adecuada, los paneles solares pueden recibir luz durante gran parte del tiempo. Google estima que podrían producir hasta ocho veces más energía que un panel equivalente instalado en la superficie terrestre, al evitar la noche, parte de la atmósfera y determinadas pérdidas.

Project Suncatcher imagina constelaciones compactas de satélites con aceleradores TPU, paneles solares y enlaces ópticos. En vez de enviar todos los datos a un único vehículo, el trabajo se repartiría entre muchas unidades conectadas mediante láser. El objetivo a largo plazo sería disponer de una capacidad de cálculo que pudiera crecer añadiendo módulos, de forma parecida a un centro de datos distribuido.

La motivación energética no elimina los problemas ambientales. Fabricar y lanzar satélites consume materiales y combustible; las constelaciones afectan a la gestión del tráfico espacial y generan riesgo de residuos. Una comparación rigurosa tendría que incluir todo el ciclo de vida: fabricación, lanzamiento, sustitución, operaciones, comunicaciones y retirada al final de la misión.

En la Tierra, el consumo tampoco es una cifra fija. Los operadores pueden desplazar cargas, pactar reducciones temporales y acercar instalaciones a fuentes renovables. Nuestro análisis sobre demanda eléctrica flexible en centros de datos explica por qué la relación entre computación y red energética depende de contratos, ubicación y momentos de máxima demanda.

El reto de refrigerar una TPU en el vacío

El espacio es frío en términos de radiación de fondo, pero no ofrece aire para transportar el calor. En la Tierra, ventiladores, agua y torres de refrigeración mueven energía térmica desde los chips hacia el entorno. En el vacío no hay convección: el calor debe viajar por el propio hardware hasta radiadores que lo emiten en forma de radiación infrarroja.

Esto limita la densidad de potencia. Un chip puede alcanzar rápidamente una temperatura peligrosa si el sistema no extrae el calor al mismo ritmo que lo genera. Google ha ensayado tuberías de calor y radiadores en cámaras de vacío térmico, pero la operación prolongada en órbita aportará datos que un laboratorio no puede reproducir por completo.

La orientación del satélite también importa. Los paneles deben recibir luz, los radiadores necesitan una vista fría del espacio y las antenas o terminales ópticas deben apuntar con precisión. Cualquier cambio para mejorar una función puede perjudicar otra. Por eso el prototipo actual es sobre todo un instrumento para medir y aprender, no el primer nodo comercial de una futura nube.

Radiación, memoria y fiabilidad

Fuera de la protección más intensa de la atmósfera, los componentes electrónicos reciben partículas capaces de alterar bits, degradar materiales o provocar fallos. Los chips diseñados para satélites suelen priorizar tolerancia a la radiación antes que potencia de cálculo. Project Suncatcher explora si hardware derivado de centros de datos puede funcionar con protección, corrección de errores y redundancia adecuadas.

En sus pruebas de investigación previas, Google expuso una TPU Trillium a un haz de protones de 67 MeV. La memoria de gran ancho de banda fue la parte más sensible y comenzó a mostrar irregularidades después de una dosis acumulada de 2 krad de silicio. Google calcula una dosis de unos 750 rad de silicio para cinco años con blindaje, pero esa proyección debe contrastarse con datos reales de misión.

Una inferencia correcta no demuestra fiabilidad a largo plazo. Harán falta millones de operaciones, variaciones de temperatura, eventos solares y ciclos de encendido para estimar la tasa de errores. Además, un sistema comercial necesitaría detectar fallos, migrar tareas y sustituir nodos sin interrumpir el servicio.

Comunicación entre satélites: el cuello de botella invisible

Entrenar o ejecutar modelos grandes requiere mover datos entre muchos aceleradores. En un centro de datos, las conexiones son cortas y utilizan fibra, cobre o enlaces internos de muy alta velocidad. En órbita, los satélites se desplazan continuamente y deben mantener alineados terminales láser mientras vuelan a varios kilómetros por segundo.

El diseño de Google plantea grupos compactos, con vehículos separados por cientos de metros o pocos kilómetros. Esa proximidad reduce las pérdidas ópticas y permitiría enlaces de decenas de terabits por segundo. En laboratorio, el equipo informó de 800 Gbps en cada sentido con un par de transceptores, pero todavía debe demostrar ese rendimiento en movimiento, con vibraciones, variaciones térmicas y restricciones de potencia.

La segunda misión prevista para 2027 utilizará dos satélites interconectados. Será una prueba mucho más relevante para la arquitectura distribuida: permitirá evaluar coordinación, comunicación óptica y reparto de tareas. Hasta que esa fase funcione, Project Suncatcher solo ha probado computación en un nodo orbital, no una constelación de inteligencia artificial.

Latencia: el espacio no sustituye automáticamente a la nube

Una instalación orbital no estaría necesariamente más cerca del usuario. Los datos tendrían que viajar desde una estación terrestre, alcanzar el satélite, procesarse y regresar. La distancia física puede ser menor que la de determinados cables submarinos, pero el recorrido incluye ventanas de visibilidad, estaciones, colas y enlaces intermedios.

Las tareas tolerantes a la demora, como entrenamiento por lotes, simulaciones o análisis científicos, podrían adaptarse mejor que una aplicación conversacional interactiva. En cambio, un servicio que necesita responder en milisegundos seguirá dependiendo de infraestructura cercana, redes terrestres y puntos de presencia regionales.

La ubicación afecta también a protección de datos, jurisdicción y continuidad del servicio. En nuestra guía sobre latencia, costes y ubicación de la nube detallamos por qué la distancia es solo una parte del problema y por qué las obligaciones legales no desaparecen al cambiar el lugar físico del hardware.

Coste de lanzamiento y mantenimiento

El precio de enviar masa a órbita es uno de los mayores obstáculos. El estudio de Google proyecta que, si continúa el aprendizaje industrial, el lanzamiento podría caer por debajo de 200 dólares por kilogramo a mediados de la década de 2030. Con ese supuesto, el coste anual por kilovatio de una instalación espacial podría aproximarse al coste energético declarado de un centro de datos terrestre.

Se trata de una proyección, no de un precio disponible. También excluye incertidumbres importantes: vida útil, fallos de lanzamiento, seguros, radiadores, comunicaciones, reposición y retirada. En tierra se puede cambiar una fuente de alimentación o una tarjeta; en órbita, reparar puede ser imposible o más caro que reemplazar el satélite completo.

Planet construyó y opera la plataforma espacial del prototipo. La empresa comunicó que la colaboración utiliza experiencia de constelaciones y tecnología de su plataforma Owl. El acuerdo anunciado por Planet confirma la naturaleza experimental del programa y su orientación a validar hardware y comunicaciones, no a ofrecer capacidad comercial inmediata.

Qué aplicaciones podrían tener sentido

Si la arquitectura llegara a ser viable, los primeros usos podrían ser cargas intensivas que no necesiten respuesta instantánea y que aprovechen energía solar casi continua. Entre ellas podrían estar determinadas simulaciones, entrenamiento programado, procesamiento de observaciones espaciales o análisis científico distribuido.

También sería posible procesar datos cerca de los sensores antes de enviarlos a la Tierra. Un satélite de observación genera enormes volúmenes de imágenes; filtrar nubes, detectar eventos o resumir información en órbita reduciría el ancho de banda necesario. Sin embargo, Project Suncatcher apunta a computación general a gran escala, un objetivo mucho más exigente que el procesamiento local habitual en satélites.

Para equipos pequeños y creadores, el impacto inmediato es nulo: no hay un servicio que contratar ni una instancia espacial disponible. Quien quiera desarrollar aplicaciones de inteligencia artificial hoy debe centrarse en herramientas y plataformas existentes. Nuestro análisis de un curso para crear aplicaciones sin programar aborda esa capa práctica y comercial, muy distinta de la investigación de infraestructura orbital.

En sectores de diseño y visualización, la computación remota ya permite delegar cargas pesadas sin administrar servidores. La guía sobre BIM, renderizado en la nube e inteligencia artificial muestra un ejemplo actual de ese modelo. La diferencia es que funciona sobre centros de datos terrestres disponibles y medibles.

Hechos confirmados y predicciones abiertas

Hechos confirmados

  • El prototipo fue lanzado el 1 de octubre de 2026 y estableció comunicación con tierra.
  • El equipo encendió el sistema anfitrión y las bandejas de TPU y ejecutó pruebas de aprendizaje automático.
  • Una TPU a bordo ejecutó Gemma 4 y devolvió texto generado durante un contacto con la estación terrestre.
  • Google continuará midiendo comportamiento térmico, radiación y fiabilidad.
  • La siguiente fase prevé dos satélites interconectados en 2027.

Predicciones que siguen sin demostrarse

  • Que una constelación pueda igualar el ancho de banda y la latencia interna de un centro de datos.
  • Que la energía solar compense el coste ambiental y económico de fabricar, lanzar y sustituir satélites.
  • Que el hardware mantenga rendimiento estable durante años bajo radiación y ciclos térmicos.
  • Que el coste de lanzamiento baje hasta el nivel utilizado por las proyecciones económicas.
  • Que exista una demanda suficiente para justificar infraestructura orbital a gran escala.

Qué deberíamos exigir a las próximas pruebas

  1. Rendimiento sostenido: tareas completadas, latencia y consumo durante semanas, no una sola respuesta.
  2. Fiabilidad: errores de memoria, reinicios y degradación bajo radiación real.
  3. Temperatura: capacidad de evacuar calor con cargas continuas y diferentes orientaciones.
  4. Red óptica: ancho de banda estable entre satélites en movimiento.
  5. Coste total: fabricación, lanzamiento, operación, reposición y retirada.
  6. Impacto ambiental: materiales, emisiones, tráfico orbital y residuos.
  7. Seguridad: cifrado, actualización de software y recuperación ante fallos sin acceso físico.

Conclusión

Project Suncatcher ha superado una primera barrera real: una TPU de centro de datos ha sobrevivido al lanzamiento y ha ejecutado un modelo en órbita. Es un resultado técnico verificable y relevante, pero sigue siendo el comienzo de una investigación de largo plazo.

El salto desde una respuesta generada en el espacio hasta una constelación comparable a un centro de datos es enorme. Refrigeración, radiación, enlaces ópticos, costes y mantenimiento siguen abiertos. La lectura prudente no es que la nube vaya a mudarse al espacio, sino que Google ha obtenido el primer dato práctico para comprobar si esa posibilidad merece seguir investigándose.