Project Suncatcher startet ins All – vier TPUs laufen nur 15 Minuten

Google hat in seiner Mitteilung vom 24. September 2026 den geplanten ersten Orbitaltest von Project Suncatcher angekündigt: Ein mit Planet entwickelter Prototyp soll auf der SpaceX-Mission Transporter-18 in eine niedrige Erdumlaufbahn starten. Der Versuch soll zeigen, wie Googles Tensor Processing Units (TPUs) die Belastungen des Starts, Strahlung und die Kühlung im Vakuum bewältigen.

Der Bericht von Ars Technica nennt den 1. Oktober 2026 als geplanten Starttermin und beschreibt vier TPUs im Satelliten MVP, die nur in Phasen von ungefähr 15 Minuten arbeiten sollen, bevor sie zum Abkühlen abgeschaltet werden. Der Flug steht noch aus. Die Laufzeit ist eine Angabe zum vorgesehenen Betrieb, kein bereits im Orbit gemessenes Ergebnis.

Was der einzelne Satellit tatsächlich leistet

Der Prototyp ist eine kleine Testplattform und kein orbitales Rechenzentrum. Der Technikbericht von TechSpot verortet den vorgesehenen Start an der Vandenberg Space Force Base in Kalifornien und beschreibt Solarmodule mit rund einem Kilowatt Leistung. Die Rechenkapazität der Chips entspricht dem Bericht zufolge ungefähr der eines einzelnen Rechenzentrumsservers.

Während der kurzen Betriebsphasen sollen die TPUs einfache Anfragen mit Googles KI-System Gemini verarbeiten. Das gibt dem Test eine tatsächliche Rechenaufgabe, macht den Satelliten aber noch nicht zu einem dauerhaft verfügbaren Dienst. Vor allem zeigt die Kombination aus begrenzter Stromversorgung und nötigen Kühlpausen, wie klein der erste Maßstab gegenüber der langfristigen Idee eines Rechnerverbunds ist.

Planet stellt die Satellitenplattform bereit, Google die KI-Hardware für den Versuch. Dadurch kann das Projekt zunächst an einem einzelnen Raumfahrzeug untersuchen, ob sich die Komponenten überhaupt gemeinsam betreiben lassen. Aus einem erfolgreichen Start allein folgt noch keine Aussage darüber, wie zuverlässig die TPUs über längere Zeit rechnen oder wie viel Arbeit spätere Satelliten übernehmen könnten.

Welche Belastungen der Flug prüfen soll

Ein Teil der Prüfung beginnt schon auf der Rakete. Starke Vibrationen und Beschleunigung beanspruchen die Elektronik, bevor der Satellit seine Umlaufbahn erreicht. Bei Bodentests wurde das Raumfahrzeug in mehreren Richtungen geschüttelt; die Hardware hielt diesen simulierten Belastungen stand. Der tatsächliche Start bleibt dennoch ein eigener Test für das vollständig integrierte System.

Im Orbit kommt Strahlung hinzu. Energiereiche Teilchen können gespeicherte Bits verändern und so Fehler in Programmen oder Berechnungen auslösen. Trillium-TPUs wurden bereits während laufender KI-Aufgaben einem Protonenstrahl ausgesetzt. Solche Versuche liefern Hinweise auf die Widerstandsfähigkeit der Chips, bilden aber den gleichzeitigen Betrieb von Elektronik, Stromversorgung und Kühlung auf einem Satelliten nur teilweise ab.

Entscheidend sind deshalb die Daten aus dem Flug: Bleiben die Komponenten nach dem Start funktionsfähig, und treten bei Rechenaufgaben unter den Bedingungen des Orbits Fehler auf? Ebenso wichtig ist, ob sich ein Fehler erkennen und der Betrieb fortsetzen lässt. Der Prototyp soll Antworten auf diese Hardwarefragen liefern; die Leistungsfähigkeit eines ganzen Satellitenverbunds kann er nicht erproben.

Warum nach 15 Minuten eine Kühlpause nötig ist

Die begrenzte Laufzeit hängt am Wärmehaushalt des Testsystems. TPUs erzeugen beim Rechnen viel Wärme auf engem Raum. In einem Rechenzentrum können Kühlsysteme sie mit Hilfe von Luft oder Flüssigkeit abtransportieren. Im Vakuum gibt es keine umgebende Luftströmung; die Wärme muss innerhalb des Satelliten zu einem Radiator geleitet werden, der sie als Strahlung abgibt.

Beim Prototyp verbinden wärmeleitende Materialien die Chips mit Bauteilen aus Aluminium und Kupfer, die die Wärme zum Radiator führen. Während die TPUs arbeiten, fällt Wärme schneller an, als das kompakte System sie dauerhaft abführen kann. Anschließend müssen die Prozessoren pausieren, damit der Radiator aufholen kann. Die geplanten Betriebsfenster beschreiben somit diesen Aufbau und keine allgemeine physikalische Laufzeitgrenze für TPUs im All.

Ein Kühlansatz wurde bereits in einer thermischen Vakuumkammer am Boden erprobt. Dort lassen sich Vakuum und Temperaturbedingungen nachbilden, doch erst der Flug verbindet sie mit den übrigen Bedingungen der Mission. Noch unbekannt ist, wie sich wiederholtes Rechnen und Abkühlen tatsächlich auswirkt und wie lange die Pausen zwischen den Betriebsphasen dauern müssen.

Was bis zum orbitalen Rechnerverbund fehlt

Project Suncatcher untersucht langfristig, ob Satelliten gemeinsam größere KI-Aufgaben bearbeiten können. Dafür müssten künftige Raumfahrzeuge erheblich mehr Chips tragen und Daten schnell untereinander austauschen. Vorgesehen sind Laser-Verbindungen zwischen Satelliten, die ihre Positionen zueinander präzise kennen müssen. Der einzelne MVP-Satellit prüft weder einen solchen Datenaustausch noch den gemeinsamen Betrieb einer Konstellation.

Auch die Kühlung würde mit mehr Rechenhardware zu einer anderen Größenordnung von Aufgabe. Mehr Chips bedeuten mehr abzuführende Wärme; die Ergebnisse eines kompakten Prototyps lassen sich deshalb nicht einfach auf einen großen Verbund übertragen. Hinzu kommen Fragen nach Stromversorgung, zuverlässigem Dauerbetrieb und der Abstimmung zwischen mehreren Raumfahrzeugen. Der erste Flug kann für diese späteren Entwürfe Messdaten liefern, aber ihre technische oder wirtschaftliche Tragfähigkeit nicht belegen.

Der nächste konkrete Schritt ist der geplante Start des Testsatelliten. Danach werden vor allem Messungen zu Startbelastung, Strahlungsfehlern und wiederholten Rechen- und Kühlphasen zeigen, welche Teile des Systems funktionieren und was geändert werden muss. Bis solche Daten vorliegen, bleibt das Rechenzentrum im All eine Forschungsabsicht; bestätigt ist ein bevorstehender Hardwaretest in kleinem Maßstab.

Lesen Sie auch:

• Pixxel erhält 100 Millionen Dollar – vier Geschäfte ersetzen den Satellitenfokus
• ESA vergibt 760-Mio.-Auftrag – nur 310 Millionen sind zunächst fest
• Meeting-Panne kostet 12,2 Minuten – IT wird meist zu spät beteiligt