The 15-Minute Space TPU: Why Orbital Data Centers Are a Radiator Problem

Google's first Project Suncatcher prototype satellite has reached orbit on SpaceX's Transporter-18 rideshare mission. The spacecraft, built with Planet Labs and roughly the size of a refrigerator, carries four Google TPUs. Google says the ground team has made contact and that the satellite is operating as expected.

The detail that traveled fastest was this: the TPUs can run for about 15 minutes, then must shut down while the radiator rejects the heat. That sounds like a thermal failure in orbit. It is not. The 15-minute window was written into the mission profile before launch. Google designed an intermittent operating cycle because, in vacuum, the radiator rather than the chip sets the long-run compute ceiling.

That distinction matters. It moves the question from "can a TPU survive space?" to "what kind of system can run continuously in space?" A data center is judged by sustained average power, not by a 15-minute burst. On that measure, the radiator is the main character.

Three problems, one still open

Google's public test results divide the engineering risk into three buckets.

Launch vibration: the TPU assembly passed three-axis vibration testing, with local loads of 50 to 100 g. Google's team described the result as better than expected.

Radiation: at UC Davis, Google ran the Trillium TPU under a proton beam while it was executing workloads. The chip absorbed a total ionizing dose exceeding the cumulative dose of a five-year mission. That is a positive early signal for inference workloads. Training would face a higher risk profile.

Heat rejection: Google tested the thermal path in a thermal vacuum chamber. The result was an intermittent operating mode. Vibration and radiation have fairly clear answers. Heat is being bypassed by duty cycle.

Why the radiator sets average compute

In space, there is no air convection and no atmospheric sink. Heat moves from the chip through heat pipes to a radiator, then leaves as infrared radiation. The radiator's continuous rejection rate is fixed by its area, its temperature, and its emissivity. The Stefan-Boltzmann relationship makes temperature the dominant term: rejection scales with the fourth power of absolute temperature.

A rough estimate shows the scale. At a radiator surface temperature of 20°C (293 K) and emissivity 0.9, one square meter rejects about 376 W on one side. Two sides give roughly 750 W before accounting for Earth infrared and albedo inputs. The net figure is lower, around 600 W per square meter in a realistic low-Earth-orbit environment.

A ground-based high-density AI rack now draws well over 100 kW. At 600 W per square meter net, one such rack maps to nearly 170 square meters of radiator area. That is one rack.

This is why a space data center is a radiator-area project. The compute boards are a small part of the mass and volume. Most of the structure goes to radiators, heat pipes, and deployment mechanisms. Google's project lead has said the radiator is one of the heaviest components on the prototype. In an industry that charges by launch mass, the heaviest component also sets the compute ceiling. The economics follow the radiator.

The design logic also flips. On the ground, cooling engineers push chip temperatures down: colder water, lower PUE, lower junction temperature, less leakage, longer life. In space, a hotter radiator is better. Raising the radiator surface from 20°C to 60°C (333 K) lifts single-side rejection from about 376 W per square meter to about 627 W per square meter, an increase of nearly 70%.

A space-optimized compute chip should tolerate higher junction temperatures and accept a modest efficiency penalty in exchange for radiator mass reduction. Today's TPUs and GPUs are optimized for ground data-center temperature windows. Sending them up is a test under the wrong conditions. For a prototype, that is acceptable. For a scalable architecture, it is not.

The long-run metric changes accordingly: from performance per watt to sustained performance per square meter of radiator area, or sustained performance per kilogram of launched mass.

The duty cycle does not create extra compute

The heat sink, heat pipes, and structure have thermal capacitance. During the 15-minute run, the chip's heat output exceeds the radiator's continuous rejection rate. The difference goes into thermal capacitance, and the temperature rises. When the chip shuts down, the radiator drains that stored heat. Averaged over a full run-and-cool cycle, the continuous heat rejection equals the radiator's capacity.

The burst does not add a watt of long-run compute. It moves the radiator's capacity into a 15-minute window. For a single inference demo, one question and one answer, 15 minutes is enough. For a data center, the number that matters is the average. That number is set by radiator area and temperature.

What the orbital test should measure

Google says the satellite will run the Gemma open-weight model to observe how the chip behaves in space. The thermal chain matters more than the model output.

Three measurements matter more than benchmark scores. First, whether thermal interface materials degrade under vacuum and repeated thermal cycling. Second, how far heat-pipe performance in microgravity diverges from ground measurements. Third, whether the 15-minute window shrinks over a year. A shrinking window would indicate thermal-path degradation. That is a more serious problem than radiation-induced bit flips, because it directly erodes average compute.

Google plans to launch two more satellites in 2027 to test high-bandwidth laser inter-satellite links and formation flying. That work is as important as heat rejection. A single satellite has a fixed radiator area. Scaling means multiple satellites. The inter-satellite bandwidth determines whether dozens of satellites can operate as one cluster. One problem decides whether the system can connect; the other decides how much sustained compute the connected system can deliver.

The economics: rockets and radiators, not chip iteration

Google's own cost model sets a hard precondition. For a space data center to be cost-effective, Starship would need to complete about 1,800 launches over 10 years, roughly 180 per year, with each launch carrying about 200 metric tons. Starship has not yet demonstrated an annual cadence anywhere near that.

Google's paper argues that with launch costs around $200 per kilogram, space-based compute could compete with ground on energy cost by the mid-2030s. That conclusion covers energy cost. It does not fully account for radiator mass, orbital lifetime, or the impossibility of repair. Google's project lead has said the system will not be cheaper than ground within five years. That is a realistic statement.

More optimistic models, including some from Deutsche Bank, see the cost gap narrowing to about 1.2 times ground by 2029 and flipping by 2032, assuming Starship reuse proceeds smoothly. Every such projection rests on the same premise: launch cost falls by an order of magnitude.

The radiator enters the same arithmetic from the other side. In traditional spacecraft thermal systems, radiators can account for a large share of thermal-management mass. Only when high-temperature chips and lightweight deployable radiators raise sustained compute per kilogram by an order of magnitude does unit compute cost approach ground levels. The turning point may come from aerospace manufacturing, not semiconductor manufacturing.

The near-term use: orbit-side filtering

Before the thermal bottleneck and the launch economics are solved, a space data center will not replace a ground data center. It has a nearer use that matches intermittent operation: in-orbit data filtering and edge inference.

Planet Labs operates a remote-sensing constellation. Its satellites produce far more imagery than downlink bandwidth can carry. An on-orbit model can discard cloud-covered frames and downlink only changed areas. That task is trigger-based and intermittent. A 15-minute operating window fits it. Google's choice of Planet as a partner likely reflects this logic.

The same pattern applies to maritime and aircraft detection, disaster-change detection, and beam scheduling on communication satellites. The data is produced in space; the decision needs to be near the data; downlinking everything is neither economic nor necessary. Space compute becomes useful before it becomes large.

Competition and the open question

Starcloud has already tested an Nvidia H100 in orbit. SpaceX has announced plans to deploy the Starmind AI1 satellite in 2027 with Nvidia chips, 120 kW of continuous compute, 150 kW peak, and about 110 square meters of deployable liquid-cooled radiator. That power level matches a ground high-density AI rack. SpaceX's route uses Starlink platform technology to lower risk and push down cost per satellite. Google's route is cautious validation. Starcloud's route is agile iteration. The winner will be the one that proves a workable economic model for sustained compute per launched kilogram.

The split judgment is straightforward.

Over the next three to five years, the main battlefield is in-orbit edge inference: remote sensing, communications, and other tasks where data is produced where it must be processed. The keyword is validation and use, not replacement. The 15-minute window is an engineering reality, and it is acceptable when the task itself is intermittent.

From the mid-2030s onward, whether space data centers become a scalable alternative or parallel option to ground facilities depends on Starship pushing launch cost below $200 per kilogram and on lightweight deployable radiators reaching low-cost mass production. Chips matter. They are not the only variable. A space data center is a radiator-area project. Its economics is first an arithmetic problem of launched mass and manufacturing yield.

The most useful data from Google's prototype will not be how Gemma answers a prompt from orbit. It will be whether the 15-minute window is still 15 minutes after a year of thermal cycling. That number will decide whether the architecture remains a demo or becomes infrastructure.