Emerging Systems

Systems built from the ground up.

Architecture and systems engineering — designing how a system works at the level of memory, hardware and first principles, rather than assembling parts and hoping. We measure what we build against the best thing that already exists, and we publish what fails.

Driving technological evolution

systems architecture low-level engineering performance & memory applied research

Mission

Keep capable intelligence running on hardware people already own.

The capability frontier is increasingly gated by access to compute that only a few organisations can afford to own. That is a genuine chokepoint, and left unopposed it has a predictable shape: intelligence rented by the meter on terms the renter does not set, and the ability to build and verify one’s own tools quietly atrophying. We do not argue against the concentration — we work to make the requirement it rests on economically irrelevant.

Why efficiency, specifically

Openness can be withdrawn and regulation can be captured, but efficiency cannot be taken back. The moat is the compute requirement; every bit shaved and every model distilled to run on commodity silicon dissolves a little of it. Our results are measured on ordinary CPUs with no GPU on purpose — that is the point, not a limitation.

What that commits us to

Owned hardware first; efficiency over scale; tools that run with no gatekeeper in the loop; and every claim verified against a real reference before it ships. A result that only holds on a rented cluster does not advance this mission — a capable one that runs on a decade-old desktop does.

The squeeze, in numbers (2026)

SignalFigureSource
HBM share of global DRAM wafers23% in 2026, up from 8% in 2024IntuitionLabs / TrendForce
2026 supply growth, DRAM / NAND16% / 17% YoY — below historical normIDC
Server DRAM contract price, Q3 2026+13–18% QoQTrendForce
Enterprise SSD contract price, Q1 2026+80%Astute Group
Memory as share of a mid-range phone’s BOM15–20%IDC
Sub-$300 smartphoneshit hardest; some brands cutting output or exiting the tierThe Register
Supply reliefnot before 2027; HBM effectively sold out; new fabs 2028–29IDC

External market data, cited — the environment this work answers, not our own measurement. It is the reason generative memory — a machine that runs as if it holds far more RAM than it physically does — is a response to concentration, not a novelty.

Generative memory — a working definition

Generative memory treats a machine’s working memory as something to be produced on demand rather than held in full. Instead of keeping every byte resident in physical DRAM, the system retains a compact form from which the exact contents are reconstituted — faithfully, at the moment they are touched — and released again when they are not. The effect is that a machine can present substantially more usable memory than it physically contains, on ordinary hardware, with the original bytes reproduced exactly.

In one line: it trades a resource that is scarce, costly, and increasingly centralised — physical memory capacity — for one that is abundant and locally owned: computation on hardware you already have.

An approach under active development at Emerging Systems. The enabling method is deliberately withheld; a measured account will follow.

Efficiency

The same efficiency that answers cost answers energy.

Compute concentration carries a second bill after price: energy. Serving and training at frontier scale draw power and water at data-centre scale, and that draw is rising faster than the grid behind it. Efficiency is the rare lever that lowers the cost and the footprint at once — a unit of capability that needs less silicon needs less energy to run, on hardware that already exists rather than a new rack that has to be built, cooled and fed.

Where the saving is structural

The engine runs on ordinary CPUs with no GPU and no accelerator, demonstrated on hardware as old as a 2008 Xeon. The single largest energy cost in modern AI — the accelerator cluster and the high-bandwidth memory that feeds it — is simply not in the loop. What is drawn is CPU-class power, on a machine you already own.

What we measure, and what we will not claim

Where the hardware exposes it, energy is read on-die through RAPL in real joules, never estimated; on CPUs with no energy counter we report timing only and say so plainly. A measured joules-per-token account is in preparation. We will not publish a carbon or energy figure we did not measure.

We treat the environmental case as a consequence to be measured, not a slogan: the efficiency that makes capability affordable on owned hardware is the same efficiency that makes it lighter on the grid.

Position

Ground-up architecture, held to an academic standard.

Most engineering work is assembled from components chosen by convention and benchmarked against whatever the team wrote first. We work the other way round: understand the system at the level where its behaviour is actually decided — bandwidth, cache, layout, precision, the shape of the data — then build upward from what is true there.

And we hold the result to a standard borrowed from research: every claim is measured against the best available reference, and where we lose, we say by how much. That discipline is the product; the domain is wherever the problem is.

What ground-up means

Start at the constraint that actually governs the system rather than the layer that is easiest to change. Most performance problems are memory problems wearing a costume; most architecture problems are decided by a data layout chosen years earlier. Find that, and the rest follows.

Research is how we prove the method

The published work below is an audit of our own approach: ten hypotheses tested against real systems, seven falsified with the numbers attached. We publish the failures because an engineering claim that has never been allowed to fail is not worth much. The tools stay open regardless.

Applied research

A worked example: ten hypotheses, seven falsified.

One programme, chosen because it is unusually easy to fool yourself in: making a large model run on small hardware. Measured on real weights, on a 6-core laptop CPU with no GPU. Three of ten survived. Each is written up in the library with the script that produced it — the point is the method, which transfers to any system where the constraint is physical.

HypothesisResultMechanism
int8, per-output-column scalesurvives · 2× y-cosine 0.999949; tokens unchanged through 28 layers
Batchingsurvives · 3.4–8× throughput only; single-stream latency unaffected
Lloyd–Max quantiser levelssurvives · 35% error cut at 4 bits by placing levels on the density
Ternary weightsfalsified cosine 0.877 vs int8's 0.99995, on both model families
Magnitude pruningfalsified dominated by dense int4; weights are a bell, median 0.81× mean
Contextual sparsityfalsified SwiGLU emits no zeros; 10–30% active-set overlap between tokens
Low-rank activation subspacefalsified dimensionality grows with sample size, not a model property
Content-addressed deduplicationfalsified 1.000× at every chunk size; 7.025 bits/byte entropy
Operation fusionno gain 197 → 113 matrix-vector calls moves zero bytes
Multi-core threadingno gain 0.94× at 6 threads — bandwidth is shared, cores don't add bus

Read the full write-ups in the research library →

Cross-cutting result: quantisation fidelity is a property of bit width, not of the model. Llama-3.2-3B and Gemma-4-12B agree to three decimal places at every width tested — including on a model trained quantisation-aware for 4 bits.

Open tools

One runs in your browser. The rest run on a CPU, in seconds, with no GPU.

Each answers a question that is usually guessed at. They read model weights directly and require no forward pass, so a result cannot be contaminated by a broken engine.

Wave Observatory  —  runs in your browser

An interactive Kuramoto ring: 16 coupled oscillators with a live harmonic spectrum, mode-coupling products and the full coupling matrix G(p,q). Micro, macro and super scales, four lens profiles, and the 17th oscillator — a central repeller that fights the ring's urge to synchronise.

no install, no account, nothing leaves your machine
bitwidth_sweep.py

Reconstruction fidelity across ternary, int2, int4 and int8, with per-column and global scaling controls, measured against the original matrix.

per-column rescues int2 (0.50 vs 0.036) — neither is usable
gate_geometry.py

Treats the FFN as a hyperplane arrangement and measures how concentrated and how stable the active gate set is between consecutive tokens.

50% of channels for 90% of mass; 10–30% overlap
subspace_rank.py

Effective dimensionality of hidden activations, with the massive-activation channels removed — they distort any naive rank estimate by an order of magnitude.

effective rank 1.1 → 15.0 after removing 8 of 3072 channels
lloyd_max.py

Non-uniform quantiser levels placed on the observed weight density instead of spaced evenly, with the error reduction per bit width.

52% error reduction at 3 bits — worth a full extra bit
coupling_test.py

Compares amplitude, phasor and phase-only oscillator encodings against an exact matrix product on real weights.

amplitude exact; phase-only 0.975 rel-err — encoding matters
bqsm_full_settle.py

The whole forward pass as one equilibrium. Runs both a sequenced and an unsequenced solver and compares the logits they converge to.

identical logits, error 0.000e+00 at the critical path

Engineering

What the method produces when applied end to end.

Every operation in the forward pass has an equivalent wave form, and each was verified against its reference rather than assumed: RMSNorm is a saturable gain medium to an exact identity, softmax is parametric amplification with a shared power pool, RoPE is free-running oscillator phase.

The result that matters is structural. The forward pass is normally understood as 28 sequenced layers; it is equally a single fixed point, and two solvers sharing no structure — one sequenced, one fully unsequenced — converge to identical logits.

It is not faster. The wave form is an equivalence proof about the arithmetic, not a replacement for it, and the engine runs 2.1× slower than llama.cpp on the same machine. We publish that comparison rather than a flattering internal baseline.

ModelLlama-3.2-3B, 28 layers
Weightsint8 per-column, 2.82 GB
KernelsAVX2, in-register widening
Throughput1.43 tok/s
llama.cpp, same box3.02 tok/s
Token agreement5/5 exact vs reference
Arithmetic intensity1.78 FLOP/byte
Critical path227 of 311 blocks

Support the research

Independent measurement, funded independently.

The tools above are free and will stay free. Funding pays for compute, model access and the time to run experiments that may return nothing — which, as the findings table shows, is most of them. Every result is published either way.

Contributions fund research and are not tax-deductible — Emerging Systems is a commercial entity, not a registered charity. We would rather say so plainly than let anyone assume otherwise.