Today I wanted to test how much of CKE's architecture is actually holding up as new models arrive.

It is easy to say a runtime is extensible when the models being tested have already been supported for months. Qwen3.8 gave us a cleaner test. The model was new, its GGUF metadata still identified the underlying architecture as qwen35, and CKE had to decide whether to quietly reuse the old model identity or describe the new model properly.

In CKE, a model is not just a name attached to one large inference function. Each model family is described as an explicit template or circuit. The circuit states how many layers exist, which operations each layer needs, how tensors flow between them, and how different block types are interleaved. One layer may use full attention with Q/K normalization, RoPE, a gate, or a bias. Another may use recurrent DeltaNet state. A dense model may use SwiGLU, while an MoE model also needs routing and expert kernels. Those choices live in the model circuit rather than being scattered through a model-specific runtime. I explained the idea conversationally in Templates Are Circuit Maps; the technical companions are the CKE system architecture and IR and code-generation pipeline.

The qwen35 value in the GGUF file was still useful. It told CKE where the artifact came from and which broad architecture it resembled. But it was not a complete executable description of Qwen3.8-27B. Qwen3.5 in CKE includes MoE routing and shared-expert work; this Qwen3.8 model uses a dense SwiGLU path. Reusing the Qwen3.5 identity might have been the quicker shortcut, but it would have made generated manifests, compatibility checks, and future debugging describe the wrong model. We therefore kept qwen35 as source provenance and added a model-owned Qwen3.8 circuit. The CKE GGUF-to-BUMP documentation covers the conversion and materialization boundary behind that step.

The CKE DSL is much simpler in purpose than the name may suggest. In plain English, it is a circuit stitcher and a memory planner. It takes the selected circuit and mapped model weights, asks the kernel registry for a legal implementation of every operation, validates shapes, dtypes, layouts, phases, and numerical contracts, plans buffer lifetimes and arena offsets, and then generates the C program. For the implementation-level rules, see CKE's kernel maps and provider-selection documentation. The earlier CKE memory-planning article gives the causal explanation, while the CKE memory-safety documentation records the allocator, canary, and validation contracts.

This is also why the DSL must fail hard. If a required kernel is missing, ambiguous, or incompatible with the requested tensor contract, the compiler should stop. Continuing would mean stitching together a circuit CKE cannot justify, which may crash but can just as easily produce fluent-looking gibberish. For Qwen3.8, the converter mapped the weights, the new circuit asked for its operations, and the DSL found existing providers for the required arithmetic. With a small amount of model-resolution and circuit work, CKE generated a complete native runtime.

The first native Qwen3.8-27B Q4_K_M run worked in roughly an hour of our working session. I am treating that as a practical work-session estimate, not a benchmark. The repository evidence is more precise: merged PR #387 mapped every required weight, validated the generated prefill and decode graphs, compiled the native C runtime, and produced coherent output on the Ryzen 9 9950X3D node.

Then the parity work went much further. Merged PR #388 compares a 4,000-position visible-reasoning trajectory against pinned llama.cpp. All 4,000 top-1 rows match. All 4,000 complete 248,320-value vocabulary rows are bit-exact. X-Ray adds another 4,011 exact internal rows across three sentinel layers. That is the evidence that the circuit was stitched correctly, and those certification gates are now part of the main CKE branch. The reusable method is documented in the CKE X-Ray guide and divergence-harness reference.

That is a more interesting result than merely getting a chat response. It suggests that CKE's unusual circuit-and-contract architecture is beginning to do what it was designed to do: make a new model mostly a problem of truthful composition when the required kernels already exist.

Why CKE Did Not Just Call It Qwen3.5

The Qwen3.8 GGUF artifact advertises general.architecture=qwen35. A permissive runtime could accept that label and run the model through the existing Qwen3.5 path. CKE deliberately does not do that.

Qwen3.5 in CKE includes routed and shared MoE operations. Qwen3.8-27B is a dense SwiGLU model. Both use the same broad hybrid decoder idea: three recurrent DeltaNet-style blocks followed by one full-attention block. They also share RMSNorm, split RoPE, Q/K normalization in full-attention layers, recurrent state, and many of the same quantized projection families. But their MLP topology and model ownership are not the same.

Silently treating Qwen3.8 as Qwen3.5 would create two problems:

• The model identity would be false. Generated reports, manifests, X-Ray artifacts, and future compatibility rules would continue to say Qwen3.5.
• A future topology change could become unsafe. If Qwen3.8 changes while CKE assumes it is merely a Qwen3.5 artifact, the compiler can select an invalid circuit without an obvious failure boundary.

The declarative GGUF model map now matches the Qwen3.8 basename and size label, selects template=qwen38, records family=qwen38, and keeps source_arch=qwen35 as provenance. Ambiguous artifact matches fail closed instead of picking whichever rule happens to run first.

GGUF says:       source architecture = qwen35
CKE resolves:    runtime model       = qwen38
CKE selects:     circuit             = qwen38
CKE preserves:   source provenance   = qwen35

This separation is small in code and important in architecture. External file-format labels are inputs to model resolution. They are not permission to erase CKE's own model contract.

What CKE Already Had

The fast bring-up happened because Qwen3.8's required arithmetic was already represented in CKE's kernel portfolio. That work came from months of supporting and debugging other models, especially the Qwen family.

The new Qwen3.8 circuit composes:

• Hybrid recurrent and full-attention layer scheduling.
• Gated DeltaNet recurrent prefill and decode providers.
• Dense SwiGLU gate, up, activation, and down projections.
• RMSNorm and full-attention Q/K normalization.
• Split RoPE and the model's text-position behavior.
• FP16 KV-cache attention and exact reduction contracts.
• Q4_K, Q5_K, Q6_K, Q8_0, Q8_K, and FP32 projection boundaries used by the artifact.
• Weight tying, BPE tokenization, chat formatting, and visible/suppressed thinking modes.

Most of those providers were not invented for Qwen3.8. They were hardened while X-Ray was finding one-ULP drift, reduction-order differences, storage boundaries, compact projection layouts, and fused-provider mismatches in Qwen3.5, Qwen3.6, and Qwen3-VL. The earlier posts on Qwen3.5 hybrid recurrent attention, Qwen3.6 X-Ray attribution, and numerical parity explain where much of that work came from.

This is the compounding effect I hoped the architecture would create. A difficult kernel or numerical contract should be paid for once, registered explicitly, and then reused by every compatible circuit. A new model should not require another hand-written runtime if it is built from operations CKE already understands.

What The First Ryzen Run Proved

The Ryzen machine is not a random benchmark host. It is part of the heterogeneous CPU lab I am building for CKE, alongside the Intel systems used for parity and ISA coverage. I documented the CAD $9,575 hardware purchase and compute budget, while CKE's hardware support and lab inventory records what each machine is meant to test. The Ryzen node gives this bring-up a concrete AMD Zen 5 execution target rather than an abstract claim of x86 portability.

The merged result in PR #387 used the standard 17.8 GB Qwen3.8-27B Q4_K_M artifact on the CKE Ryzen node:

The generated runtime allocated a mixed-backed 25,488 MiB arena, mapped 16,718 MiB of weights, prepared 78 model-owned prefill weights inside explicit budgets, compiled AVX-512/VNNI native code, and completed prefill and decode.

Those numbers are not a performance victory. The short smoke is not a matched llama.cpp benchmark, and 3.17 tokens/s is not where I want CKE to stop. The result establishes something narrower: conversion, identity, tensor mapping, memory planning, generated code, model loading, prefill, and decode all composed without a new Qwen3.8 arithmetic kernel or compiler branch.

The 4,000-Row Parity Result Is The Stronger Evidence

A coherent answer can hide numerical problems. Two runtimes can agree for the first few tokens and then diverge as small differences cross a quantization threshold, change a router decision, or flip the top logit. That is why CKE does not use readable text as its main correctness oracle.

Merged PR #388 adds a production-size text certification fixture. The prompt asks Qwen3.8 to reason about and return a standalone SVG explaining tokenize, prefill, decode, and detokenize. The test requests up to 4,000 generated positions and compares CKE with a pinned llama.cpp commit.

The vocabulary has 248,320 entries. A complete 4,000-row comparison covers roughly 993 million logits, so the certifier switches to row-streamed comparison instead of duplicating the entire trajectory in memory.

The internal X-Ray rows come from recurrent layer 0 and full-attention layers 31 and 63. A companion X-Ray fix preserves compact physical projection checkpoints and reconstructs semantic gate/up boundaries when the selected provider is fused. The diagnostics follow the provider CKE actually executed instead of pretending the graph remained unfused.

Exact Numerics And A Failed SVG Are Not A Contradiction

The model completed its visible reasoning, started the SVG answer, and then reached the 4,096-token runtime capacity. The answer was truncated, so it could not satisfy the standalone SVG quality contract.

At the same time, CKE and llama.cpp produced the same full-vocabulary logits for every compared row. Numerical status is therefore pass. SVG quality status is fail.

This distinction matters. Runtime correctness asks whether CKE executed the model circuit the same way as the oracle. Answer quality asks whether the model completed the requested task inside the available context and whether the output passed structural checks. A runtime can be numerically exact while the model answer is incomplete. It can also produce a plausible answer while its internal arithmetic is drifting.

CKE should report both rather than allowing one to stand in for the other.

What This Says About The CKE Architecture

I am increasingly confident that the basic architecture is holding up:

1. Models are explicit circuits. Qwen3.8 has a model-owned description of its recurrent blocks, full-attention blocks, dense MLP, state, chat contract, and phase behavior.
2. Artifacts resolve declaratively. GGUF metadata selects a model variant without adding basename checks throughout the compiler.
3. Kernels implement numerical contracts. A Q4_K projection is not selected merely because the weight bytes are Q4_K. The circuit also specifies activation type, phase, layout, reduction behavior, and evidence.
4. The DSL remains mechanical. It validates shapes, plans memory, chooses registered providers, and emits C. It does not need to understand Qwen3.8 as a special story.
5. X-Ray follows the physical execution. Compact and fused providers still expose semantic checkpoints so first divergence can be assigned to the operation that actually ran.
6. Failures remain separate. Unsupported quant types, ambiguous artifact identity, numerical mismatch, context exhaustion, and answer-quality failure are different states.

This is close to the idea I described in Templates Are Circuit Maps. The circuit describes what should happen. Kernel maps and numerical contracts describe how a legal implementation may happen. Generated C is the artifact that actually executes it.

How Broad Is This Result?

CKE now has meaningful work across Qwen language and vision models, Gemma language and vision models, GLM-4, Whisper audio, Kimi-family experiments, Nemotron, Instella, and several dense Llama-style architectures. The July CKE recap gives the broader model and modality picture.

But the support depth is not identical:

• Some families have full model execution and long trajectory parity.
• Some have focused circuit, conversion, or kernel certification.
• Some remain architecture research until public weights or missing kernels become available.
• A standard Qwen3.8 Q4_K_M artifact was tested; this does not certify every UD or mixed GGUF quant.
• AMD Zen 5 and Intel AVX2/AVX-512/Xeon lanes expose different providers and reduction behavior. Passing on one CPU does not automatically certify every ISA.

Model compatibility is evidence, but it is not the final objective of CKE. The longer-term objective is to turn kernels, dtypes, quantization formats, circuits, gradients, and ISA providers into reusable trainable building blocks. I want to be able to ask: what happens if we stitch this attention mechanism to this normalization, gate, or state update because the combination appears capable of packing intelligence more efficiently? We should be able to build one layer, inspect it, train it, extend it to two or five layers, and eventually scale the same explicit circuit much further without hiding the mathematics inside a large framework.

I do not have the budget to research every new kernel from first principles. Open weights, technical reports, and published implementations give me access to some of the output of research programs funded at a scale I could never reproduce independently. CKE lets me study those ideas as explicit circuits, learn why they work, and then investigate how they can run on CPUs for inference, training research, and practical use on commodity hardware. CKE still has a long way to go, but the small wins and occasional quick wins keep the work moving. Bringing up Qwen3.8 in about an hour was one of those quick wins.

That is also why bringing up released model families matters. Every architecture is invented by someone. The difference is that Qwen, Gemma, GLM, Whisper, and similar model families have already been trained at enormous cost, evaluated, released, and used by people outside CKE. Their weights provide evidence that these circuits can actually learn useful representations. If I sketch a new circuit inside CKE and make it execute, I have proved that the runtime can run my circuit; I have not yet proved that the circuit can learn anything useful.

Implementing established model families first gives CKE stronger reference points, numerical oracles, and components whose value has already been demonstrated through training. Later, those components can be recombined into original experiments, but those experiments must earn their own credibility through training and evaluation. Each released model also reveals the smallest genuinely missing kernel or numerical contract, and the resulting component should become available for both faithful model execution and future research. The ambition is not only inference. It is to make model composition and training increasingly practical on commodity hardware. Whether CKE reaches that full destination is still an open question, but that is the direction we are actively building toward.

GLM-4 required its own interface corrections. Gemma4 required per-layer attention-width and sliding/full-attention rules. Qwen3-VL required vision preprocessing, M-RoPE, BF16 boundaries, and multimodal state. Whisper required an audio frontend, encoder, cross-attention cache, and timestamp behavior. Those differences belong in circuits and providers, not in one expanding model-name switch statement.

What Comes Next

With PR #388 merged, the long-trajectory and physical-checkpoint gates are now part of CKE's main branch. The immediate work moves from establishing this correctness boundary to broadening and accelerating it:

• Keep the long-trajectory and physical-checkpoint gates reproducible as the runtime changes.
• Increase or stage context capacity so the SVG quality fixture can complete.
• Profile matched 128, 512, and 4,096-token prefill against llama.cpp.
• Break down provider time, barriers, cache traffic, prepared-weight selection, and decode scheduling on Ryzen.
• Repeat the architecture and numerical gates across Intel and AMD ISA lanes.
• Test additional Qwen3.8 quant artifacts only after their GGUF types and contracts are explicitly supported.
• Add an opt-in high-memory nightly lane once the artifact and runtime cost are practical for CI.

CKE still has performance gaps, incomplete model lanes, and a lot of kernel work ahead. But Qwen3.8 is a useful architecture result. A new 27B model arrived, and the missing work was mostly truthful model description and certification rather than another runtime implementation.

That is what I wanted the circuit architecture to become.