Today I want to write about the small CPU lab I have been building for C-Kernel-Engine (CKE). If you are new to the project, this introduction explains why CKE turns transformer circuits into generated C. The short version is that I want modern language, vision, and audio models to be easier to inspect, run, and eventually train on ordinary Linux CPU systems.

For a long time, most CKE work happened on whatever CPU I could reach: my laptop, a small Lenovo server, GitHub's hosted runners, and a 5th-generation Xeon environment at work. That was enough to build kernels, compare outputs with PyTorch and llama.cpp, and find many performance problems. It was not enough to build a repeatable cross-vendor laboratory or to start serious physical distributed-computing work.

That changed this month. The AMD node is assembled, Linux is running, the processor and storage have been verified on the machine, and it is reachable through the same private network as the Intel P3. The lab is still small and the first network link is only 1 Gb/s. That is fine. I now have the two physical failure domains needed to stop drawing distributed diagrams and start measuring where the design breaks.

What I Have Actually Spent

The current receipt-backed total is CAD $9,575.16. This is founder-funded money, not sponsorship, money raised, or the estimated value of old equipment. It includes six dated purchases currently recorded in the CKE hardware ledger.

This is also a strange time to build the lab. Memory and NAND prices are inflated, and my bet is that meaningful relief may not arrive quickly. That is my purchasing judgment, not a market forecast. I can wait and postpone the distributed CPU work, or accept today's price and keep moving CKE forward. I chose to keep moving, while recording the actual cost so nobody mistakes this for a cheap reference build.

Across the three active development machines, I now own 248 GB of memory: 24 GB in the T14, 64 GB in the P3, and 160 GB allocated to the Ryzen through separate 64 GB and 96 GB kits. The Ryzen's 64 GB configuration is the currently validated baseline; the mixed 160 GB configuration must be installed, trained, and tested before I attach benchmark claims to it. The old ThinkPad W530 is available but excluded from the dollar total because I do not have a verified original receipt. Electricity, my time, and future Xeon systems are also excluded.

Why These Machines Are Different On Purpose

The ThinkPad T14 remains my daily Linux machine. I write, inspect code, run smaller AVX2 tests, control the servers, and turn the resulting work into documentation and articles from it. It is also a useful reminder that CKE cannot assume a server-class CPU or unlimited memory.

The Lenovo P3 Tiny is the stable Intel execution node. Its Core i7-14700T exposes AVX2, FMA, and AVX-VNNI, but not AVX-512. It now has 64 GB of DDR5 and a separate 2 TB artifact drive. This is where CKE can run unattended tests, compare thread placement across performance and efficiency cores, and use Intel VTune, Advisor captures already in the evidence archive, and Linux perf to study the complete generated runtime.

The new Ryzen 9 9950X3D system is not merely a faster desktop. On-node inspection confirms 16 cores, 32 threads, full Zen 5 AVX-512 flags, BF16, VNNI, and 128 MB of L3 cache. It currently has 64 GB of DDR5, a 4 TB Samsung 990 PRO, and a 12 TB WD Red drive. Linux perf and AMD uProf give it an independent profiler path. This node lets CKE ask whether a provider selected for AVX-512 is actually faster, whether it stays numerically consistent with AVX2, and how the large cache changes decode, attention, and quantized kernels.

The ThinkPad W530 is useful because old hardware is inconvenient. It can expose accidental ISA assumptions, compiler regressions, scalar fallbacks, and setup requirements that disappear on a new workstation. CKE should not claim broad CPU portability if its generated C only survives on the newest machine in the room.

The First Experiments Are Quite Practical

I do not need a 400 Gb/s network before I can learn anything. The current machines already create a useful sequence of experiments:

1. Record each machine exactly. CPU model, microcode, ISA flags, memory capacity, storage, kernel, compiler, CKE commit, thermals, and thread topology become part of every result. I wrote earlier about why even a green nightly check must name the machine that produced it.
2. Run the same CKE circuit on Intel and AMD. The model, quantization, prompt, generated IR, compiler flags, and output comparison stay fixed. The ISA and provider path change.
3. Measure AVX2 against AVX-512 instead of assuming width wins. Wider vectors can expose downclocking, tail handling, cache pressure, conversion costs, or a kernel shape that simply does not feed the machine well.
4. Find the batch transition. CKE will sweep runnable token rows from small decode-like shapes toward dense prefill shapes and record where each node moves from a bandwidth-bound regime toward useful compute reuse.
5. Compare numerical drift across providers. X-Ray can stop at the first tensor where Intel AVX2, AMD AVX-512, PyTorch, or llama.cpp disagree. That connects the hardware experiment to the numerical-parity work already inside CKE.
6. Run one model across two physical nodes. Start with a deliberately poor 1 Gb/s link, measure serialization and synchronization, then change partitioning and overlap. Faster networking should be purchased only after traces show which payloads deserve it.
7. Test storage as an explicit tier. The 2 TB and 4 TB NVMe drives plus the 12 TB HDD let the lab retain models, converted weights, X-Ray tensors, benchmark corpora, and profiler captures. Later, CKE can test its Memory Tetris idea: keeping a deliberate working set in DRAM while treating storage as a slower, scheduled tensor tier. SSD is not RAM, and the experiment must measure the exposed transfer.

What CKU Means For This Lab

CKE now has a systems metric called the C-Kernel Throughput Unit, or CKU. It measures useful model-path bytes advanced per second. It is not a claim that copying memory is AI work, and it does not replace tokens per second, latency, FLOPS, parity, or power.

potential CKU = sum of the useful isolated node rates
realized CKU  = useful model path advanced / distributed wall time
efficiency    = realized CKU / potential CKU

The new hardware makes this measurable. First, CKE can establish an isolated CKU for the P3 and the Ryzen under the same declared workload. Then it can split a circuit, include serialization and communication in the wall clock, and report the realized result. If the two-node system achieves little more than the faster node alone, the network, partition, synchronization, or load balance is wrong. The number is valuable precisely when it makes a disappointing result visible.

The long-range CKU goal is aggressive: understand how a family of CPU nodes could collectively move very large active model states at a practical rate. The first honest step is much smaller: two machines, one direct experiment, one measured efficiency, and X-Ray evidence explaining where time went.

What This Opens Up For CKE

CKE already has explicit circuits for language, vision, and audio families, including Qwen, Gemma, GLM, Kimi-related architectures, Qwen3-VL, and Whisper. It has forward kernels, growing backward and training support, quantized GGUF paths, generated C runtimes, an HTTP/SSE server, a mechanical provider resolver, and X-Ray numerical attribution. The July progress report captures how quickly that surface expanded.

The lab lets those features meet different physical constraints:

• Which provider should the compiler select on AVX2, AVX-VNNI, AVX-512, and BF16-capable CPUs?
• Does prefill benefit from wider vector execution while decode remains bound by weight and cache movement?
• Can large L3 cache keep more quantization blocks, recurrent state, or KV data close enough to alter the useful schedule?
• Which models fit completely in 64 GB, which require quantization, and which need explicit storage or node partitioning?
• Can bounded training and backward passes preserve parity across Intel and AMD?
• Can the native session and server interfaces schedule useful work across machines without hiding the communication cost?

Memory Tetris, Distributed Zip, And A Much Larger Model Workshop

The memory and storage purchases matter because they let CKE work on more than one narrow benchmark at a time. The Intel P3 now has 64 GB of DRAM and 2 TB of NVMe. The Ryzen has 160 GB of purchased memory capacity across separate 64 GB and 96 GB kits, plus 4 TB of fast NVMe and 12 TB of local model storage. Until the combined memory configuration passes training and sustained-load validation, published Ryzen measurements will continue to name the validated 64 GB configuration. The point is that the lab now has multiple real memory capacities and enough persistent storage to stop repeatedly deleting and downloading the evidence around them.

This is where Memory Tetris becomes a hardware experiment rather than only a diagram. CKE knows the intended tensor lifetimes and generated execution order. The research question is whether it can keep a deliberate working window in DRAM, asynchronously stage a future tensor from NVMe into a proven-dead arena slot, and hide enough of that transfer behind useful compute. The 4 TB NVMe supplies the fast backing tier; validated 64 GB and future validated 160 GB Ryzen configurations create different working-window constraints; the 12 TB disk keeps the larger source models, conversions, checkpoints, and failed runs. SSD is still not RAM. The result must report the transfer time that remained exposed after overlap.

The second experiment is Distributed CPU Zip Fusion. The design tries to keep each node on a long independent path through quantized unpacking, local projections, attention heads, activation functions, and partial outputs, then synchronize only where the mathematics requires it. The P3 and Ryzen are not equivalent nodes, which is useful: the scheduler must account for different ISA paths, core counts, cache sizes, and local rates instead of assuming a perfectly matched cluster. The present 1 Gb/s network will probably expose communication quickly. That gives CKE a baseline against which future partitioning, compression, overlap, and networking upgrades can be measured.

The storage also changes model-family development. CKE can keep representative checkpoints and fixtures for Qwen, Gemma, GLM, Whisper, Qwen3-VL, recurrent and hybrid attention, MoE, and future open model families available together. A kernel change can be tested against a broader matrix instead of whichever model still happens to fit on the active drive. Training work can retain optimizer state, periodic checkpoints, gradient captures, and failed trajectories long enough to compare them rather than overwriting yesterday's evidence.

More importantly, this begins the physical foundation for distributed CPU compute. It is only two nodes and it does not yet prove scaling. But CKE can now implement one partition, run it on two different machines, measure the synchronization tax, inspect the first numerical divergence, change the schedule, and run the same experiment again. That loop is how the larger CPU cluster has to begin.

The goal is not to declare CPUs faster than every GPU. The goal is to stop dismissing CPUs before the runtime, memory plan, kernels, and distributed schedule have been engineered and measured seriously. These machines are enough to begin that work.

How Collaborators Could Use The Lab

I would like CKE contributors to be able to use these machines without needing to buy the same hardware. That access is not open today. A Tailscale address and an SSH key are useful for my own administration, but they are not a multi-user research service.

The first safe workflow should be job-based rather than unrestricted shell access:

1. A known contributor authenticates and is invited to a specific CKE project or investigation.
2. The contributor selects an approved commit, model fixture, command, node, time budget, and expected artifact types.
3. A human reviews the first runs, especially when weights, external data, network access, or long jobs are involved.
4. The runner creates an isolated worktree and container or restricted Linux identity with CPU, memory, disk, and wall-time limits.
5. The node captures its hardware manifest, command, logs, output hashes, parity result, profiler files, and failure state.
6. The contributor receives the evidence bundle. Credentials, unrelated models, private datasets, and other users' artifacts remain inaccessible.
7. Every grant can expire or be revoked. No contributor receives root access through the research workflow.

Initially, this can support practical contribution work: verify an AVX-512 PR on the Ryzen, reproduce an AVX2 regression on the P3, compare a generated circuit on both nodes, or run a bounded profiler capture that a GitHub-hosted runner cannot provide. Later, the same control plane could support a small queue, reserved experiment windows, browser-visible results, and authenticated access to CKE's IR and X-Ray reports.

This is also why the hardware must produce standardized artifacts. A collaborator should not have to trust my summary of a run. They should receive the machine identity, exact commit, exact command, raw output, and limits alongside the result.

The Next Thirty Days

The immediate plan is intentionally less dramatic than the hardware:

1. Finish commissioning the Ryzen node: firmware, memory stability, thermals, storage health, compiler, perf, and AMD uProf.
2. Update the public hardware page and nightly metadata so installed hardware is never described as planned.
3. Create one canonical cross-node CKE fixture with the same model, prompt, quantization, generated circuit, and output checks.
4. Publish the first Intel AVX2/VNNI versus AMD AVX-512 evidence packet.
5. Run the first two-node experiment over the current network and retain the bad result if it is bad.
6. Define the contributor job manifest and authentication boundary before exposing either node.

The future Xeon plan still matters. Xeon 600-class systems would add AMX BF16, ECC RDIMMs, more memory channels, NUMA and serious high-speed networking. But the Ryzen and P3 pair now provide the evidence needed to design that purchase more intelligently. They can reveal whether CKE is limited by compute, DRAM, cache, storage, networking, or its own software before more money is committed.

What I Am Not Claiming Yet

• The Ryzen purchase does not prove CKE is fast on AVX-512.
• Two reachable machines do not prove distributed scaling.
• A 12 TB drive does not make storage equivalent to model memory.
• CKU is not meaningful until the workload, active-byte accounting, and wall-clock boundary are published.
• Contributor access is a plan until authentication, isolation, quotas, artifact ownership, and revocation are implemented and tested.

What is real is simpler: the machines exist, the purchases are recorded, the Ryzen and P3 are running Linux, and CKE now has a physical two-node laboratory on which these questions can be answered.

Follow Or Contribute

The source code, issues, and pull requests are in the CKE repository. The hardware support page contains the detailed ledger, evidence contract, future Xeon stages, and ways to contribute hardware access, loaners, engineering help, or a bounded investigation.

If you want the distributed background first, read Distributed CPU AI: MPI, RDMA, NUMA And C-Kernel-Engine and Pipeline vs Tensor Parallelism. The next useful post in this series should contain measurements from the new AMD node, not another purchasing plan.