The link comes first
On 1 October 2026 a prototype satellite went into orbit to test how AI chips cope with radiation and temperature. It is a real experiment, and it is one satellite. Our evidence report on signals, fibre and satellites sets out what it does and does not show.
The lesson for anyone building with AI today is less exotic. Every model sits on top of a link, and the link decides how fast an answer can come back, how much data can reach the model, and what happens when the connection drops. Decide that first, and the question of where the model should run mostly answers itself.
1. Know what the link gives you
Three numbers describe a link well enough to design against. Measure them where the system will actually run, not in the office.
- Delay. Starlink puts a low-orbit satellite link at around 25 ms and a geostationary one above 600 ms. A voice assistant can live with the first and not with the second.
- Capacity. A camera produces far more data than most remote links can carry. If the raw data cannot travel, the model has to go to the data.
- Availability. Cables break and clouds interrupt laser links to the ground. Ask how often the link is down and for how long, and get the answer from logs.
2. Put the model where the data is
There are three places a model can run, and most systems end up using more than one.
- On the device or at the edge, when the delay budget is tight or the raw data is too large to send. Models are smaller here, so measure what accuracy you give up.
- At a gateway or regional site, when several devices share one model and the link to them is good.
- In a data centre, when the work is heavy and can wait. This is still where almost everything runs, on the far side of fibre that carries over 99% of international data flows.
3. Design for the link failing
A system that only works with a perfect connection will fail in the field. The behaviour during an outage has to be designed, and then tested by pulling the plug.
- Queue and resume. Work that cannot be sent waits in a durable queue and goes when the link returns, in order and without duplicates.
- Degrade on purpose. A smaller local model answers when the large one is out of reach, and says that it is the fallback.
- Monitor the link like a model. Track delay, loss and outage time next to accuracy and drift, and alert on a trend before it becomes a failure.
4. What orbit changes, and what it does not
Computing in orbit is the same decision taken one step further: run the model next to data that is already in space, and send down only the result. Where that fits, it is a sensible idea.
- It suits data that starts in orbit, such as Earth observation, where sending every raw image down is the bottleneck.
- It does not remove the hard parts. Heat leaves only through radiators, hardware cannot be repaired, and results still need a link to the ground.
- It is not a reason to change plans now. What exists is a prototype reported by the company that built it, with more tests planned for 2027.
Where to start
Pick one model that matters and write down the delay it can tolerate, the data it needs and what should happen when its link is down. Measure the real link against those three lines. The gap between them is the work.
The full analysis, with the source for every figure and six step-through diagrams from the voice to the satellite, is in the evidence report.
Blog
Insights, frameworks and strategies from Algorythmos on AI, security and data innovation.
