Skip to content

SYSTEM Cited by 1 source

Project Suncatcher

Project Suncatcher is Google Research's moonshot programme (announced 2025-11-04) for a space-based, scalable AI infrastructure: compact constellations of solar-powered satellites carrying Google TPUs, interconnected by free-space optical links, designed around the physics of continuous orbital solar power rather than the constraints of the terrestrial electricity grid.

"In the future, space may be the best place to scale AI compute. Working backwards from there, our new research moonshot, Project Suncatcher, envisions compact constellations of solar-powered satellites, carrying Google TPUs and connected by free-space optical links." — Google Research, 2025-11-04 (sources/2025-11-04-google-exploring-space-based-scalable-ai-infrastructure)

Framing: work backwards from the energy source

Google's space-based-compute thesis starts from solar physics rather than from cloud economics:

  • The Sun emits "more power than 100 trillion times humanity's total electricity production" — the energy-supply side of the scaling problem is essentially unbounded if the compute can physically reach it.
  • In the right orbit, a solar panel is "up to 8 times more productive than on earth, and produce power nearly continuously, reducing the need for batteries." The combination — higher instantaneous panel yield + near- continuous generation — changes both perf/watt and the energy-storage sizing constraint simultaneously.
  • "This approach would have tremendous potential for scale, and also minimizes impact on terrestrial resources." Terrestrial resources — land, grid capacity, water for cooling — are treated as first-class constraints in the design framing, not sustainability retrofit.

The framing chooses the Sun as the anchor and asks what infrastructure shape reaches it, rather than choosing a datacenter shape and asking how to power it. The wiki's canonical articulation of "work backwards from the physics constraint" applied at the AI-infrastructure scale.

Architectural shape: modular disaggregated constellation

Suncatcher is explicitly a modular disaggregated constellation — "compact constellations of… smaller, interconnected satellites" — not a single large orbital platform:

"By focusing on a modular design of smaller, interconnected satellites, we are laying the groundwork for a highly scalable, future space-based AI infrastructure." — sources/2025-11-04-google-exploring-space-based-scalable-ai-infrastructure

The analogy at the space layer to terrestrial distributed systems' shift from monolithic mainframes to commodity-cluster fleets (systems/borg, et al.): capacity scales by adding satellites, individual satellite failures degrade the constellation rather than taking down the platform, and the unit of replacement / upgrade is smaller and more frequent.

Load-bearing for this shape is the inter-satellite network fabric — FSO links at bandwidths that can host AI-workload traffic (gradient exchange in training; KV-cache / model- parallel intermediate tensors in serving). Without sufficient FSO bandwidth between satellites, the constellation cannot behave as a single logical compute substrate; it decays into isolated single-satellite workloads.

Three named foundational-research challenges

Google lists three problem classes the preprint paper works on:

  1. High-bandwidth communication between satellites. The FSO inter-satellite link problem: achieving AI-workload-sufficient bandwidth between satellites in close formation, under the pointing / tracking / atmospheric-free-space / vibration constraints unique to orbital deployment.

  2. Orbital dynamics. The constellation geometry + station-keeping problem for tightly-spaced satellites. Formation flying at the compactness needed to keep FSO link budgets manageable is a harder geometry than wide-dispersal LEO constellations.

  3. Radiation effects on computing. Commodity TPUs (the chosen substrate) were designed for terrestrial radiation environments; space introduces single-event upsets / transients / latchup / cumulative total-ionising-dose damage at rates terrestrial ECC and retry primitives were not designed for. Mitigation is explicitly framed as open research in the announcement.

Each of the three is a first-class research problem at the physics / hardware layer — the architectural story of Suncatcher is that these must be solved together, because the constellation is a single logical compute substrate only if all three hold simultaneously.

Compute substrate: commodity TPUs, not radiation-hardened silicon

The announced stack is "carrying Google TPUs" — commercial TPUs (systems/google-tpu) rather than a purpose-built radiation-hardened space ASIC. This is a load-bearing stance:

  • Radiation-hardened silicon has historically lagged commercial process nodes by ~2 generations and carried non-trivial perf/watt penalty.
  • Using commodity TPUs keeps the constellation on the commercial-compute density curve — the per-satellite AI-compute density tracks the mainline TPU roadmap.
  • The radiation-tolerance problem is therefore pushed into architectural / software mitigation rather than silicon mitigation — error-correction, redundancy, workload-placement, voting, checkpointing, and similar patterns at the distributed-systems layer. Raw does not enumerate which mitigations Suncatcher adopts — that lives in the preprint.

Relationship to Google's moonshot lineage

The announcement post explicitly anchors Suncatcher to two prior Google moonshots:

  • Large-scale quantum computing — started "a decade ago, before it was considered a realistic engineering goal" (~2015 timeframe).
  • Autonomous vehicles — started "over 15 years ago, which eventually became Waymo and now serves millions of passenger trips around the globe" (~2010 timeframe).

Suncatcher is claimed as the third entry in this lineage — a 10–15-year-horizon research bet whose premise is "this will be an engineering goal eventually; start now." The wiki's canonical serving-AI-infrastructure instance of that category (as opposed to quantum-computing or autonomous-mobility).

Status: research, not production

  • No deployment; no satellite count disclosed; no orbit selected publicly.
  • Announcement + preprint only.
  • Moonshot framing explicitly acknowledges "there will be unknowns."
  • No commercial integration with existing Google commercial compute (Google Cloud / GCP regions / TPU-pod availability zones) disclosed.

What the raw does not disclose

  • Constellation orbit (altitude, inclination, sun-synchronous vs other).
  • Satellite count or per-satellite TPU count.
  • FSO link bandwidth budget (per-link Gbps/Tbps target) or wavelength / modulation.
  • Radiation-mitigation technique (architectural voting, ECC variant, workload redundancy, hardened packaging, none-of-the-above).
  • Training-vs-serving split across the constellation.
  • Terrestrial↔space link topology (downlink bandwidth, ground-station footprint).
  • Target compute density, energy-per-token, or cost model.
  • Deployment roadmap.
  • Relationship to commercial launch / space partners.

All of these live in the preprint paper (not in the raw capture) or in future research output.

Seen in

Last updated · 200 distilled / 1,178 read