CKE can now run the tested Q4_K_M text artifact for Qwen3.8-Flash-Next. The Q4_K_M quantization format is not experimental. What remains experimental is CKE's support boundary for this particular model: short-prompt Q4_K_M text execution is working and numerically certified, while full-model BF16 parity, multimodal execution, consumed long contexts, and matched performance remain open.

This model was a useful test because it was not simply another dense decoder with different dimensions. It brought a combination CKE had not represented as one complete circuit before: four hyper-connection streams, Per-Layer Embedding, recurrent Gated DeltaNet layers, query-selected sparse attention, 512 routed experts, and a gated shared expert.

That sounds like the kind of model that should force a runtime rewrite. It did not. It required real new kernels, new storage and scheduling contracts, and some shared compiler fixes, but the basic C-Kernel-Engine architecture held: describe the model, map its tensors, declare the circuit, bind operations to kernels, generate C, and compare every observable boundary against an independent oracle.

CKE is not at the point where every new model becomes a tiny data-only change. The bring-up still modified five core compiler and planner files. But it is getting closer to a workflow where the remaining work is mostly explicit: which mathematical operation is new, which storage format is missing, which kernel contract must be added, and where does the first numerical difference appear?

Why Flash Next Was Not Just Another Qwen Model

Qwen's official model card describes Qwen3.8-Flash-Next as a 125B-parameter model with about 6B activated parameters and a large additional n-gram embedding component. CKE's current work covers the text runtime of a quantized GGUF artifact, not the complete multimodal model. The GGUF architecture identifies itself as qwen4exp, which resolves to CKE's dedicated qwen4_exp circuit.

The 48-layer topology interleaves two kinds of sequence processing. Most layers use recurrent Gated DeltaNet, carrying compact state rather than scanning a full attention cache. Twelve layers use Query-Selected Attention, where a cheaper indexing pass selects useful prefix blocks before sparse attention reads them.

The residual path is also different. Instead of carrying one hidden stream through every block, the model carries four hyper-connection streams. Each layer dynamically mixes those streams, runs its recurrent or attention operation, and injects the result back into selected streams. A Per-Layer Embedding side path hashes recent token n-grams into layer-specific tables, gates and smooths that signal through a causal convolution, and injects it into the same stream system.

Finally, the MLP is sparse. For each token, the router selects ten of 512 routed experts and combines them with one gated shared expert. The artifact also mixes quantization formats across expert projections. The model therefore stresses topology, persistent state, sparse selection, packed weights, mixed storage, reduction order, and memory planning at the same time.

The New Kernel Families CKE Needed

The main additions were not a single monolithic “Qwen3.8 kernel.” They were smaller mathematical providers that can be tested and reused independently.

The details matter. During X-Ray, the first material full-model difference was traced to a shared expert whose Q5_0 down-projection path processed prompt rows one at a time. The oracle grouped four rows. The values differed by only around 1e-6 at first, but a later Q8_0 quantization boundary amplified that difference. CKE did not fix this by loosening tolerance. It made the Q5_0 and Q8_0 shared-expert variants use the same declared four-row projection schedule, then proved all 102,400 isolated shared-expert output values matched exactly.

How A New Model Enters CKE

The bring-up loop is becoming repeatable:

1. Read the model rather than guess from its name. CKE inspects the GGUF or safetensors metadata and records layer kinds, dimensions, state sizes, expert topology, attention policy, chat format, tensor names, and actual tensor storage.
2. Add the model and tensor maps. The maps translate external architecture and weight names into CKE's internal vocabulary. Unsupported quantization must fail here or at provider selection, not silently reinterpret bytes.
3. Declare a circuit template. The circuit says how operations are connected, which state persists, which buffers exist, and which contracts each phase requires. Flash Next received a dedicated circuit rather than pretending to be dense Qwen.
4. Reuse existing kernels and identify the real gaps. Ordinary projections, normalization, RoPE, routing, DeltaNet pieces, cache operations, and output logic can be reused when their contracts match. Hyper connections, PLE, QSA, and some mixed-expert paths were genuine gaps.
5. Add kernel maps for each provider. A kernel map states the operation interface, accepted dtypes and layouts, prefill/decode phase, workspace, threading behavior, numerical contract, source function, and evidence status.
6. Run the DSL and inspect generated C. The compiler lowers the circuit, chooses matching providers, plans memory, and emits a native runtime. Missing or ambiguous providers should stop generation with a precise error.
7. X-Ray the circuit against an oracle. CKE captures intermediate tensors and compares them with llama.cpp or PyTorch at each operation and layer. The first divergence is more useful than staring at final gibberish.
8. Promote the successful path into regression coverage. A pinned model, command, machine, numerical boundary, and retained report must continue running after the bring-up PR is merged.

For this model, llama.cpp was the complete quantized-runtime oracle while PyTorch and independent staged references covered kernel-level BF16 and mathematical boundaries. X-Ray also had to become stricter about provenance: a newly generated model library cannot be combined with stale engine or tokenizer libraries and still be called valid evidence.

What The Numerical Evidence Actually Proves

Merged PR #456 records several levels of evidence on the Ryzen 9 9950X3D with 160 GB RAM:

• A one-token-prefix trajectory matched all 248,320 vocabulary logits across 256 decode comparisons.
• After shared-expert scheduling and circuit-owned terminal-row planning, a real 40-token batched prompt followed by 64 comparisons matched every full-vocabulary row bit-exactly, including the initial prefill result.
• The follow-up all-layer X-Ray analysis reported 45,285 exact comparisons, 671 explicitly unavailable comparisons, and zero value differences among the compared boundaries.
• The focused Flash component gate covered the circuit, hyper connections, PLE, sparse BF16 attention, mixed MoE, storage contracts, terminal-row planning, and trajectory harness.

Unavailable does not mean passed. A 40-token prompt is not an 8K test because the runtime capacity was 8192. The 128K result is currently a memory-plan result: the compiler planned an arena of roughly 126.8 GiB with 4,096 transient rows. It is not a consumed-128K numerical or performance certification. Full BF16 model parity, long-context execution, and matched performance remain open.

This also answers a potentially confusing question about the word experimental. CKE is not missing the kernels needed by the tested Q4_K_M text path: the complete path generated, executed, and reached bit-exact full-vocabulary parity for the retained short trajectory. The label remains because that is only one artifact, one modality, one execution boundary, and one evidence ladder. It should not be stretched into a claim that every quantization, dtype, context length, or modality of Qwen3.8 Flash Next is certified.

The current operator boundary is documented in the Qwen3.8 Flash Next runbook. The exact debugging trail, including failed comparisons rather than only the final green result, is retained in the Flash Next bring-up record.

Did The Architecture Really Hold?

Mostly, but this was still a large bring-up. CKE's advisory novelty report for the merge range counted 127 changed files: two circuit/model-map groups, 40 kernel-map files, 14 kernel-source/include files, 28 test/evidence files, and five core compiler or memory-planner files. The core-compiler portion was 933 additions and 280 deletions. The file count includes broad registry, evidence, and documentation work; it does not mean 127 model-specific exceptions were added.

The 40 kernel-map files also overstate the conceptual surface because generated registry updates and provider metadata can create broad diffs. The more meaningful architectural signal is the five central files. Each changed for a different reason:

When Should A New Model Change The DSL?

The preferred path is to define a new capability in the circuit or kernel-map JSON and let the DSL interpret it generically. If a later model changes the number of hyper streams, chooses a different provider, declares another terminal suffix, or uses different state dimensions, those are values inside an existing contract. They should not require another Python branch.

A DSL change is justified only when the existing contract language cannot describe what the model means. Flash Next introduced several such concepts: a multi-stream residual topology, PLE history, QSA index state, storage-aware composite providers, and a terminal-row execution schedule. The right implementation is not if model == qwen4_exp. It is to add a named, validated semantic contract, teach the generic parser and planner what that contract means, and make the circuit opt into it through JSON. Once that work exists, another model should be able to reuse the same contract without changing lowering.

Many difficult changes appear at the producer-consumer boundary in memory. A producer writes a typed logical slot. One or more consumers read that slot through declared ports. The planner must decide whether the value is transient scratch, a persistent recurrent or cache state, a quantized view, an in-place alias, or a full-prefix tensor needed after another operation runs. It must also prove shape, dtype, lifetime and capacity compatibility. Hyper streams, PLE, QSA and mixed expert paths made this graph more sophisticated; they did not justify guessing from the Qwen model name.

A reusable DSL extension therefore needs four pieces:

1. A schema. The JSON field has a documented type, allowed values and ownership rules.
2. A generic interpretation. Lowering converts the field into operation, dependency, state and scheduling semantics without inspecting the model family.
3. A memory contract. Every producer and consumer port declares shape, dtype, lifetime, persistence and aliasing constraints.
4. Fail-closed evidence. Invalid or incomplete declarations stop compilation, while focused tests and X-Ray prove the generated path.

This is how compiler growth can remain healthy. The first model exposing a genuinely new idea may require central work. The second model using that idea should mostly supply different JSON values, tensor maps, providers and evidence. If it requires the same central edits again, the earlier abstraction was incomplete.

Other general repairs accompanied the bring-up. Hierarchical weight names such as attn_hyper.mix_down are now converted into collision-safe C identifiers. Missing providers can no longer be mistaken for KV-cache operations. X-Ray fingerprints the model, engine and tokenizer libraries so a freshly generated model cannot be tested accidentally with stale companion binaries. Quantized sigmoid and SiLU evaluation order lives in numerical providers rather than model-name lowering.

These changes make CKE stronger because they replace ambiguity with explicit contracts. The brittle part is that build_ir_v8.py and the code generators still had to learn several new operation names and their dataflow/emission behavior. That is better than branching on qwen4_exp, but it is not yet data-only model bring-up. A later model that uses the same hyper, PLE, QSA, mixed-expert and terminal-row contracts should reuse them without repeating this compiler work. The novelty report will tell us whether that promise holds.

The scaling metric is simple: when the next model arrives, how much work lands outside its circuit, tensor map, genuinely missing reusable kernels, and evidence fixtures? The target for core DSL/compiler churn should move toward zero. If every new family requires another model-name branch in lowering, CKE is not scaling. PR #456 specifically avoided adding such a branch for the terminal-row solution; the scheduling need became a circuit-owned contract.

Why Some Models Take Longer

A model takes longer when it crosses a boundary the runtime has never implemented:

• A genuinely new mathematical kernel, such as QSA index selection or hyper-stream mixing.
• A new weight or activation storage format, especially when mixed within one layer.
• A new persistent-state layout or ownership rule.
• A different prefill reduction order that matters at quantization boundaries.
• A tokenizer, chat, multimodal, or tool-use contract not yet represented explicitly.
• An oracle that cannot expose the corresponding internal boundary.
• A memory requirement larger than the available evidence node.

But the more model families CKE covers, the smaller many of those gaps become. Qwen, Gemma, GLM, Kimi, Cohere, Nemotron, and Whisper have already forced the runtime to represent dense attention, recurrent state, MoE routing, multiple quantization families, vision bridges, audio frontends, and different numerical schedules. A future model can reuse those pieces if its contracts really match. If it introduces new math, that new math becomes another reusable kernel family rather than another opaque model implementation.

That is the part I find encouraging. The work moves away from “support model X” and toward “make this operation, storage contract, or schedule explicit and correct.” The model name tells us where the idea came from. The kernel and circuit tell CKE what the computer must do.

What Flash Next May Reuse For DeepSeek-Like Models

There is an important architectural relationship here, but it should be stated precisely. Qwen3.8 Flash Next did not simply import DeepSeek-V4's complete residual system. Both belong to the broader hyper-connection design space and both carry four residual lanes, but the CKE path implemented for Qwen is not yet DeepSeek's manifold-constrained Hyper-Connections (mHC).

Qwen's current CKE circuit expands one hidden row into four streams, derives a dynamic read from the normalized streams, runs the selected block, and injects that block output back into the four-stream state. DeepSeek mHC adds another material operation: a learned residual carry matrix that mixes the old lanes with each other. That matrix is projected through repeated Sinkhorn normalization so it remains approximately doubly stochastic. CKE's Qwen hyper-connection kernels do not perform that manifold projection or cross-lane carry today.

A future DeepSeek-like circuit should therefore reuse substantial engineering from Flash Next:

• Multi-stream storage: the [tokens, streams, hidden] layout, stream expansion, final collapse, shape propagation, buffer sizing, and lifetime planning already exist.
• Read and write plumbing: dynamic stream reads, per-stream block injection, FP32/BF16 boundaries, mixed-quantized weight providers, and X-Ray checkpoints are reusable when their numerical contracts match.
• Sparse-selection infrastructure: QSA and DeepSeek DSA are not interchangeable algorithms, but both need index scoring, top-k selection, gathered sparse attention, persistent index state, and explicit cache ownership. Those generic contracts can reduce the new work.
• Existing model portfolio: CKE already has reusable MLA, MoE routing, grouped expert execution, recurrent-state, RoPE, normalization, and cache providers from Qwen, Kimi, Instella, GLM, and other model families.

The missing DeepSeek work remains real: implement and certify the residual carry matrix, exponentiation and Sinkhorn iterations; represent the exact mHC controller parameters and tensor layouts; add the released CSA, HCA, DSA, MLA, MoE, cache, and quantization contracts that are actually present in the target artifact; and compare every boundary with an authoritative implementation. Similar names or four matching lanes are not parity evidence.

This becomes another test of CKE's architecture. The ideal DeepSeek bring-up adds a new circuit, tensor map, genuinely missing kernels such as manifold projection, and model-specific evidence. It should reuse the generic hyper-stream operation interfaces and memory contracts without adding if model == deepseek_v4 to lowering. The earlier DeepSeek-V4 kernel roadmap describes the target operations in more detail. Flash Next now turns part of that roadmap from a blank page into tested infrastructure, not completed DeepSeek compatibility.

Compatibility Is Evidence, Not The North Star

CKE running Qwen3.8-Flash-Next matters, but collecting model names is not the final objective. These models give me access to architectures created by labs with research budgets I do not have. By implementing and testing their published kernels on CPUs, I can study what their work actually computes rather than only calling a hosted API.

The longer-term goal is to make kernels, dtypes, quantization formats, circuits, gradients, and ISA providers reusable as trainable building blocks. I want to be able to combine an attention mechanism, normalization, gate, recurrent update, or expert layout; build one layer; inspect it; train it; and then scale that explicit circuit on commodity CPU hardware. CKE has a long way to go, particularly in backpropagation and training. Model compatibility is evidence that the architecture can represent real work while moving toward that north star.

For now, Qwen3.8 Flash Next is a meaningful step. A model with new residual topology, sparse attention, recurrent layers, PLE, and mixed experts now generates through the same broad CKE pipeline used by dense text, audio, and vision circuits. The bring-up also left behind more reusable kernels, stricter X-Ray evidence, better cache provenance, and a clearer metric for whether the next model becomes easier.

Implementation And Documentation

• Official Qwen3.8-Flash-Next model and architecture card
• GGUF artifact family used by llama.cpp-compatible runtimes
• CKE PR #456: Flash Next circuit and numerical providers
• The explicit qwen4_exp circuit
• QSA kernel deep dive
• Hyper-connections and Flash Next circuit anatomy
• Per-Layer Embedding deep dive
• How CKE kernel maps bind operations to implementations
• DeepSeek mHC paper: Manifold-Constrained Hyper-Connections

Related Notes

• DeepSeek-V4 Architecture From Kernels maps mHC, CSA, HCA, DSA, MoE, cache, and training work into prospective CKE kernel boundaries.
• CKE Added Qwen3.8 In About An Hour explains why the earlier dense model required a much smaller bring-up.
• Qwen3.8 Broke In CKE shows why compatibility claims must remain protected by real-model regression evidence.
• I Used CKE To Transcribe My Video follows the same model from practical use to a permanent Whisper nightly gate.
• CKE Now Runs More Than Qwen surveys the model-family portfolio whose shared kernels Flash Next can reuse.
• A Green Checkmark Should Name Its Machine explains the hardware and evidence discipline behind CKE's scheduled tests.