TerraByte went to the Small Satellite Conference in Salt Lake City with one question: where is on orbit AI inference actually heading? The short answer is that the compute problem is solved and the data movement problem is not. Satellites can run useful models in space today. They still cannot send most of what they see.
What is on orbit AI inference?
On orbit AI inference is the practice of running a machine learning model on the satellite itself rather than downlinking raw imagery and running the model on the ground. The purpose is narrow and economic: decide what is worth transmitting before paying to transmit it.
That framing matters because an Earth observation satellite is a very productive sensor attached to a very narrow pipe. Sensor capability has outrun downlink capacity. On orbit inference is the industry's attempt to close that gap by moving the first filtering decision off the ground and into space.
SmallSat has been the small satellite industry's main gathering since 1987. TerraByte spent two days there and roughly twenty conversations on this single question. The answers converged, and they pointed away from the processor.
Why is bandwidth, not compute, the bottleneck for satellite AI?
The constraint on satellite AI is downlink bandwidth, not onboard processing power. Loft Orbital's software CTO put the storage side plainly: "a gig is nothing." Storage is cheap. Getting bits to the ground is not.
The numbers TerraByte collected at SmallSat 2026 make the imbalance concrete:
| Component | Figure reported at SmallSat 2026 |
|---|---|
| Camera output rate | 5.5 Gbps |
| Time to clear that camera's buffer on the radio its bus vendor ships today | about 38 hours |
| Intel Starfire space processor | 4 grams, 10 to 35 watts |
| ISI onboard vision language model | 3.8 billion parameters, 1.6 seconds per scene, about 15 watts total system power |
A camera that produces 5.5 Gbps and needs roughly 38 hours to clear its buffer is not facing a compute problem. It is facing a queueing problem. Every additional pixel the sensor collects makes the queue longer, and no processor upgrade shortens it.
Space grade silicon is no longer the limiting factor. Intel's new space processor, Starfire, draws 10 to 35 watts across its two configurations. Nobody at SmallSat described themselves as short of compute. One caveat deserves stating precisely, because it is the kind of detail summaries flatten: Intel lists Starfire's radiation data as characterization in process, so the part is not radiation qualified yet. In this industry "available" and "flight qualified" are different dates. A part you can buy is not a part you can fly, and mission schedules turn on that distinction.
What can a satellite actually run onboard today?
A satellite can run a multi billion parameter vision language model in space today, inside the power and thermal budget of a small spacecraft payload computer. ISI (ImageSat International) showed an onboard vision language model built on Gemma 3n, Google's open model family for on-device use, with these characteristics:
- 3.8 billion parameters, running on the spacecraft
- 1.6 seconds to classify a scene
- About 15 watts total system power
- Deterministic output on every run, meaning the same input produces the same result
ISI's SmallSat 2026 paper, Payload Operation Using On-Board Vision Language Model, reports end to end inference latency below two seconds on imagery acquired in orbit, running on an NVIDIA Jetson Orin based payload processor.
The determinism point separates a demonstration from a deployment. Repeatable output is what makes an onboard model auditable. If the same scene produces the same classification every time, an operator can reason about what the spacecraft did and why. ISI presented this as deployable, not as a laboratory result.
The ground side of this pipeline operates at a different order of magnitude. TerraByte ingests Earth observation data continuously, indexes more than 15 million events daily, and serves natural language queries against that index at roughly 0.4 second latency. Onboard models decide what leaves the spacecraft. Systems like TerraByte's index decide what a person can find once it arrives.
Why do onboard models do tip and cue instead of full analysis?
Onboard satellite models are built for tip and cue, not autonomous exploitation. The model in orbit emits a hint, not evidence. It flags that a scene may contain something of interest and lets a system on the ground decide what that something is.
This changes how the model is tuned. Teams optimize for recall over precision, accepting false positives to avoid missing real detections. The asymmetry is severe: a false positive costs bandwidth, while a false negative costs the observation permanently, because a scene that is never downlinked is never recoverable.
The routing decision, meaning what to do with the hint, sits in an agent after the model rather than inside it. Two consequences follow:
- The onboard model stays small, stable, and testable, because it only has to answer "is this worth a closer look?"
- The judgment about what counts as interesting lives in software that can change without touching flight hardware
A further constraint shapes the whole design. Models get preloaded before launch. There is no persistent connectivity in orbit, so the set of questions a satellite can answer is fixed before the rocket leaves the pad. Updates ship as weight diffs measured in kilobytes, not as new models. The practical effect is that the tasking question is decided months before the imagery exists.
What is still unsolved in Earth observation AI?
The open problem in Earth observation is not running models in space. It is the layer that decides what the satellite should be looking for in the first place.
The hardware argument is effectively over. Processors are small enough, power budgets close, and a 3.8 billion parameter model classifies a scene in under two seconds on a payload computer. What remains unresolved sits upstream of all of it: given finite bandwidth, finite onboard model capacity, and questions fixed before launch, how does an operator express what matters right now?
That is a search and tasking problem, not a silicon problem. TerraByte works on the ground half of it. TerraByte is an Earth search engine: a single JSON endpoint that takes a plain English query such as "oil storage tanks" and returns ranked imagery matches with latitude, longitude, year, and a relevance score, with no STAC (SpatioTemporal Asset Catalog) filters, GIS expertise, or SDK required.
Most satellite imagery access today is structured query. STAC catalogs, Sentinel Hub, and NASA GIBS all require the user to know the parameters of what they want before they can ask. That model works when the question is known in advance. It works less well when the question is "show me everything that looks like this, anywhere, across the archive."
TerraByte's position is that natural language search over the archive and better tasking logic in orbit are the same problem seen from opposite ends. Both are about expressing intent to a system holding more data than it can move. Neither is solved by a faster chip.
The five things TerraByte took home from SmallSat 2026:
- The bottleneck is the pipe, not the processor. Bandwidth constrains everything downstream.
- Silicon is no longer the hard part, though "available" and "flight qualified" remain different dates.
- The power and latency budget closes. A 3.8 billion parameter model runs in under two seconds on a spacecraft payload computer.
- Onboard inference lands on tip and cue. The model emits a hint, and an agent after the model does the routing.
- Models are preloaded before launch, so the questions a satellite can answer are set before the rocket goes up.
Developers can run live queries at portal.terrabyte.ai, and TerraByte's use cases cover the applications this indexing supports today.