Rock, Paper, Silicon: How a Web Developer Used a Satellite Hack and an AI Agent to Ask a Ridiculous Question About Frontier AI
This is not an academic research paper. I am certainly not a systems engineer. I am a self-taught, full-stack web developer — the kind whose GitHub is full of frontends and web stacks, not GPU kernel optimizations or low-level memory management. This is simply a curious builder's diary about an experiment that probably shouldn't have worked, built with an AI agent who hopefully knows C++ and processors, because I do not 😅.
1. The Problem I Wasn't Qualified to Solve
Silicon Valley has a bucket problem.
To run a modern frontier AI model — something like Qwen3-235B with its 235 billion parameters — the industry tells you that you must hold the entire mathematical mountain in RAM simultaneously. At bfloat16 precision, that is roughly 470 GB of memory. On a good day, a high-end Mac Studio ships with 192 GB. A standard MacBook? 16 to 48 GB.
The conclusion drawn by everyone qualified to draw conclusions is: you cannot run frontier AI locally on consumer hardware. Go rent a cloud GPU.
The thing that nagged me: In a Mixture of Experts model, 95%+ of those 235 billion parameters are completely silent at any given millisecond. For a token about philosophy, the math experts never fire. For a token about code, the poetry experts never fire. The weights are cold stone. Standard runtimes hold all of them in RAM, just in case.
I am not a systems architect. I have no background in high-performance computing. My daily bread is APIs, web stacks, and the kind of code that orchestrates systems rather than talks to raw silicon. But I had a question that wouldn't leave me alone:
What if you only loaded what fires, and loaded it just before it fires?
I didn't know how to answer it. So I called for help.
2. The AI Agent as a Bridge
I want to be completely honest about how this was built.
I opened a conversation with an AI agent and I told it my idea. I described the shape of what I wanted. I asked naive questions. The agent wrote C++. I read it, trying to make sense of pointers and memory allocations. I pushed back when things got too complex. It revised. We iterated.
I am not writing this to diminish the work — there is real, terrifyingly low-level engineering here, and I understand a little more of it with each session. But I want to be honest that the architecture we landed on emerged from a collaboration where I brought the curiosity and the direction, and the agent brought the implementation depth. My GitHub profile tells the truth: I am a web developer who had a question and found a way to pursue it beyond my formal training by talking to a machine.
What I could bring was exactly what pure computer science training sometimes blocks: I wasn't afraid to ask an "obviously impossible" question, because I simply didn't know enough to know it was supposed to be impossible.
3. The Satellite Man Who Looked Sideways
My technical inspiration came from a place nobody in Silicon Valley would have looked.
Ing. Filippo Biondi published a paper in 2022 in the MDPI journal Remote Sensing titled "Synthetic Aperture Radar Doppler Tomography Reveals Details of Undiscovered High-Resolution Internal Structure of the Great Pyramid of Giza". It is a stroke of pure genius, and the underlying physical intuition is what captured my imagination.
Here is the idea:
Electromagnetic waves cannot penetrate rocks and go underground. That is not a limitation to work around — it is physics. SAR satellites orbit Earth and illuminate surfaces with microwave radar pulses, but those pulses bounce off solid stone.
But Biondi used a brilliant technique. When the EM wave strikes the pyramid's exterior, it generates acoustic phonons — mechanical sound vibrations that propagate through the stone. The stone vibrates in response to the surface strike, and the internal geometry of the pyramid modulates those vibrations.
The satellite cannot see inside the rock. But using a Doppler technique and some Fourier transforms, Biondi measured the sub-nanometer surface displacements caused by those returning phonons. He used those phonon readings to gain Tomographic images, capturing all the 3D information of the pyramid's interior projected beautifully onto a 2D plane.
SAR Satellite
│ │ microwave pulse (cannot penetrate rock) ▼┌──────────────────────────────────────────┐
│ PYRAMID SURFACE │
│ EM pulse → generates phonons in stone │
│ Phonons propagate through interior │
│ Internal geometry modulates wavefront │
│ Surface micro-vibrates (sub-nanometer) │
└──────────────────────────────────────────┘
│ │ Doppler shift in reflected SAR signal │ encodes surface displacement ▼Fourier transform across synthetic aperture
│ ▼3D tomographic image (internal structure)
Stop fighting the physical barrier. Measure what the barrier does to the signal instead.
I am not comparing my experiment to Biondi's work. He is an engineer doing something I cannot evaluate. But his framing — you cannot see inside the rock, so measure the sound the rock makes when you strike it — became the exact mental model I needed for the LLM memory problem.
4. The Translation: Acoustic Streaming for LLMs
The translation from Biondi's method to a language model inference problem is surprisingly direct:
| Seismic Concept | S-MoE Equivalent |
|---|
| Deep rock strata | The 235B model weights, cold on the NVMe SSD |
| EM surface pulse | The Surface Scout processing the current token |
| Generated phonons | The Scout's predicted expert activation map |
| Acoustic receivers | The async I/O thread reading predictions |
| Seismic map | The K-step expert ID lookahead schedule |
| Reconstructed image | The generated token |
The insight is this: you don't need to read the full model to know what parts of it will activate next. If you run a lightweight forward pass on the model's dense backbone — the embeddings, attention layers, and routing gates — those routing gates will tell you, probabilistically, which expert columns in the FFN are about to fire for the next several tokens.
This is the Surface Scout. It is not a separate model I trained. It is the dense parts of the target model itself — everything except the routed expert weights — running permanently in Unified Memory. Its routing gate matrices produce logits that are, in effect, a phonon map: a structural fingerprint of what the full model is about to need.
5. The System That Emerged
S-MoE (Seismic Mixture of Experts) is the result of this experiment. Built in C++ with a Metal compute backend, co-designed with an AI agent, it runs on Apple Silicon Macs.
It works in three concurrent streams:
The Sculptor (offline, run once)
A Python script (shatter_moe.py) takes any supported MoE model and splits it into two artifacts:
- The Vault (
.smoe): All routed expert blocks, aggressively quantised and page-aligned to 16 KB hardware boundaries for Direct I/O
- The Scout (
.scout.safetensors): The dense backbone — embeddings, attention, norms, routing gates — that lives in RAM
The Scout (always running)
At every token step, the Scout runs a complete forward pass on the current token. Its routing gate outputs produce a prediction of which experts will activate across all MoE layers for the next K tokens. This phonon map is handed to the Streamer.
Guided by the Scout's predictions, background I/O threads fire pread() calls with F_NOCACHE — bypassing the OS page cache entirely — loading the predicted expert blobs directly into a pre-allocated, page-aligned ring buffer in Unified Memory. The Metal GPU kernel reads from that ring buffer and executes the FFN computation via a fused dequant-multiply that decodes compressed weights directly in GPU register space.
The three streams run simultaneously. The GPU executes experts loaded one step ago. The Streamer loads experts needed one step from now. The Scout predicts experts needed K steps from now. No thread waits for another.
There are three rules the system never breaks:
- No runtime heap allocations.
malloc, new, and std::vector::resize are banned inside the token generation loop. Every buffer is pre-carved at startup.
- Direct I/O only.
F_NOCACHE on every vault file descriptor. SSD → DMA → RAM. No OS copy.
- Atomic synchronisation only. No OS mutexes. No blocking. The I/O thread and GPU thread are structurally incapable of blocking each other.
6. The Model-Agnostic Evolution
The system started hardcoded for a single model — DeepSeek-MoE-16B, a 16B parameter model small enough to test quickly. But the original question was never about one model. It was about whether the approach could scale.
Over several weeks of collaboration with the AI agent, I refactored the entire engine to be model-agnostic. Now, when you point S-MoE at a model's Scout file, it reads the tensor header at boot time and auto-detects:
- Hidden dimension, vocabulary size, FFN intermediate dimension
- Number of MoE layers, experts per layer
- Whether Layer 0 is a dense MLP (DeepSeek style) or a full MoE layer (Qwen style)
The engine reshapes itself to fit. No recompilation. No configuration files.
The current target is Qwen3-235B-A22B-Instruct-2507 — a genuinely frontier model, 235 billion parameters, 22 billion active per forward pass, 128 experts per MoE layer, Apache 2.0 licensed. A 400 GB download. The kind of model that is supposed to require a $250,000 GPU cluster.
It is downloading on my MacBook right now.
7. The Democratic Claim
I want to be careful not to oversell this. S-MoE is an experiment. It is incomplete. The Scout's predictions are imperfect, which means the Streamer sometimes misses and the system spin-waits. The quantisation introduces error. The throughput on a 16 GB Mac running a 235B model will be slow — perhaps one token every few seconds.
But here is the claim I am willing to stand behind:
A 16 GB Mac and a 512 GB Mac will produce identical outputs. The 512 GB Mac will produce them faster.
Speed scales with hardware. Intelligence does not degrade.
The user with the MacBook Air and the user with the Mac Pro get the same 235 billion parameters. The same knowledge. The same reasoning depth. The same model. One waits longer. Both get the answer.
This is not a smaller, distilled, dumbed-down model for the masses. It is the real thing, delivered at the rate the hardware allows.
I built this because I believe the memory wall around frontier AI is partly physical and partly artificial — a consequence of software assumptions that nobody questioned, not a law of nature.
I am a web developer who asked what else you could do with the NVMe that's sitting three inches from the CPU. The AI agent helped me find out.
The mountain is already vibrating. You just have to listen.
S-MoE is open source under the MIT License. The code, the philosophy, and the mistakes are all public: github.com/melasistema/s-moe.
Built by Luca Visciola and an AI agent who hopefully knows C++ and low level programming, because I do not 😅.
Acknowledgements: The seismic tomography concept is an experimental, philosophical translation of the published work of Ing. Filippo Biondi on SAR-based subsurface imaging. His methodology and its application to the Giza Plateau is his genius, not mine — I merely borrowed his intuition to solve a problem with language models.
