Lunar Foundation Model is the plain name on what NASA and IBM released on Thursday 10 September 2026: an open AI model for exploring the Moon, trained on almost two million co-registered tiles of orbital data and posted to Hugging Face with its weights, fine-tuning code, benchmark datasets and a technical report. NASA calls it among the first open-source AI models built specifically for lunar science. IBM’s press release leads with a sharper promise: the model “exceeds widely used methods by up to 23%” at finding ice deposits, craters and volcanic formations.
That 23% is where the story gets interesting. The release is unusually well documented, so every percentage in the announcement can be traced to a table in the report the two organisations published. Do that and the numbers hold up, but they measure different things. The 23% is an error metric the release body never names, the crater figure uses a stricter score than the report’s headline metric, and the volcanic-feature gain is measured against a baseline that was not the strongest one tested.
Below we set out what shipped in the NASA-IBM Lunar Foundation Model release, how the model was trained, what each claim really compares, what the model card says the Lunar Foundation Model cannot do, and what the release means for anyone building AI on specialised imagery. For wider context, see our guide to open-weight AI models in 2026 and our AI Models, Tools and Releases hub.
Table of contents
- What NASA and IBM Shipped in the Lunar Foundation Model Release
- How the Lunar Foundation Model Was Built
- The Lunar Foundation Model Claims, Checked Against the Tables
- Four Benchmarks Behind the Lunar Foundation Model Scores
- What the Lunar Foundation Model Cannot Do, in Its Own Words
- The SpaceX Crater Test and the Artemis Context
- Where the Lunar Foundation Model Sits in the NASA-IBM Family
- How to Download and Fine-Tune the Lunar Foundation Model
- What the Lunar Foundation Model Means Outside Space Science
- Frequently Asked Questions
- References
What NASA and IBM Shipped in the Lunar Foundation Model Release
The announcement came in three coordinated pieces on 10 September: a NASA Science article by Rachel Wyatt, an IBM newsroom release datelined Yorktown Heights, and an IBM Research blog post by Kim Martineau. Behind them sits a set of files that went up well before launch day. The main Lunar Foundation Model repository on Hugging Face was created on 1 September, the four benchmark datasets on 31 August, and the GitHub code repository on 30 July.
The Lunar Foundation Model and its three task checkpoints
The core download is the pretrained NASA-IBM Lunar Foundation Model. Like most open AI models it lives on Hugging Face, in this case under the nasa-ibm-ai4science organisation. Three task checkpoints sit alongside it, each adapted from the same backbone: crater detection, with one LoRA-adapted checkpoint per image scale; irregular mare patch segmentation, built on a frozen backbone; and polar ice prospectivity, a dense regression model. NASA says the complete codebase is on GitHub “for testing and experimentation”, and the repository README is candid about scope: “Pretraining code is not included.”
SomBench, the dataset that ships with it
Alongside the model, the teams released SomBench, which IBM describes as a unified lunar dataset “aggregating over 30 spatially-aligned layers from nine instruments across four missions.” On Hugging Face the pretraining corpus is only a sample: that repository totals 149.9 MB, and its card points to the full corpus in a public AWS bucket, s3://nasa-lunar-fm-bench/, readable without credentials. Four task benchmarks are published as separate datasets.
Size figures for the full corpus disagree. The technical report puts it at about 53 TB compressed, 51.4 TB of it Wide Angle Camera data and 1.6 TB Narrow Angle Camera data. The Hugging Face card’s table lists 38 TB and 1.4 TB for the same two tracks. If you plan to mirror SomBench, list the bucket before provisioning storage. NASA’s Kevin Murphy spoke of “petabytes of scientific data”, which describes NASA’s archive; SomBench itself is measured in tens of terabytes.
Four missions and nine instruments
Reuters described the layers as coming from four NASA missions. One of the four, SELENE, also known as Kaguya, belongs to the Japan Aerospace Exploration Agency. The release does not list the nine instruments, so the table below is our reading of the source columns in the SomBench dataset card, which name each product’s instrument.
| Mission (agency) | Instruments behind SomBench layers | Example layers |
|---|---|---|
| Lunar Reconnaissance Orbiter (NASA) | LROC cameras (Wide Angle and Narrow Angle), LOLA, Diviner, Mini-RF | Imagery, roughness, permanently shadowed regions, temperatures, radar |
| GRAIL (NASA) | Gravity mapping | Free-air gravity disturbance |
| Lunar Prospector (NASA) | Neutron Spectrometer | Hydrogen abundance near the poles |
| SELENE, or Kaguya (JAXA) | Multiband Imager, Spectral Profiler, Terrain Camera | Mineralogy, polar mineralogy, SLDEM2015 elevation combined with LOLA |
Which licence covers which part
TNW wrote on launch day that IBM and NASA had not provided “a model size, parameter count, licence, or architecture description.” The model card answers three of those four. The Lunar Foundation Model weights and task checkpoints are Apache-2.0, the SomBench datasets are CC BY 4.0, and the GitHub repository’s LICENSE file is the Apache 2.0 text, although GitHub’s licence detector labels it “Other”. The gap TNW and The Register both found is real: no parameter count appears anywhere in the release.
| Component | Where it lives | First uploaded (2026) | Licence | Size or scope |
|---|---|---|---|---|
| Lunar Foundation Model backbone and nine tokenizers | Hugging Face | 1 September | Apache-2.0 | 12.79 GB repository |
| Crater detection checkpoints | Hugging Face | 1 September | Apache-2.0 | Two, one per image scale |
| Irregular mare patch checkpoint | Hugging Face | 1 September | Apache-2.0 | Frozen backbone |
| Ice prospectivity checkpoint | Hugging Face | 1 September | Apache-2.0 | Dense regression |
| SomBench pretraining sample | Hugging Face, full corpus on AWS | 1 September | CC BY 4.0 | 149.9 MB sample |
| Four SomBench task benchmarks | Hugging Face | 31 August | CC BY 4.0 | 10 to 100 test items each |
| Fine-tuning code | GitHub, NASA-IMPACT | 30 July | Apache 2.0 text | TerraTorch integration, no pretraining code |
| Technical report | Inside the model repository | 1 September | Not stated | 25.0 MB PDF |
How the Lunar Foundation Model Was Built
The architecture is borrowed, and the team says so. The model card describes a ViT-B encoder-decoder “trained from scratch” on SomBench using the masked-token recipe of TerraMind, the Earth-observation model IBM developed with the European Space Agency. The report explains why it did not simply fine-tune TerraMind’s Earth checkpoint: “existing geospatial adaptations transfer imperfectly to the Moon.”
Two lunar extensions to the TerraMind recipe
The Lunar Foundation Model adds two things TerraMind does not have. First, acquisition geometry becomes an explicit input: per-tile illumination angles, solar-frame anchors and tile footprint are tokenised and fed to the encoder. The card’s reasoning is blunt: “Lunar surface appearance is governed more by illumination geometry than by intrinsic surface variation.” Second, tiles from the Narrow Angle Camera, at about 1 metre per pixel, and the Wide Angle Camera, at about 100 metres per pixel, train in one mixed-batch loop, so one set of weights “covers both resolution families across a 100× scale gap.”
Why shadows made the Moon hard to learn
Juan Bernabé-Moreno, director of IBM Research Europe, UK and Ireland, explained the problem to Engadget. “In Earth observation, you have pristine images,” he said. Earth’s atmosphere scatters sunlight into shadows, while Engadget describes lunar shadows as knife-edged and pitch black, so shadowed pixels carry no information and a crater can look completely different from one image to the next. The IBM Research blog adds that a lunar day is two weeks of sunlight followed by two weeks of darkness, and that near the poles the Sun sits low enough to throw long shadows.
Cutting the Moon into wedges like an orange
The usual way to pretrain a vision model, removing most of an image and asking the model to rebuild it, also struggled. Engadget reports that the approach did not work for the Moon because so many craters look alike from orbit, and Bernabé-Moreno called the first attempts a “complete disaster”. His description of the fix: “We took the Moon and divided it into wedges, like an orange, and we completely separated the training wedges from the testing wedges.”
The report gives the formal version. Tiles are grouped by Lunar Transverse Mercator zones, which are map strips, plus polar stereographic caps. Whole zones go to training, validation or test in roughly an 80/10/10 split, and tiles that straddle a zone boundary are dropped. Because overlapping orbits photograph the same ground many times, a random split “would place near-duplicates on both sides of the evaluation boundary,” so the test set would quietly overlap the training data. That spatial split is what makes the Lunar Foundation Model benchmark numbers worth reading at all.
Eleven modalities at two scales
The Lunar Foundation Model takes nine image-like layers plus two sequence-like context inputs: eight fields of per-tile optical metadata and 28 fields of static-map context, drawn from Diviner, LOLA, Mini-RF, Kaguya, GRAIL and Lunar Prospector products. Modality-wise tokenisation means users can drop or add inputs at fine-tuning time, and a FlexiViT patch embedding lets the checkpoint run at other patch sizes without retraining.
| Specification | NASA-IBM Lunar Foundation Model |
|---|---|
| Encoder | ViT-B: 768 dimensions, 12 layers, 12 attention heads |
| Decoder | 12-layer Transformer at the same width |
| Input and patch size | 256 × 256 pixels; 16 × 16 patches at pretraining, resizable with FlexiViT |
| Modalities | 11: nine image-like layers, optical metadata, static-map context |
| Tokenizers | Nine modality-specific VQ-VAE tokenizers with FSQ quantisation |
| Pretraining corpus | 963,609 Wide Angle Camera bundles and 1,000,113 Narrow Angle Camera bundles |
| Pretraining compute | 16 H100 GPUs, 150,000 steps, global batch 1,536, about 1,100 GPU-hours |
| Adaptation | TerraTorch, with LoRA as the recommended default |
| Licence | Apache-2.0 |
The compute arithmetic is modest by current standards. 1,100 GPU-hours across 16 GPUs is 68.75 hours, a little under three days of wall-clock time. 150,000 steps at 1,536 tiles per step is 230.4 million tile samples, about 117 times the 1,963,722 bundles in the whole corpus, and more again against the training share alone. The Lunar Foundation Model saw each bundle many times over, which is normal for masked-token pretraining on a fixed dataset.
The Lunar Foundation Model Claims, Checked Against the Tables
IBM’s release makes four quantitative claims and footnotes every one of them to the technical report. That is good practice, and it makes checking possible. The recurring comparison is SwinV2-B, a Swin Transformer from Microsoft pretrained on ImageNet, which Engadget notes is a common baseline for image analysis. We matched each Lunar Foundation Model figure to the report’s Tables 4 to 7 and recomputed it.
“Up to 23%” is a different metric from the body’s 22%
The subhead says the Lunar Foundation Model “exceeds widely used methods by up to 23%”. The body then gives the ice result as a 22% reduction in RMSE against SwinV2-B. Both numbers are in Table 7. RMSE falls from 0.0377 to 0.0293, which is 22.3%. Mean absolute error falls from 0.0256 to 0.0197, which is 23.0%. So the headline uses the larger of two error metrics for the same test, and Reuters, Engadget, CNET and TNW all repeated 23%.
“Nearly 19%” on craters uses the stricter AP@75 score
The crater claim reads: at about 100 metres per pixel, the model “outperforms SwinV2-B by nearly 19% using just half the training data.” Table 4 reports three scores. On mean average precision, the report’s headline detection metric, the Lunar Foundation Model at 50% data scores 0.2541 against SwinV2-B’s 0.2313 at the same fraction, a 9.9% gain. The 19% comes from AP@75, which only counts a detection whose box matches the labelled crater at an intersection-over-union of 0.75 or better: 0.2213 against 0.1862, an 18.9% gain.
That is a legitimate result and arguably the more interesting one, because it says the lunar model draws tighter crater boxes. But it is not the number the report leads with, and “half the training data” compares both models at 50%. The stronger claim sits in the report rather than the release: at 50% data, the pretrained Lunar Foundation Model (0.2541) already beats SwinV2-B trained on the full set (0.2420).
“3%” on volcanic patches compares against SwinV2-B, not the leader
For irregular mare patches, IBM says the model “better captures the extent of the volcanic features” than SwinV2-B “by 3%”. Table 6 agrees: an IoU of 0.5709 against SwinV2-B’s 0.5555 is 2.8%. But SwinV2-B was not the strongest baseline on this task. ConvNeXtV2-B scored 0.5687, which leaves the Lunar Foundation Model 0.4% ahead, with a seed spread of ±0.0114 on its own score. The report’s verdict is that the top models “achieve comparable results.”
“Comparable” at 1 metre means a whisker behind
On metre-scale Narrow Angle Camera craters, the release promises “comparable accuracy as state-of-the-art models like SwinV2-B.” Table 5 has the best Lunar Foundation Model variant at 0.1543 mAP and SwinV2-B at 0.1552, so the lunar model trails by 0.6%. The report calls the two comparable because the gap is smaller than the seed spread, which is the right reading. A tie is a fair description; a win would not be.
| Figure | Report table | Scores compared | Our arithmetic | What it measures |
|---|---|---|---|---|
| “Up to 23%” (subhead) | Table 7 | MAE 0.0197 vs 0.0256 | 23.0% lower | Ice prospectivity, mean absolute error |
| “Up to 22%” (body) | Table 7 | RMSE 0.0293 vs 0.0377 | 22.3% lower | Ice prospectivity, root mean squared error |
| “Nearly 19%” | Table 4 | AP@75 0.2213 vs 0.1862 | 18.9% higher | Wide Angle craters at 50% data, strict box matching |
| Same test, headline metric | Table 4 | mAP 0.2541 vs 0.2313 | 9.9% higher | Wide Angle craters at 50% data, mean average precision |
| “By 3%” | Table 6 | IoU 0.5709 vs 0.5555 | 2.8% higher | Volcanic patch segmentation against SwinV2-B |
| Same test, strongest baseline | Table 6 | IoU 0.5709 vs 0.5687 | 0.4% higher | Volcanic patch segmentation against ConvNeXtV2-B |
| “Comparable accuracy” | Table 5 | mAP 0.1543 vs 0.1552 | 0.6% lower | Narrow Angle craters at 1 metre per pixel |
Ranked on the metric each benchmark leads with, and against the strongest baseline rather than a chosen one, the picture is one decisive win, one clear win and two ties.
Four Benchmarks Behind the Lunar Foundation Model Scores
Each claim above rests on one of four SomBench benchmarks, and their sizes matter as much as their scores. All four hold loaders, splits, augmentations, loss and metric fixed across models, and every result is a mean over five random seeds, which is careful practice. The test sets are small, though, and the Lunar Foundation Model’s widest margin comes from one of the smallest.
Crater detection at 100 metres per pixel
The Wide Angle Camera benchmark takes crater positions from Stuart Robbins’ 2019 global lunar crater catalogue, which is near-complete for craters larger than about 1 to 2 kilometres, and packages them over 1,000 tiles of 512 × 512 pixels. Training uses 800 tiles, validation 100 and testing 100, with 114,329 crater boxes in total. Solar incidence angles run between 60° and 80°, so every tile is lit from low on the horizon.
Crater detection at 1 metre per pixel
The Narrow Angle Camera benchmark is hand-labelled. Subject-matter experts marked every crater inside 35 study boxes, each 1,024 metres square, across six sites including Apollo 17 and Reiner Gamma. The result is 408 image chips carrying 57,611 annotations of 49,106 unique craters. The median crater is only about 6.5 pixels across, and 27% of annotations are under 5 pixels, which explains why every model scores low on this test.
Irregular mare patches
Irregular mare patches are small volcanic landforms that look unusually young for a Moon thought to have gone quiet long ago. NASA’s Michael Barker, who co-led the project with IBM, told the IBM Research blog that “the ages of these features remain a matter of great debate.” The benchmark pairs Narrow Angle Camera tiles with binary masks: 130 tiles in total, split 100 for training, 20 for validation and 10 for testing. Around 100 patches larger than a 256-metre tile were excluded.
Polar ice prospectivity
The ice benchmark regresses a prospectivity value between 0 and 1 at 240 metres per pixel, within about 10° of each pole, from layers such as Diviner ice-stability depth, maximum temperature and permanently shadowed regions. It holds 162 patches. The published split lists name 108 for training, 24 for validation and 25 for testing, which sums to 157, consistent with files named “filtered”. The target follows a prospectivity workflow published by Coyan and colleagues in 2025.
| Benchmark | Source imagery | Tile size and resolution | Train / val / test | Labels |
|---|---|---|---|---|
| Wide Angle craters | LROC Wide Angle Camera | 512 × 512 px at 100 m per pixel | 800 / 100 / 100 tiles | 114,329 boxes from the Robbins (2019) catalogue |
| Narrow Angle craters | LROC Narrow Angle Camera orthophotos | 256 × 256 px at about 1 m per pixel | 289 / 56 / 63 tiles | 57,611 expert boxes of 49,106 craters |
| Irregular mare patches | LROC Narrow Angle Camera | 256 × 256 px at about 1 m per pixel | 100 / 20 / 10 tiles | Binary masks from published patch outlines |
| Polar ice prospectivity | Diviner thermal, illumination and terrain layers | Patches at 240 m per pixel | 108 / 24 / 25 patches | Model-derived prospectivity map from 0 to 1 |
The widest margin in the release, on polar ice, comes from a 25-patch test set, and the volcanic result from 10 tiles. Each ice patch holds many pixels, and the ice gap of 0.0084 RMSE is more than six times the larger seed spread, so the small count does not undo that result. It does limit how far any of these rankings should travel.
What the Lunar Foundation Model Cannot Do, in Its Own Words
The most useful part of the release is the model card’s “Out of scope” paragraph, and it reads differently from the launch material. IBM’s release says crater mapping “helps NASA select safe landing sites” and that the model can “predict where ice may be present.” Both statements describe what crater maps and ice maps are for. The card is careful about what the Lunar Foundation Model itself has and has not been validated to do.
It keeps no geodetic reference frame
The card states that the model “maintains no geodetic reference frame.” It recovers local structure but not absolute values: “DTM shape is right at a shifted elevation offset,” and “generated lat/lon can be off by tens of degrees.” The report repeats the point and adds that, in principle, the gap “could be learned during finetuning.” For any use that depends on knowing exactly where something is, the Lunar Foundation Model is a starting representation, not an answer.
Ice prospectivity is not measured ice
The ice task, the source of the headline 23%, trains the model to reproduce a map produced by a knowledge-driven method. The card says so directly: ice-prospectivity outputs regress “a knowledge-driven fuzzy-overlay prospectivity map, not measured ice.” The dataset card adds that prospectivity is “a model-derived, tunable product” whose weights “may evolve as in-situ constraints improve.” A 22% lower RMSE means the Lunar Foundation Model reproduces that expert map more closely than SwinV2-B does. It does not mean it finds 22% more water.
Not validated for landing sites or hazards
The card names operational uses explicitly. The model is “not validated for operational decisions such as landing-site certification or hazard clearance,” and it is “not evaluated beyond the Moon or on products absent from SomBench.” Its generated fields “are not calibrated predictions and are no substitute for instruments, stereo photogrammetry, or geodetic solutions.” None of that contradicts NASA’s goals. It describes the distance between a research model and a mission tool.
Two limitations hidden in the card’s source
The raw README on Hugging Face contains two limitation bullets wrapped in HTML comments, so they do not render on the model page. One is headed “Small test sets”, lists “10 tiles (IMP), 25 (ice prospectivity), 62 patches (NAC craters)” and adds: “Differences below the reported seed spread are not a ranking.” The other notes that optimiser recipes differ between the lunar model and the baselines, calling that “standard practice per family, but not a single shared recipe.” The report itself does acknowledge that “some of the benchmarks have limited samples in the test set.”
| What the announcement says | What the model card or README says |
|---|---|
| Crater mapping “helps NASA select safe landing sites” (IBM) | “Not validated for operational decisions such as landing-site certification or hazard clearance” |
| The model can “predict where ice may be present” (IBM) | Ice outputs regress “a knowledge-driven fuzzy-overlay prospectivity map, not measured ice” |
| “Using the model as a mapping tool” (NASA) | The model “maintains no geodetic reference frame” |
| “Exceeds widely used methods by up to 23%” (IBM) | “NAC craters and IMP segmentation: treat leaders as comparable” |
| An open model for the global research community (IBM) | “Pretraining code is not included” (GitHub README) |
The SpaceX Crater Test and the Artemis Context
The most vivid demonstration in the launch material involves a crash. On 5 August 2026, a SpaceX Falcon 9 upper stage from the January 2025 launch of Firefly’s Blue Ghost 1 mission struck the Moon. NASA’s Lunar Reconnaissance Orbiter photographed the new crater on 11 and 12 August, and NASA measured it at 60 feet wide and less than 10 feet deep.
What NASA says the model spotted
NASA’s article shows before-and-after images near Einstein crater in which the fine-tuned Lunar Foundation Model outlined existing craters and flagged the new impact. NASA notes the post-impact image “was excluded from pre-training,” and cautions that “varying lighting conditions between orbits may influence smaller crater visibility.” Bernabé-Moreno told Engadget the model identified the site as a new crater on its first attempt, even though it closely overlapped an existing one. “It worked fantastically,” he said.
A demonstration, not a benchmark
A 60-foot crater is about 18.3 metres across, roughly 18 pixels in a Narrow Angle Camera image at 1 metre per pixel, well within the range the metre-scale benchmark covers. But this was one crater in one pair of images, and the test does not appear in the technical report, which never mentions the Falcon 9 impact. It is a good illustration of change detection with the Lunar Foundation Model, and it should be read as one.
Where the model fits in Artemis planning
The timing is not accidental. NASA’s Artemis II crew flew around the Moon in April, and Reuters reported that Artemis plans to return astronauts to the surface in 2028. IBM’s blog frames the release around that return, pointing to polar craters that could give future crews “a source of drinking water, oxygen, and fuel” and to crater rims in near-constant sunlight that could power equipment. The Lunar Foundation Model supports the scientific mapping behind those plans; its card is explicit that it does not certify the sites.
Where the Lunar Foundation Model Sits in the NASA-IBM Family
The lunar release is the latest in a run of open science models from the same partnership. The Register traces the line: Prithvi for satellite imagery in 2023, a weather and climate model the following year, and Surya for solar flare prediction in 2025. IBM’s release says the Lunar Foundation Model “joins the Prithvi family of open foundation models, spanning geospatial, weather, heliophysics and now the Moon.”
One family or a growing collection?
NASA frames it slightly differently. Its article lists “The Prithvi Models” for Earth observation and “The Surya Model” for heliophysics as separate members of a growing collection “developed through this partnership.” The Hugging Face layout follows NASA’s grouping: the Prithvi models sit under ibm-nasa-geospatial, while the Lunar Foundation Model sits under nasa-ibm-ai4science next to Surya. The difference is branding, not substance, but it matters when you are searching for the files.
| Model | Domain | Hugging Face organisation | Earliest date we found |
|---|---|---|---|
| Prithvi | Satellite imagery | ibm-nasa-geospatial | 2023, per The Register |
| Prithvi WxC | Weather and climate | ibm-nasa-geospatial | 20 September 2024 upload |
| Prithvi-EO-2.0 | Earth observation, second generation | ibm-nasa-geospatial | 22 November 2024 upload |
| Surya-1.0 | Heliophysics and solar flares | nasa-ibm-ai4science | 13 August 2025 upload |
| NASA-IBM Lunar Foundation Model | Lunar remote sensing | nasa-ibm-ai4science | 1 September 2026 upload, announced 10 September |
What the Moon borrowed from Earth
The link to the Earth models is technical as well as organisational. The Lunar Foundation Model reuses TerraMind’s any-to-any masked-token design, and fine-tuning runs through TerraTorch, an open-source Python toolkit for fine-tuning geospatial foundation models. For a team that has already adapted Prithvi or TerraMind to Earth imagery, the lunar workflow will look familiar: YAML configs, a terratorch fit command and a path to the backbone checkpoint.
How to Download and Fine-Tune the Lunar Foundation Model
Getting started is a snapshot_download call against the Hugging Face repository, and the card shows how to pull only the backbone folder. That option matters, because most of the Lunar Foundation Model repository is not the backbone.
What the 12.79 GB download contains
We summed the file sizes the Hugging Face API reports for the repository. The full download is 12.79 GB. The backbone checkpoint and its config are 2.43 GB. The nine modality tokenizers, each around 1.15 GB, add 10.34 GB, and the technical report, diagram and small config files make up the last 25.7 MB. The card’s example for fetching “only model weights and config” pulls the backbone folder alone, which skips about 81% of the bytes.
LoRA as the default, full fine-tuning for small sets
The card gives unusually direct advice on adaptation. “LoRA is the sensible default,” at rank 16 and alpha 32 on the encoder’s attention and MLP layers: it matches or beats full fine-tuning on crater detection and shows narrower seed spread. IBM’s blog says the adapters left 90% of the base model’s weights frozen. Full fine-tuning “keeps an edge on our two smallest benchmarks.” A frozen encoder belongs “only after validating on your task,” since it won on the 100-tile volcanic set but fell “below every baseline on crater detection.”
| Strategy | What trains | Where it scored best | The card’s advice |
|---|---|---|---|
| LoRA, rank 16, alpha 32 | Low-rank adapters on encoder attention and MLP layers | Wide Angle craters at full data (0.2581 mAP); best Narrow Angle variant (0.1543) | The sensible default |
| Full fine-tuning | Whole encoder, with layer-wise learning-rate decay | Ice prospectivity (0.0293 RMSE); Wide Angle craters at 50% data (0.2541 mAP) | Worth it on the smallest benchmarks |
| Frozen encoder | Task head only | Irregular mare patches (0.5709 IoU) | Validate first; weakest on craters |
Hardware for pretraining and fine-tuning
Pretraining used 16 H100 GPUs for about 1,100 GPU-hours. For fine-tuning, an IBM spokesperson told The Register that “most of our fine-tuning experiments were conducted using Nvidia A100 GPUs,” adding that smaller experiments and inference workloads “may be possible on more modest hardware.” The GitHub README targets Python 3.12. With no parameter count published, the nearest guide is the architecture: ViT-B was the Base configuration in the original Vision Transformer paper, at about 86 million parameters, and the Lunar Foundation Model adds a 12-layer decoder and per-modality adapters on top.
What the Lunar Foundation Model Means Outside Space Science
Few businesses need crater maps. Many build computer vision on imagery that looks nothing like the photographs ImageNet was built from: drone surveys, thermal inspection, microscopy and satellite data. The Lunar Foundation Model is a well-documented case study in how that work succeeds, and three lessons carry over directly.
The dataset is the durable asset
Bernabé-Moreno made the point himself to Engadget: “AI models get superseded by other models. The data is what really creates the industry of AI models.” The lasting work here was co-registering 30-plus layers from nine instruments onto a shared pixel grid, not training a ViT-B. If you are scoping a custom vision project, budget for that alignment work first, because it is the part of ML model development that no pretrained backbone does for you. Our analysis of hidden annotation errors in object detection datasets shows how much labels decide outcomes.
Split your data by place, not by image
The orange-wedge split is the most transferable idea in the Lunar Foundation Model release. Whenever the same field, asset or site is photographed many times, a random train and test split leaks near-duplicates and inflates scores. Splitting by geography, site or asset, as the lunar team did with whole map zones, is the fix. It costs test-set size, which is exactly the trade visible in the four SomBench benchmarks, and it is a trade worth making.
Read the table, not the percentage
The 23% headline was accurate and still told readers less than Table 7 does. Model releases now routinely ship with cards and reports, and the habit worth building is checking which metric, which baseline and which data fraction a headline figure uses. We ran the same check on DeepSeek V4.1 Flash earlier today and on the label quality gap in MS-COCO. For help turning a benchmark into a decision, see our data science services.
Frequently Asked Questions
Is the NASA-IBM Lunar Foundation Model free to use?
Yes. The weights and the three task checkpoints are released under Apache-2.0, which permits commercial use, and the SomBench datasets are CC BY 4.0, which requires attribution. The fine-tuning code is on GitHub. The pretraining code is not included.
How large is the Lunar Foundation Model?
NASA and IBM have not published a parameter count. The encoder is ViT-B, with 768 dimensions, 12 layers and 12 attention heads, paired with a 12-layer decoder. The full Hugging Face repository is 12.79 GB, of which the backbone checkpoint and config are 2.43 GB.
Can the Lunar Foundation Model find water ice?
Not directly. It estimates ice prospectivity, meaning how likely ice is to be stable, by learning to reproduce an expert-built prospectivity map from thermal, illumination and terrain layers. The model card states that its output is “not measured ice.” Confirming ice still requires instruments and missions.
What hardware do I need to fine-tune it?
IBM told The Register that most fine-tuning experiments used Nvidia A100 GPUs, and that smaller experiments and inference may run on more modest hardware. LoRA adaptation, the card’s recommended default, trains only a small fraction of the encoder’s parameters, which lowers memory needs.
Is the Lunar Foundation Model part of Prithvi?
IBM says yes, describing a Prithvi family “spanning geospatial, weather, heliophysics and now the Moon.” NASA lists Prithvi and Surya as separate models in a wider collection. On Hugging Face the lunar model sits with Surya under the nasa-ibm-ai4science organisation.
What data was the model trained on?
SomBench: 963,609 Wide Angle Camera bundles at 100 metres per pixel and 1,000,113 Narrow Angle Camera bundles at about 1 metre per pixel, with context layers from LRO, GRAIL, Lunar Prospector and Japan’s SELENE mission. The report puts the full corpus at about 53 TB compressed.
References
NASA, IBM Launch AI Foundation Model for Lunar Science (NASA Science)
IBM and NASA Release Open-Source AI Model to Support Lunar Exploration (IBM Newsroom)
A Rough Guide for Going Back to the Moon (IBM Research)
NASA-IBM Lunar Foundation Model Card (Hugging Face)
Multimodal-Multiresolution Foundation Model for Lunar Remote Sensing (Technical Report)
NASA-IBM Lunar Foundation Model Fine-Tuning Code (GitHub)
SomBench Pre-training Corpus (Hugging Face)
NASA-IBM Lunar FM and Downstream Models (Hugging Face Collection)
SomBench Benchmark: Polar Ice Prospectivity Regression (Hugging Face)
NASA’s LRO Images Falcon 9 Crater on Moon, Learns New Details (NASA Science)
TerraMind: Large-Scale Generative Multimodality for Earth Observation (arXiv)
An Image Is Worth 16×16 Words: Transformers for Image Recognition at Scale (arXiv)
NASA and IBM Made an AI Model for Exploring the Moon (Engadget)
NASA and IBM Open Source Lunar Mapping Tools (The Register)
IBM and NASA Release an Open-Source Lunar Foundation Model (TNW)
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.