Before You Buy Performance, Measure It

The most expensive thing in AI is waiting

AI accelerators compute far faster than memory can feed them. The result is a quiet, enormous cost: powerful GPUs spending a large share of every hour stalled, waiting for parameters, activations and attention state to arrive. Industry analyses consistently place the idle share of memory-bound AI infrastructure at 30 to 50 percent. Whoever you buy your hardware from, you are paying full price for that waiting time.

At Physivitis we treat this not as an engineering inconvenience but as a physics problem: a mismatch between the rate at which computation demands data and the rate at which the memory system supplies it. Our answer is CFMDI, a patented predictive data staging framework. Instead of fetching data when the chip asks and paying the full transfer delay on the critical path, CFMDI is designed to move data ahead of demand using knowledge the system already holds about its own future: the model's largely deterministic execution schedule, the serving scheduler's queue of pending requests, and the structure that repeats across requests. Transfers overlap compute instead of blocking it.

Why we sell measurement before we sell performance

Here is something unusual for a deep-tech company to publish: before approaching any partner, we attacked our own claims. We built adversarial simulations, pitted our approach against the strongest published baselines, and measured a perfect-knowledge oracle to find the true ceiling of each approach.

Two results came out of that work, and we state both. First, cache retention, the dimension most of today's methods compete on, is close to a solved problem: even a perfect retention policy gains only 1.3 to 1.6 times over standard baselines. We do not claim that territory. Second, staging data ahead of demand showed 4 to 16 times effective-throughput headroom in the same framework. That is the dimension CFMDI targets, and it is the only dimension where gains of that scale are structurally possible.

Headroom is the size of the prize, not an achieved result. The decisive commercial question is what fraction of it a real system can reach on real workloads. We believe the only honest way to answer that question is to measure it, on your hardware, against your baselines, under a protocol agreed in writing before a single run. So that measurement is the product.

The CFMDI Validation Pilot

The Validation Pilot is a fixed-price, fixed-scope engagement that produces one thing: the measured answer for your workloads. Every tier includes a pre-agreed written protocol, benchmarking against your current baseline and a perfect-knowledge oracle bound, end-to-end metrics (tokens per second, p95 and p99 latency, GPU utilisation), a reproducible benchmark harness your engineers keep and can rerun, and a plain-language go or no-go recommendation. Pilot customers receive preferential licensing terms with first refusal if the results justify going further.

The pilot runs safely: the evaluation operates in user space, changes no model outputs, and begins in observe mode, in which CFMDI decides and reports but issues no transfers at all, so your team can audit its behaviour before anything is enabled.

What is waiting validation, and what it could be worth

Three deployment tiers of CFMDI stand behind the pilot, each at a different depth of integration. All three figures below are design projections pending validation; publishing them as projections, and then measuring, is precisely the discipline the pilot exists to enforce.

* Design projections pending independent validation. Our simulations establish 4–16x staging headroom; the pilot measures the fraction your workloads can reach.

A worked scenario: what you actually gain, in pounds

The following is an illustrative scenario, not a completed engagement or client result. We publish every assumption so you can rerun the arithmetic with your own figures; replacing these assumptions with your measured number is what the pilot does.

First, what a gain means in practice

When the pilot measures, say, a 1.5x end-to-end throughput gain, it means your GPUs complete 50 percent more inference work per hour because they spend less time waiting for data. That one number converts into three concrete benefits, and you choose which to take:

• Cut cost: serve exactly the same traffic with a third fewer GPUs. Those machines are switched off, returned, or their cloud contracts not renewed. The saving lands directly on the infrastructure bill.
• Grow revenue: keep every GPU and serve 50 percent more customers, tokens or requests on hardware you have already paid for. No procurement, no waiting for allocation.
• Defer spending: your next capacity purchase moves 12 to 18 months out, because the estate you own just became half as big again.

Scenario: an AI cloud operator with 1,000 accelerators

The assumptions: 1,000 current-generation accelerators (H100 or MI300X class) serving LLM inference, at a conservative all-in cost of £2 per GPU-hour, running year-round.

Step 1, what the estate costs today: 1,000 GPUs x £2 per hour x 8,760 hours equals roughly £17.5 million per year.

Step 2, what the waiting costs today: industry analyses place memory-stall idle time at 30 to 50 percent, so £5 million to £9 million of that £17.5 million is paid every year for silicon that is waiting, not working.

Step 3, what each measured outcome is worth. A gain of G means the same workload needs only 1/G of the fleet, so the benefit is the cost of the GPUs you no longer need (or the extra work the same GPUs now do):

Read the fourth column again, because it is the whole argument: on an estate of this size the Hardware Pilot fee is 0.17 percent of one year's running cost, and if the measured gain is 1.5x the benefit repays the fee roughly every two days, indefinitely. Even the worst outcome, no gain, is worth the fee, because it stops a seven-figure licensing and integration programme before it starts. There is no outcome in which the measurement is worth less than its price.

Scenario: an accelerator or memory vendor

For a hardware vendor the benefit is not an infrastructure saving but a selling advantage, and it is larger. Accelerators such as AMD's MI300X carry a genuine memory-capacity lead; the market question is how much of that capacity becomes delivered throughput in the benchmarks that decide purchases. If a vendor-run pilot measures a meaningful gain on its own silicon, the benefit is concrete: stronger published inference benchmarks against the competition, a differentiating software capability across an entire product line, and a sharper price-performance story in every customer deal, for a pilot fee smaller than the cost of a single benchmarking engineer-month. If the measured gain is small, the vendor has spent £30,000 to £45,000, not a roadmap commitment, to find out.

How a pilot runs

1. Scoping call and NDA.
2. Protocol agreed in writing: workloads, baselines, metrics, information budget, oracle bound.
3. Observe-mode run first; no changes to system behaviour.
4. Measured runs against baselines on real serving traces.
5. Report and joint readout, with the reproducible harness handed over.
6. Your decision; no obligation beyond the pilot.

The honest close

Most performance products ask you to believe a number. We are asking you to help us measure one, at fixed cost, under a protocol you approve, with results you can rerun. If CFMDI's staging approach reaches a meaningful fraction of the headroom our simulations have quantified, you will be first in line, on preferential terms, for a capability no incumbent stack ships today. If it does not, you will know quickly and cheaply, and we will say so as plainly as we have said everything else on this page.

Physivitis Ltd. Deep-Tech IP and Software for the AI and Quantum Era. CFMDI is protected by UK Patent GB2605144.1 (Patent Pending). All performance figures are design projections or simulation measurements pending independent validation; scenarios in this article are illustrative with stated assumptions and do not describe completed engagements. The pilot sells measurement, not performance. Method details are available under NDA.