El lanzamiento de Google Project Suncatcher pone a prueba si la computación de IA puede sobrevivir en órbita
Google enviará cuatro chips TPU a la órbita el 1 de octubre, convirtiendo el lanzamiento de Google Project Suncatcher de una propuesta de investigación en un experimento físico. El satélite MVP, del tamaño de un frigorífico, viajará a bordo de la misión de viaje compartido Transporter-18 de SpaceX. Pondrá a prueba si el hardware de IA habitual puede soportar las fuerzas del lanzamiento, la radiación y la refrigeración sin aire.
Es fácil exagerar la misión. MVP no es un centro de datos orbital operativo, y cuatro procesadores no pueden reproducir un clúster de IA terrestre. El experimento de Google es más acotado y relevante: pregunta si los aceleradores de IA comerciales pueden operar de forma fiable fuera del entorno para el que fueron diseñados.
Esa distinción genera la tensión central. El espacio ofrece abundante energía solar y menos restricciones terrestres, pero elimina la infraestructura que mantiene con vida a los aceleradores modernos. Google debe intercambiar energía accesible por una gestión térmica difícil, despliegues costosos, opciones de reparación limitadas y dependencia de proveedores de lanzamiento.
SpaceX, Starcloud, Aetherflux y otros operadores están explorando ideas relacionadas. Google aporta una ventaja distinta: chips personalizados, experiencia en computación distribuida y experiencia directa operando sistemas terrestres enormes. Su desventaja es igual de clara. No controla los cohetes necesarios para hacer que la computación orbital sea económicamente creíble.
El lanzamiento de Google Project Suncatcher es una prueba de supervivencia del hardware
La misión del 1 de octubre prueba si los chips de IA de Google pueden sobrevivir en órbita, no si un centro de datos orbital ya funciona.
Google anunció el 24 de septiembre que su primer prototipo de Project Suncatcher volaría en la misión Transporter-18 de SpaceX. El lanzamiento está programado desde la Base de la Fuerza Espacial Vandenberg, en California, para situar la nave en órbita terrestre baja.
El prototipo, llamado MVP, utiliza una plataforma satelital suministrada por Planet. Google integró cuatro de sus Tensor Processing Units, o TPU, procesadores especializados creados para cálculos de aprendizaje automático. Según las especificaciones de MVP publicadas, sus paneles solares proporcionan alrededor de un kilovatio de potencia.
Ese presupuesto energético impone límites estrictos. Según se informa, el satélite puede operar su hardware de IA durante unos 15 minutos antes de detenerse para disipar el calor acumulado. Un servidor terrestre puede usar ventiladores, refrigeración líquida, agua enfriada y suministro eléctrico constante. MVP no dispone de ninguna de esas máquinas auxiliares.
En cambio, el experimento medirá cómo responden los chips ante tres etapas hostiles. Primero llegan la vibración y la aceleración del lanzamiento. Después, los procesadores deben funcionar bajo exposición a la radiación. Por último, el sistema de refrigeración debe alejar el calor de la electrónica concentrada en el vacío.
Google afirma que el trayecto en cohete dura unos 10 minutos y expone la nave a cargas sostenidas de hasta 10 veces la gravedad terrestre. Los componentes individuales pueden experimentar fuerzas de entre 50 y 100 veces la gravedad. Antes del vuelo, los ingenieros sacudieron el satélite a lo largo de tres ejes para reproducir esas condiciones.
La empresa también probó TPU Trillium dentro de una instalación de haz de protones en la Universidad de California, Davis. La exposición a protones ayuda a los investigadores a estudiar la dosis total de radiación y los efectos de evento único, incluidos los cambios de bits que alteran los datos almacenados.
Google informó de que no hubo fallos permanentes atribuibles a la radiación acumulada durante su prueba de dosis más alta. Sin embargo, las pruebas en tierra no pueden reproducir todas las condiciones orbitales. La radiación procede de fuentes distintas, las temperaturas de los componentes varían y los fallos pueden interactuar con el software de formas inesperadas.
Por tanto, el lanzamiento inicial de Google Project Suncatcher debería producir evidencia operativa, no un veredicto definitivo. Un chip funcional es solo el primer hito. Las cargas de trabajo fiables, la recuperación predecible ante fallos y los ciclos térmicos repetibles importan mucho más para cualquier futuro servicio de computación.
MVP también modifica el calendario original de Google. Project Suncatcher apuntaba inicialmente a dos satélites prototipo para 2027. Google aceleró la primera prueba de hardware al instalar sus procesadores en una nave existente de Planet, mientras mantiene la misión de satélites emparejados para experimentos posteriores de redes.
Ese enfoque limita la misión de octubre, pero ofrece a Google respuestas antes. Si MVP revela un problema térmico, de radiación o de energía, los ingenieros pueden revisar los prototipos más grandes antes del lanzamiento. Si funciona bien, Google obtiene evidencia de que los diseños estándar de aceleradores necesitan menos adaptación de la que esperaban los escépticos.
Por qué Google quiere infraestructura de IA por encima de la red eléctrica
Project Suncatcher es, en última instancia, una respuesta a los límites físicos que rodean la expansión terrestre de la IA.
Los sistemas de IA modernos requieren grandes clústeres de aceleradores operando durante periodos prolongados. Esos clústeres necesitan electricidad, equipos de refrigeración, capacidad de red, terreno, transformadores y conexiones a la infraestructura de transmisión. Cada requisito puede retrasar un nuevo centro de datos antes de que llegue su primer servidor.
El espacio parece atractivo porque la luz solar puede alcanzar un conjunto solar orbital sin pérdidas por el clima o la atmósfera. En una órbita heliosincrónica adecuada, un satélite sigue una trayectoria que ofrece largos periodos de iluminación. Google estima que un panel orbital puede generar hasta ocho veces más energía que el mismo panel en la Tierra.
Esa comparación no hace que el espacio sea eficiente de forma automática. Un satélite debe transportar cada procesador, radiador, panel solar, terminal óptica, estructura y componente de protección durante el lanzamiento. Una vez desplegados, los equipos averiados no pueden recibir las reparaciones rutinarias disponibles dentro de un centro de datos convencional.
La ventaja solar sigue explicando por qué Google considera que la idea merece ser probada. La construcción terrestre de infraestructura de IA afronta presión de empresas de servicios públicos, reguladores y comunidades preocupadas por la capacidad de la red eléctrica, el consumo de agua, la generación de respaldo y el uso del suelo. Los sistemas orbitales trasladarían algunos de esos conflictos.
No eliminarían los costes ambientales. Fabricar y lanzar satélites consume energía y materiales. Las grandes constelaciones añadirían congestión, riesgo de colisión y preocupaciones por la reentrada atmosférica. Las estaciones terrestres y las redes en tierra seguirían siendo necesarias porque los usuarios y la mayoría de las fuentes de datos permanecen en la Tierra.
La latencia también determina qué cargas de trabajo pertenecen a la órbita. Los servicios interactivos deben trasladar solicitudes y respuestas entre usuarios, estaciones terrestres y satélites. Los trabajos de entrenamiento requieren enormes transferencias de datos antes de que comience la computación. Las tareas originadas en el espacio, como el procesamiento de imágenes satelitales, encajan de forma más inmediata.
Un satélite podría analizar datos de sensores antes de enviar los resultados a la Tierra. Esto reduce la necesidad de transmitir cada imagen o medición sin procesar a través de enlaces descendentes limitados. También permite que las naves espaciales tomen decisiones locales más rápidas para navegación, monitorización u observación científica.
Project Suncatcher aspira a ir más allá de esos casos de computación perimetral. El objetivo declarado de Google es un sistema de aprendizaje automático escalable, con clústeres de satélites que se comporten más como un centro de datos conectado. Eso requiere que los procesadores en naves separadas intercambien datos a velocidades asociadas con la infraestructura terrestre.
El concepto es ambicioso porque los clústeres de IA actuales dependen de redes estrechamente integradas. Los aceleradores intercambian repetidamente parámetros de modelos y resultados intermedios. Una conexión lenta puede dejar esperando a procesadores costosos, reduciendo el trabajo útil obtenido de todo el clúster.
Por ello, Google está probando algo más que una nueva ubicación para servidores. Explora si las suposiciones físicas que sustentan un centro de datos de IA pueden reconstruirse alrededor de luz solar, movimiento orbital, enlaces láser y refrigeración radiativa.
El vuelo de octubre aborda únicamente la parte de supervivencia del hardware de esa tesis. Incluso un resultado impecable no resolvería las redes, la economía de los lanzamientos, el mantenimiento ni el control orbital a gran escala. Simplemente mantendría la arquitectura más amplia como técnicamente plausible.
La IA orbital depende de láseres y vuelo en formación
El mecanismo decisivo no es la TPU por sí sola; es la red que conecta muchos procesadores entre naves espaciales en movimiento.
El artículo técnico publicado por Google describe flotas de satélites alimentados por energía solar conectados mediante óptica de espacio libre. Estas conexiones láser transportarían datos directamente entre naves, en lugar de enrutar cada intercambio a través de la Tierra.
La comunicación óptica de espacio libre utiliza luz dirigida para transmitir información sin fibra física. Puede ofrecer un gran ancho de banda, pero las terminales deben mantener la alineación mientras ambos extremos viajan a velocidad orbital. Errores mínimos de puntería pueden interrumpir la conexión.
Google estima que las cargas de trabajo de IA distribuidas requerirían enlaces capaces de transportar decenas de terabits por segundo. Su demostrador de laboratorio transmitió 800 gigabits por segundo en cada dirección mediante un par de transceptores. Esto produjo 1,6 terabits por segundo de capacidad bidireccional total.
El resultado de laboratorio es significativo, pero no recrea el movimiento orbital. Un banco de pruebas ofrece distancias controladas y alineación estable. Los satélites experimentan vibración, distorsión térmica, radiación, resistencia atmosférica y pequeñas diferencias en sus trayectorias.
La respuesta propuesta por Google es una formación compacta. Sus investigadores modelaron un clúster ilustrativo con 81 satélites dentro de un radio de un kilómetro, a una altitud de 650 kilómetros. Las naves vecinas permanecerían separadas por solo cientos de metros.
Las distancias más cortas facilitan los enlaces ópticos de gran ancho de banda porque la señal recibida se debilita rápidamente a medida que aumenta la separación. La formación cercana también incrementa la complejidad operativa. Cada satélite debe conocer su propia posición y mantener una separación segura respecto de múltiples vecinos.
El sistema necesitaría navegación continua, detección de fallos y prevención de colisiones. Un propulsor averiado o una estimación de posición incorrecta podría amenazar a las máquinas adyacentes. Ese riesgo aumenta cuando el clúster contiene decenas de satélites estrechamente espaciados.
La misión de 2027 está diseñada para probar este problema de redes de forma más directa. Google y Planet planean desplegar dos prototipos que puedan validar la comunicación óptica entre naves espaciales. Los futuros satélites transportarían decenas de TPU en lugar de las cuatro de MVP.
Planet reveló que Project Suncatcher utiliza tecnología relacionada con su plataforma satelital Owl de próxima generación. La divulgación de la asociación de la empresa indica que la colaboración respalda el desarrollo relevante para esa plataforma, al tiempo que explora la computación de IA escalada en el espacio.
La asociación da a Google acceso a ingeniería espacial consolidada. Planet tiene experiencia operando flotas, gestionando comunicaciones terrestres y procesando datos de imágenes de la Tierra. Google aporta aceleradores, software de aprendizaje automático e investigación de sistemas distribuidos.
Sin embargo, la asociación también subraya cuántas organizaciones requiere un centro de datos orbital. Google suministra el hardware de computación. Planet proporciona la plataforma espacial. SpaceX ofrece el primer viaje a la órbita. Proveedores adicionales respaldan los sistemas ópticos, térmicos, energéticos y terrestres.
Los centros de datos terrestres también dependen de cadenas de suministro, pero los técnicos pueden sustituir switches, unidades, bombas y equipos eléctricos averiados. En órbita, la redundancia debe diseñarse antes del lanzamiento. La recuperación por software se vuelve esencial porque el acceso físico no está disponible.
Esto crea una definición distinta de fiabilidad. Un satélite no necesita que todos los componentes funcionen para siempre. La constelación debe mantener una capacidad de cómputo útil mientras aísla nodos dañados, corrige errores y redirige cargas de trabajo ante fallos.
Ese diseño se parece a los grandes sistemas en la nube, donde las máquinas individuales fallan con regularidad. La diferencia está en el tiempo de reemplazo. Un operador de nube puede instalar otro servidor dentro de una instalación existente. Un operador orbital debe fabricar, programar, lanzar y poner en servicio otra nave espacial.
Project Suncatcher debe demostrar que el software distribuido puede absorber esa demora. De lo contrario, cada fallo reducirá gradualmente la capacidad de la constelación hasta que otro lanzamiento la restaure.
SpaceX controla el punto de presión económica
Google puede diseñar el sistema de cómputo, pero el acceso al lanzamiento determina si la arquitectura puede superar la fase experimental.
MVP viaja como carga útil compartida, lo que significa que varios clientes comparten un mismo cohete. Este modelo permite realizar pequeñas demostraciones sin comprar un lanzamiento completo. No establece una vía económica para desplegar una gran constelación de cómputo.
Un futuro clúster llevaría procesadores, radiadores, terminales ópticos y grandes paneles solares. Cada componente añade masa. Más masa exige mayor capacidad de lanzamiento, mientras que el despliegue dedicado incrementa la dependencia de la disponibilidad de cohetes y de la precisión de la inserción orbital.
SpaceX ocupa una posición inusual en esa ecuación. Puede vender lanzamientos a empresas que persiguen el cómputo orbital mientras desarrolla su propia infraestructura espacial. Starlink ya proporciona a SpaceX experiencia en la fabricación, lanzamiento, interconexión y reemplazo de satélites a escala.
Esa integración vertical ejerce presión sobre Google. Google controla el diseño de TPU y opera importantes servicios de IA, pero carece de un sistema de lanzamiento propio. SpaceX puede coordinar el diseño de satélites con la capacidad de sus cohetes y reutilizar aprendizajes entre ambos negocios.
El panorama competitivo va más allá de dos empresas. Starcloud ha puesto hardware de cómputo en órbita. Aetherflux ha descrito planes de procesamiento basado en el espacio. Blue Origin y otros proveedores de lanzamiento también perciben una demanda emergente en torno a infraestructura orbital intensiva en datos.
Esta actividad no demuestra que la IA orbital sea comercialmente viable. Muestra que varias empresas consideran suficientemente serias las restricciones de energía e infraestructura como para financiar experimentos. Sus enfoques difieren en escala, carga de trabajo, acceso al lanzamiento y clientes objetivo.
Ya se ha formado una competencia sectorial en torno a esta distinción. Los proveedores de lanzamiento pueden internalizar los costes de despliegue y reservar capacidad para proyectos vinculados. Las empresas sin cohetes deben negociar el acceso con posibles competidores.
La respuesta más sólida de Google es la especialización. Los TPU están diseñados específicamente para el aprendizaje automático, y Google controla la pila de software que los rodea. Puede optimizar conjuntamente los modelos, compiladores, redes y recuperación ante fallos, en lugar de adaptar un sistema de propósito general.
Esa ventaja solo importa si los costes de lanzamiento y de las naves espaciales disminuyen lo suficiente. La investigación de Google sostiene que el cómputo orbital puede aproximarse a la economía energética terrestre bajo supuestos ambiciosos sobre futuros despliegues. Esos supuestos siguen siendo previsiones, no resultados operativos observados.
La comparación también depende de qué se contabiliza. Un centro de datos terrestre requiere conexiones a la red eléctrica, refrigeración, edificios y mantenimiento. Un clúster orbital requiere lanzamientos, fabricación de naves espaciales, misiones de reemplazo, estaciones terrestres, prevención de colisiones y retirada.
La utilización será otra variable decisiva. Un centro de datos obtiene valor al mantener ocupados sus costosos procesadores. Si los límites térmicos imponen largas pausas de enfriamiento, un acelerador orbital produce menos trabajo del que su capacidad nominal sugiere.
La ventana operativa de 15 minutos comunicada para MVP ilustra el problema. La misión es deliberadamente pequeña y experimental, por lo que su ciclo de trabajo no predice un sistema de producción. Aun así, identifica la métrica que inversores e ingenieros deberían vigilar: cómputo útil por órbita.
Google también debe demostrar que la vibración del lanzamiento no acorta la vida útil del hardware. Un chip puede sobrevivir al despegue y, aun así, desarrollar fallos meses después. La telemetría de larga duración importará más que una activación exitosa poco después del despliegue.
Por tanto, SpaceX presiona a Project Suncatcher desde dos direcciones. Sus cohetes hacen posible el experimento de Google, mientras que sus capacidades integradas de satélites muestran lo que Google no tiene. Si el cómputo orbital madura, el control del transporte pasará a formar parte de la pila de cómputo.
La refrigeración convierte la abundante energía solar en una disyuntiva
El espacio ofrece energía abundante, pero el vacío dificulta mucho más la eliminación del calor de los procesadores.
Las descripciones de centros de datos orbitales suelen destacar que el espacio es frío. Esa afirmación puede inducir a error. La temperatura mide el movimiento de las partículas, mientras que enfriar un chip requiere alejar de él el calor. Un vacío casi no contiene materia que pueda transportar ese calor.
Las instalaciones terrestres transfieren calor mediante aire, agua, refrigerantes, tuberías, torres de refrigeración e intercambiadores de calor. Una nave espacial debe conducir el calor desde el procesador hasta un radiador, que libera energía en forma de radiación infrarroja.
Google afirma que MVP combina tubos de calor con radiadores. Un tubo de calor aleja la energía térmica de un componente caliente mediante la circulación de un fluido de trabajo dentro de una estructura sellada. El radiador libera después esa energía al espacio.
El área necesaria del radiador crece con la carga térmica. Los aceleradores modernos de IA concentran una potencia considerable en encapsulados pequeños, lo que convierte la densidad térmica en una restricción central de diseño. Los radiadores grandes añaden masa, superficie, complejidad estructural y vulnerabilidad.
Los paneles solares plantean un problema geométrico similar. Más cómputo requiere más energía, y más energía exige superficies de captación mayores. Esas superficies deben desplegarse correctamente, tolerar residuos y mantener una orientación útil hacia el Sol.
Una formación muy compacta complica aún más el diseño térmico. Los satélites deben evitar bloquear la exposición solar de los demás o irradiar calor hacia naves espaciales vecinas. Su orientación también debe permitir la alineación láser y la comunicación con la Tierra.
Google ha probado su diseño de refrigeración en una cámara de vacío térmico. Esa cámara elimina el aire y alterna temperaturas para aproximar las condiciones orbitales. No puede reproducir todas las interacciones entre luz solar, sombra, radiación, orientación y envejecimiento de componentes.
MVP aportará la evidencia operativa que falta. Los ingenieros podrán comparar las temperaturas previstas con lecturas reales de sensores. Podrán observar con qué rapidez se calientan los procesadores, con qué eficiencia los enfrían los radiadores y si los ciclos repetidos dañan conexiones o memoria.
La radiación introduce otra capa de incertidumbre. Las pruebas de Google determinaron que la memoria de alto ancho de banda es más sensible que el núcleo TPU. Los fallos de memoria pueden corromper los pesos del modelo o cálculos intermedios incluso cuando el procesador principal sigue funcionando.
El software puede detectar algunos errores mediante sumas de comprobación, ejecución redundante o comparación entre nodos. Esas protecciones consumen cómputo, memoria y energía. Esa sobrecarga debe incluirse al estimar la capacidad útil de un clúster orbital.
La capacidad de reparación sigue siendo la ventaja terrestre más clara. El anterior experimento submarino de Microsoft mostró que los sistemas de cómputo sellados pueden operar de forma remota durante periodos prolongados. Sin embargo, el fondo marino sigue siendo más accesible que la órbita.
Project Natick también se benefició del agua circundante, que evacuaba el calor. Project Suncatcher se enfrenta al entorno opuesto. El espacio mejora la captación solar mientras elimina el medio fluido del que dependen los sistemas de refrigeración convencionales.
Por tanto, la disyuntiva de Google es más precisa que «espacio frente a Tierra». Se trata de energía solar casi continua frente a masa de lanzamiento, refrigeración radiativa, alineación de red y mantenimiento limitado. Cada ventaja genera una factura de ingeniería correspondiente.
Por eso una activación exitosa el 1 de octubre no resolverá el debate. El resultado significativo es una operación sostenida y predecible a lo largo de muchos ciclos. Los ingenieros necesitan saber cómo cambia el rendimiento con la temperatura, la exposición a la radiación y el tiempo.
Google deberá publicar finalmente resultados a nivel de carga de trabajo. Las temperaturas de los chips por sí solas no pueden demostrar si el sistema realizó cómputo valioso. La evidencia más sólida incluiría tareas de inferencia completadas, tasas de error, ciclos de trabajo, consumo energético y recuperación ante fallos.
Hasta que lleguen esas cifras, las afirmaciones sobre la eficiencia de los centros de datos orbitales seguirán siendo condicionales. MVP puede validar componentes individuales, pero una arquitectura de producción debe validar toda la cadena, desde la luz solar hasta una salida de IA útil.
Tres señales decidirán en qué se convierte Project Suncatcher
Los próximos hitos deben demostrar fiabilidad, redes y escalabilidad, en ese orden.
La primera señal es la telemetría de MVP tras el lanzamiento. Google debe confirmar que el satélite alcanza la órbita prevista, establece comunicaciones, alimenta los TPU y completa las cargas de trabajo de IA planificadas. Un lanzamiento exitoso sin cómputo estable debilitaría la afirmación central.
La duración de la operación fiable importa más que la primera demostración. Los ingenieros deberían observar si la radiación produce errores corregibles, si la memoria permanece estable y si el sistema de refrigeración admite ventanas de procesamiento repetidas.
Google también debería revelar con qué frecuencia puede operar MVP. Una sesión de 15 minutos seguida de un breve intervalo de enfriamiento cuenta una historia distinta de un largo periodo de recuperación. El ciclo de trabajo traduce la capacidad de laboratorio en capacidad orbital útil.
La segunda señal es la misión de dos satélites prevista para 2027. Esa prueba debe llevar Project Suncatcher del cómputo aislado a un sistema conectado. Su resultado definitorio será un enlace óptico estable y de alto ancho de banda entre naves espaciales en movimiento.
Una comunicación láser exitosa reforzaría el argumento arquitectónico de Google. Los satélites deberían intercambiar datos mientras mantienen la alineación, la posición y el control térmico. Una demostración limitada con menor ancho de banda dejaría sin resolver la comparación con los centros de datos.
La tercera señal es evidencia de que el diseño escala más allá de prototipos personalizados. Google debe mostrar una ruta creíble desde cuatro TPU en un satélite hasta decenas de chips repartidos entre muchos satélites. Esa ruta necesita fabricación, capacidad de lanzamiento, redes y planificación de reemplazos.
Conviene vigilar la selección de cargas de trabajo como parte de ese plan de escalado. El cómputo orbital presenta su argumento inicial más sólido cuando los datos se originan en el espacio o toleran respuestas demoradas. Presenta un argumento más débil para servicios que requieren interacción constante con usuarios terrestres.
Por ello, un despliegue práctico podría comenzar con imágenes satelitales, análisis meteorológico, sensores científicos u operaciones autónomas de naves espaciales. Esas aplicaciones reducen la demanda de enlace descendente y dan al cómputo local un propósito inmediato.
El entrenamiento de modelos grandes plantea un objetivo más difícil. El entrenamiento exige una comunicación intensa entre aceleradores y acceso a conjuntos de datos enormes. La carga de datos, la sincronización de nodos y la recuperación de tareas interrumpidas pondrían a prueba cada punto débil de la arquitectura.
La inferencia podría llegar antes porque algunos modelos pueden ejecutarse con menor coordinación. Sin embargo, incluso la inferencia depende de actualizaciones de modelos, entrega de entradas, transmisión de resultados y salvaguardas contra salidas corrompidas. La ubicación por sí sola no simplifica la pila de software.
La actualización de la misión de Google de septiembre presenta el vuelo de octubre como un ejercicio de aprendizaje. Esa descripción es precisa. La empresa está recopilando evidencia sobre los puntos de fallo antes de comprometerse con un diseño mayor.
Los lectores deberían considerar el lanzamiento de Google Project Suncatcher como el inicio de un programa de ingeniería, no como la apertura de una nube orbital comercial. La misión importa porque convierte supuestos en mediciones bajo condiciones reales.
Si MVP funciona de forma fiable, el desafío se traslada a los láseres, el control de formación y la escalabilidad. Si presenta dificultades, Google seguirá obteniendo información valiosa antes del experimento más amplio previsto para 2027. Cualquiera de los dos resultados hace avanzar la investigación, aunque solo un éxito sostenido respalda la visión más amplia de un centro de datos.
La pregunta inmediata es sencilla: ¿pueden cuatro chips de IA conocidos seguir produciendo resultados correctos mientras la órbita elimina sus sistemas de soporte habituales? Hay que observar la telemetría, el ciclo de trabajo térmico y la prueba de enlace óptico de 2027. Esos resultados revelarán si Project Suncatcher se está convirtiendo en infraestructura o sigue siendo un experimento instructivo.
