SpaceX and Nvidia are reported to have designed a space-optimised version of the Vera Rubin NVL72 system, with a view to launching it into orbit by the end of the year, with a first compute satellite running on it. We wrote on 5 August that this idea was neither absurd nor imminent. The second part of that assessment deserves revisiting.
We devoted a detailed article to space data centers, concluding that the gap between a sixty-kilogram satellite and a multi-gigawatt constellation represented around a decade of engineering. This announcement does not close that gap, but it narrows it faster than expected.
What changes compared with previous demonstrations
Previous attempts were proof-of-concept: a single processor aboard a small satellite, a tiny model trained in orbit. That was impressive and symbolic.
A system of the NVL72 class is a different beast. It is a complete rack architecture, designed to get a large number of accelerators working together over very high-speed interconnects. Adapting that to space constraints implies having dealt with the problems we had identified as blockers.
The problem this implies has been solved
We had insisted on a point most articles ignore: space is not a refrigerator.
A vacuum does not carry heat away. Without air or water, neither convection nor conduction is possible. The only available mechanism is thermal radiation, which is inefficient, forcing the use of radiators that are often bulkier than the solar panels themselves.
A dense rack produces enormous amounts of heat in a small volume. Designing a space version therefore implies having designed a dissipation system up to the task, or having accepted a far lower density. No public information allows us to know which of the two options was chosen, and that is precisely the technical question that decides viability.
The main economic obstacle to orbital compute is the cost of reaching orbit. A player that owns its own launchers and operates them at high cadence removes an intermediary's margin and controls its own schedule. Combined with a compute system designer, that brings together the two necessary skill sets. It is the most credible configuration we have seen on this topic, and it explains why the timeline is accelerating.
What it does not solve
Three questions remain open, and we stand by them.
The environmental footprint. It depends on two unknowns: the real lifespan of the equipment and the carbon cost of launching at the scale envisaged. A satellite that runs for ten years does not have the same footprint as one replaced every three years. Without those figures, no one can decide, and anyone announcing a net balance is selling you a conviction.
Maintenance. On Earth, you replace a faulty card. In orbit, the entire object becomes debris. At rack scale, that means a partial failure can doom the whole unit.
Real-world usage. We had distinguished two regimes: batch training, which tolerates latency, and conversational inference, which does not. A low-orbit system will not serve a voice conversation at 300 milliseconds. Orbital compute targets a specific segment, not the replacement of terrestrial infrastructure.
What it really says
The most interesting point is not technical. It is what this timeline reveals about terrestrial constraints.
We have documented decrees requiring municipal approval, a project blocked over water, and a component shortage. When companies accelerate a space project, it is because the ground has become difficult.
And that reinforces the argument we made in our conclusion three weeks ago. Before seeking to produce more energy for AI, it would remain reasonable to ask what it is for. Most of today's waste is software: an oversized model for a simple task, a context sent without caching, an agent spinning idle. Optimising costs less than a launcher, and requires no orbit.