The Pulse
Satlyt Runs Google’s Gemma 3 1B Model on a Satellite
Satlyt has deployed a quantized Google Gemma 3 1B model aboard a satellite to analyze telemetry, system logs and software faults in orbit. In fault-injection tests, the onboard system cut diagnostic data sent to Earth by about 64% while gen

AI.info Team ·
Satlyt’s onboard AI system reduced two satellite diagnostic payloads by 64.4% and 64.8% in fault-injection tests, turning more than 1,300 bytes of raw troubleshooting data into fewer than 470 bytes of summarized information. The company achieved those results by deploying a quantized version of Google’s Gemma 3 1B language model on a satellite, where it analyzes telemetry, software logs and stack traces without waiting for the data to reach Earth.
The deployment represents a practical use of a small language model in orbit: not commanding a spacecraft or replacing flight software, but helping operators understand failures under severe limits on bandwidth, memory, power and communication time. Satlyt runs Gemma through the open-source llama.cpp inference framework and uses it to produce concise explanations of software errors generated by onboard image-processing workloads.
Google DeepMind detailed the work in a case study published on its Gemma site. Nelson Kigen Psenjen, Satlyt’s chief technology officer, said the company is focused on making onboard AI operate within the physical limits of spacecraft rather than treating orbit as a conventional cloud-computing environment.
“Our focus is on making onboard AI practical under real spacecraft constraints. With Gemma, we are evaluating how smaller, efficient models can analyze telemetry, system logs, and faults locally while staying within strict power, thermal, and memory limits.”
— Nelson Kigen Psenjen, CTO, Satlyt
Satlyt’s 1,319-Byte Fault Became a 469-Byte Diagnosis
Satlyt evaluated the system by introducing common failures into an image-processing pipeline and feeding Gemma a combination of telemetry, system logs and stack traces. In one representative test, the input described a spacecraft using 99.6% of its available RAM alongside an OutOfMemoryError caused by an attempt to allocate 144,000,000 bytes while processing a 12,000-by-12,000-pixel image.
Gemma condensed that diagnostic context from 1,319 bytes to 469 bytes, a 64.4% reduction. The model generated at 22.71 tokens per second and returned a root-cause explanation with a recommended action, rather than simply forwarding the full log for a ground operator to interpret.
A second test simulated a camera hardware failure. Telemetry showed nominal computing resources, while the kernel reported that the satellite’s I2C interface received no acknowledgment from address 0x36; the image-capture process also returned an OSError: [Errno 121] Remote I/O error.
That payload fell from 1,318 bytes to 464 bytes, a 64.8% reduction. Gemma generated at 25.48 tokens per second and again produced a compact diagnosis based on the interaction between the telemetry snapshot, the operating-system warning and the application error.
What Satlyt has demonstrated: a small language model can summarize multi-source spacecraft diagnostics onboard, reducing the amount of information that must be transmitted to ground operators while preserving the details needed for initial troubleshooting.
Why Local Diagnosis Matters in Orbit
Satellites do not maintain the continuous, high-capacity network connection expected by most terrestrial AI applications. Communication depends on available ground-station passes, orbital position and the bandwidth assigned to a mission. Sending every raw log, stack trace and telemetry record back to Earth can consume limited downlink capacity and delay the point at which an operator understands what went wrong.
Satlyt’s approach moves the first stage of interpretation onto the spacecraft. Instead of transmitting an entire exception report, the satellite can send a shorter explanation that identifies the likely failure and proposes a response for human review. The company describes the benefit as extracting high-value operational context before the data leaves orbit.
The distinction matters during faults that affect image-processing workloads. A satellite may generate large volumes of information while analyzing imagery, yet only a small portion of the logs may explain why a process stopped or why a sensor failed. A local model can examine those related signals together, then send a compact result during the next available communications window.
Satlyt’s system does not give Gemma direct control over the spacecraft in the demonstration described by Google DeepMind. The model serves as an analysis layer for telemetry and software failures, leaving commands and operational authority with spacecraft operators.
Gemma 3 1B Fits a Narrow Spacecraft Budget
Satlyt selected Gemma after evaluating multiple small language models. The company says the model offered a useful combination of reasoning performance and a small enough footprint for hardware that must share memory and power with sensors, communications systems and other flight services.
Quantization reduces the numerical precision used to represent model parameters, allowing the model to occupy less memory and run on less capable hardware than a full-precision implementation. Satlyt’s deployed Gemma 3 1B model runs through llama.cpp, a framework commonly used to execute language models locally on a range of constrained devices.
The company is now evaluating Gemma 4 E2B on an NVIDIA Jetson Orin Nano as a next phase of the project. In the configuration described by Google DeepMind, the model uses about 4 gigabytes of peak RAM on a system with 8 gigabytes available, leaving capacity for other onboard services.
Active inference raises total processor power consumption to approximately 11 watts, compared with a baseline of about 4 watts. Satlyt measured a processor temperature increase of roughly 3 to 5 degrees Celsius and recorded ground-test generation speed of 19.08 tokens per second for the Gemma 4 E2B evaluation.
Those figures expose the engineering tradeoffs behind orbital AI. A model that works well on a desktop may still consume too much power, memory or thermal capacity on a satellite. Spacecraft cannot rely on air cooling, and their processors must operate alongside mission hardware within a fixed electrical and thermal budget.
From Quantization to Pruning and Distillation
Satlyt is not treating quantization as the final optimization step. The company is also working on pruning and distillation, two techniques that can remove unnecessary components or train a smaller model to reproduce the behavior of a larger one.
For diagnostic workloads, Satlyt is targeting a model-memory reduction of more than 90%. Its broader work aims to reduce the memory envelope for individual managed onboard AI services by approximately 85% to 90%, which could allow several specialized workloads to share the same computing platform.
That specialization could matter more than deploying a single general-purpose assistant. A model designed only to interpret camera faults may need fewer capabilities than one expected to summarize telemetry, understand imagery, parse inter-satellite messages and coordinate tasks. Smaller task-specific systems could run concurrently while preserving resources for the primary payload.
Satlyt says it is also evaluating instruction-tuned models, fine-tuning, layer reduction and additional inference optimizations. The near-term objective is to extend the diagnostic workflow into onboard anomaly detection, summarization and decision support, with operators retaining authority over spacecraft commands.
Satlyt’s Plan for 50 Spacecraft
Google DeepMind says Satlyt has software packages prepared for deployments on up to 50 spacecraft in 2026. The figure describes the company’s planned software reach, not a claim that 50 satellites are already running Gemma or that all deployments will use identical hardware.
Satlyt’s wider business focuses on distributed computing infrastructure for spacecraft. Its software is intended to let satellites process and validate data close to where it is created, reducing dependence on ground-based processing and supporting coordination across orbital systems.
Founder and chief executive Rama Afullo framed the Gemma deployment as part of that broader effort.
“Space systems are one of the clearest examples of why local AI matters. You cannot always rely on cloud connectivity, and you cannot afford to downlink every raw log, stack trace, or telemetry stream.”
— Rama Afullo, Founder and CEO, Satlyt
The company refers to its long-term concept as “Virtual AI Data Centers in Space,” but the Gemma 3 1B demonstration is narrower and more concrete. It shows a language model interpreting operational data on a satellite, reducing diagnostic traffic and generating useful output at roughly 23 to 25 tokens per second in the reported tests.
What the Demonstration Does—and Does Not—Prove
Satlyt’s results establish that a quantized small language model can run onboard a satellite and summarize injected software faults under constrained conditions. They do not establish that the model can independently recover from failures, operate without supervision or replace conventional fault-management software.
Fault-injection benchmarks also differ from long-duration flight operations. A production system would need to handle changing workloads, radiation effects, unexpected sensor behavior, model errors and the consequences of acting on an incorrect diagnosis. Operators would also need confidence that a concise summary has not omitted a detail needed to distinguish between similar failures.
The most immediate value lies in reducing the time and bandwidth required for the first diagnosis. A satellite that can send a short, structured explanation instead of a complete raw log may give ground teams a faster starting point, particularly when a communications window is brief or a mission is operating far from reliable ground coverage.
Satlyt’s deployment places Gemma in that specific role: a local interpreter for spacecraft data. The measured reductions—from 1,319 bytes to 469 bytes and from 1,318 bytes to 464 bytes—are the clearest evidence so far of what the system is designed to do.