The framing of "machine learning in space" often defaults to the wrong reference point. The mental model is a cloud ML platform — GPU clusters, large model weights, terabytes of training data ingestion, inference APIs with arbitrary latency tolerance. Running that in orbit is not the relevant problem, and the requirements it implies — massive compute, flexible power draw, bidirectional high-bandwidth connectivity — are not compatible with satellite hardware reality.
The actual problem is more constrained and, in some ways, more tractable. Constellation operators running Earth observation or sensor fusion missions need to answer specific questions about specific imagery within a bounded time window. The ML capability required to answer those questions is not general-purpose intelligence. It's a narrow inference task, executed reliably, within a predictable latency, on hardware that fits in a satellite bus payload bay and draws single-digit watts.
What Constellation Operators Are Actually Trying to Do
The use cases that drive demand for onboard inference are concentrated in a few categories. Change detection — flagging areas of an image that differ from a baseline — is the most common. It doesn't require large model weights or high computational complexity; efficient change detection algorithms are well-studied and can be quantized aggressively without unacceptable accuracy loss. The output is a change mask or a set of flagged regions, not a full-resolution processed image.
Object detection and classification at fixed object categories is the next tier. A constellation tasked with vessel monitoring, infrastructure surveillance, or agricultural activity assessment needs to classify a finite set of object types — ships, vehicles, structures — with enough confidence to trigger a priority flag. This is a bounded problem. The operator knows what they're looking for before launch; they don't need a model that generalizes to arbitrary categories. A well-trained, well-quantized classification model for a fixed category set can be far smaller and less computationally demanding than a general-purpose detection architecture.
Sensor fusion — combining data from multiple sensors (optical, SAR, thermal, AIS) to produce a composite alert — is more complex but follows similar principles. The inputs are defined, the fusion logic is operator-specific, and the output is a structured result rather than a processed image. The compute requirement scales with the number of input streams and the complexity of the fusion logic, but again, this is a bounded problem with a bounded compute requirement.
Power Budget as the Binding Constraint
For a 6U CubeSat with a body-mounted solar panel array and a modest battery, total average power generation is in the range of 15–25 W. Allocating 8–10 W to an onboard inference compute module is possible but requires disciplined power management. The inference pipeline cannot run continuously; it runs during the imaging window and sleeps between passes.
This duty-cycle constraint is actually less limiting than it might appear. The imaging window is precisely when inference needs to run — when the sensor is producing data, the inference pipeline processes it. Between passes, there's no data to process and no reason to keep the inference engine active. A well-designed inference module that supports power gating and fast wake-from-sleep can operate within a tight average power budget while providing full processing capability when the satellite is over the target area.
The power constraint does shape model design requirements. A model that requires a 100 ms inference pass at 10 W average power over a 10-minute imaging window draws about 1 Wh per pass — manageable. A model that requires 4 W continuous to maintain context state is a worse architecture for this environment. Stateless inference — where each image frame is processed independently without requiring persistent state between frames — is the more appropriate paradigm for orbit-native inference, both for power reasons and for fault tolerance.
Model Deployment and the Pre-Launch Constraint
The most significant operational difference between orbit-native ML and cloud ML is the model update cycle. In a cloud environment, model updates can be deployed continuously — new weights pushed to production inference servers on any schedule. In orbit, model updates must be uplinked through the command channel, which has limited bandwidth and is shared with all other satellite command traffic. A full model weight update to a satellite running a moderately sized convolutional network is non-trivial in terms of uplink bandwidth, and the verification process for ensuring the update completed correctly and the new model is behaving as expected adds operational overhead.
The practical implication is that the primary inference pipeline should be configured before launch and treated as a mission parameter rather than an operational variable. Operators who expect to frequently update inference models post-launch are setting themselves up for operational complexity that may exceed the benefit. The pre-launch model configuration process — selecting the model architecture, training and validating it against representative imagery, quantizing it for deployment, loading it into the onboard runtime, and verifying end-to-end behavior in a test environment — is where the real engineering effort lives.
We're not saying post-launch model updates are impossible or undesirable. We're saying that treating them as the primary use case drives hardware and software requirements that are significantly more complex than treating pre-launch configuration as the baseline. Building the operational model around pre-launch deployment with post-launch updates as a contingency capability is more realistic for most early-stage constellation programs.
Model Portability and the ONNX Question
Constellation operators develop their ML pipelines in standard training frameworks — PyTorch, TensorFlow, similar environments. The question of how to get from a trained model in one of those frameworks to a running model on orbit-native hardware is a non-trivial integration problem. The answer in TILE's architecture is ONNX as the interchange format: operators export their trained model to ONNX, and the onboard runtime handles quantization and execution scheduling for the specific hardware. ONNX covers most standard layer types for detection and classification architectures; operators using custom layer implementations will need to work through compatibility before assuming portability.
The quantization step deserves specific attention. Moving from FP32 inference (standard in training) to INT8 (appropriate for power-constrained hardware) introduces accuracy degradation that must be characterized against the operator's specific mission requirements before the model is considered flight-ready. Representative target imagery should be used for quantization calibration, not just generic datasets. Operators who skip this step and assume quantization is lossless will be disappointed by their on-orbit classification performance.
Constellation operators entering the onboard inference space for the first time typically underestimate the effort required to go from "we have a trained model" to "we have a validated model that we trust to run in orbit." The gap is real but traversable — it's primarily an engineering and validation effort, not a research problem. The operators who close that gap before launch are the ones who will be able to treat their satellites as compute platforms, not just sensors.
