A new mathematical algorithmic model · formalized · developed by Immanu
A new mathematical algorithmic model that considerably optimizes AI infrastructure.
- GPU
- Disk
- Tokens
- Processing
- Energy
Without changing the hardware. It complements the optimization techniques that already exist: it boosts what you already run.
Today, every time data changes, AI infrastructure redoes work it has already done: the GPU recomputes, search runs again, and the disk rewrites. Our model replaces the way of deciding what to touch when something changes. The same GPU, the same disk and the same processor do far less work, with the exact same answer; and less work means capacity and energy freed up. It installs in the infrastructure you already have, without changing the AI model.
And in energy: if every GPU in the world had it, 435 thousand to 2.37 million GPU equivalents would be freed, and at most 2.81 to 20.70 TWh of electricity a year.
How to read the figures
Every measured figure is a floor: the conditions favor the rival. Each one states what it was measured against, under what condition, and in what unit.
Every figure carries its labels. Tap or hover over any of them to see what it means.
Where the figure comes from
We counted it in a test, against the rival in its standard form.
Calculated from measured figures, with the source or the assumption behind every factor in plain view; it was not measured in a data center.
Adds an assumption about uses we did not measure against a rival; it holds under the condition stated next to it, is kept apart and is never added in.
Under what condition
The data changes during the test: it comes in, gets corrected, expires or is deleted, as in real use.
The data doesn't change during the test: the rival's best condition.
What is compared
Compares only the way of deciding, in the same program.
Compares the whole system against the whole system, with the same changes.
Shows what the rival does when the data changes, without inventing a ratio.
A third party's figure, with its source; we didn't measure it.
At most: under the stated assumptions, the real value can be lower.
The test conditions favor the rival.
Rests on an assumption stated next to the figure.
Checks that the answer matches other tools'; it doesn't measure time.
Tokens were counted in the test, on both sides; the multiple is calculated from those counts.
What problem does it solve?
When something changes, systems redo work they've already done.
Today, every time something changes, a fixed rule decides what to redo. Each rule makes sense on its own; together, they make the GPU, the search engine, the disk and the processor repeat work they've already done to reach the same answer. These are the rules of the tools the industry already runs.
GPU
- Data changes
- An agent corrects one fact halfway through a long document.
- Today's rule
- The AI server's prefix cache.
- What gets redone
- Recomputes everything after it.
Search
- Data changes
- A document expires or its permissions change.
- Today's rule
- Query everything again.
- What gets redone
- The whole search, again.
Disk
- Data changes
- A record changes.
- Today's rule
- The database's write-ahead log.
- What gets redone
- Writes each changed page twice.
Processor
- Data changes
- A new release of a catalog arrives.
- Today's rule
- Redo the cross-match.
- What gets redone
- The whole cross-match, again.
See more · specificationsHide specificationsWhat the market already charges to redo work · what the industry runs · the market, according to third parties
12.5×
what it costs to rewrite the AI's memory, versus re-reading it
Anthropic's list price. Redoing work already has a price.
What the industry already runs, according to each source
- vLLM is offered on AWS, Google Cloud and Azure.
- SGLang, according to its website, runs on more than 400,000 GPUs.
- pgvector is offered by Amazon, Google and Microsoft.
- SQLite, according to its website, is in more than one trillion databases.
The market, according to third parties
- Hardware for serving AI models: from USD 106.15 billion in 2025 to USD 254.98 billion in 2030, according to MarketsandMarkets (Feb 2025).
- Vector databases: from USD 2,652 million in 2025 to USD 8,946 million in 2030, according to MarketsandMarkets (Dec 4, 2025).
Our model replaces that rule. Here's what it is, and what it isn't.
What is it, exactly? A vector database? An AI model?
A layer that decides. Not a database, not an AI model.
When data changes, something decides what has to be touched: what to recompute, what to query again, what to rewrite, what to rebuild. Today a fixed rule decides, and the hardware does more work than it needs to. Our model replaces that rule.
Applicationsearch for AI · agents · apps · large catalogs
Our modelthe rule that decides what to touch when something changes: what to recompute, what to query again, what to rewrite, what to rebuild
less work, flowing down to the layers below
What you already runsearch engine and index (pgvector, Qdrant, FAISS) · AI memory on the server (vLLM, SGLang) · database (SQLite)unchanged
HardwareGPU · processor · memory · disksunchanged
Not an AI model. It doesn't train it or touch its weights.
Not a vector database. The search engine and its index stay untouched.
Not hardware. It runs on the same GPU, the same processor and the same disks.
Exact: it returns the same answer as recomputing everything.
Provable: every answer comes with its proof (the evidence that comes with each answer).
What you already run stays as it is. What changes is how much it works: here's what we measured.
How much work does it save, and against which rival?
The same infrastructure does far less work to deliver the same answer.
See more · specificationsHide specificationsThe GPU · search · the text the AI receives · disk
Does it work in AI? Does it beat the cache in AI servers? Does it affect model quality?
71× less recomputation on the GPU. More than 100× less work in search. The same answers.
AI memory, on the GPU
A language model keeps what it has already read so it doesn't compute it again: its KV cache (the memory where it stores what it has read). When an agent corrects one fact halfway through a long document, the standard rule in production, the prefix cache used by vLLM and SGLang, recomputes everything after it. We measured that rule in llama.cpp, the open server behind Ollama, and validated it against its real server. On a 128,000-token document with one fact corrected halfway, our model recomputes 71 times less.
The same answers
- 9 correct answers per seed, the same as recomputing everything.
- The corrected fact, right in 3 of 3.
- 16 times less deviation than storing the AI's memory in 8 bits.
Tokens recomputed after one fact is corrected halfway through the document
vs. the prefix cache · the same test, at two document lengths
32,000-token document
128,000-token document
The server's own reuse option (llama-server --cache-reuse), with a change halfway through a 32,000-token document, saved nothing: it redid the same work as the prefix cache.
ink = our model · gray = rival
View this chart as a table
| document | rival | tokens recomputed (our model = 1) |
|---|---|---|
| 32,000-token document | Prefix cache (vLLM, SGLang) | 18× |
| 128,000-token document | Prefix cache (vLLM, SGLang) | 71× |
The second rival
CacheBlend (U. of Chicago) matches the quality, but recomputes more than 3 times what we do (floor).
We measured its way of deciding in the rival's favor: its selection pass isn't counted against it.
The search that feeds AI
Before answering, the AI searches for documents filtered by customer, permission and date (RAG: retrieving documents before the AI answers), while those documents are corrected, deleted and expire. We measured with 30,000 live documents, coming in and going out, and the same thousand questions repeating, as in alerts or an agent's memory. The rival is the application on exact pgvector, following its recipe: the form of pgvector that returns the same answer. Our model works on top of the search engine, which stays untouched.
Work to return the exact same answer, under three filter conditions
vs. exact pgvector, following its recipe
ink = our model · gray = rival
View this chart as a table
| filter condition | exact pgvector's work (our model = 1) |
|---|---|
| exact pgvector · no filter | 128.5× |
| exact pgvector · per customer | 127.4× |
| exact pgvector · narrow filter | 116.8× |
| Our model | 1 |
If documents also expire: the rival, in both its modes
No filter; per customer, 152× and 81×. Periodic sweep: deleting expired documents every so often.
View this chart as a table
| rival's mode | work (our model = 1) |
|---|---|
| Filters out expired documents at query time | 154× |
| Deletes them in a periodic sweep | 82× |
| Our model | 1 |
Small scale, up to 2,552 documents
0expired documents kept. The rival that doesn't rebuild keeps 778.
Nonemaintenance. pgvector's, emulated with its thresholds, ran more than 160 times.
In their fast modes, how many of the correct answers each one finds
30,000 documents · Sep 28, 2026
Qdrant, in its normal mode, finds everything, but by scanning everything for each customer. This chart shows only how much each one finds, not its work; the work ratios above are against exact pgvector.
View this chart as a table
| who | share of the correct answers |
|---|---|
| Our model | all of them |
| FAISS (Meta), even knowing how many answers there are · depending on the filter | 53.3% to 57.4% |
| Qdrant forced onto its fast index · narrow filter | 41.1% |
| pgvector with its index and 10 results · depending on the filter | 10.5% to 69.4% |
Less text sent to the AI
With narrow filters, we measured 18 times less text sent to the AI than with a typical ten-result search with no threshold. With those filters and the AI's memory full, the math gives up to twice as many conversations per GPU.
Text the AI receives, with narrow filters
View this chart as a table
| rival | tokens delivered (our model = 1) |
|---|---|
| Typical 10-result search, no threshold | 18× |
| Our model | 1 |
And on disk? With changing data or static data? Do the figures depend on the hardware?
Writing to disk
SQLite is the database inside applications: according to its website, it runs on every Android, every iPhone and every Mac, in more than one trillion databases. We measured it as it's really used, with its write-ahead log (WAL, Android's default mode) and with its application, which queries again every round. This is system against system: our whole system, doing the work of SQLite and its application. With the same changes and the same answer, our system writes 36.4 times less to disk.
Bytes written to disk for the same answer
our system, doing the work of SQLite and its application
The full repeat gave 36.6×; we publish 36.4×, the lower one.
View this chart as a table
| condition | bytes written (our system = 1) |
|---|---|
| SQLite and its application · change spread out | 36.4× |
| SQLite and its application · change in a single customer | 78× |
| Our system | 1 |
Another rival, another test: whoever rebuilds its whole structure on every change
14.6×fewer physical bytes written
20.0×less writing, logical against logical
First round, measured on both sides · real Gaia records.
Less work means capacity and energy freed up. At world scale, derived from our measurements, it looks like this.
How does it improve the hardware? What does it mean in a data center, and worldwide?
Less work means capacity and energy freed up.
If every GPU in the world had it, what derives from our measurements would free 2.9% to 15.8% of the world's GPU capacity.
435 thousandcautious scenario · central figureto2.37 millionwith factors already measured · ceiling
GPU equivalents that would be freed, from current capacity
2.81cautious scenario · central figureto20.70TWhwith factors already measured · ceiling
of electricity a year, at most
1.25cautious scenario · central figureto9.21with factors already measured · ceiling
million tonnes of CO₂ a year, at most
Base: more than 15 million H100 equivalents, according to Epoch AI (Jan 2026) · third-party context. The cautious scenario is a central figure; the one with factors already measured is a ceiling. None of this was measured in a data center. Electricity and CO₂ are a ceiling, not a guaranteed saving.
The projected part, kept apart
590 thousand to 1.24 millionmore GPUs · if the same result holds in the rest of inference
314 thousand to 486 thousandmore GPUs · if training saves on its data what the disk already saves
Projected figures are not added to the derived ones.
See more · specificationsHide specificationsThe world, in detail · a data center, per MW · per GPU · per petabyte
Nothing in this section was measured in a data center. Derived figures come from measured ones, with the source of every factor; projected figures add assumptions about uses we didn't measure against a rival, and they're kept apart, with their condition. Energy is a ceiling, not a guaranteed saving. The figures don't add up across one another.
Worldwide
One measured job, the world's entire GPU fleet
In the job it replaces, the ratio is large and measured: 71 times less recomputation after a correction, 18 times less text sent to the AI with narrow filters. Across all the work of the world's GPUs the percentage is smaller, because a GPU also does work our model doesn't touch. Even so, what derives from our measurements frees 435 thousand to 2.37 million GPU equivalents, and at most 2.81 to 20.70 TWh and 1.25 to 9.21 Mt of CO₂ a year.
The projected part, kept apart. In the rest of inference, if the same result holds in those uses, another 590 thousand to 1.24 million GPUs are freed; and if training saves on its data what the disk already saves, another 314 thousand to 486 thousand.
Share of the world's GPU capacity that would be freed
derived and projected in separate panels: no bar adds one to the other
Derived from our measurements
Projected, under its conditions
filtered search and mid-document edits | the rest of inference | training | |
|---|---|---|---|
| GPU equivalents freed (of current capacity) | 435 thousand · 2.37 million | 590 thousand · 1.24 million | 314 thousand · 486 thousand |
| share of world capacity | 2.9% · 15.8% | 3.9% · 8.3% | 2.0% · 3.2% |
| electricity a year, at most (TWh) | 2.81 · 20.70 | 3.81 · 10.91 | 2.03 · 4.24 |
| CO₂ a year, at most (Mt) | 1.25 · 9.21 | 1.69 · 4.85 | 0.90 · 1.88 |
filtered search and mid-document edits
- GPU equivalents freed (of current capacity)
- 435 thousand · 2.37 million
- share of world capacity
- 2.9% · 15.8%
- electricity a year, at most (TWh)
- 2.81 · 20.70
- CO₂ a year, at most (Mt)
- 1.25 · 9.21
the rest of inference
- GPU equivalents freed (of current capacity)
- 590 thousand · 1.24 million
- share of world capacity
- 3.9% · 8.3%
- electricity a year, at most (TWh)
- 3.81 · 10.91
- CO₂ a year, at most (Mt)
- 1.69 · 4.85
training
- GPU equivalents freed (of current capacity)
- 314 thousand · 486 thousand
- share of world capacity
- 2.0% · 3.2%
- electricity a year, at most (TWh)
- 2.03 · 4.24
- CO₂ a year, at most (Mt)
- 0.90 · 1.88
In each entry: cautious scenario · with factors already measured. The columns don't add up into a single figure.
The conditions of the projected part
- The rest of inference: if the same result holds in those uses.
- Training: if it saves on its data what the disk already saves.
Per GPU and per MW
The same demand, with less infrastructure
With the AI's memory full and narrow filters, against a typical ten-result search with no threshold, each MW of GPU working this way serves 1.53 to 2.31 times the conversations. For the same demand, 0.344 to 0.567 MW of every MW is freed: grid connection, cooling and building you don't have to build. In energy, that's at most 3,287 to 7,645 MWh per year per MW, and at most 1,150 to 3,402 tonnes of CO₂. It applies to the share of the load that works in that regime.
0.344 to 0.567 MWfreed from every MW of GPU in that regime
3,287 to 7,645MWhEnergy, per MW per year
1,150 to 3,402tCO₂, per MW per year
Of every MW of GPU working in that regime, the share that's freed
built on the measured 18× in tokens
Energy, per MW per year
CO₂, per MW per year
1,630 to 17,200
kWh per year for every GPU freed, data center included
Range: power per GPU from 171 W to 1,275 W and PUE from 1.09 to 1.54.
On each correction, the energy spent recomputing is 71 times lower, in the same proportion as the recomputation.
Per PB
Reading: cross-matching large catalogs114.6 to 162.0kWh less per PB cross-matched
Writing 36.4 times less0.11 to 0.38%of the day, with our system · 4.0 to 13.6% of the day, with SQLite
Reading: cross-matching large catalogs
With static data and the structure already built, each PB cross-matched uses 114.6 to 162.0 kWh less and emits 40.1 to 72.1 kg less CO₂ (from the US grid to the world grid). With the same fleet, 6.2 times more cross-matches per hour.
Preliminary: it assumes a 400 W server and that energy follows compute time.
Writing 36.4 times less
With a load of three full disk writes a day, the time the disk spends writing, from its fastest kind of write to its slowest:
4.0 to 13.6%of the day, with SQLite
0.11 to 0.38%of the day, with our system
Where the disk's endurance is the limit and all its writes come from this load, it lasts up to 36.4 times more work. Direct electricity is the small part: 0.49 to 1.83 kWh per PB not written.
Beyond energy, what we measured opens other uses.
What else can it open up?
What it opens up: on frontier models, potential; on the tools the world runs on, figures already measured.
Frontier models
Potential on frontier models · its figure was measured on an open 7-billion-parameter model
Potential
on frontier models, no figure
We measured it with an open 7-billion-parameter model: 71 times less recomputation, with the same answers. We did not measure it on frontier models; there, the impact is potential.
With narrow filters, up to twice the conversations per GPU
up to 2×
conversations per GPU · 1.53× to 2.31×
With narrow filters, we measured 18 times less text sent to the AI than with a typical ten-result search with no threshold. With those filters and the AI's memory full, the math gives up to twice as many conversations per GPU.
Beyond AI: tools used all over the world
Measured (the multiples) · third-party context (their reach)
36.4×
less writing than SQLite as it's really used
SQLite, the database that, according to its website, runs on every Android, every iPhone and every Mac, in more than one trillion databases: doing its job, our system writes 36.4 times less, measured on a laptop with SQLite as an application uses it.
The anti-fraud use
Fraud rules cross-match transactions against time windows and amounts, and today they're rerun in full on every batch.
It works there as in the other uses: it replaces the way of deciding what to touch when something changes. The customer's rules, data and anti-fraud system stay as they are, and the answer is the same.
Fraud detection and prevention: from USD 35.7 billion in 2026 to USD 80 billion in 2031, according to MarketsandMarkets (Jul 22, 2026).
5.46 to 28.66×
faster at running a fraud rule, depending on the window-and-amount combination; 7.58× on the default question (48 h, USD 100)
Measured with a clock · synthetic transactions: 250,000 deposits and 50 million withdrawals in one year · static data, in memory · vs. the standard cross-match with its optimizer, in its best normal form · technique against technique. It measures how much faster the rule runs on data that doesn't change; this is not a comparison against fraud engines.
See more · specificationsHide specificationsThe full texts · how each figure was measured · conversations per GPU, as a chart
Frontier models
The rule we measured against is the standard one in language-model servers: the prefix cache of vLLM and SGLang. According to its website, SGLang runs on more than 400,000 GPUs. Redoing work already has a price: Anthropic charges 12.5 times as much to rewrite the AI's memory as to reread it. We measured it with an open 7-billion-parameter model: 71 times less recomputation, with the same answers. We did not measure it on frontier models; there, the impact is potential.
How each figure was measured
- More than 400,000 GPUs · according to SGLang's website · third-party context.
- 12.5× · Anthropic's list price: writing to its 5-minute cache costs 1.25 times the input, and rereading, 0.1 times · third-party context.
- 71× · measured with an open 7-billion-parameter model, as in “Efficiency.”
- On frontier models · potential: we did not measure it on them.
Beyond AI: tools used all over the world
SQLite, the database that, according to its website, runs on every Android, every iPhone and every Mac, in more than one trillion databases: doing its job, our system writes 36.4 times less, measured on a laptop with SQLite as an application uses it. Exact pgvector, offered on Amazon, Google and Microsoft: more than 100 times less work, with the same answer. The European Space Agency's Gaia catalog: with static data, 6.2 times sooner than its official cross-match method, with the same answer.
How each figure was measured
- 36.4×, more than 100× and 6.2× · measured, as in “Efficiency.”
- "Every Android, every iPhone and every Mac" and "more than one trillion databases" · according to SQLite's website · third-party context.
- "Offered on Amazon, Google and Microsoft" · according to each provider · third-party context.
With narrow filters, up to twice the conversations per GPU
With those narrow filters and the AI's memory full, the math gives each GPU 1.53× to 2.31× the conversations, versus a typical ten-result search with no threshold. Each end of the range says where it comes from: the low end counts only the questions that have an answer; the high end counts every question, as in the test.
Conversations per GPU, with narrow filters and the AI's memory full
Built on the measured 18× in tokens · AI memory full · narrow filters · context share from a published source (Cache-Craft) · assumptions in plain view.
Every measured figure is a floor. Derived figures come from measured ones, with the source of every factor; projected figures depend on the stated condition. Energy is a ceiling, not a guaranteed saving.
Time to run the same fraud rule, with static data
vs. the standard cross-match with its optimizer · synthetic transactions
The combination with the least advantage
The default question: 48 h, USD 100
The combination with the most advantage
The other citable combinations fall between the lowest and the highest; two of the nine aren't cited because they failed the machine check. This is not a comparison against fraud engines.
View this chart as a table
| combination | standard cross-match time (our model = 1) |
|---|---|
| The combination with the least advantage | 5.46× |
| The default question: 48 h, USD 100 | 7.58× |
| The combination with the most advantage | 28.66× |
And in science, the potential is astronomical.
And in science, where data never stops growing?
An astronomical potential.
With the entire Gaia catalog, larger than the machine's memory, and even with static data, the rival's best condition, we finish 6.2 times sooner than the Gaia Archive's official cross-match method.
Fast data processing
6.2×faster than the Gaia Archive's official cross-match method (ESA), with the same answerimplemented from its published method · structure already built on both sides
7.6×faster than HEALPix, astronomy's standard, with the same answerimplemented from its definition · structure already built on both sides
1.812 billionsky sources and 58 GB: the entire Gaia DR3 catalog, more than the machine's 24 GB of memory
11,881,062relationships: the same list returned by STILTS, LSDB and Q3C, three real astronomy tools.
10.55 sto be sure nothing is missing, measured vs. 132 days of compute, derived: calculated, not run, comparing everything with everything, as pgvector, hnswlib and FAISS prescribe to check it
In research, where data keeps growing
Scientific archives and data integration cross-match catalogs with billions of records, and every new release forces the cross-match to be redone. The more the data grows, the more it costs to redo the whole cross-match. The test is astronomical; the question, what relates to what, belongs to the whole industry.
When the data changes
868relationships lost, without warning
911relationships no longer valid, without warning
The rival that doesn't rebuild loses 868 relationships and returns 911 that are no longer valid, without warning.
See more · specificationsHide specificationsThe cross-match in detail · almost at the limit of the disk · both rivals, each in its own panel · being sure nothing is missing
Reading large catalogs
Scientific archives and data integration cross-match catalogs with billions of records, and every new release forces the cross-match to be redone. The test is astronomical; the question, what relates to what, belongs to the whole industry. With the entire Gaia catalog, larger than the machine's memory, and even with static data, the rival's best condition, we finish 6.2 times sooner than the Gaia Archive's official cross-match method. Same answer, same memory, almost at the limit of the disk itself.
Almost at the limit of the disk: each side's time, against the cost of just reading the catalog
time, as a % of the cost of just reading the catalog's 58 GB from disk
View this chart as a table
| who | time, as a % of just reading the catalog |
|---|---|
| Gaia Archive's official cross-match method | 739% |
| Our model | 119% |
Two rivals, two runs: each in its own panel, on the same axis
Gaia Archive's official cross-match method
HEALPix, astronomy's standard
HEALPix: 5.6× if it's given help its library doesn't include.
View this chart as a table
| rival | time (our model = 1) |
|---|---|
| Gaia Archive's official cross-match method | 6.2× |
| HEALPix, astronomy's standard | 7.6× |
Being sure nothing is missing
measured, with the structure already built, against derived: comparing everything with everything
At this scale, the 10.55 s can't be seen. The scale is linear: a logarithmic one would shrink the difference.
Figures like these demand a method. Here's how we tested.
How did you test it? Why believe these figures? How do I know you didn't tune the test until you won?
Before counting who does less work, we require the exact same answer.
Four promises in every test
- The same answer, or no ratio. Both sides are checked against a ground truth computed separately; when the rival doesn't deliver it, we show its behavior, with no ratio.
- The rival, as the industry runs it. Its version, its documented recipe and its defaults; if it has two modes, both.
- Every correction in the rival's favor. If a setup put it at a disadvantage, we fixed it before publishing.
- The prediction, before measuring. We write down what we expect and which result would prove the hypothesis wrong.
See more · specificationsHide specificationsThe eight rules · the life of a test · the prediction · what we compare · the machine and the data
Both sides must return exactly the same thing, and that answer is checked against a ground truth computed separately, from the written rule. The rival runs the way the industry uses it: its version, its documented recipe, its defaults; if it has two modes, we measure both. When a setup put it at a disadvantage, we corrected it in the rival's favor before publishing. And before measuring, we write down what we expect and which result would prove the hypothesis wrong.
The eight rules of every test
Exact same answerBoth sides return the same thing, checked against a ground truth computed separately.
Technique or systemEach figure says whether it compares the way of deciding or the whole system.
Standard documented formThe rival runs with its version, its recipe and its defaults.
Two modes, bothIf the rival has two modes, both are measured, with what each one costs.
Corrections in the rival's favorIf a setup put it at a disadvantage, it was corrected in the rival's favor before publishing.
Regime on every figureAgainst what, with what data, static or changing, and at what scale.
One cost, one verdictTokens, bytes, work, time and memory are measured separately. They're never added up.
One machine, the same dataBoth sides on the same machine, with the same sequence of changes, sealed before measuring.
The life of a test
- Prediction
- Reviewer before
- Planted errors
- Reproduce the previous run
- Measure
- Reviewer after
- Repeat
- Publish the lower figure
Planted errors
A control that can't fail proves nothing. On the GPU, the control that recomputes nothing answers with the stale fact, and fails, as it should. In search and in SQLite, the planted faulty versions fail. In a slice of the Gaia catalog, an error planted by hand stops the test with an error, instead of returning less.
Reproduce the previous run
On the GPU and in search, before measuring anything new, the same instrument repeats the previous measurement, and it must give exactly the same result: zero differences.
Repeat and publish the lower figure
The SQLite test gave 36.4×; the full repeat, 36.6×. We publish 36.4×, the lower one. In the Gaia cross-match, three runs were discarded by the machine control, even though one favored us. The order of the sides alternates in every run.
A reviewer with veto power
Since Oct 21, 2026, a project reviewer who neither designs nor measures approves each test before it touches the machine, checks that each rival is in its standard form, and recomputes the figures from the raw data. Without that sign-off, the test doesn't run. Before that, an internal audit of each rival's code and data led to 11 corrections of figures or labels, all applied; no headline figure changed direction.
Did we tune the test until we won?
Before measuring search, we wrote down the range we expected. The figure landed inside it. And the prediction protected the rival too: twice, an advantage that didn't match what we expected told us we were measuring it wrong, and we corrected it in the rival's favor.
Prediction written before measuring, and the measurement
What we compare
Only the way of deciding, in the same program.
The whole system against the whole system.
What the rival does when the data changes, without inventing a ratio.
Five costs, kept separate
- Tokens
- Bytes
- Work counted
- Time
- Memory
Most figures are counts, which travel from one machine to another; the clock is used only where we controlled that the machine was idle.
The machine and the data
- MacBook Pro, Apple M4 Pro, 24 GB: both sides on the same machine.
- The same sequence of changes for both, sealed before measuring.
- The entire Gaia DR3, from the European Space Agency: 1,812,731,847 sources and 58 GB.
- Real Gaia records, for the disk; technical text with planted facts, for the GPU.
- An in-house corpus and the Reina-Valera 1909 Bible, in the public domain, for search.
Why every figure is a floor
- Static data is the rival's best condition.
- What the rival doesn't pay for, like building its index, stays out of its count.
If the structure was built beforehand, on both sides, the figure says so.
With the evidence in view, one question remains: where it fits.
Which layer does it work in? Does it fit my architecture? What change does it ask of my infrastructure?
It works wherever a fixed rule decides what to touch when data changes.
It installs as a library or a container in the customer's infrastructure, where nothing leaves their servers. Their data, hardware, AI model and search engine aren't touched, nor is what the application asks and receives. The answer is the same. Load balancers, queues, replicas, partitions and compression keep doing their job: each request arrives asking for less work.
The architecture map
measuredanalyzedexpectedcoexists
Logical architectures
- measuredAI model server
- measuredSearch for AI (RAG)PostgreSQL: measured as the rival's host (pgvector)
- measuredAgent memory, with expiration
- measuredEmbedded database (SQLite)
- measuredBatch processes that rebuild
- measuredLarge-catalog cross-matchingthe data-integration question: what relates to what
- analyzedText searchLucene, Elasticsearch, OpenSearch
- analyzedAnalytical warehousematerialized views
- analyzedSpatial joinsH3, S2, PostGIS
Physical architectures
- measuredGPUon the GPU of an Apple chip (Apple M4 Pro)
- measuredProcessorless counted work and less time, with the same data read
- measuredSSDwrites far less; reads almost at the limit of the disk
- analyzedPhone flash memorythe same disk-write case as SQLite
- coexistsMultiple machines and cloudcoexists with what's already there
- measuredSmall machineeverything ran on a laptop, with a 7-billion-parameter model at 4 bits
It replaces the rule that decides. Everything else keeps working.
They combine; they don't compete
See more · specificationsHide specificationsWhere it works in an AI solution · how it installs · what it replaces and what it complements
Where it works in an AI solution
- Data
- Prepare
- Store and index
- Search with filterswhat to query again when documents change · in the application, on top of the search engine
- Assemble the context
- Language model, on its serverwhat to recompute in the AI's memory · on the model server
- Answer
How it installs
The customer's infrastructure
- Their application
- Their tool: search engine, model server or database
- Their data
- Their hardware
Our model · library or container
Untouched
- the data and its format
- the hardware
- the AI model and its weights
- what the application asks and receives
- the search engine and its index
The answer is the same.
Coexists with everything else
expected Each request arrives asking for less work, and under load, the queue should get shorter.
In text search, we measured the rival
In SQLite, a text index that catches up every so often misses what arrived in between, and its answer gives no way to know: if some 1,000 matching relationships arrive in that lag, it misses 974 to 1,026, on databases of 10 thousand to 1 million records.
Which techniques does it replace, and which stay? Is it the hardware or the software?
It replaces the rule that decides. Everything else keeps working.
It replaces the rule that decides what to recompute, what to query again, what to rewrite or what to rebuild. Whatever stores with fewer bits, sorts, distributes or computes faster keeps working: model quantization ran alongside it in our tests, with 4 bits weights, and the search engine and its index stayed untouched. New hardware makes each operation faster; our model means there are fewer operations. They combine; they don't compete.
Replaces
- measuredThe prefix cache, on a mid-document correctionsee its figure
- measuredCacheBlend's selectionsee its figure
- measuredQuerying everything againsee its figure
- measuredAlways asking for the ten most similar documents, when there are filterssee its figure
- measuredThe periodic sweep of expired datasee its figure
- measuredWriting every page twice and querying againsee its figure
- measuredRebuilding the whole structuresee its figure
- measuredThe official cross-match method and HEALPixsee its figure
- DerivedA check that, at this scale, nobody runs because of its cost: comparing everything with everything to be sure nothing is missingsee its figure
Analyzed, no figure
- analyzedFull refresh of views
- analyzedQuerying again in text search engines
- analyzedSpatial joins
Complements
Measured alongside
- Weight quantization: the GPU ran at 4 bits
- The search engine and its index, untouched
Documented
- Partitions
- AI memory paging (vLLM)
- FlashAttention
- Ordered writes on disk
- SSD firmware
- Lakehouse deletion vectors
No figure
- AI memory compression
- Compression and columnar formats
- Load balancers, queues and replicas
The test that matters most is the one run on your data.
How do I test it on my data?
Write to me to set up a meeting.
We'll deliver the correct set, with its proof. Write to me with your name, company, role and what you'd like to evaluate: AI memory, search for AI, disk writes, or large-catalog cross-matching, and we'll set up a meeting. In your first message, please don't send data or details about your systems.
Write to me to set up a meeting