Inside the SpacemiT K3 Preview Paper: Homogeneous Fusion, X100 + A100, and What 60 TOPS Actually Means

SpacemiT has published a technical preprint on its second-generation AI CPU: “SpacemiT K3: A RVA23 RISC-V AI CPU with 60 TOPS AI Compute”, hosted as a PDF on the SpacemiT forum. The document is stamped “Preview Version” and dated 2026-01-29 — a vendor preprint, with its reference list still marked “TBD.” Our August 14 deep dive covered the product brief; the paper goes far beyond it, disclosing the X100 and A100 microarchitectures, the IME matrix-extension tiers, the Linux scheduling policy with AI-partitioned cores, and full benchmark tables. This article annotates the paper section by section.

Design Targets: 12 nm, <150 mm², 30 W

Section 2 of the paper frames K3 as a mass-production AI CPU for two form factors — AI computers and AI robots — converged into three hard constraints:

Under those constraints, the compute subsystem is fixed at 8× X100 cores (2 clusters) for 130K DMIPS of general-purpose throughput and 8× A100 cores (2 clusters) for 60 TOPS-class AI compute, plus system enablers: 2×32-bit LPDDR5 controllers, a UCIe interface, a dual-RT24 real-time design for motor-control and sensing tasks (the RT24 baseline core is openhwgroup’s CVA6, per the acknowledgements), and an AI-DMA engine the paper credits with reducing data-movement overhead and providing “controllable primitives for resource governance under multi-agent and multi-model concurrency.”

The Homogeneous-Fusion Paradigm

The paper’s central argument is architectural. Traditional edge-AI SoCs pair a host CPU running Linux with an accelerator that needs its own stack — which the paper describes as effectively running two largely identical Linux instances in one system, with duplicated memory/storage/resident services, cross-boundary IPC and data copies, and a multiplied version-patching-verification matrix. SpacemiT’s answer is homogeneous fusion: X100 and A100 are both RISC-V cores under a unified ISA and extension framework, run a single Linux OS, and are scheduled with ordinary threads/tasks as the unit — “one platform, one stack, and one operations surface.” The paper draws the obvious analogy: big.LITTLE gave smartphones performance and efficiency under one OS in the mobile era; homogeneous fusion targets performance plus AI throughput in the AI era, while “compressing the system fragmentation cost introduced by heterogeneity into a controllable range.”

AI compute is invoked in-process, in the same address space, at low overhead — the paper calls this eliminating the “heterogeneity tax” of driver round-trips and context switches.

X100: The RVA23 General-Purpose Core

X100 is a 4-wide, out-of-order application core whose starting point is openly stated: OpenC910, the open-source release of XuanTie’s C910. For general-purpose computing the paper says X100 introduces no proprietary ISA extensions — it implements all mandatory RVA23U64/RVA23S64 extensions and adds selected optional ones: vector cryptography (Zvkng, Zvksg, Zvbc) and the half-precision family (Zfh, Zvfh, Zfbfmin, Zvfbfmin, Zvfbfwma).

A100: The AI-CPU with 1024-bit Vectors and Two IME Tiers

A100 is the paper’s most interesting disclosure: an AI-centric RISC-V AI-CPU that keeps full RVA23 general-purpose functionality except the Hypervisor extension (AI workloads are dispatched exclusively to A100, so it has no virtualization role), but stretches the vector registers to VLEN 1024-bit (32 registers, v0–v31). Each A100 cluster is composed of four scalar cores, two vector cores, two local-memory banks and a shared L2; the two vector cores in a cluster share one Tensor Core and one local-memory bank.

The matrix capability comes in two tiers — the same IME extensions our September 17 MNN article benchmarks from the software side:

The paper is unusually candid about physical-design reality: closing timing on a VLEN=1024 datapath at 12 nm does not happen with default synthesis — the team partitioned register-file ports and bypass networks, retimed critical paths, and used floorplanning to bring the VLEN-1024 paths to 2.1 GHz PPA closure. A100 also adds custom FP8 (E4M3/E5M2) vector conversion instructions integrated into the pipeline; the paper notes RISC-V had no official OFP8 extension at K3’s design time and future cores will migrate once it is ratified.

The Tensor Core utilization math

Section 3.2.2 works an INT8→INT32 MMA microkernel (M=N=8, K=16 → 1024 MACs per instruction) to show why the shared-Tensor-Core arrangement works: a single core without tiling reaches 50% MAC utilization (operational intensity 8 MAC/byte); register blocking with 16 vector registers held for C-tiles at (rₖ, rₗ)=(2,4) lifts intensity to ≈10.67 MAC/byte at 66.7% utilization; and with two cores streaming loads in parallel, the shared MAC engine saturates to 100%. Local-memory capacity was sized via a performance–cost Pareto sweep over CNN/LLM/ViT workloads — the paper says the selected knee point was Qwen-30B-A3B, prioritizing working-set residency for 30B–80B-scale model inference. Main-memory design follows Little’s Law with a cluster-level in-flight window of ≈100 and asymmetric borrowing between cores.

Scheduling: One SMP Linux, Two Explicit Domains

All 16 cores appear to the Linux kernel as a single SMP system with a unified 16-core logical view. But the policy is explicitly partitioned: the 8 A100 cores are AI-dedicated and excluded from general-purpose handling. User threads bind to X100 (CPU0–7) by default and are never migrated onto A100, even when X100 saturates; AI threads must be bound to A100 (CPU8–15) after creation and stay there for their lifetime. The stated reason is sound — a general-purpose thread scheduled onto an A100 core (which implements only an AI subset of instructions and a different VLEN state) would fault, and vector contexts must not migrate across mismatched VLEN domains.

The paper then honestly lists the costs of its own policy: load balancing is not optimal (A100 can idle while X100 is saturated), migration constraints complicate the scheduler, the current implementation modifies Linux kernel code in ways that are hard to upstream, and developers must understand hardware-aware scheduling to optimize. The proposed fix, under exploration, moves the partition into a cpuset-based user-space configuration: CPU0–7 as the default domain, CPU8–15 as an AI-exclusive domain that only tasks explicitly labeled as AI may enter.

Software Stack: ONNX Runtime + a Tile-Level Triton Compiler

The AI stack runs on Linux on top of A100 and is deliberately pragmatic: hand-tuned operator kernels first, compiler generation second. Today’s implementation is an inference engine based on ONNX Runtime with a private backend, alongside a tile-based Triton operator compiler, sharing one runtime with unified threading and memory optimization. Operator-library APIs are aligned with MLIR meta-op definitions and exposed as a C API so the compiler pipeline could be exercised before full IR-based codegen existed.

In the runtime abstraction, every operator — convolution, GEMM, Triton-compiled kernels — is scheduled at A100-cluster granularity, which maps to a group of four A100 Linux threads; two clusters form two groups (eight A100 Linux threads total), a design the paper compares to CUDA multi-stream execution. The X100 runtime dispatches tile-level tasks to the least-loaded cluster. (This is the same Triton-on-K3 direction that SpacemiT’s upstream report documented in our September 5 article — the Triton-spacemit backend is now merged into FlagOS FlagTree.)

Every Published Benchmark Table, Annotated

SPEC CINT2006 — and what KVM costs

Measured at a fixed 2.4 GHz with LPDDR5 (paper §5.1): X100’s single-core SPEC CINT2006 geomean is 22.88. Under virtualization (LPDDR5-6400), the geomean drops 5.48% to 21.62, with per-benchmark losses from 0.1% to 16% — worst where two-stage page-table walks hurt most: 429.mcf −16.5%, 471.omnetpp −10.5%, 403.gcc −10.0%; nearly untouched: 456.hmmer −0.14%, 462.libquantum −2.6%. The paper attributes the pattern to extra guest-physical→host-physical translation on TLB misses.

Vector Crypto: GHASH 46.6×, AES ~14×, ChaCha20 barely moves

Using OpenSSL’s speed normalized to scalar baseline at 16,384-byte messages (paper Table 6): GHASH 46.6× (the vghsh instruction completes an iteration in 3 cycles), aes-128-cbc 13.9×, aes-256-cbc 13.7×, sha256 10.5×, hmac(sha256) 10.2×, SM4 6.2×, SM3 2.6×, sha512 2.3× — and chacha20 only 2.1×, because shift/add-dominated ciphers have little acceleration potential; the paper says ChaCha20 only pulls ahead at >64 KB blocks.

Memory bandwidth and CNN throughput

Decode-phase LLM performance is bandwidth-dominated, so the paper measures thread-sharded multi-stream sequential reads on A100’s main-memory path: the baseline reaches 10,139 (test-setup units), rising to 33,226 — 3.28× — with the optimization knobs enabled, explicitly labeled “not final peak performance.” The 1024-bit vector file is pitched as a 4 KB scratchpad: norm-style broadcasts hold the whole scale vector on-chip for C<512; FlashAttention’s V·QK accumulation stays resident in 2–4 registers; and LMUL=1 at VLEN=1024 replaces VLEN=256/LMUL=4 without register spills. Typical CNN numbers (fps, paper Table 8): ResNet50 52 → 129 → 165 (batch1/thread1 → batch1/thread4 → batch2/thread4), RepVGG 207 → 451 → 570, YOLOv8s 9 → 31 → 44.

What to Verify and What Remains Open

• It is a preview preprint. Dated 2026-01-29, references marked TBD, with several results (memory bandwidth knobs, distributed inference, cpuset scheduling) explicitly described as in-progress. Treat numbers as engineering targets disclosed by the vendor, not audited results.
• “60 TOPS” = INT4 sparse. Dense INT4 is 30 TOPS; BF16/FP16 and FP8 are 7.5 TOPS. Any comparison against other NPUs must normalize precision and sparsity first.
• No board-level power/thermal data appears in the paper; the 30 W TDP is a design constraint, not a measured platform figure. The K3 Pico-ITX board (our August 15 overview) is where platform-level numbers will surface.
• Scheduling is evolving. The kernel-modification approach described as current is slated to move to cpusets; until then, AI-thread placement behavior depends on the Bianbu OS build you run.
• A100 omits the Hypervisor extension by design. Anything expecting to run VMs on all 16 cores will be disappointed — virtualization is an X100-only capability (up to 7 VMs per core).

Where This Sits in the K3 Story

The paper is the architectural counterpart to a busy year of K3 ecosystem news: RVA23 compliance analysis (July), the flagship product deep dive (August 14), the Pico-ITX board (August 15), upstream kernel/Triton/llama.cpp progress (September 5), MNN W4B64 benchmarks (September 17), and deepin 25’s Next(RVA23) toolchain port with IME backport (September 16). What the preview paper adds is the “why” layer: why one OS instead of two, why 1024-bit vectors on an AI-CPU instead of a separate NPU, and why the scheduling partition looks the way it does. For teams evaluating K3 for edge-AI products — including the K3 modules and boards in our catalog — it is the single most substantive primary source published so far.