The SpacemiT K3: RISC-V Finally Competes, and the Vendor Kernel Gets in the Way

A.C. Jokela — Fri, 25 Sep 2026 13:00:00 GMT

Every RISC-V board I have reviewed here has needed an excuse. The Pine64 Star64 compiles Rust slower than a quad Cortex-A53 from 2012. The MangoPi MQ Pro takes two hours and ten minutes to do what a Raspberry Pi 5 does in seventy-seven seconds. The Orange Pi RV2 spends eight cores losing to four. The reviews all end the same way: buy it because it is RISC-V, not because it is good.

The SpacemiT K3 Pico-ITX does not need that excuse. It compiles the benchmark in 161.80 seconds, which puts it seventh of thirteen boards on my bench and ahead of the Banana Pi CM5-Pro. It pushes 2,372 MB/s of AES-128-GCM, beating the Cortex-A76 in a Rockchip RK3588. On SHA-512 it is 1.72x faster than that A76. A single SpacemiT X100 core scores 94% of an A76 on sysbench.

This is the first RISC-V machine I have tested that competes on the merits.

It also cost \$1,175.09 delivered, cannot schedule a single job across more than 8 of its 16 cores, and cannot run a virtual machine at all, which is the specific thing I bought it for.

"RVA23 Profile Chip" on the box is the part that matters. RVA23 is the RISC-V application profile that mandates the vector extension and the vector crypto suite, which is exactly why this board's ISA string is so much richer than every other RISC-V machine on my bench.

What it cost

I am putting this near the top because every other review of frontier RISC-V hardware buries it.

The board was \$889 for the 32 GB RAM and 128 GB storage configuration, \$45 shipping, and then \$241.09 in customs duty collected by DHL four days later. That duty is 27.1% on top of the order and appears on no spec sheet or product page.

Origin HKG, shipped by Firefly Technology out of Tsing Yi. Declared contents: "plastic main board for to drive display", 0.85 kg. That declaration is what the \$241.09 got assessed against.

A Raspberry Pi 5 with 8 GB currently sells for around \$200 on Amazon, not the \$80 I quoted in older reviews here. So the honest multiple is roughly 5.9x the price for a board with four times the RAM, twice the cores on paper, vector crypto, PCIe, an NVMe slot and a hypervisor extension. It is not a \$1,095 difference in value, but it is also not the 15x gouging that a stale MSRP comparison would suggest.

The hardware

Pico-ITX, under the acrylic cover it ships with. Two M.2 slots, a coin-cell RTC, an eDP header, and MAC address stickers on the right.

The port edge: two USB-C, four USB-A, gigabit Ethernet, and an SFP cage on the right. Only the gigabit port had a link during testing.

Component	Specification
SoC	SpacemiT K3
CPU	16 cores enumerated: 8x Spacemit X100 @ 2.2 GHz, 8x Spacemit A100 @ 1.8 GHz
ISA	`rv64imafdcvh` plus Zba/Zbb/Zbc/Zbs, V (vector, `vlen:256`), H (hypervisor)
Vector crypto	Zvkned, Zvknha, Zvknhb, Zvksed, Zvksh, Zvkg, Zvbb, Zvbc
RAM	32 GB
Storage	119 GB onboard UFS, plus an NVMe slot
GPU	PowerVR B-Series BXM-4-64 MC1, DRM nodes present
Network	Gigabit, link up on `end0`
OS as shipped	Bianbu 4.0.4, kernel 6.18.3-generic

That ISA string is the most complete of any RISC-V board I have tested, and by a wide margin. Every previous one was rv64imafdc with nothing above baseline. This one has vectors, bit manipulation, the full vector crypto suite, and the hypervisor extension.

I parsed it with the rv64 prefix stripped before matching single letters, because a naive substring search finds the v in rv64 and reports a vector unit that is not there. That mistake cost me an hour on the Star64.

As shipped, plus the NVMe I added. Note the sixteen cores it reports, and hold that thought.

Compiling Rust

The workload is a clean release build of ballistics-engine, three runs after cargo clean, in two tiers: the pinned tree at commit 2821bba that every archived fleet result used, and current HEAD at b0cfcd4.

Pinned tier (2821bba, 16,639 LOC, 144 crates):

Run	Time
1	160.68 s
2	162.41 s
3	162.30 s
Mean	161.80 s (sigma 0.97, 0.60% CV)

HEAD tier (b0cfcd4, 155,867 LOC, 243 crates):

Run	Time
1	1271.27 s
2	1273.18 s
3	1271.06 s
Mean	1271.84 s (sigma 1.16, 0.09% CV)

A 0.09% coefficient of variation across three twenty-one minute builds is the tightest result on my bench. Nothing on this board wobbles: the governor is userspace pinned at maximum, both clusters hold their clocks, and there is no thermal headroom being negotiated.

Left: the pinned-tree fleet. The K3 appears twice because its two clusters are, in practice, two separate eight-core machines. The MangoPi MQ Pro is omitted at 7,824 s, which is 48x the next slowest board and would flatten the chart. Right: single-thread crypto throughput, linear scale, three platforms.

The generational comparison is the cleanest number here. The Orange Pi RV2 runs SpacemiT's previous Ky X1 and takes 650.60 s on the same tree with the same rustc 1.98.1. The K3 does it in 161.80. That is 4.02x faster from the same vendor, one generation later.

Against ARM it is a tie rather than a win. 161.80 s versus the Banana Pi CM5-Pro's 167.15 s is a 3% margin, which I would not defend as a victory. But a RISC-V board landing within noise of an eight-core ARM part is new.

Cryptography, where it actually wins

Single-thread OpenSSL 3.5.5, 16 KB blocks:

Algorithm	SpacemiT K3	RK3588 Cortex-A76	Pine64 Star64	vs A76	vs Star64
AES-128-GCM	2372.7	2185.7	21.7	1.09x	109x
AES-256-GCM	1853.0	1763.9	17.9	1.05x	104x
SHA-256	1520.6	1429.4	35.4	1.06x	43x
SHA-512	646.8	376.1	63.5	1.72x	10x
AES-128-CBC	1622.7	1831.8	31.4	0.89x	52x
ChaCha20-Poly1305	372.4	674.4	51.0	0.55x	7x

A RISC-V board beating a Cortex-A76 on AES-GCM, SHA-256 and SHA-512 has not happened before on this bench.

Isolating the extensions makes the mechanism obvious. Restricting OPENSSL_riscvcap to plain rv64gc disables the vector crypto fast paths:

Algorithm	Full detection	`rv64gc` only	Gain
AES-128-GCM	2373.3 MB/s	68.8 MB/s	34.5x
AES-256-GCM	1854.3 MB/s	56.7 MB/s	32.7x
SHA-256	1520.0 MB/s	146.1 MB/s	10.4x
SHA-512	646.8 MB/s	270.6 MB/s	2.4x

Strip the extensions and this board performs like every other RISC-V machine I have tested. That 68.8 MB/s figure is in the same league as the Star64's 21.7. The silicon is not what changed; the instruction set is.

The two losses are informative rather than embarrassing. Zvkned and Zvknh accelerate AES and SHA specifically, so ChaCha20 gets nothing from them and falls behind a chip whose general SIMD is better tuned in OpenSSL. If you are terminating TLS on this board, prefer AES-GCM, which is the opposite of the advice I gave for the Star64.

Asymmetric work is unremarkable: RSA-2048 at 245 signs/s, ECDSA P-256 at 4,437 signs/s. Nobody accelerates those in silicon here.

You get eight cores at a time, never sixteen

This is the finding that changes how you should read every number above. I got it wrong twice before I got it right, so here is the whole path.

/proc/cpuinfo lists sixteen processors. Eight report model name: Spacemit(R) X100 and eight report Spacemit(R) A100, with distinct marchid and mimpid values. The boot log says smp: Brought up 1 node, 16 CPUs. The possible, present and online masks all read 0-15.

And then:

nproc                          : 8
PID 1 Cpus_allowed_list        : 0-7
taskset -c 8 <anything>        : failed to set affinity: Invalid argument
cpu8 jiffies after a 3s burn   : 0
cpu0 jiffies after a 3s burn   : 301

My first reading was that the vendor kernel was hiding half the machine. My second reading, after actually looking up what an A100 is, was that the A100 cluster is a 60 TOPS AI engine that merely happens to be built from RISC-V harts, so nproc returning 8 is correct and there is nothing to complain about.

Both readings are wrong, and the truth is more annoying than either.

The A100 cores are reachable. You write a PID to /proc/set_ai_thread, which is world-writable, and that thread's affinity mask flips from 0-7 to 8-15. The setting is inherited by children, so it is enough to do it once in a shell and then run whatever you like. taskset works normally afterwards, within the new mask. That is why plain taskset -c 8 fails as root: the affinity mask is not the door, but there is a door.

And once you are through it, the A100 cores run ordinary code perfectly well. Not AI kernels. Not vector math. rustc.

Rust clean release build, pinned tree 2821bba, cargo -j8, n=2:

  X100 cluster (cpu0-7,  2.2 GHz) : 161.58 s, 161.00 s   mean 161.29 s
  A100 cluster (cpu8-15, 1.8 GHz) : 344.32 s, 341.23 s   mean 342.78 s

The A100 cluster compiles the same tree 2.13x slower than the X100 cluster. Correct for the 2.2 versus 1.8 GHz clock difference and the A100 cores land at 57.5% of X100 per-clock throughput. sysbench, a completely different workload, puts the same figure at 57.4% (428 events/s against 912 single-threaded, 3,430 against 7,245 across eight). Two unrelated benchmarks agreeing to a tenth of a point is about as solid as this kind of measurement gets.

So these are not accelerator lanes that cannot run general code. They are eight real, if unexceptional, RISC-V application cores, roughly 57% the per-clock performance of the big ones, that SpacemiT has tuned for AI work by giving them 1024-bit vectors instead of the X100's 256-bit.

Here is the actual problem. You cannot have both clusters at once. After opting in, taskset -pc 0-15 fails:

taskset: failed to set pid 56055's affinity: Invalid argument
pid 56055's current affinity list: 8-15

0-7 or 8-15. Never 0-15. No process on this machine can be scheduled across all sixteen cores, so no single job can use the whole chip. That is why the compile pinned to cpu0-7 finished in 161.14 s against 161.80 s for the nominally sixteen-core run: the nominally sixteen-core run was always an eight-core run, because sixteen-core runs do not exist here.

What that costs is easy to bound. Summing the two clusters' throughput puts a hypothetical combined build at about 110 seconds, roughly 1.47x faster than the X100 cluster alone. Treat that as a ceiling rather than a prediction, because this build's serialised LTO link would eat into it and cross-cluster scheduling on a chip this asymmetric is not free. But the gap between 161 s and something near 110 s is real compute, sitting in the same coherence domain, fenced off by software.

I am not sure whether the fence is deliberate product design, a limitation of the vendor scheduler patches, or a hardware constraint I cannot see from userspace. SpacemiT's marketing splits the chip into "130K DMIPS of general-purpose compute and 60 TOPS of AI compute", which suggests they think of the two clusters as separate products that happen to share a die. That is a defensible way to build a chip. It is a poor way to describe one, because nothing on the board, in fastfetch, or in the shipped OS tells you any of this. You find out by pinning a compile to cpu8-15 and getting a 0.016 second result.

The one A100 claim I still cannot check is the interesting one: SpacemiT's IME2 llama.cpp build reportedly puts the A100 cluster ahead of X100 on token generation, which is the entire point of those 1024-bit vectors. That needs their runtime and a proper model, and it belongs in its own piece.

Geekbench makes the same mistake I made first, which is some comfort. I uploaded a run as Geekbench 7 result 466791: 363 single-core, 2019 multi-core under Geekbench 7.0.0 Preview for Linux RISC-V. Its system panel reports "1 Processor, 16 Cores", labels the whole chip Spacemit(R) X100, and then gives up with "Cluster 1: 0 Cores". That is detection logic meeting a topology it has no model for.

The scores contradict the topology it printed. Multi-core comes in at 5.56x single-core, and the Clang subtest at 6.43x. Those are eight-core scaling factors, measured on the eight cores Geekbench was allowed to touch.

The benchmark's own blind spot

While measuring this I found a flaw in my own workload that applies to every board I have tested.

The project's release profile sets lto = true and codegen-units = 1, which forces the final crate through a single-threaded link. Parallel efficiency on the K3 falls from 46% on the pinned tree to 22% on HEAD, because HEAD's final crate is much larger and the serial portion grows faster than the parallel one.

That penalises wide machines. A four-core board loses little to a serial link; an eight or sixteen-core board idles through it. Every board ran the identical profile so the fleet numbers remain comparable to each other, but they measure "compile this specific LTO-heavy project" rather than general compile throughput. The K3 is the first machine wide enough to make that visible, and I should have caught it sooner.

Thermals, memory, storage

Nothing dramatic, which is itself worth reporting.

Seven thermal zones sit at 51 to 56 C idle. Under 120 seconds of sixteen-worker stress-ng the hottest cluster peaked at 65 C and both clusters held full clock throughout. No throttling.

The reason the thermal numbers look good: an aluminium heatsink with an integrated blower fan, bolted to the board. No other RISC-V board in this comparison ships with active cooling.

Worth being precise about why: this board is actively cooled. It ships with a substantial aluminium heatsink and a blower fan bolted to the underside, which is not something any other RISC-V board in this comparison has. Holding 65 C under full load is a good result, but it is a good result with a fan, not in spite of having none.

Memory measured 32,468 MB/s read and 23,768 MB/s write. The onboard UFS does 903 MB/s buffered read via hdparm, 238 MB/s write and 932 MB/s read by dd.

I also fitted a WD_BLACK SN850X 2 TB in the NVMe slot, which does 1.0 GB/s write and 2.1 GB/s read. That is a different universe from the microSD-bound RISC-V boards I have reviewed, where the Star64 managed 22.4 MB/s because its controller never leaves SD high-speed mode.

KVM is broken

I bought this board to run virtual machines. Thirty-two gigabytes of RAM and a hypervisor extension is a credible small virtualization host, and RISC-V finally having RVH 1.0 with AIA and an IOMMU is the reason to care about the K3 over anything else on this list.

It does not work.

The ISA string advertises h. The kernel ships CONFIG_KVM=m. Loading the module produces a kernel oops:

Unable to handle kernel paging request at virtual address ffffffff81a0f1c0
Oops [#1]
CPU: 5 UID: 0 PID: 55989 Comm: modprobe Not tainted 6.18.3-generic #1.0.5.4
Hardware name: SpacemiT K3 Pico ITX (DT)
epc : jump_label_module_notify+0x1de/0x368
      load_module+0x15d4 -> blocking_notifier_call_chain_robust -> notifier_call_chain

The fault is in the static-key relocation path during module load, so /dev/kvm is never created and no virtual machine can start. This is a software defect in Bianbu's kernel build, not a hardware limitation: SpacemiT's own materials describe RVH 1.0, AIA and IOMMU support, and K3 KVM work has been landing upstream.

Do not buy this board expecting to run VMs on the image it ships with.

Who this is for

Buy it if you are doing RISC-V platform work and need real hardware that does not make you wait: a build machine, a CI runner, a place to port and profile software where the compile times are tolerable and the crypto is genuinely fast. On those terms it is the first RISC-V board I would actually choose rather than tolerate.

Do not buy it if you want the virtualization host its spec sheet promises, at least not yet, and not on Bianbu. Do not buy it as a compile box either: a \$200 Raspberry Pi 5 does the same tree 2.11x faster, and nothing here changes that. The case for the price is the 32 GB of RAM and the 60 TOPS AI engine, and this review tests neither.

The honest summary is that SpacemiT built genuinely competitive silicon and shipped it with a kernel that cannot load KVM. The hardware is ready. The software is not, and the documentation is worse than the software.

What is broken, restated plainly

Because these are the things that will cost you time if you buy one:

KVM does not work on the SpacemiT-provided kernel. modprobe kvm oopses in jump_label_module_notify on Bianbu 4.0.4 with kernel 6.18.3-generic #1.0.5.4. The hardware supports RVH 1.0; the shipped kernel cannot use it. If virtualization is why you are buying this board, you cannot use the image it arrives with.
No process can use more than 8 of the 16 cores. The A100 cluster is reachable by writing a PID to /proc/set_ai_thread, and those cores run ordinary code at 57.5% of X100 per-clock throughput. But the mask is 0-7 or 8-15, never 0-15, so the whole chip is never available to one job. Every other benchmark here was produced by the eight X100 cores.
A newer BSP kernel did not help. I installed 6.18.3-1.0.8.4 from the porting repo and tried to boot it with kexec. The board did not come back and needed a power cycle. Notably, kexec also failed with a kernel that unquestionably has full K3 support, which suggests kexec itself is unreliable on this vendor firmware rather than the kernel being at fault.
Ubuntu's generic 7.0.0 kernel is not a workaround. It carries one spacemit config entry against the BSP's sixty-six, ships no K3 device trees, and lacks the dwmac-spacemit-ethqos driver this board's network port needs. Booting it would produce an unreachable machine.
The customs duty is real. \$241.09 on a \$934 order, payable on delivery.

A follow-up is coming

Canonical officially supports the SpacemiT K3 starting with Ubuntu 26.10 "Stonking Stingray", and that is the interesting thread to pull. The supported path replaces SpacemiT's U-Boot with EDK2 UEFI firmware, flashed over fastboot with the board in FDL mode, and then installs Ubuntu from a USB stick.

The reason I think it will matter: Ubuntu 26.10 ships kernel 7.3.0, and the mainline SpacemiT device tree pull request that adds K3 support was titled RISC-V SpacemiT Devicetrees for v7.3. That is the first kernel where this board's support is upstream rather than carried in a vendor tree. It is the obvious candidate to fix the KVM oops, which is a kernel-side failure rather than a silicon one.

I have the 26.10 daily image written to a USB stick and the flashing procedure mapped out. The next piece will cover whether official Ubuntu turns this from a fast compile box into the virtualization host it was supposed to be, and whether a mainline kernel lets one process schedule across all sixteen cores instead of eight.

By the numbers:

Rust clean release build, pinned tree (2821bba, 16,639 LOC): 161.80 s mean, 7th of 13 on my bench
Rust clean release build, current tree (b0cfcd4, 155,867 LOC): 1271.84 s mean, 0.09% CV
vs SpacemiT's own previous generation: 4.02x faster than the Ky X1 in the Orange Pi RV2
Single X100 core: 911 sysbench events/s, 94% of a Cortex-A76 at 2.35 GHz
Geekbench 7: 363 single-core, 2019 multi-core (result 466791)
AES-128-GCM 2372.7 MB/s, ahead of a Cortex-A76 and 109x the Pine64 Star64
Vector crypto contribution: 34.5x on AES-128-GCM, 10.4x on SHA-256
Cores usable by one process: 8 of 16, either cluster but never both
A100 cluster on the same compile: 342.78 s against X100's 161.29 s, 57.5% of X100 per clock
KVM: broken, kernel oops on module load
Thermals: 51 C idle, 65 C peak under sixteen-worker load, no throttling
NVMe: 1.0 GB/s write, 2.1 GB/s read
Cost: \$1,175.09 delivered, including \$241.09 customs duty

Caveats. Every figure except the A100 compile and sysbench runs comes from the eight X100 cores. The A100 numbers are n=2 on the compile and single runs on sysbench. I did not test the A100 cluster on AI workloads at all, which is what it exists for, so its 60 TOPS rating remains SpacemiT's number rather than a measurement of mine. The compile workload uses lto = true and codegen-units = 1, which serialises the final link and understates wide machines. Commit 2821bba predates the project having a Cargo.lock, so dependency versions resolve fresh. Network throughput was not measured. The sysbench comparison against the Cortex-A76 uses version 1.0.20 on both boards; the Star64 shipped 0.4.12 and its sysbench figures are not comparable to either.

Review Date: September 25, 2026

Hardware Tested: SpacemiT K3 Pico-ITX, 32 GB RAM, 128 GB UFS, WD_BLACK SN850X 2 TB NVMe added

OS Tested: Bianbu 4.0.4, kernel 6.18.3-generic #1.0.5.4

Benchmark Workload: ballistics-engine clean release builds at commits 2821bba and b0cfcd4, rustc 1.98.1

Conclusion: The first RISC-V board that competes with ARM on performance rather than on novelty, sold at a price that is defensible only if you need what it uniquely offers, and shipped with a kernel that disables half its cores and cannot start a virtual machine.

TinyComputers.io (Posts about spacemit x100)