Honestly, that surprised me. One side of the comparison had access to a frontier model running on enormously expensive datacenter infrastructure. The other was Qwen3.8-27B running through C-Kernel-Engine (CKE) on one AMD Ryzen 9 9950X3D in my lab. If I removed the model names and only showed the completed infographics, the difference was not obvious to the people looking at them.

This was an informal comparison, not a controlled benchmark, and it does not measure every workload. It does show that, for the technical reasoning and artifact-generation work I tested, Qwen3.8 delivered the same class of general capability I was getting from a frontier model. The Ryzen was much slower, but the useful, polished, editable result was not obviously worse.

For the measured run, I gave Qwen3.8-27B exactly 131,072 input tokens and let it generate until the model chose to stop. CKE produced two complete technical SVGs containing 10,546 and 12,472 output tokens. They took hours, not seconds. Both ran locally, used about 50.65 GiB at peak, and exposed a much more interesting CPU-AI workload than a short chat benchmark.

Yesterday I wrote about how CKE added Qwen3.8 in roughly an hour. That post was about architecture and correctness: an explicit circuit, reusable kernels, generated C, and 4,000 rows of exact trajectory comparison with llama.cpp.

Today I wanted to see what that model could actually do on the Ryzen node.

I was not interested in asking it one short question and reporting a flattering tokens-per-second number. I gave it a real 128K technical context, asked it to synthesize that material into standalone vector documentation, and allowed it to continue until its own stop token. The result was not instant. The first run took about 3 hours and 12 minutes. The second took about 3 hours and 37 minutes. Both finished without a GPU and produced valid, self-contained SVG files.

That is the CPU-AI use case I care about. A local CPU does not have to beat every accelerator at interactive chat to be useful. It can work unattended on private context, use large system memory, produce an editable artifact, and leave behind enough profiling evidence to tell us what to optimize next.

What Ran On The Ryzen

The machine is the AMD node from the founder-funded CKE CPU lab:

• AMD Ryzen 9 9950X3D, Zen 5, 16 cores and 32 hardware threads.
• CKE pinned execution to physical CPUs 0 through 15.
• 64 GB of DDR5 memory.
• 4 TB NVMe active storage and 12 TB of model/archive storage.
• Qwen3.8 27B Dense in Q4_K_M GGUF form.
• A CKE v8 generated native C runtime using AVX-512/VNNI-capable providers.
• A 262,144-token runtime capacity, with exactly 131,072 prompt tokens used in each showcase run.

The model has 64 layers arranged as three recurrent DeltaNet-style layers followed by one full-attention layer. Its full-attention topology uses 24 query heads and 4 KV heads, so six query heads share each KV head. The hidden width is 5,120, head dimension is 256, and the model records a 64-dimension rotary section. Those values come from the generated runtime configuration, not from the prose inside the model-generated SVG.

CKE processed the logical 128K prompt through 32 physical prefill chunks of 4,096 tokens. The memory planner kept the persistent recurrent and KV state alive while reusing bounded scratch for each chunk. This is the same circuit-to-generated-C architecture described in the CKE architecture, IR pipeline, and deterministic memory documentation.

The Two Completed Runs

Qwen3.8 Also Mapped The CKE And llama.cpp Comparison

The new SVG below separates the matched repeated-token benchmark from the realistic-dossier generation run. Under the matched conditions recorded in the artifact, llama.cpp completed the 128K workload at 24.44 tok/s, CKE's baseline completed it at 31.21 tok/s, and the CKE FP32-pool variant reached 32.22 tok/s. The 32.66 tok/s dossier result is shown separately because it used a different input and is not a valid direct speedup claim.

The prefill number also needs context. The first 4,096-token chunk ran at about 47.78 tok/s. The final chunk ran at about 24.67 tok/s because the full-attention layers had much more prior context to scan. The complete 128K average was 32.63 tok/s. A single average hides the shape of long-context work, which is why CKE retained the per-chunk timings in the run record.

The Artifact Is More Interesting Than A Chat Response

The output was not a screenshot and it was not a raster image generated by another model. Qwen3.8 wrote the SVG markup itself: text, panels, arrows, equations, colors, labels and layout. The first document contains 157 SVG elements. The second contains 195. Both include an opening and closing SVG tag, parse as valid XML, contain no forbidden elements or external references, and can be edited like any other vector document.

Here is the first model-generated artifact exactly as it came from the run:

That correction is not a footnote I want to hide. The artifact gate proved that the model completed a valid standalone document. It did not prove that every technical statement inside the document was correct. The model had enough context to design a coherent infographic and still mixed in stale topology values. A human or an independent machine-readable validator must review the claims before the SVG becomes documentation.

The second output is visually very different:

The artifact workspace also contains this broader CKE systems synthesis:

I still consider these useful outputs. They provide a strong first visual draft, they show what the model understood, and their errors are inspectable because the output is plain SVG text. I can search the document, compare labels against the runtime configuration, patch it, or reject it. That is much better than treating an opaque image as unquestionable.

What The Profiles Found

The completed artifact is only half the experiment. The run also turned 128K execution into a profiling workload.

At long-context decode, CKE measured approximately 59 GB/s of DRAM reads and about 41.6 GB of traffic per generated token. The estimated minimum weight plus KV working traffic is about 26.1 GB/token. That leaves roughly 15.5 GB/token of additional movement to investigate rather than explain away.

AMD IBS sampling attributed approximately:

• 48.6% of sampled decode operations to FP16-KV attention.
• 35.6% to Q4 projection work.
• 7.5% to Q6 projection work.

The 9950X3D also made the cache problem unusually visible. Its 96 MB V-Cache CCD showed about a 58.3% L3 hit rate, while the 32 MB CCD showed about 22.2%. Both CCDs received nearly equal cache-request volume. This does not prove that L3 bandwidth is saturated. It does show that capacity, placement and reuse materially affect this workload.

Qwen3.8 Mapped Core Saturation And Scheduling

The next generated SVG turns the scheduler evidence into one view. It shows the two eight-core CCD domains, the 16 pinned physical workers, persistent worker timelines, dynamic tile queues, topology-weighted ownership, fixed-order reductions, and the different utilization shape observed between prefill and one decode diagnostic.

CKE's profiling workflow exists for exactly this reason. A working answer tells me the runtime can execute. Hardware counters and provider ledgers tell me where the bytes and cycles went.

The Next Attention Kernel Is Now Concrete

Qwen3.8 has 24 query heads and 4 KV heads. Six query heads therefore share one KV head. The current decode provider schedules work by query head and context chunk. At 128K context, that can cause the same K/V region to be traversed separately for each of the six related query heads.

The next candidate should schedule by KV head and context tile:

1. Choose one KV head and one context tile.
2. Load or prefetch that K/V tile once.
3. Process all six associated query heads while the tile is still useful in cache.
4. Keep six independent online-softmax accumulators.
5. Prefetch the next tile while computing the current tile.
6. Sweep 64, 128, 256 and 512-token tiles, then certify the winner against the existing numerical contract.

Why Distributed CPU Still Matters

At the current measured 41.6 GB/token, a balanced two-node split would assign roughly 20.8 GB/token of local work to each node before communication. That does not guarantee 2x speed. Reductions, synchronization, network latency, partition imbalance and duplicated state all reduce real scaling.

But it gives CKE ZIP a much clearer target. The objective is not to split the identity of the one decode token. It is to keep weight, head, KV, recurrent-state and MLP slices resident on their owning nodes for as long as the graph allows, then reduce only where the next operation mathematically requires a complete value.

Two matched Ryzen nodes with a low-latency fabric are the next serious experiment. The bandwidth-only ceiling can approach 2x, but the measured result will decide whether the architecture works. This is why the CPU lab, networking plan and single-node profiling are one research program rather than unrelated purchases.

What I Think This Result Means

Qwen3.8 at 1.4 decode tokens per second is not fast enough to declare CPU inference solved. It is fast enough to complete a 10,000 to 12,000-token structured artifact unattended in a few hours, on owned hardware, with a dense 27B model and a real 128K prompt.

That is useful to me today.

It also gives CKE a clean optimization ladder: reduce excess bytes per token, group GQA reuse, place work with cache topology in mind, prepare selected weights within an explicit memory budget, and then test persistent weight sharding across matched nodes. Every step has a number to beat and a correctness contract it is not allowed to break.

The more important point is that CPU AI should be measured by the work it completes, not dismissed because one workstation is slower than a rack of accelerators. A 16-core desktop CPU read 128K tokens, ran a dense 27B model, and wrote two substantial vector documents. One of those documents also reminded us why inspectability matters: impressive output can still contain wrong details.

CKE is trying to make both sides better. Run increasingly capable models on commodity CPUs, and make the circuit, memory, kernels, profiles and resulting artifacts inspectable enough that we can improve them honestly.