Distributed CPU: Zip Fusion Beyond Tensor Parallelism

A research design for treating a cluster of CPU nodes as one pool of compute that re-shapes per graph region: fused one-dimensional lanes that unzip into two-dimensional head-by-context attention at long context, then zip back. The metric is the unresolved span between global synchronization boundaries, priced by a quantitative token-budget and sizing model — and tested by a falsifiable validation ladder, not asserted.

Status: research design
Zip fusion is not implemented in the production runtime. All performance figures on this page are idealized arithmetic, not measurements, and experimental validation is pending. This HTML page is the canonical public design and visual reference; the engineering note DISTRIBUTED_CPU_ZIP_FUSION.md (in docs/notes/) is subordinate to it. Nothing here is a supported feature, a measured speedup, or a committed hardware-compatibility claim.

What it is

  • Whole-graph algebraic scheduling: per graph region, pick the representation that maximizes the independent local path before any global synchronization — including work usually treated as implementation detail (quantized unpack, scale decode, local accumulation, SwiGLU, RMSNorm partial statistics, output projection, expert routing, Memory-Tetris residency).
  • A cluster as one pool of compute that re-shapes per region: 1-D fused lanes for projections and MLP, a 2-D head-by-context decomposition for long-context attention, and back.
  • A measurement program whose deliverable is a topology-versus-context map and a published collective-time fraction — not a single tok/s number.

What it is not

  • Not a claim that CKE invented head or context parallelism. Megatron Core, DeepSpeed-Ulysses, Unified Sequence Parallelism, LoongTrain and ATTENTION2D all got there first; the prior-art section below says so plainly.
  • Not a promise that link bandwidth equals application throughput. The ~10 µs figure on this page is a division by nominal bandwidth, not a measurement.
  • Not implemented. No production code path distributes a model across nodes today; the experimental gates decide whether the idea earns promotion.

The Parallelism Taxonomy: Where Each Method Syncs

Every distributed method shards something different and pays for it at a different synchronization boundary. The honest distinctions that matter for CKE:

Six-row comparison of data, tensor, pipeline, context, expert and head parallelism showing what each shards, where it synchronizes, and whether all nodes work on the same request at once. Data parallelism and pipeline parallelism do not aggregate single-request compute; tensor, context, expert and head parallelism do. Tensor parallelism pairs column-parallel with row-parallel linears and pays roughly two collectives per layer; head parallelism is fully head-independent and needs only the output-projection reduction, with the online-softmax statistic merge appearing only when context is also sharded

TP, head and context parallelism are the interesting family for latency: they can make every CPU in the cluster work on the same request at the same time. Zip fusion composes them as one scheduling problem instead of three separate flags.

Prior Art, Candidly

CKE did not invent head-shard or context-shard attention, and this page does not claim otherwise:

The distinctive claim is deliberately narrower: whole-graph algebraic scheduling on CPU-first economics. Rather than exposing named strategies, the scheduler asks, per graph region: what representation lets N CPU nodes execute the longest independent local path before any global synchronization? The unit of distribution is the whole quantized operator subgraph — including packed-weight unpack, scale decode, quantized dot products, local accumulation, SwiGLU, RMSNorm partial statistics, attention-head work, output projection, expert routing and Memory-Tetris residency — not just GEMM or attention. Whether that combination is worth anything is an experimental question, not a marketing one.

What Exactly Is Being Sharded? The Block as a Zipper

Before budgets and topologies, the object itself: a transformer block drawn as a zipper. The hidden state enters replicated on every node (CPU DRAM is plentiful — replication is cheap, communication is not). Each node then runs a vertical local lane — quantized unpack, local QKV GEMM, head-local work (RoPE, QK-norm, attention over its heads), and its own output-projection partial — with zero data movement between lanes. The zipper closes only where the algebra forces it: the output-projection partials must sum into one hidden-state vector. It immediately unzips again for the MLP region and closes once more at the down-projection partials.

A transformer block drawn as a zipper across four node lanes: three Ryzen lanes and one Xeon lane. A replicated hidden state feeds all four. In the attention region each lane runs quantized unpack, a local QKV GEMM shard, head-local RoPE, QK-norm and attention, and its own output-projection partial, with open zipper teeth between lanes meaning zero data movement. The zipper closes at reduce one, summing the four partials into one hidden-state vector — sixteen kilobytes per token at 8192-dimensional BF16, labeled as a model. The MLP region unzips again over the reduced hidden state: unpack gate and up shards, local GEMM plus SwiGLU, down-projection partials. The zipper closes a second time into the replicated next-layer input. A legend distinguishes replicated, sharded and partial-sum tensor states. All sizes are theoretical model labels, not measurements

Three tensor states appear, and the scheduler treats them differently: replicated (same bytes on every node — hidden state, norm parameters, routing metadata), sharded (disjoint slices — weight columns, heads, context), and partial-sum (values that are mathematically incomplete until reduced — projection partials, norm statistics). The zip schedule is the discipline of keeping tensors in the sharded state for as long as the algebra allows, and letting the partial-sum state exist only at true dependency boundaries.

The Zip Schedule

The centerpiece. Most of a transformer layer does not need a 2-D decomposition at all: each node can run a fused 1-D lane — unpack its local packed-weight shard, run its QKV shard, its local heads, its local output-projection partial, its local reduction. Crucially, heads are never concatenated into one giant intermediate tensor: each node applies its local output-projection shard to its own attention output, so the first communication boundary is already hidden-state-sized, not attention-sized.

For attention at long context, the decomposition unzips into 2-D — head groups on one axis, context shards on the other — because head count alone eventually stops exposing enough parallelism while the sequence keeps growing. After attention, the schedule zips back to the 1-D lane for the MLP. The cluster is one pool of compute that re-shapes per graph region.

Two-node lane diagram. A replicated hidden state feeds Node A and Node B, each running a fused one-dimensional lane: unpack weight shard, QKV shard, local heads with RoPE and QK norm. The attention region unzips into a two-dimensional head-groups-times-context-shards decomposition computing local attention tiles, merged by online-softmax sufficient statistics: local max, local normalization sum, local weighted output. Each node then applies its local output-projection shard and the first merge sums hidden-state partials: sixteen kilobytes per token at 8192-dimensional BF16, about 512 kilobytes for a 32-token batch. The schedule zips back into the one-dimensional MLP lane, gate and up shards through local SwiGLU to down-projection partials, ending in one final merge. Raw attention matrices never move

Communication boundaries carry only the mathematically unavoidable reductions:

GQA note. Modern Qwen-like models use grouped-query attention — conceptually 32 query heads against 8 KV heads rather than 32 independent Q/K/V sets. Head sharding must partition query-head groups so the needed KV heads are local or cheaply replicated. Because CPU RAM is plentiful, replicating K/V-head metadata or even some KV data can be preferable to forcing communication — the abundance-of-memory thesis again.

What Must Cross the Fabric: The Reduction Algebra

The synchronization payload is not an implementation choice — it is fixed by the algebra. Split a weight matrix column-wise across \(N\) nodes, \(W = [W_1, W_2, \dots, W_N]\). Each node computes its local product and everything that depends only on it:

\[ Y_i = X\,W_i, \qquad H_i = f(Y_i) \]

where \(f\) covers arbitrarily much local work — head-local attention, SwiGLU, quantized unpack and scale decode. No bytes cross the fabric for any of it. Only when the graph needs the output projection does anything meet:

\[ Z = \sum_i H_i\,V_i \qquad \text{REDUCE: one hidden-size vector} \]

RMSNorm looks like a global dependency, and it is — but the dependency reduces to a scalar. Each shard accumulates its local sum of squares, and only those scalars ever meet:

\[ s_i = \sum_{j \in shard_i} x_j^2, \qquad s = \sum_i s_i \qquad \text{REDUCE: one scalar} \]
Two panels. Panel A: a weight matrix split column-wise across N nodes; each node computes a local product Y_i equals X times W_i, then a local nonlinear function H_i equals f of Y_i, and only the final output projection requires a sum Z equals the sum over i of H_i times V_i — labeled reduce: one hidden-size vector, sixteen kilobytes per token at 8192-dimensional BF16 as a model label. Panel B: RMSNorm as the scalar example; each shard accumulates a local sum of squares s_i and the global statistic s is the sum of the s_i — labeled reduce: one scalar. A takeaway states that a global mathematical dependency does not imply gathering the full tensor

This is the honest foundation of the zip schedule: a global mathematical dependency does not imply gathering the full tensor. The reduction above is also exactly where CKE's zero-tolerance numerical contracts bite — the distributed sum must be specified with the same reduction-order discipline as every other kernel contract, or parity fails. Distribution changes where the tiles run, never the arithmetic.

Two-Dimensional Attention at Long Context

Head parallelism exhausts itself: with 32 heads, 32 nodes means one head per node, and the head axis is spent. At 128K–1M context the sequence is the next parallel axis. A 6-node cluster can decompose as 3 context shards × 2 head groups, each node computing large local attention tiles over 1/3 of the context and 1/2 of the heads, then merging across context partitions with online-softmax sufficient statistics.

A six-node grid: two head-group columns and three context-shard rows, each node owning half the heads and a third of a one-million-token context and computing local attention tiles independently. Per head-group column, context partitions merge with online-softmax sufficient statistics: local max, local normalization sum, local weighted output. A struck-through panel contrasts this with moving the full one-million by one-million attention matrix, and notes that grouped-query attention requires partitioning query-head groups so needed KV heads are local or replicated

Two honesty constraints at 1M context. First, not every layer needs this: models mix recurrent or local-attention layers (bounded state, no full-context dependency) with global-attention layers, and the mix must be read from the exact model config — never hard-coded into the scheduler. Second, the cross-context merge is exact, not approximate: online softmax rescales each shard's partial statistics before summing, the same algebra a single-node flash-attention kernel uses internally.

Panel A: the layer mix is model-config-dependent — recurrent or local-attention layers carry bounded state and schedule like any other region, while global-attention layers see the full context and need the two-dimensional decomposition; the ratio comes from the exact model config. Panel B: a global-attention layer decomposes as head groups times context shards. Each node holds the KV slice for its context shard, computes a local attention tile for its head group, and exports only online-softmax sufficient statistics: local max m_i, local normalizer l_i, local weighted output o_i. A merge per head rescales by the exponential of m_i minus the global max and sums the partials into the exact global result. A struck-through panel notes the L-times-L attention matrix is never materialized and KV never leaves its owning node. The merge is the same algebra a single-node flash-attention kernel uses, so distribution does not change the numerical contract

Decode at 1M is not prefill at 1M

The grid above is shared, but the two phases pay radically different communication over it. At decode there is one new query, \(Q: 1 \times d\), against \(K, V: L \times d\) — each context shard returns the sufficient statistics for that single query per head (a scalar max, a scalar normalizer, one \(d_{\text{head}}\) vector): bytes-to-KB per head per shard, independent of \(L\). This is where the long-context communication thesis is strongest. At prefill, \(T\) queries run simultaneously, so the sufficient statistics themselves carry the query dimension — the merge payload scales with \(T\) and must be tiled or streamed, priced like a GEMM-shaped region rather than a decode-shaped one. Same exact algebra; different payload shape. Any 1M-context claim on this page that does not name its phase is incomplete.

Two panels over the same head-groups-times-context-shards grid. Decode: one new query, Q is 1 by d, against K and V of L by d — each context shard returns the online-softmax sufficient statistics for that single query per head, a payload of bytes to kilobytes per head per shard, independent of L. Prefill: T simultaneous queries, Q is T by d — the sufficient statistics carry the query dimension, so the merge payload scales with T and must be tiled or streamed, budgeted like a GEMM-shaped region, not a decode-shaped one. A footer notes both merges are the same exact online-softmax algebra; distribution changes the payload shape, never the numerical contract

The Metric: Synchronization Boundaries per Layer

“We support TP=2” says nothing about how often nodes stop to agree. The useful metric is global synchronization boundaries per layer — and the honest baseline is stronger than a strawman: established TP schedules already pair column-parallel with row-parallel linears, so a conventional layer pays roughly two collectives, not one per operator. The real contrast is not the nominal count but the unresolved span: paired TP keeps activations sharded between its two boundaries, while the zip schedule pushes the whole operator subgraph — quantized unpack, scale decode, local accumulation, RoPE / QK norm, SwiGLU, norm statistics, projection partials — into the shard layout. The experimental question is whether Shard → Shard → Shard → PartialSum can stay unresolved for longer portions of the graph than existing schedules allow.

Top flow: an established tensor-parallel layer pairs column-parallel and row-parallel linears — column-parallel QKV projection with no collective, head-local attention, row-parallel output projection, one collective, column-parallel MLP gate and up, SwiGLU, row-parallel MLP down, one collective — roughly two collectives per layer. Bottom flow: a whole-subgraph zip schedule runs one fused lane from unpack through the output-projection partial, one hidden-state merge, the fused MLP lane, and one final merge — one merge per fused region. The takeaway panel states the claim is the unresolved span, not the count: whether Shard to Shard to Shard to PartialSum can stay unresolved longer than existing schedules allow

The Token Budget: A 20 ms Worked Example (MODEL)

The figures so far say what moves; this section prices it. Take a 50 tok/s decode target — 20 ms per token — and a parameterized example model: 93 layers, hidden dimension 8192 in BF16. These are THEORETICAL model labels with no real-model attribution; the point is to show the arithmetic a planner would run, not to benchmark anything.

The per-layer budget is a division:

\[ \frac{20\ \text{ms}}{93\ \text{layers}} \approx 215\ \mu\text{s / layer} \]

Against that budget, the synchronization payload is tiny. A hidden-state reduction at 8192 dimensions in BF16 is 16 KB; at two such reductions per layer (attention out-projection, MLP down-projection) the whole token pays:

\[ 93 \times 2 \times 16\ \text{KB} \approx 3\ \text{MB / token} \quad \text{(before collective-algorithm overhead)} \]

Meanwhile each node must stream its weight shard from DRAM inside the same 215 µs. The first-class variable is fresh bytes — the bytes DRAM must actually deliver, after cache reuse:

\[ B_{\text{fresh}} = B_{\text{required}} - B_{\text{cache hits / reuse}} \]

This is why a large-cache node can outperform what its nominal two-channel DRAM bandwidth suggests on some regions: the planner cares about \(B_{\text{fresh}}\), not total weight bytes. At a sustained stream bandwidth \(B_i\), the fresh bytes a node can absorb per layer are:

\[ B_{\text{fresh}}\ \text{/ layer} = B_i \times 215\ \mu\text{s} \qquad \text{e.g. } 80\ \text{GB/s} \times 215\ \mu\text{s} \approx 17.2\ \text{MB} \]

That is the sense in which cache is a staging mechanism, not a model residence: the current tile is cache-resident while DRAM streams the next one, and AVX/AMX compute consumes the current one — compute current tile in parallel with fetch next tile. A 100 tok/s variant simply halves every budget — which doubles the sync share of wall time, making the same model a stress test of the communication path.

The latency arithmetic: why 3 MB is not the story

The 3 MB/token payload sounds trivially cheap — and on bandwidth it is. The danger is latency, paid serially. The reductions do not overlap each other; each layer's boundary waits for its collective, so per-token synchronization cost is:

\[ T_{\text{collective / token}} = 186 \times L_{\text{collective}} \]

At \(L = 10\,\mu s\) that is 1.86 ms — 9.3% of the 20 ms budget gone to waiting, before any collective-algorithm overhead. At a 100 tok/s target the same 10 µs collective costs 18.6%. The whole distributed-CPU thesis therefore reduces to one measurable question: can CKE get its real small-vector reduction into the latency regime the target token budget requires? The ruler below makes the budget, the serial ticks and the latency table one picture.

A horizontal 20-millisecond token ruler for a 50 tokens-per-second target: layer slots of local work separated by thin reduction ticks, 93 layers times 2 reductions equals 186 reductions per token, so collective time per token is 186 times the per-reduction latency. A table converts latency into sequential cost and budget share: 2 microseconds costs 0.372 milliseconds or 1.9 percent, 5 microseconds 0.93 ms or 4.7 percent, 10 microseconds 1.86 ms or 9.3 percent, 20 microseconds 3.72 ms or 18.6 percent, 50 microseconds 9.3 ms or 46.5 percent. At a 100 tokens-per-second target every share doubles. The experimental gate: can CKE get its real small-vector reduction into the latency regime the target token budget requires — measured latency answers this, not the link sheet. All figures are theoretical model arithmetic
A model timeline for a 50 tokens-per-second target, 20 milliseconds per token, in three regions. In each region Ryzen A and Ryzen B lanes carry smaller shards and a Xeon lane carries a larger shard, all ending at the same reduction boundary: regions one and three close on a 16-kilobyte hidden-vector reduction, region two on a scalar norm reduction, each sync labeled approximately x microseconds, unmeasured. A lower band shows the current tile cache-resident while DRAM streams the next tile at B_i gigabytes per second and AVX or AMX compute consumes the current tile — streaming, not fitting the model in cache. A side panel lists the worked theoretical numbers: 93 layers at about 215 microseconds per layer, 186 reductions of 16 kilobytes totaling about 3 megabytes per token before collective overhead, and about 17.2 megabytes streamed per layer at 80 gigabytes per second. The takeaway: useful local work is much greater than bytes synchronized — the ratio is the thesis, measurement decides

Decode vs Prefill: Same Weights, Different Bottlenecks

One model, two operating points. Decode multiplies a one-token vector by the weight matrix: every packed weight byte is read once and used once, and the region is bandwidth dominated. The arithmetic intensity is set by the format, not a universal constant — the honest expression is:

\[ AI_{\text{decode}} \approx \frac{2 \times P_{\text{active}}}{B_{\text{packed weights}}} \]

FP32 gives 0.5 FLOP/byte, BF16 gives 1, and ideal packed 4-bit weights give \(\approx 4\) FLOP/byte before scale/block metadata, unpack overhead and activation traffic — e.g. a 100B-parameter model at \(\approx\)50 GB packed streams 200 GFLOP against 50 GB, \(\approx 4\) FLOP/byte. CKE computes this from the actual format rather than assuming one. Prefill multiplies a token matrix by the same weights: each byte is reused across \(T\) tokens, arithmetic intensity grows with \(T\), and the region is GEMM/compute dominated. Node capability is therefore phase-dependent:

\[ P_i^{\text{decode}} \approx \text{packed-weight stream bandwidth}, \qquad P_i^{\text{prefill}} \approx \text{measured GEMM throughput} \]

“Packed-weight stream bandwidth” means whatever quant format the target model ships in (an MXFP4-class format for the model class this research targets) — it is a property of the model artifact and the node's memory system, not a CKE capability claim. The planner consequence: a bandwidth-strong node and a compute-strong node deserve different shard fractions per phase, and the best prefill topology may differ from the best decode topology on the same hardware.

Two panels. Decode: a one-token vector times the weight shard, every packed weight byte read once and used once, arithmetic intensity set by the format — about one FLOP per byte for BF16 and four for ideal four-bit packing, for example 200 gigaFLOPs against 50 gigabytes — bottleneck memory bandwidth; node capability for decode is approximately packed-weight stream bandwidth in the model's quant format. Prefill: a token matrix times the same weight shard, each byte reused across T tokens, arithmetic intensity growing with T, bottleneck GEMM and compute throughput — node capability for prefill is approximately measured GEMM throughput, ISA-dependent across AVX2, AVX-512 and AMX node classes. A consequence band states the planner may assign different shard fractions per phase, and the best prefill topology may differ from the best decode topology

Prefill First, Then One Matrix-Work Scheduler

Prefill is the cleanest place to prove CKE's deterministic scaling story first. A prefill region multiplies a token matrix by the weight matrix, \(X_{B \times d}\,W_{d \times k}\), so the same weight tile is reused across \(B\) token rows and arithmetic intensity rises with \(B\). When the region is genuinely dense — compute time exceeds streaming time:

\[ \frac{F_r}{P} > \frac{B_{\text{fresh},r}}{BW} \quad\Longrightarrow\quad T_r \approx \frac{F_r}{P_{\text{cluster}}} + T_{\text{sync}} \]

— the first objective becomes simple to state: maximize sustained useful GEMM throughput across the cluster, and check whether adding a node adds its measured compute minus a small, visible synchronization term. No bandwidth cliff, no cache phenomenology — those enter later, on their own measured terms.

Decode then stops being a separate architecture. Batch-1 decode multiplies one token row by the weights, but continuous batching packs every runnable sequence into the same product:

\[ X = \begin{bmatrix} x_1 \\ x_2 \\ \vdots \\ x_B \end{bmatrix}, \qquad XW \]

As \(B\) grows, the workload slides along a continuum — GEMV-like, small GEMM, large GEMM — and CKE needs one matrix-work scheduler, not a “prefill runtime” and a “decode runtime”. The scheduler's question is always the same: how many compatible activation rows are ready for this weight region, and which tiling and sharding gives the shortest critical path — continuously packing available token work toward dense GEMM while respecting per-user latency constraints.

A schematic plot with runnable token rows B on a logarithmic axis from 1 to 128 and useful throughput on the vertical axis. The single-node curve sits flat in the bandwidth regime at B equals 1 to 4 where every weight byte is read once, steepens through a transition around B equals 16 to 32 where reuse begins to pay, and flattens into the compute plateau, the dense-GEMM regime, near B equals 64 to 128. The saturation point marks enough rows to feed the cores. A dashed curve above sketches the two-node plateau as approximately P1 plus P2 minus synchronization, explicitly labeled a hypothesis. The footer states the experiment: the first Ryzen sweep of B equals 1 through 128 measures effective gigaFLOPs per second, gigabytes per second and CKU, replacing the schematic with the real transition point, then repeats distributed on two nodes. The shape is a schematic model to be measured, not data

The transition point on that curve is an experimental deliverable, not an assumption: MXFP4-class unpacking, scaling, tile shapes, ISA utilization and cache behavior decide where a real node stops being bandwidth-bound. The first Ryzen experiment sweeps \(B = 1, 2, 4, \ldots, 128\) and measures effective GFLOP/s, effective GB/s and CKU per point; the two-node repeat should show the plateau move to approximately \(P_1 + P_2\) minus synchronization if the scheduler is honest.

KV and recurrent state stay special — but as regions, not as an architecture. Even when batching makes the dense projections GEMM-like, every sequence carries independent state, \(KV_1, KV_2, \ldots, KV_B\), so attention has a different data-access structure from the projections. CKE treats it as another region in the same schedule — dense projection, local attention/KV work, small reduction if required — and lets X-Ray report which regions ran below peak and why. Models with recurrent or linear-attention layers may shrink the long-context KV burden; that is a per-model measurement, never a CKE core assumption. The overall objective stays singular: keep as much of the execution graph in the dense-GEMM regime as possible, and optimize the whole architecture around that rather than around the worst batch-1 decode case.

Communication Must Be Measured

The fast-switch intuition, stated honestly: 512 KB at a nominal 400 Gb/s (≈ 50 GB/s) link serializes in about 10 µs — and that figure is a division, not a measurement. Real end-to-end synchronization adds RDMA/collective latency, software overhead, PCIe traversal, memory access and barrier cost. None of that is in the division.

The thesis stands on the ratio, not the absolute number: if each node performs milliseconds of useful attention/GEMM work between boundaries, hundreds of kilobytes of communication is not scary — and at 1M context the compute/communication ratio can become particularly favorable. But this is a research hypothesis. It must be demonstrated on the real NICs and switch, not assumed from a link sheet, and the measurement plan below publishes the collective-time fraction whatever it turns out to be.

A timeline with a long bar of millisecond-scale local attention and GEMM work between boundaries and a sliver for the 512-kilobyte boundary payload. One panel shows the idealized arithmetic: 400 gigabits per second is about 50 gigabytes per second, 512 kilobytes divided by 50 gigabytes per second is about 10 microseconds, labeled a division not a measurement. A second panel lists what a real sync adds: RDMA and collective latency, software overhead, PCIe traversal, memory access, barrier and straggler cost. A hypothesis band states that a fused schedule might cut collective time from about 25 percent of wall time to 5 to 10 percent, both figures marked as hypotheses to test

The synchronization root is also a constraint

One appealing small-cluster shape is a star: Ryzen leaf nodes with direct high-speed links to a PCIe-rich Xeon hub, which hosts the reduction. The appeal is determinism — CKE knows exactly which link each rank uses, its measured latency and bandwidth, where the reduction happens and how long broadcast takes, with no external switch fabric whose congestion must be modeled. And the hub is asked to combine partial results, not model tensors: leaves keep weights local (\(B_{\text{local weights}} \gg B_{\text{sync}}\)), send their partials, and the hub computes \(z = \sum_i z_i\) and broadcasts \(z\).

But the star just moves the constraint — it never deletes it. The hub's PCIe bandwidth, NIC DMA capability, memory system, reduction compute and per-message processing bound \(T_{\text{star}}(N)\); what is perfectly reasonable at 4 leaves may fail at 32. The planner must therefore treat topology itself as a variable — star, hierarchical tree of hubs, or peer-to-peer reduction — and say, at a measured node count, “the hub is now the active constraint; change topology.” This is the constraint model applied to the fabric: every topology has a slowest active boundary, including the one CKE just created on purpose.

Streaming reductions: keep the pipeline moving

Reductions are associative, so the hub need not wait for every partial before doing anything: reduce-as-arrive (\(z^{(1)} = z_1 + z_2\), then \(z^{(2)} = z^{(1)} + z_3\), …) overlaps network reception with reduction compute, and sufficiently segmented results can begin broadcast as soon as portions resolve. “Receive everything → reduce everything → send everything” becomes a streaming reduction — the flowing-pipeline discipline of the constraint model applied to the collective itself. One hard boundary remains: reduction order is part of the numerical contract, so any streaming order must be fixed, declared and certified — never an opportunistic arrival-order sum.

CPU-First Economics: Spend DRAM to Eliminate Communication

GPU frameworks shard because HBM is scarce — state often cannot be replicated. CPU nodes can carry 150 GB, 256 GB, 512 GB or eventually terabytes of DRAM, which inverts the optimization objective: CKE can deliberately spend memory to eliminate communication:

Memory Tetris adds the dimension the mainstream parallelism literature usually does not center: tensor residency itself is part of scheduling. Per tensor, the planner could choose to compute from a resident tensor, fetch from remote DRAM over RDMA, fetch from local or remote NVMe, recompute, replicate for future reuse, or route the activation to a remote resident expert. See Memory Tetris: DRAM as a Tensor Cache over NVMe for the residency design — itself a research design at the same status as this page.

Heterogeneous Topology

Megatron-style systems generally assume fairly regular accelerator groups. The CKE lab fleet is explicitly heterogeneous — an Intel i7-14700T node (active), a Ryzen 9950X3D node (planned) and Xeon AMX hardware (future) — so equal ranks are the wrong default. Shards should be proportional to X-Ray-measured throughput: Node A might take 30% of a tensor shard and Node B 70%, because X-Ray measured them that way. The target is distributed graph compilation over heterogeneous CPU resources. See Support Hardware for the lab fleet.

X-Ray per-node throughput measurement feeds the CKE scheduler, which assigns a thirty-percent shard lane to an Intel i7-14700T node marked active and a seventy-percent shard lane to a Ryzen 9950X3D node marked planned. A panel lists Memory-Tetris residency choices per tensor: compute from resident local DRAM, fetch from remote DRAM over RDMA, fetch from local or remote NVMe, recompute, replicate for future reuse, or route the activation to a remote resident expert. A second panel records the fabric assumption of 200 or 400 gigabit RDMA-class links to be validated, and the fleet status: i7-14700T active, Ryzen 9950X3D planned, Xeon AMX future

The sizing model (OPTIMISTIC LOWER BOUND)

Heterogeneous sharding needs a quantitative rule, not a vibe. Let \(P_i\) be node \(i\)'s X-Ray-measured CKE throughput for the relevant region — and note that \(P_i\) is really \(P_i(r, \text{phase}, \text{dtype})\): stream bandwidth for decode-shaped regions, GEMM throughput for prefill-shaped regions, something like \(f(BW_{\text{KV}}, F_{\text{attention}})\) for long-context attention — never nominal FLOPS, and not one constant per node. The same Xeon/Ryzen ratio does not apply everywhere, which is exactly where this differs from a static --tensor-split 0.2,0.2,0.6: the shard size is operator- and phase-dependent. The fractions follow directly:

\[ s_i(r) = \frac{P_i(r)}{\sum_j P_j(r)} \]

Region time is bounded below by whichever resource saturates first — on fresh bytes, not total weight bytes — plus the synchronization the algebra forces, which is a measured, node-count-dependent term \(C_r(N)\):

\[ T_r = \max\!\left( \frac{B_{\text{fresh},r}}{\sum_i BW_{i,r}},\ \frac{F_r}{\sum_i F_{i,r}} \right) + C_r(N) \]

Elevated to the headline equation — the whole distributed-CPU hypothesis in one line:

\[ \boxed{\; T_{\text{token}} = \sum_r \left[ \max\!\left( \frac{B_{\text{fresh},r}}{\sum_i BW_{i,r}},\ \frac{F_r}{\sum_i F_{i,r}} \right) + C_r(N) \right] \;} \] \[ \text{tok/s} = \frac{1000}{T_{\text{token}}\ \text{(ms)}} \]

where \(B_{\text{fresh},r}\) and \(F_r\) are the region's fresh bytes and FLOPs. Two labels apply to every use of these equations on this page: OPTIMISTIC LOWER BOUND — measured time will be predicted, because the max() ignores overlap penalties, stragglers, collective algorithms and software overhead; and THEORETICAL — the model exists to be validated or falsified by the ladder below, not to advertise a number.

On heterogeneous nodes the region finishes at the slowest lane's time, not the fastest: lanes measuring 180, 182, 179 and 95 µs produce a ≈182 µs region, with the fast node wasting 87 µs at the barrier. Shard assignment is therefore the critical-path minimization:

\[ \underset{s_1,\dots,s_N}{\arg\min}\ \left[ \max_i T_i(s_i)\ +\ T_{\text{sync}}(N, B) \right] \quad \text{subject to } \sum_i s_i = 1 \]

Rebalance until the lanes tie — 180, 181, 179, 180 — and \(\max_i T_i\) is minimized. This equation is the distributed instance of the CKE Constraint Model, which defines the shared per-resource clocks and the exposed-versus-hidden vocabulary this page uses throughout.

The Topology-versus-Context Thesis

For a tiny decode prompt there is not enough arithmetic between synchronization points to justify distributing aggressively. As context grows — 32K, 128K, 500K, 1M — the attention work becomes enormous and the optimal topology plausibly changes: one node for small context, TP=2 for medium, head-parallel plus TP for long, and head-by-context 2-D for very long. The interesting output of this research is the measured map of which topology wins at which context — not a single tok/s figure.

A stepped map along the context-length axis. Small context: one CPU node, because there is not enough arithmetic between synchronization points to justify distributing. Medium context around 32K: tensor-parallel 2 with two fused lanes and hidden-state merges. Long context around 128K: head-parallel plus tensor parallelism, heads split across nodes with softmax-statistic and output reductions. Very long context, 128K to one million tokens: a six-node two-dimensional grid of three context shards times two head groups with online-softmax merging, where the compute-to-communication ratio is most favorable. A footer states the zone boundaries are hypotheses to be mapped experimentally

Experimental Plan and Promotion Gates

Same rigor as Memory Tetris: ordered experiments, each with a promotion gate, every result cell not yet certified until measured and recorded to CKE's evidence standard.

Experiment What it measures Result Status
Single-node baseline fully resident model; per-region kernel times Not yet certified
Two-node TP reference conventional TP=2; percentage of wall time in collectives Not yet certified
Hyper-fused schedule boundaries per layer; total sync time; collective-time fraction Not yet certified
Head × context 2-D 6-node 3×2 grid with online-softmax merging at long context Not yet certified
Token-row sweep B = 1…128 batch continuum; effective GFLOP/s, GB/s and CKU per point; locates the bandwidth-to-compute transition; repeated on two nodes Not yet certified
Numerical parity distributed schedule vs single-node baseline under the zero-tolerance numerical contract rules; layer/checkpoint outputs, not just tokens Not yet certified
Topology-vs-context map winning topology per context length, published as a map Not yet certified

The hypothesis to test — not a result

If two nodes running a conventional TP implementation spend, say, ~25% of wall time in collectives, a hyper-fused schedule might cut that to ~5–10%. Both numbers are hypotheses the experiments are designed to confirm or refute, and the collective-time fraction gets published either way.

The validation ladder: prediction first, measurement second

The experiments above order the work; the ladder orders the fleet. Each rung adds compute the sizing model claims it can price, and each rung publishes the same evidence pack: predicted vs measured region time, predicted vs measured tok/s, collective-time fraction, scaling efficiency, effective stream bandwidth and prefill GEMM throughput, watts, and hardware cost per added tok/s. The fraction is published whatever it turns out to be — no cherry-picking.

Left: a four-rung ladder — one node baseline for calibration, two identical nodes as the purest scaling test, a heterogeneous pair testing whether shards weighted by measured throughput equalize lane time, and a larger fleet to find the ceiling where synchronization stops scaling paying. Each rung publishes predicted and measured region time and tokens per second, collective-time fraction, scaling efficiency, effective stream bandwidth and prefill GEMM throughput, watts and hardware cost. Right: an empty plot of decode tokens per second against aggregate calibrated capability with a dashed ideal-linear reference line and a large watermark reading no data yet — placeholder. A falsifiability band gives hypothetical example numbers: doubling nodes moving decode from 0.20 to 0.38 tokens per second supports the model, while 0.20 to 0.21 falsifies an assumption and the measured breakdown shows which one

The headline question — sharper than “CPU vs GPU”

Can transformer latency scale approximately with aggregate calibrated CPU capability until synchronization becomes the ceiling?

This is deliberately falsifiable. If one node decodes at 0.20 tok/s (hypothetical example number) and two deliver 0.38, the sizing model is supported. If two deliver 0.21, an assumption is falsified — and the per-region breakdown shows exactly which one: the bandwidth term, the GEMM term, or the sync term. Either outcome is a publishable result, because the research claim is not “CPU is faster than GPU” but CKE can predict how much useful transformer throughput each added node, memory channel, cache hierarchy or ISA capability contributes to the compute fabric.

Failure modes to measure

Related Pages

Image
100% | |
Scroll to zoom | Drag to pan | W/H to fit | 0 to reset | ESC to close