← Back to Signal
Technical PositionMarket SignalsPosition on The Inference War

The processor side of the inference war

Why Nate B. Jones's three-force framework has a fourth body, and why Prizmal is the company that defines it.

Audry Larocque and Jonathan Pilault · April 12, 2026 · 8 min

Key takeaways
  1. 01Jones's three-force model is accurate but incomplete. The fourth force is Runtime Compute Control.
  2. 02TurboQuant compresses the RAM. PrizmalRun governs the processor. Different layers, different problems.
  3. 03R/E, reasoning quality per joule, is the metric that defines the inference era. Tokens per watt treats all tokens as equal; they are not.
  4. 04TurboQuant and PrizmalRun are additive. There is no overlap with Prizmal's patents or GTM.
  5. 05Compression has a ceiling. Compute allocation does not. Every token, every context, is different.

01 · The signal

Jones names the architecture.

On April 11, 2026, Nate B. Jones, one of the most widely read AI infrastructure analysts writing today, published a piece titled Your GPUs Just Got 6x More Valuable. No New Hardware Required. It reached the top of the AI infrastructure conversation within hours. The framing matters to us because Jones independently arrived at the exact metaphor that defines Prizmal's category.

"If the model weights are the processor, the KV cache is the RAM."
Nate B. Jones · Nate's Substack · April 11, 2026

Jones built a three-force taxonomy around the inference memory crisis: constrained memory supply set by fab timelines, exploding agent demand set by adoption curves, and compression as the fastest-moving third force. His central exhibit is TurboQuant, Google's KV cache compression algorithm that achieves 6x memory reduction with zero accuracy loss. His conclusion: compression is the fastest variable in a system where the other two forces are structurally slow.

The framework is correct. It is also incomplete. Jones mapped the RAM story with precision. The processor story has no name yet.

02 · The four forces

Three forces, plus one.

Jones's three-force model correctly identifies what is constraining AI infrastructure. Adding the fourth force is not a correction. It is a completion. Each force operates on a distinct timescale and a distinct layer of the stack.

ForceWhat it isTimescale
SupplyMemory constrained by fab timelines. HBM consumes 3x silicon per bit. New capacity targets 2027 to 2030.Years
DemandAgent workflows exploding token consumption. Jensen: "$250K tokens per $500K engineer."Quarters
CompressionTurboQuant. 6x KV cache reduction. Math papers ship in days. No hardware required.Days
Runtime Compute ControlGoverns how much compute each token earns, live, during inference. No fab cycle, no training run, no deployment overhead.Forward pass

Compression is the fastest force Jones identified. Runtime Compute Control operates on the same timescale, at a different layer. It is not competing with TurboQuant. It is the missing axis.

03 · Processor vs RAM

The metaphor, fully extended.

Jones's metaphor is structurally precise. The KV cache is the RAM. It holds what the model has seen. TurboQuant compresses that RAM by 6x. That is a real and significant result. PrizmalRun operates on the processor side. Not what gets stored. What gets computed. The distinction is architectural, not rhetorical.

Model · LLM weights

The processor. Neither system modifies the weights.

Prizmal · PrizmalRun

Operates inside the inference engine. Reads attention entropy, logit variance, and hidden state norm changes per token in real time. Modulates compute dynamically: layer skipping, head scaling, precision switching, sparsity injection. Hard tokens get full compute. Simple tokens skip layers. Decided live, every token.

TurboQuant · KV cache layer

Compresses stored key-value vectors to 3-bit representations. Acts on data at rest in memory. Data-oblivious by design. Has no mechanism to observe or influence the forward pass compute graph.

Silicon · GPU, NPU, edge SoC

Execution substrate. Both systems run on existing hardware without modification.

A model running TurboQuant still executes every layer, every attention head, at full compute depth, for every token regardless of difficulty. TurboQuant's operating surface ends at the memory buffer. The question of how much compute a token actually requires is not a compression question. It is a control question.

04 · Investor implications

R/E is the metric of the era.

The inference era's defining efficiency question is not tokens per watt. That metric treats all tokens as equivalent. They are not. A token completing a filler phrase and a token resolving a multi-step reasoning step are not the same computation. Measuring them identically is the wrong frame. R/E, reasoning quality per energy consumed, is the correct metric. Maximizing it requires knowing, in real time, how much compute each token deserves. That is exactly what the SpeCo controller does.

R/E vs dense
+251%

Reasoning quality per joule.

Reasoning kept
99%

At 50% sparsity.

Compute
-60%

FLOPs reduction at inference time.

Intact

TurboQuant does not enter PrizmalRun's operating domain. It cannot adapt to token difficulty. It cannot route compute. The problem PrizmalRun solves is untouched.

Strengthened

TurboQuant reduces memory bandwidth cost. It does not improve R/E. The R/E constraint, reasoning yield per joule, is a compute allocation problem, not a compression problem. That is Prizmal's category.

No overlap

Prizmal's provisional patents cover guided blockwise structured pruning, disagreement-aware adaptive pruning, layer-sensitivity pruning caps, and oracle-guided routing policy training. Zero overlap with vector quantization prior art.

Additive

TurboQuant and PrizmalRun optimize independent axes in the same stack. A joint deployment addresses both memory-side and compute-side efficiency simultaneously.

Middleware squeeze

Jones identifies that compression advantages accrue closest to the metal, squeezing the orchestration layer. PrizmalRun sits inside the engine. It is the layer that survives the squeeze.

Compression ceiling

KV cache compression is near the ceiling for its problem class. Beyond that point, further compression destroys effective information nonlinearly. The compute allocation problem has no such ceiling.

05 · Bottom line

The position.

Runtime Compute Control is the fourth force

PrizmalRun is the control system. R/E is the metric of the era. Prizmal is not a model. It is the control system for AI compute.

Nate B. Jones published the best public taxonomy of the inference stack written to date. His three-force model is accurate, his processor and RAM metaphor is precise, and his identification of the middleware squeeze is correct. His framework has an empty slot that Prizmal fills: the layer that governs compute on the processor side, token by token, in real time.

FAQ

Is the fourth force a competitor to TurboQuant?
No. TurboQuant compresses what is stored in memory between forward passes. Runtime Compute Control governs what executes inside the forward pass. They operate on different axes and stack cleanly.
Why R/E and not tokens per watt?
Tokens per watt treats every token as equivalent. A filler token and a multi-step reasoning token consume different amounts of computation and produce different amounts of value. R/E captures the actual yield of the work.
What does Jones's framework get exactly right?
The processor and RAM metaphor is structurally precise. The identification of the middleware squeeze is correct. The timescale taxonomy of years, quarters, and days is the cleanest public map of inference economics.

Run the numbers on your own traffic

The R/E Audit measures reasoning per unit of energy on your real workload, read only and reversible.