C-Kernel-Engine (CKE) is an open-source CPU runtime and kernel compiler for transformer-based language, vision and audio models. It describes a model as mathematical circuits, resolves those operations against explicit kernel contracts, and generates C that can be inspected and compared with reference implementations such as PyTorch, llama.cpp and whisper.cpp.

July was the first month where that idea began to look like one system rather than several separate experiments. Vision, language and audio still have different model contracts, but they now pass through more of the same compiler, evidence and regression machinery.

“Active” has different strengths here. Some families run end to end on named artifacts. Some have exact primitive and stitched-model gates. Others are still bring-up or diagnostic contracts. The article keeps those evidence boundaries separate instead of turning every circuit file into a blanket support claim.

This is why CKE compares against pinned llama.cpp and PyTorch oracles at several scales. A reduction may add the same values in a different order and differ by only one FP32 ULP. BF16 or FP16 storage can round that result before the next operation. Attention, recurrent state and autoregressive decode then reuse earlier outputs, so a tiny early difference can remain harmless, grow gradually, change a logit ranking, or eventually flip a token. A 100,000-token context makes that accumulation question more important, not less.

CKE therefore records a spectrum of evidence: byte-exact leaf providers, exact production-route replay, first non-exact checkpoints, maximum and RMS drift, top-1 agreement, recurrent-state equality, and multi-token or long-context behavior. X-Ray exists to walk backward from a later behavioral difference to the first circuit where the two executions stopped matching.

What Actually Merged In July?

Using the Pacific-time month boundary, CKE merged 194 pull requests and 466 commits to main. Two GitHub contributors are represented in the merged PR authorship: Anthony Shivakumar and Aaditya Anand. Commit identity counts are larger because the repository also records separate human, GitHub noreply and managed Xeon-agent identities.

A title-based audit found 50 vision-related PRs, 20 audio-related PRs, 51 mentioning numerical parity, X-Ray or reference oracles, 41 performance-related PRs, and 34 involving DSL, circuit, code-generation or kernel-contract work. These groups overlap. A Qwen3-VL change can be vision, numerical and compiler work at the same time, which is precisely why the total should not be read as five separate piles.

From Text To Vision And Audio

CKE did not simply add a list of model names. July expanded the kinds of circuits the compiler can represent and test.

The audio progression is a good example of the method. Between PR #220 and PR #239, Whisper moved from a log-Mel contract to end-to-end Tiny transcription. Base then reached 25/25 exact generated tokens on the JFK fixture, timestamp decoding produced exact boundaries, and a 33-second fixture reached 81/81 raw generated tokens against Hugging Face. The important part is that the frontend, encoder and decoder are generated through the CKE path rather than hidden behind a framework call.

Making The DSL More Mechanical

The architectural goal is intentionally plain: model-specific knowledge should live in data that the compiler can validate, not in clever branches scattered through generic code generation. PR #144 made circuits authoritative for model dimensions, weight policies, position behavior and required operations. PR #153 moved call-ABI ownership into kernel maps. Later changes made quantization storage, decode providers and checkpoint exports flow from those resolved contracts.

model weights + sidecar + circuit template
                 |
                 v
        validated GraphIR / LoweredIR
                 |
                 v
 kernel maps resolve shape + dtype + ABI + arithmetic
                 |
                 v
             call IR
                 |
                 v
            generated C

This makes the DSL “dumber” in a useful sense. It should not infer that sliding attention is close enough to full attention, silently choose a family default, or call a kernel because its function name looks plausible. A circuit requests exact semantics. A kernel map advertises an exact implementation. Missing or incompatible information fails closed. The power comes from composing many small, explicit pieces, not from hiding model behavior inside the compiler.

Qwen3-VL made this necessary. Its vision bridge, multidimensional positions, mixed storage and segmented prompt shapes exposed places where a leaf kernel could pass while the assembled model still executed the wrong contract. Once those ownership rules were made explicit, Qwen3.5, Qwen3.6 and Whisper could reuse more of the same lowering and validation machinery.

How The Code Was Different Before July

The earlier code could already generate and run model-specific C, but too much meaning could still be supplied indirectly. Generic compiler paths knew about model-family names. Some operation mappings had defaults or compatibility fallbacks. A kernel could be selected from an operation name without the map owning its complete call ABI, storage policy, reduction behavior and valid shape range. Debugging scripts could also observe a different route or stale runtime without failing the evidence immediately.

This is what “making the DSL mechanical” means in practice. The earlier implementation relied on more developer knowledge outside the machine-readable graph. The July implementation moves more of that knowledge into circuits and kernel maps, then makes the compiler reject combinations it cannot justify. The generated C may still be specialized, but the specialization should follow a resolved contract rather than a hidden model-name rule.

How The Tests Became Harder To Fool

Seventy-four July PR titles mention tests, parity, oracles, contracts, provenance, regressions, CI or nightly execution. That category overlaps heavily with the model work. The meaningful change is not that CKE accumulated more test files. It is that each layer of evidence began checking a different way the runtime could be wrong.

1. Leaf arithmetic gates. Scalar and vector providers are compared with pinned llama.cpp or PyTorch arithmetic for named shapes, dtypes, thread counts and ISA paths.
2. Selector and contract gates. Tests prove that a provider accepts its certified topology and rejects nearby incompatible shapes. The Qwen3.6 rank-48 projection, for example, must not leak into Qwen3.5's rank-16 circuit.
3. Call-ABI and lowering gates. Kernel-map arguments, scratch requirements, storage policies and generated call IR must agree before C is emitted.
4. Production-route replay. Tests execute the same public dispatch used by the runtime instead of calling only a convenient test function.
5. Stitched checkpoints. X-Ray compares semantic stops across a complete layer or model path and identifies the last passing and first divergent operation.
6. End-to-end behavior. Text tokens, image-conditioned prefixes, recurrent state, timestamps and transcripts are checked on named model artifacts and fixtures.
7. Cross-family regressions. A Qwen3.6 optimization must not silently change Qwen3.5, Gemma, Qwen2, Qwen3, Nanbeige, v7 training or shared runtime behavior.
8. Compiler, ISA and thread matrices. GCC and ICX, AVX2 and native Xeon lanes, and 1/16/20/24-thread cases expose contraction, reduction and scheduling differences.
9. Provenance and nightly gates. Stale libraries, wrong model hashes, private paths, unowned caches, unsupported hardware and incomplete artifact records fail or report their limits explicitly.

The Q=63 attention failure shows why this layering matters. One compiler-dependent FP32 ULP was found at the final short-prefill boundary. The surrounding provider, shape, storage, threading and oracle identity were already fixed, so the repair could be isolated to an explicit fused multiply-add without changing tolerance or routing. A broad “output is close enough” test could not provide that attribution.

X-Ray Became The Investigation Surface

At the beginning of the month, parity debugging still depended on several backend-specific scripts and tensor dumps. The first Qwen3-VL work established canonical semantic checkpoints and first divergence. PR #164 then put PyTorch and llama.cpp vision evidence behind one X-Ray entry point and ordered results by the model circuit rather than alphabetically by dump filename.

By PR #250, X-Ray reports were joined directly into the IR visualizer. An engineer can inspect the backend, phase, checkpoint drift, call-IR operation, selected provider, required contract and available coverage in one place. Later Qwen3.6 work extended that attribution to prefill schedules and performance timing.

This matters because a wrong token is only the final symptom. The source may be stale generated C, the wrong chat template, a shape-specific provider, a storage conversion, a reduction schedule, recurrent-state ownership or one arithmetic operation. X-Ray first checks whether both backends executed comparable state and inputs. Only then does it assign the first numerical divergence to a circuit location.

The deeper account is in What Numerical Parity Actually Requires and the Qwen3.6 case study, How CKE X-Ray Found Qwen3.6's First Bad Circuit.

Closing Gaps Without Hiding Them

July's performance work concentrated on exact Q4/Q6 providers, packed-weight reuse, query tiling, visual-attention parallelism, recurrent-head ownership, Whisper scheduling and ISA-specific paths. Two end-of-month measurements show both the progress and the remaining work.

Qwen3.6 prefill on one Xeon node

On an Intel Xeon Gold 6542Y, inside a 14-CPU cgroup, the measured Qwen3.6-27B Q4_K_M GGUF 29-token prefill improved from 6,682.61 ms to 2,552.64–2,601.74 ms. Throughput moved from 4.34 to 11.15–11.36 tokens per second, approximately 2.6x faster than the earlier CKE path. The same-host llama.cpp reference measured about 20.7 tokens per second, so CKE remained about 1.85x slower. The optimized route is still opt-in because 1K-context logits retain unresolved accumulated drift even though top-1 remains aligned in the tested run.

Whisper Base changed within two days

The first controlled Whisper benchmark measured CKE at 26.751 seconds of compute against 0.544 seconds for whisper.cpp: a 49.15x gap, despite all three backends producing the same 25 transcript tokens. That baseline isolated generated decoder and attention execution as the real problem.

Subsequent profiling, packed-K attention, persistent-thread scheduling, Conv1D parallelism, oneDNN integration and validated FP16 encoder storage reduced the exact CKE hybrid path to 1.53–1.58 seconds on the same 11-second fixture. The recorded whisper.cpp FP16 result remained faster at 0.567 seconds, roughly a 2.7x gap. This is still one Base fixture, not a broad audio benchmark, but it shows why retaining an honest slow baseline is useful: the same benchmark can prove whether later work changed the actual bottleneck.

The Qwen3.6 sequence is explained in How CKE Made Qwen3.6 Prefill 2.6x Faster.

A Contributor Started The Server Surface

Aaditya's July work covered Arch Linux profiling guidance and the first experimental Responses schema scaffold. PR #183 corrected the Cachegrind setup workflow from a contributor's environment. That led to stronger contributor attribution in CONTRIBUTORS.md, .mailmap and project governance documentation.

PR #272 added an experimental Responses request, response and streaming schema with 56 passing tests. The current implementation returns deterministic mock data; it does not load a CKE model. That is deliberate. The wire contract can be reviewed while the eventual native C or Rust server is designed around one model load, bounded queues, cancellation and streaming from the generation loop.

One Codebase, Several CPU Generations

Most July performance investigation happened on two very different machines. The first is a personally funded CAD 1,050 Lenovo P3 Tiny with a 14th Gen Intel Core i7-14700T and 32 GB of RAM. It is a dedicated minimal Ubuntu Server node for repeatable AVX2/FMA/AVX-VNNI execution, VTune and Advisor profiling, perf, flamegraphs, assembly inspection and unattended experiments. It does not provide native BF16 or AMX, which makes it a useful commodity-CPU baseline rather than a substitute for Xeon evidence.

The second is external access to a 5th Gen Intel Xeon Gold 6542Y inside a Kubernetes environment. The processor exposes 24 physical cores and 48 logical CPUs, AVX-512, VNNI, BF16 and AMX, but the container has a 14-CPU quota. Runs above that quota measure CFS/cgroup throttling as well as kernel work. That constraint is inconvenient, but still valuable: it enabled native Xeon compiler, ISA, BF16 and AMX investigation while forcing the reports to separate physical hardware capability from the resources actually allocated to CKE.

The wider validation range includes older and 12th-generation Core i7 systems, GitHub's AMD x86 runners, external 2nd- and 3rd-generation Xeons, and an Arm-class TI TDA4VM portability lane. These machines do not all run the same model matrix. Together they expose ISA assumptions, compiler contraction, hybrid-core scheduling, thread-capacity limits and portability failures that one workstation would hide.

This is not a claim that every model passes every gate on every machine. The purpose of the fleet is to stop one fast workstation from defining “CPU support.” Provider selection, arithmetic, threading and compiler contraction can change across machines. Each published result therefore needs its model, quantization, CPU, ISA, compiler, thread policy, prompt or tensor shape and reference identity.

The July Writing Record

The engineering program also produced 32 public ShivasNotes articles in July. The writing was not a separate marketing exercise after the code. Each article turned a cluster of PR evidence, model architecture, profiling work or mathematical background into something a human could inspect without reading the complete repository history.

Together, the PR ledger and the article ledger show two views of the same month. Pull requests preserve exact implementation and validation history. The articles explain why those changes mattered, how the mathematics connects, and where the remaining evidence boundaries sit.

The Complete July Pull-Request Ledger

The narrative above groups the work by engineering problem. The chronological ledger below keeps the complete source record: every pull request merged during July in the America/Vancouver time zone. Titles are retained because they describe whether the change added a capability, corrected a numerical boundary, improved performance, strengthened tests, or documented an evidence limit.

This ledger is intentionally a source index rather than 194 rewritten summaries. The detailed PR descriptions contain the problem, diagnosis, measured delta, regression guard, limitation and validation commands for each bounded change.

What July Did Not Finish

• Qwen3.6's optimized batched prefill remains opt-in until long-context accumulated drift is attributed.
• CKE still trails llama.cpp on the measured Qwen3.6 prefill and whisper.cpp on the measured Whisper Base fixture.
• Whisper Medium and Large are not certified, and broader audio corpora are still required before FP16 becomes a default policy.
• AVX2 is the broad x86 production baseline; AVX-512, BF16 and AMX claims remain tied to explicit hardware lanes and evidence.
• The Responses server is a schema scaffold, not a production inference server.
• Distributed tensor, pipeline and expert parallel execution across CPU nodes is still future work.

The Next Constraint Is The Fleet

August should continue the same method: close the remaining Qwen3.6 long-context divergence, improve audio scheduling and corpus coverage, turn the server schema into a native execution design, and keep moving model-family behavior out of generic compiler branches.

The larger research direction is distributed CPU AI. If the planned hardware budget permits, the next fleet additions should be expandable Xeon nodes with enough PCIe and memory-channel headroom to test tensor, pipeline and eventually expert parallelism. The first goal is not to claim that a small cluster beats an accelerator system. It is to prove numerical equivalence, partitioning, communication, failure behavior and measured scaling on hardware that can be expanded one node and one memory channel at a time.

That transition will be gradual. The first distributed work should harden node discovery, reproducible placement, tensor and pipeline boundaries, KV-cache movement, communication traces, numerical replay across partitions and failure recovery. Additional CPU purchases only become useful when CKE can show which constraint each new node, memory channel or network link removes.

Review the complete July history in the merged pull-request record, inspect the CKE documentation, or join the CKE Discord to test another CPU, model or numerical boundary.