Google puts four Trillium TPUs in orbit

Google has launched the first orbital prototype for Project Suncatcher, its research program for space-based AI computing. Built with Planet, the spacecraft rode SpaceX’s Transporter-18 mission from Vandenberg Space Force Base and deployed about an hour after liftoff. Ground controllers established contact and reported that the satellite was operating as expected.

The flight adds in-orbit telemetry to Google’s laboratory tests of Trillium Tensor Processing Units. The refrigerator-sized spacecraft carries four TPUs and will run short Gemini inference workloads while engineers measure radiation errors, power consumption and heat rejection.

Project Suncatcher’s proposed end state is a constellation in which satellites carrying dozens of accelerators cooperate on training or inference. The current mission, designated M1, tests one small compute slice and has no inter-satellite peer.

Why orbit offers more solar power

Google estimates that a solar panel in the target orbit could receive up to eight times as much usable solar energy as a comparable terrestrial installation. A dawn-dusk sun-synchronous orbit keeps a spacecraft in near-continuous sunlight, avoiding most nighttime, cloud and atmospheric losses.

Near-continuous generation could ease the power constraints affecting terrestrial AI expansion, including limited grid connections and competition for new generation capacity. Orbit introduces separate constraints, particularly launch mass, radiation exposure and cooling without air.

Inside M1’s refrigerator-sized payload

Launch, radiation and heat set the limits

Launch loads

Before flight, Google vibration-tested the satellite along all three axes to reproduce Falcon 9 launch conditions. Individual components experienced accelerations of 50 to 100 times Earth’s gravity. M1 will show whether connectors, memory, power systems and cooling hardware continue working after launch and sustained orbital operation.

Radiation exposure

Google tested Trillium TPUs at the Crocker Nuclear Laboratory at the University of California, Davis, using a 67 megaelectronvolt proton beam. The beam reproduces one class of energetic particles that can corrupt data or damage semiconductor components in space.

High-bandwidth memory irregularities appeared after a cumulative dose of 2 krad(Si), a measure of ionizing energy absorbed by silicon. One TPU showed no hard failure attributed to total ionizing dose through 15 krad(Si), which Google says exceeds the expected dose for a five-year mission.

Memory behavior matters because model throughput depends heavily on how quickly parameters move between high-bandwidth memory and the accelerator. Possible safeguards include error-correcting code memory, redundant computation, frequent checkpoints, workload retries and software that quarantines unreliable devices.

Heat rejection

Vacuum eliminates convective cooling, so nearly every watt consumed by the electronics must leave through radiators. M1 uses heat pipes and radiator surfaces, with the TPUs scheduled to run in short bursts before cooling. A larger satellite would require more radiator area and thermal transport capacity, adding mass and constraining the placement of chips, solar panels and communications hardware.

Lasers determine whether the cluster can scale

An orbital cluster needs inter-satellite links fast enough to move model parameters, activations and checkpoints between accelerators. Google’s bench-scale optical system reached 800 gigabits per second in each direction through one transceiver pair, providing 1.6 terabits per second of aggregate bidirectional capacity.

Maintaining that throughput requires two moving spacecraft to keep narrow laser beams precisely aligned despite vibration, formation drift and attitude adjustments. Existing optical space links generally prioritize long-distance communication at lower bandwidths. Suncatcher requires much higher bandwidth across shorter distances between satellites flying in formation.

M1 has no second satellite with which to test an optical crosslink. Orbital validation therefore depends on the planned follow-up mission.

What one satellite can measure

M1 can provide error rates, component temperatures, power profiles and evidence about how long commercial AI accelerators remain usable in low Earth orbit. Those measurements will help Google estimate thermal limits, hardware redundancy and expected service life for a larger design.

Questions beyond M1

• Economics: Cost per useful unit of compute after spacecraft manufacturing, launch, ground infrastructure and replacement missions.
• Scale: Radiator mass, solar-panel area and formation-control requirements for satellites carrying dozens of TPUs.
• Ground connectivity: The cost, bandwidth and latency of uploading data and returning results.
• Service life: Long-term degradation of memory, solar panels, optical hardware and thermal systems.
• Orbital operations: Collision avoidance, constellation management and reliable deorbiting at end of life.

Software has to expect dropouts

An orbital TPU cluster would need software designed around intermittent links, thermal pauses and hardware faults. Conventional data center assumptions about stable nodes and continuously available network paths would be unreliable in that environment.

• Fault-tolerant inference: Retry failed operations, detect corrupted outputs and remove unreliable chips without stopping an entire job.
• Thermal scheduling: Assign work according to radiator capacity, chip temperature and available solar power.
• Model partitioning: Place parameters and operations to limit traffic across constrained optical links.
• Checkpointing: Preserve recoverable state when satellites lose contact or pause compute.
• Dynamic routing: Redirect traffic as formation geometry and link availability change.

M1’s telemetry can supply the failure rates, cooldown times and power limits needed to design those policies. The two-satellite mission would add real measurements for link stability, throughput and recovery after interruptions.

Terrestrial constraints drive the experiment

Large AI data centers face limited grid connections, lengthy power contracts, water constraints and local permitting. Other proposals include data centers supplied directly by nuclear plants and sealed computing modules placed underwater. Project Suncatcher explores whether near-continuous orbital solar power can support another deployment model.

Google contributes the accelerators and distributed-systems research, Planet supplies small-satellite engineering, and SpaceX provides rideshare access to orbit. Any commercial design must also account for launch expense, difficult repairs, hardware replacement, debris management and dependence on ground networks.

The next flight tests the network

Google Research plans to launch two prototype satellites with Planet by early 2027. That mission is intended to test the high-bandwidth optical link, formation flying and distributed workloads across separate spacecraft.

Combined data from M1 and the two-satellite flight could support realistic estimates for cluster size, radiator capacity, network topology and fault budgets. Google has not published a schedule for production workloads or a commercial orbital computing service.