Los centros de datos espaciales de Google llegaron a la órbita, pero necesitan 1.800 lanzamientos de Starship para escalar
Los centros de datos espaciales de Google dejaron de ser solo un documento de investigación el 1 de octubre, cuando la compañía envió cuatro chips de IA a la órbita. Sin embargo, el experimento también expuso una tensión mucho mayor. El modelo económico de Google supone que SpaceX puede realizar cerca de 1.800 vuelos de Starship en una década.
Esa estimación equivale a unos 180 lanzamientos al año, suponiendo que cada misión transporte 200 toneladas métricas. Starship alcanzó la órbita terrestre por primera vez apenas unos días antes del lanzamiento del satélite de Google. Por tanto, SpaceX debe convertir un cohete aún en desarrollo en una red industrial de transporte antes de que las proyecciones económicas de Google resulten viables.
El pequeño satélite no resuelve esa cuestión. Prueba si las Tensor Processing Units, o TPUs, de Google pueden resistir la radiación, las vibraciones del lanzamiento y cambios extremos de temperatura. La misión también analiza si esos chips pueden funcionar sin la refrigeración basada en aire disponible en los centros de datos terrestres.
Google denomina al esfuerzo más amplio Project Suncatcher. Su sistema propuesto situaría satélites de computación alimentados por energía solar en órbita terrestre baja y los conectaría mediante enlaces ópticos. El atractivo es la abundancia de energía solar, pero los obstáculos prácticos incluyen el coste de lanzamiento, la disipación de calor, las comunicaciones, el mantenimiento y la coordinación orbital.
SpaceX es a la vez el proveedor esencial y la dependencia más difícil de este plan. Google puede mejorar internamente los chips, el software y los diseños de satélites. No puede crear transporte orbital barato sin que un proveedor de lanzamientos logre reutilización a una escala sin precedentes.
Los centros de datos espaciales de Google comienzan con cuatro chips, no con una nube orbital
Google ha lanzado un experimento de hardware, no un sustituto funcional de un centro de datos terrestre.
La primera nave de Project Suncatcher, denominada MVP, despegó desde California a bordo de la misión compartida Transporter-18 de SpaceX. Un Falcon 9 la transportó junto con otras 129 cargas útiles, según un resumen de la misión orbital.
El satélite fue construido mediante una colaboración con Planet, la empresa de observación terrestre. Google proporcionó el hardware de computación, incluidas cuatro TPUs. Una TPU es el acelerador personalizado de Google para el entrenamiento y la inferencia de aprendizaje automático.
La nave, del tamaño de un refrigerador, recibe cerca de un kilovatio de sus paneles solares. Ese suministro es diminuto frente a los requisitos de una instalación comercial de IA. Los grandes sistemas terrestres emplean miles de aceleradores respaldados por amplias infraestructuras de redes, almacenamiento, refrigeración y equipos eléctricos.
MVP ejecutará cargas de trabajo de Gemini para probar cómo se comporta el hardware en órbita. Según los informes, el satélite puede operar sus procesadores durante unos 15 minutos antes de detenerse para liberar el calor acumulado. Ese patrón operativo lo convierte en un instrumento científico, no en un servicio de computación disponible de forma continua.
La misión aceleró el calendario original de Google. La compañía había descrito previamente una misión de aprendizaje con dos satélites junto a Planet para principios de 2027. La integración de chips en una nave existente de Planet permitió a Google recopilar datos orbitales antes.
Google afirma que el satélite evaluará las tensiones físicas del lanzamiento y las condiciones térmicas y de radiación presentes en el espacio. Estas mediciones deberían proporcionar a los ingenieros evidencia que las simulaciones en tierra no pueden reproducir por completo.
La distinción importa porque la expresión “centro de datos espacial” puede sugerir una instalación madura que ejecuta cargas de trabajo de clientes. MVP se parece más a un laboratorio compacto. Su tarea es identificar modos de fallo antes de que Google se comprometa con una arquitectura satelital mayor.
Aun así, este lanzamiento cambia el estatus de Project Suncatcher. El proyecto cuenta ahora con hardware expuesto a condiciones orbitales reales, en lugar de únicamente simulaciones. Esa evidencia puede confirmar supuestos, revelar fallos inesperados u obligar a Google a rediseñar el sistema.
La prueba también llegó en un momento significativo para SpaceX. Starship alcanzó la órbita terrestre por primera vez el 28 de septiembre y después desplegó 26 satélites Starlink. La etapa superior perdió un motor y regresó antes de lo previsto, pero la misión demostró una capacidad necesaria.
El satélite de Google no viajó en Starship. Falcon 9 realizó la misión. Sin embargo, Falcon 9 carece de la economía de carga útil y del volumen que Google espera que requiera una red completa de computación orbital.
Por eso, el pequeño experimento apunta de inmediato a una cuestión de infraestructura mucho mayor. Cuatro chips pueden compartir una misión de lanzamiento compartido. Miles de satélites que transporten sistemas de computación densos necesitan una operación de lanzamiento radicalmente distinta.
Por qué Project Suncatcher necesita la economía de Starship
Project Suncatcher depende de que los precios de lanzamiento disminuyan mediante repetición, reutilización y un enorme volumen acumulado de carga útil.
La investigación de Google estima que el transporte a órbita terrestre baja podría acercarse a los 200 dólares por kilogramo a mediados de la década de 2030. La estimación procede de una curva de aprendizaje basada en los precios históricos de lanzamiento de SpaceX y la masa acumulada de carga útil.
Una curva de aprendizaje relaciona la experiencia de fabricación con la reducción del coste unitario. Los investigadores de Google calculan que SpaceX logró una reducción de cerca del 20 por ciento en el precio por kilogramo cada vez que duplicaba su masa total lanzada.
Extender ese patrón a Starship produce la cifra más sorprendente del proyecto. SpaceX tendría que entregar unas 370.000 toneladas métricas adicionales en órbita para mantener la trayectoria asumida.
Con 200 toneladas métricas por misión, eso equivale a aproximadamente 1.800 lanzamientos de Starship. Promediado durante diez años, el requisito pasa a ser de unas 180 misiones anuales. Los primeros años probablemente quedarían por debajo de ese promedio, lo que obligaría a las operaciones posteriores a avanzar aún más rápido.
Estas cifras proceden del documento de computación orbital de Google. Los investigadores subrayan que su trabajo no constituye un estudio completo de viabilidad económica. En cambio, su cálculo muestra qué debe ocurrir para que los precios de lanzamiento dejen de dominar el caso de negocio.
El umbral de 200 dólares importa porque Google compara los costes de entrega orbital con el gasto energético recurrente de los centros de datos terrestres. Con ese precio de lanzamiento, los costes de transporte ajustados a la vida útil de satélites eficientes podrían situarse dentro del amplio rango de los costes de electricidad en la Tierra.
Esta comparación tiene límites. Excluye varios gastos que determinan si un servicio real es competitivo. Los satélites deben diseñarse, fabricarse, asegurarse, operarse, conectarse, repararse mediante redundancia y, finalmente, reemplazarse.
El documento también presupone que las mejoras históricas de precios pueden continuar tras un cambio importante en el diseño del vehículo. Falcon 9 y Starship no comparten sistemas de producción, patrones operativos ni perfiles de riesgo idénticos. Una tendencia extraída de cohetes anteriores no puede garantizar el rendimiento futuro de Starship.
El análisis de Google reconoce esta incertidumbre. Indica que la estimación depende de una reutilización elevada, volumen acumulado, ejecución técnica, competencia de mercado y condiciones regulatorias. Por tanto, una proyección de precios es un resultado condicionado, no una oferta comercial cotizada.
La compañía también examina una vía de menor volumen. Si el crecimiento de la carga útil queda aproximadamente un 70 por ciento por debajo de la estimación central, los precios de lanzamiento podrían alcanzar aun así unos 300 dólares por kilogramo. Ese resultado podría mejorar la economía orbital sin cumplir el escenario completo de 1.800 lanzamientos.
Sin embargo, unos precios de lanzamiento más bajos por sí solos no crean demanda. SpaceX necesita clientes con suficiente carga útil para llenar misiones repetidas de Starship. La computación orbital podría convertirse en uno de esos clientes, pero solo si los lanzamientos baratos hacen primero viables los sistemas de computación.
Esto crea una dependencia circular. Los centros de datos espaciales necesitan capacidad de lanzamiento barata para escalar. Starship necesita una enorme demanda de lanzamientos para descender por la curva de costes proyectada.
Google no se limita a esperar cohetes más baratos. Project Suncatcher podría aportar por sí mismo parte de la masa necesaria para abaratar esos cohetes. Esta posibilidad sitúa a Google y SpaceX en una relación de dependencia mutua, en lugar de un contrato convencional entre proveedor y cliente.
En consecuencia, el número de lanzamientos es más que una estadística llamativa. Es el mecanismo que conecta un experimento de cuatro chips con la economía de una futura red orbital.
Google frente a la realidad de la cadencia de lanzamientos
El principal adversario no es otro proveedor de nube. Es la brecha entre las ambiciones de lanzamiento de SpaceX y una cadencia operativa de 180 misiones anuales.
El primer vuelo orbital de Starship fue un hito importante, pero alcanzar la órbita una vez es distinto de operar cientos de veces al año. SpaceX debe repetir los lanzamientos de forma segura, reutilizar ambas etapas del vehículo, reducir el trabajo de reacondicionamiento y mantener varios sitios de lanzamiento.
La misión de septiembre ilustró esa brecha. Starship desplegó su carga útil con éxito, pero un motor de la etapa superior dejó de funcionar. SpaceX también acortó el vuelo previsto y devolvió el vehículo después de unas tres horas.
Los vuelos de desarrollo están diseñados para descubrir problemas. Un problema de motor no invalida el vehículo ni la investigación de Google. Sí muestra por qué no puede inferirse una cadencia fiable únicamente a partir de la capacidad de carga útil.
Un sistema que vuele 180 veces al año promedia casi un lanzamiento cada dos días. Ese promedio debe incluir el tiempo necesario para inspecciones, integración de cargas útiles, retrasos meteorológicos, aprobaciones regulatorias, mantenimiento de plataformas y respuestas a anomalías.
La cifra también supone que cada vuelo puede entregar 200 toneladas métricas. La carga útil real depende de la configuración del vehículo, la órbita, los planes de recuperación y los requisitos de la misión. Una carga útil promedio menor requeriría más lanzamientos para entregar la misma masa acumulada.
SpaceX ha descrito tasas de vuelo a largo plazo mucho más altas. Elon Musk ha hablado de llegar a realizar miles de vuelos anuales con Starship. Estas declaraciones establecen la ambición de la compañía, pero no aportan evidencia de que el sistema operativo ya exista.
Los avances recientes sí refuerzan la idea de que Starship puede convertirse en un lanzador comercial. Su misión orbital desplegó 26 satélites Starlink V3, mientras que el propulsor completó un aterrizaje simulado cerca de la costa. SpaceX está desarrollando el vehículo para una reutilización rápida, en lugar de hardware desechable.
Starlink proporciona a SpaceX una fuente interna de demanda. La compañía puede lanzar sus propios satélites de comunicaciones mientras perfecciona las operaciones de Starship. Esa integración vertical ayudó a Falcon 9 a acumular experiencia de vuelo y podría respaldar la cadencia inicial de Starship.
Los centros de datos orbitales impondrían exigencias diferentes. Los satélites de computación transportan hardware de gestión térmica, grandes paneles solares, equipos de comunicaciones ópticas y procesadores costosos. Deben alcanzar formaciones orbitales precisas, en lugar de simplemente incorporarse a una constelación de banda ancha.
Google también es inversor de SpaceX, lo que alinea algunos intereses. Sin embargo, la inversión no elimina la dependencia técnica. El calendario de Google sigue vinculado a un sistema de transporte que no diseña ni controla.
Otros proveedores de lanzamiento podrían reducir finalmente esa exposición. Blue Origin, Rocket Lab y futuros competidores de lanzamientos pesados podrían bajar los precios. Ninguno ofrece actualmente un sustituto probado que iguale la combinación prevista de Starship de volumen de carga útil y reutilización completa.
Falcon 9 sigue siendo fiable para prototipos, pero el modelo de Google identifica límites de volumen que lo hacen inadecuado para un despliegue masivo. Esto genera una transición incómoda. El cohete existente puede probar la idea, mientras que el cohete inacabado debe hacerla económica.
La estimación de 1.800 lanzamientos se indicó inicialmente de forma errónea como 1.600 en el titular y la URL de la fuente. La corrección publicada confirma que 1.800 es la cifra basada en el documento.
Esa corrección importa porque refuerza la escala del desafío. Doscientos lanzamientos adicionales representan más de un año al ritmo medio requerido.
La evidencia decisiva vendrá de las operaciones, no de las proyecciones. SpaceX debe demostrar tiempos de rotación más cortos, reutilización repetida de vehículos, entrega fiable de carga útil y una mayor capacidad en los sitios de lanzamiento. Hasta entonces, la curva de costes de Google seguirá siendo un escenario técnicamente fundamentado.
Un clúster de IA de 81 satélites debe comportarse como un solo ordenador
El transporte barato resuelve solo el primer problema, porque la IA distribuida también necesita vuelo en formación preciso y comunicaciones propias de un centro de datos.
La arquitectura propuesta por Google utiliza grupos de 81 satélites. Un clúster ilustrativo orbitaría a una altitud media cercana a los 650 kilómetros y cabría dentro de un radio de un kilómetro.
Los satélites mantendrían separaciones de aproximadamente 100 a 200 metros respecto de sus compañeros más cercanos. Esa geometría debe permanecer estable mientras cada nave espacial viaja alrededor de la Tierra a velocidad orbital.
Las cargas de trabajo de aprendizaje automático implican intercambios frecuentes entre aceleradores. Entrenar un modelo grande exige que los procesadores sincronicen datos y resultados intermedios con baja latencia. Las conexiones lentas o inconsistentes pueden dejar chips costosos esperando información.
Los centros de datos terrestres resuelven esto con fibra y conmutadores especializados. Project Suncatcher sustituye esas conexiones fijas por enlaces ópticos de espacio libre, que transmiten datos mediante haces láser dirigidos con precisión.
Google demostró 800 gigabits por segundo en una dirección a través de una trayectoria corta de laboratorio. La capacidad bidireccional alcanzó 1,6 terabits por segundo. Esa prueba respalda el concepto de comunicaciones subyacente, pero no reprodujo una formación orbital completa en movimiento.
Una constelación real debe apuntar con precisión múltiples haces mientras los satélites cambian de posición. El sistema debe gestionar vibraciones, cambios de temperatura, degradación de componentes, evitación de desechos orbitales y fallos dentro del clúster.
Google propone modelos de aprendizaje automático para ayudar a predecir el movimiento orbital y controlar la formación. Ese enfoque podría mantener a los satélites vecinos dentro del alcance de comunicación. También añade requisitos de garantía de software a un sistema físico ya complejo.
La conectividad con tierra plantea otra limitación. El ancho de banda entre satélites no elimina la necesidad de mover entradas y salidas entre la Tierra y la órbita. La turbulencia atmosférica, las nubes, el seguimiento de haces y la disponibilidad de estaciones terrestres pueden restringir las comunicaciones ópticas.
Algunas cargas de trabajo encajan mejor que otras en esta arquitectura. Procesar datos ya recopilados en órbita podría reducir la cantidad transmitida a la Tierra. El análisis de imágenes satelitales es un ejemplo evidente, porque la información bruta se origina cerca de los procesadores.
Los grandes trabajos de entrenamiento terrestre plantean un caso más difícil. Sus conjuntos de datos pueden originarse en sistemas de almacenamiento en tierra. Subir ese material, coordinar miles de procesadores y recuperar resultados puede borrar algunas de las ventajas de la abundante energía solar.
Las cargas de trabajo de inferencia podrían resultar más tolerantes. La inferencia consiste en ejecutar un modelo entrenado para producir una respuesta, clasificación o predicción. Estas tareas pueden ser más pequeñas y requerir menos sincronización que las largas ejecuciones de entrenamiento.
Las pruebas de radiación de Google respaldan esta distinción. Sus investigadores afirman que los TPUs Trillium sobrevivieron a una dosis ionizante equivalente a una misión de cinco años sin fallos permanentes. Sin embargo, las partículas de alta energía aún pueden causar errores computacionales temporales.
Un investigador dijo a TechCrunch que una inferencia típica podría encontrar un error aproximadamente cada millón de operaciones. La misma tasa resulta más preocupante cuando miles de chips coordinan una ejecución de entrenamiento que dura varios meses.
El software puede detectar y repetir algunos cálculos erróneos. Los procesadores redundantes también pueden sustituir la capacidad fallida. Ambas respuestas consumen energía, hardware o tiempo, debilitando el argumento económico.
Por tanto, el clúster propuesto no es simplemente un rack de servidores situado sobre la Tierra. Es un superordenador distribuido cuya red, suministro eléctrico, sistema de refrigeración y disposición física permanecen en movimiento constante.
Explicado a ese nivel de sistemas, Project Suncatcher se parece menos a reubicar una región convencional de nube. Se asemeja a diseñar una nueva plataforma informática en torno a las restricciones de la mecánica orbital.
La refrigeración y las reparaciones podrían invalidar el caso de negocio
Los riesgos más difíciles siguen siendo la eliminación del calor y el mantenimiento, porque el espacio ofrece luz solar sin proporcionar aire, agua ni técnicos.
La energía solar es el principal atractivo de Project Suncatcher. Google afirma que los satélites en órbitas terrestres bajas adecuadas pueden recibir hasta ocho veces más energía solar que los paneles en ubicaciones comparables de la Tierra.
El acceso a la luz solar evita algunas limitaciones de la red terrestre. Los nuevos centros de datos en la Tierra pueden esperar años por mejoras de transmisión, acuerdos de generación eléctrica, permisos y aprobación local. Los sistemas orbitales generarían electricidad directamente junto a sus procesadores.
Sin embargo, la energía que entra en un chip termina convirtiéndose en calor. En la Tierra, las instalaciones trasladan ese calor mediante aire, agua, refrigerantes, bombas, torres de refrigeración e intercambiadores de calor. El vacío no tiene aire que pueda evacuar el calor.
En su lugar, las naves espaciales deben conducir el calor de los procesadores hacia radiadores. Esas superficies liberan energía como radiación infrarroja. El área necesaria aumenta con la cantidad de calor generada y las temperaturas que el hardware puede tolerar.
El MVP de Google pone de relieve la limitación. Sus cuatro chips solo pueden funcionar durante intervalos breves antes de que el sistema se detenga para enfriarse. Pasar de experimentos de 15 minutos a una operación comercial continua requiere hardware térmico mucho mayor o más eficiente.
Los radiadores añaden masa y superficie. Más masa incrementa los requisitos de lanzamiento, mientras que estructuras mayores complican el despliegue y la evitación de colisiones. El blindaje protector genera la misma penalización cuando los ingenieros lo emplean contra la radiación.
Una evaluación térmica independiente identifica esta disyuntiva en varias propuestas de computación orbital. Los aceleradores de IA convencionales proporcionan el rendimiento necesario, pero no fueron diseñados como componentes de naves espaciales resistentes a la radiación.
Blindar los chips añade peso. Dejarlos expuestos incrementa los errores y los posibles fallos. El hardware redundante mejora la fiabilidad, pero enviar procesadores de repuesto a órbita vuelve a elevar los requisitos de masa, energía y refrigeración.
El mantenimiento es igual de implacable. Los técnicos sustituyen rutinariamente unidades defectuosas, equipos de red, fuentes de alimentación y placas aceleradoras dentro de instalaciones terrestres. Un clúster orbital no puede depender de visitas rutinarias de servicio humano.
El documento de Google propone el aprovisionamiento redundante como la respuesta más sencilla. Eso significa lanzar más capacidad de la que el sistema necesita inicialmente y luego sortear los fallos.
La redundancia mantiene un servicio en funcionamiento, pero modifica la utilización. El hardware de reserva sigue acarreando costes de fabricación y lanzamiento. Algunos componentes pueden permanecer inactivos hasta que falle otro componente.
La vida útil de los satélites introduce otra limitación. Google evalúa la exposición a la radiación durante cinco años. Una instalación terrestre puede sustituir procesadores por etapas, mientras que un satélite puede integrar computación, energía, refrigeración y comunicaciones en un único activo de vida limitada.
Los rápidos ciclos del hardware de IA complican ese modelo. Un satélite lanzado con procesadores actuales puede volverse menos eficiente que chips terrestres más nuevos mucho antes de que la radiación termine su misión. Sustituirlo requiere otro lanzamiento en lugar de cambiar un servidor.
La retirada de equipos antiguos de órbita también debe formar parte del diseño del sistema. Un clúster de 81 satélites es manejable solo si las unidades fallidas pueden abandonar la órbita de forma segura. El despliegue a gran escala multiplica las preocupaciones sobre colisiones y desechos.
Estos problemas no demuestran que la computación orbital sea imposible. Muestran por qué una prueba exitosa de un chip no puede validar un servicio comercial. Google debe medir las tasas de error, el rendimiento térmico sostenido, la disponibilidad de energía y la degradación de componentes a lo largo del tiempo.
La misión MVP es valiosa precisamente porque un fallo sería informativo. Descubrir ahora un límite de temperatura o un patrón de radiación cuesta menos que encontrarlo después de desplegar un clúster completo.
El enfoque público de Google sigue siendo adecuadamente cauteloso. Su actualización de Project Suncatcher describe el satélite como una prueba inicial e identifica la refrigeración como un desafío crucial de investigación.
Esa cautela distingue el programa de investigación de afirmaciones más agresivas sobre capacidad de nube orbital a corto plazo. La prueba aporta evidencia, pero aún no establece cargas de trabajo continuas, costes competitivos ni una estrategia de mantenimiento desplegable.
Tres señales decidirán si la computación espacial puede escalar
La próxima evidencia debe conectar un experimento exitoso con computación repetible, lanzamientos reutilizables y una vía creíble más allá de un satélite.
La primera señal son los datos operativos sostenidos del MVP. Google necesita revelar con qué frecuencia funcionan los TPUs, con qué rapidez se acumula el calor y cómo afecta la radiación a la precisión de la inferencia.
Las sesiones cortas exitosas confirmarían que los aceleradores convencionales pueden operar en órbita. Las sesiones más largas con refrigeración predecible aportarían evidencia más sólida. Las paradas frecuentes o los errores inexplicables debilitarían el argumento a favor de clústeres orbitales densos.
Los lectores también deberían observar si Google publica resultados de inferencia de Gemini, en lugar de limitarse a mediciones sobre el estado del hardware. Un chip funcional es necesario, pero el rendimiento útil de las cargas de trabajo es el hito más relevante.
La segunda señal es el progreso hacia la misión multissatélite planificada por Google. Dos o más naves espaciales pueden probar enlaces ópticos, coordinación y cargas de trabajo distribuidas que un solo satélite no puede reproducir.
Google apuntó previamente a principios de 2027 para dos satélites prototipo con Planet. Cualquier calendario, diseño u objetivo de misión actualizado mostrará cómo las lecciones del MVP afectan a ese plan.
Una demostración multissatélite debería revelar la estabilidad de la conexión, la precisión del seguimiento de haces y el efecto del movimiento orbital en la coordinación de las cargas de trabajo. Esas mediciones comenzarían a probar Project Suncatcher como un sistema.
La tercera señal es la cadencia real de lanzamientos y el historial de reutilización de Starship. La economía de Google se vuelve más creíble cuando SpaceX vuela repetidamente hardware recuperado, reduce los tiempos de rotación y amplía las operaciones de carga útil.
Una misión orbital no establece una curva de costes. Una secuencia de vuelos comerciales fiables proporcionaría la evidencia relevante. Reutilizar ambas etapas importaría más que alcanzar otro hito aislado de vuelo.
La capacidad de carga útil también debe pasar de ser un objetivo de diseño a un rendimiento operativo. El cálculo de 1.800 lanzamientos de Google asume 200 toneladas métricas por vuelo. Una capacidad demostrada inferior cambia el número de misiones necesarias.
Estas señales deben evaluarse conjuntamente. Mejores chips no pueden compensar un transporte inasequible. El transporte barato no puede eliminar el calor de los procesadores. Una refrigeración sólida no puede crear el ancho de banda necesario para el entrenamiento distribuido.
Los competidores aportarán comparaciones útiles. SpaceX ha propuesto su propia red de computación orbital, mientras que Starcloud y otras startups prueban arquitecturas diferentes. Sus resultados pueden revelar si el diseño de clúster de Google es inusualmente conservador u optimista.
Los primeros usos comerciales también podrían diferir de la visión más amplia de Google. El procesamiento nativo en el espacio, incluido el análisis de datos de sensores o imágenes antes de transmitirlos, requiere menos ancho de banda terrestre. Eso lo convierte en un mercado inicial más creíble.
La computación en la nube general para usuarios en la Tierra enfrenta requisitos más estrictos. Los clientes esperan acceso fiable, latencia predecible, manejo seguro de los datos, sustitución rápida del hardware y garantías claras de nivel de servicio. La infraestructura orbital debe cumplir esas expectativas mientras se desplaza por encima de nuestras cabezas.
La conclusión más importante no es que Google necesite exactamente 1.800 lanzamientos. Esa cifra procede de un modelo con supuestos que cambiarán a medida que evolucionen Starship, los diseños de satélites y los mercados.
Su importancia reside en lo que revela. Los centros de datos espaciales de Google requieren un sistema industrial que abarque cohetes, fábricas de naves espaciales, redes ópticas, ingeniería térmica, operaciones autónomas y hardware de IA.
Project Suncatcher ya ha comenzado a probar un eslabón de esa cadena. El satélite puede indicar a Google si sus chips soportan las condiciones reales del espacio. No puede determinar si SpaceX realizará cientos de lanzamientos anuales.
El experimento merece atención porque convierte una idea especulativa en un programa de ingeniería medible. También hace más difícil ignorar la distancia que aún queda por recorrer.
Observe lo que Google informe desde MVP, si su misión de múltiples satélites se mantiene según lo previsto y con qué frecuencia Starship realiza misiones comerciales reutilizables. Esas tres señales mostrarán si la IA orbital se está convirtiendo en infraestructura o sigue siendo un ambicioso proyecto de investigación.
