
SpacemiT K3 is an upcoming RVA23-compliant 64-bit RISC-V processor based on X100 cores clocked at up to 2.5 GHz. So far, we had limited information, but SpacemiT gave remote access to one SpacemiT K3-powered server to Sander, and he was kind enough to share some system information and early benchmarks.
Let’s start with system information reported by inxi utility:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
superkoning@spacemit:~/CNX$ inxi -Fc0 System: Host: spacemit Kernel: 6.12.16-generic arch: riscv64 bits: 64 Console: pty pts/0 Distro: Ubuntu 26.04 (Resolute Raccoon) Machine: Message: No machine data: try newer kernel. Is dmidecode installed? Try -M --dmidecode. CPU: Info: 16-core model: Spacemit X100 variant: riscv bits: 64 type: MCP cache: L2: 10 MiB Speed (MHz): avg: 2200 min/max: 614/2400:2000 cores: 1: 2200 2: 2200 3: 2200 4: 2200 5: 2200 6: 2200 7: 2200 8: 2200 9: 2200 10: 2200 11: 2200 12: 2200 13: 2200 14: 2200 15: 2200 16: 2200 Graphics: Device-1: saturn-edp driver: spacemit_drm_drv v: N/A Display: server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.8 driver: N/A tty: 211x41 API: EGL v: 1.4 drivers: swrast platforms: surfaceless,device API: OpenGL v: 3.3 vendor: mesa v: 24.0.1 note: console (EGL sourced) renderer: softpipe API: Vulkan Message: No Vulkan data available. Info: Tools: api: eglinfo, glxinfo, vulkaninfo x11: xdriinfo, xdpyinfo, xprop, xrandr Audio: Message: No device data found. API: ALSA v: k6.12.16-generic status: kernel-api Server-1: PipeWire v: 1.4.9 status: active Network: Device-1: k3-gmac driver: dwmac_spacemit_ethqos IF: end1 state: up speed: 1000 Mbps duplex: full mac: fe:fe:fe:c6:37:53 Device-2: rfkill-gpio driver: rfkill_gpio Device-3: dwmac-5.10a driver: N/A IF: can0 state: down mac: N/A Device-4: dwmac-5.10a driver: N/A IF: end1 state: up speed: 1000 Mbps duplex: full mac: fe:fe:fe:c6:37:53 Device-5: dwmac-5.10a driver: N/A IF: can0 state: down mac: N/A Drives: Local Storage: total: 178.85 GiB used: 57.12 GiB (31.9%) ID-1: /dev/nvme0n1 model: 128GB SSD size: 119.24 GiB ID-2: /dev/sda model: KLUCG2U1DC-B0F1 size: 59.61 GiB Partition: ID-1: / size: 116.39 GiB used: 57.08 GiB (49.0%) fs: ext4 dev: /dev/nvme0n1p3 ID-2: /boot size: 223.7 MiB used: 44.4 MiB (19.9%) fs: ext4 dev: /dev/nvme0n1p2 Swap: Alert: No swap data was found. Sensors: System Temperatures: cpu: 413.8 C mobo: 395.6 C Fan Speeds (rpm): fan-1: 82 Info: Memory: total: N/A available: 31.38 GiB used: 1.02 GiB (3.3%) Processes: 305 Uptime: 2d 17h 12m Init: systemd Shell: Bash inxi: 3.3.40 |
What we have here is a 16-core SpacemiT X100 processor clocked at up to 2400 MHz, close enough to the 2.5 GHz advertised last year. It features 32 GB RAM, a 128 GB NVMe SSD, and a 64 GB UFS 2.2 flash device (KLUCG2U1DC-B0F1), and two Gigabit Ethernet ports. It runs recent software, namely Ubuntu 26.04 with Linux 6.12. Note that Ubuntu 25.10 and greater require an RVA23-compliant SoC, which the K3 provides. On the graphics side, the saturn-edp driver implies an embedded DisplayPort (eDP) display interface often used for display in laptops, and there’s no 3D hardware graphics acceleration (softpipe).
Something is clearly wrong with temperature reporting, but some other sensors return plausible temperatures:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
superkoning@spacemit:~$ sensors ctf2301-i2c-6-4c Adapter: spacemit-i2c-adapter fan1: 82 RPM temp1: +398.8°C temp2: +418.8°C pwm1: 100% (freq = 7826 Hz) thermal_6-virtual-0 Adapter: Virtual device temp1: +63.0°C thermal_4-virtual-0 Adapter: Virtual device temp1: +62.0°C thermal_2-virtual-0 Adapter: Virtual device temp1: +65.0°C thermal_0-virtual-0 Adapter: Virtual device temp1: +60.0°C thermal_7-virtual-0 Adapter: Virtual device temp1: +62.0°C thermal_5-virtual-0 Adapter: Virtual device temp1: +60.0°C thermal_3-virtual-0 Adapter: Virtual device temp1: +61.0°C thermal_1-virtual-0 Adapter: Virtual device temp1: +63.0°C |
Let’s add lspci output to see if we can find more devices:
|
1 2 3 4 |
superkoning@spacemit:~$ lspci 0000:00:00.0 PCI bridge: SpacemiT Device 0002 (rev 01) 0000:01:00.0 Non-Volatile memory controller: Silicon Motion, Inc. SM2263EN/SM2263XT (DRAM-less) NVMe SSD Controllers (rev 03) 0004:00:00.0 PCI bridge: SpacemiT Device 0002 (rev 01) |
Not much here.
Sander also ran sbc-bench.sh for us:
|
1 |
Note that those should be considered early benchmarks, as while 16 cores are detected, only eight cores were used when running 7-Zip or stress-ng, or when compiling a Linux kernel with “-j 30”.
With eight cores running, the SpacemiT K3 offers better performance than a Rockchip RK3588 SBC in 7-Zip. Here are charts showing a comparison between the K3, a Radxa Rock 5B (RK3588), a Raspberry Pi 5, and an Orion O6 mini-ITX motherboard (12-core CIX P1 Armv9 CPU).
The SpacemiT K3’s memory bandwidth looks to be on the low side and only a little better than a Raspberry Pi 5, while multi-core performance, as measured with 7-Zip, is slightly better than a Rockchip RK3588. aes-256-cbc performance (single-core) is quite low at 869,520.73k, as for instance, the Raspberry Pi 5 delivers 1,367,736.32k at the same CPU frequency. It looks specific to this workload, as single-core 7-Zip is 3136 MIPS for the Pi 5, and 2736 MIPS for the X100 core, still lower, but not quite as dramatic. You can find more details in the sbc-bench.log file. You’ll also find additional details on Sander’s GitHub repo, including the kernel log, coremark benchmark, and so on.
So far, the SpacemiT K3 delivers significant improvements over other RISC-V SoCs, but it does not offer amazing performance compared to existing Arm SoCs, being slightly better than a Rockchip RK3588 SoC. Pricing will determine whether it offers value, which has not been great for RISC-V platforms to date. One issue is the relatively low volumes of RISC-V SoCs, as South China Morning Post reports that the earlier SpacemiT K1 octa-core RISC-V SoC shipped over 150,000 units, which is not a whole lot. I’d expect the situation to improve over time, as RISC-V software becomes more mature, and mass production ramps up to higher volumes in the millions of units.

Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.





[ the SpacemiT K1 SoC ‘https://www.cnx-software.com/2024/04/30/muse-book-laptop-spacemit-k1-octa-core-risc-v-ai-processor-16gb-ram/#spacemit-k1-soc-specifications’ has a 3-5W TDP (thx) ]
Very interesting info. Wonder if that behavior during actual testing only utilizing eight cores is an indication the SOC is actually a 2x 8-core cluster die. They should release some early samples as CM4 compatible modules for early adopters. But even better news at least they started mainline linux support early: https://lkml.org/lkml/2025/12/22/718
On X, Sipeed is teasing with possibly a Spacemit K3 board.
“A New #RISCV Beast Arrives Next Week.”
https://x.com/SipeedIO/status/2014250732120154306
It’s the RVA23 designation that attracts me as, if I’ve understood it correctly, it means that generic Linux images ought to work.
Same sort of performance as a RasberryPi5? Fine for what I need. And I guess there will be some optimisations down the line.
I was worried about those temperature readings though…
It will cannibalize milkv titan
gonna come down to price differential between the two before that’s a given.
Dozens of sales will be lost.
this is made in China or by Samsung/TSMC?
Can 8 cores be the NPU ? that would be a waste…
Anyway with this RISCV is ready to compete with ARM !
(even i dont know yet the power consumption)
*even if
What ? no GPU ? seriously ?
All full-blown RISC-V-cores, with the first 8 cores as extra “h” = Hypervisor.
See https://github.com/sanderjo/SpacemiT-K3-X100-A100/blob/main/proc-cpuinfo.md
> RISCV is ready to compete with ARM !
You can still hold your breath: https://github.com/sanderjo/SpacemiT-K3-X100-A100/blob/main/pystone.md
In this python benchmark, it runs as fast as a 2017 core i5 running at 800 MHz… I tried here on my arm machines:
Q6A: This machine benchmarks at 431846 pystones/second
Orion-O6: This machine benchmarks at 589568 pystones/second
So basically for now these cores run this test 4 to 5 times slower than commonly available ARM cores. Sure it’s getting better, but they’re still quite far from making ARM shiver, given that the whole machine with all these watts would only be 1/3 of the perf of a tiny fanless board on this test…
This board will simply help RISC-V developers develop natively a bit faster (because previous chips were horribly slow, anybody who tried to compile on vf2 remembers it).
Arm’s been “shivering” since 2019, when they put out that controversial press realease disparaging RISC-V for its modularity.
Some observers are predicting performance parity as soon as the end of this year –
“The performance gap between high-end Arm and RISC-V CPU cores is narrowing and a near parity is projected by the end of 2026,” said Richard Wawrzyniak, principal analyst for ASIC, SoC and IP at The SHD Group.
That sure would be nice, but this has been claimed every single year over the last decade. For now risc-v made its place in the microcontroller market where it displaced some less common or less open architectures, but I’m still waiting to see a performant core in the high-end CPU domain. Then the next step will be to make them scale well with threads, but competition has no reason to stop during this time.
I’ve seen other RISC-V devices, (like the Ky X1) that add NPU instructions to the regular core, making the NPU cores work as regular cores when the NPU instructions aren’t needed, making them far less of a waste than any other NPU implementation I’ve seen in embedded hardware.
IMHO this is the only way NPU should be implemented everywhere else, instead of systematically inventing new devices for which there is either no driver or no application support for years, and which just wastes silicon that is dedicated to marketing.
My SpacemiT K1 has 8 cores.
This SpamemiT K3 has 16 cores (nice), but if Linux can only use 8 cores … that’s no big upgrade.
So I hope this is only now, and they will solve it.
As indicated in the data above these preliminary tests were run under linux 6.12 which was out a while ago. There have been quite a number of riscv patches sent in since. If they can rebase to 6.19 with all their driver customizations applied, there could be considerable increase in functionality and performance.
Don’t post garbage AI images, it cheapens your brand.
I must admit I thought exactly the same when seeing this image. It suddenly makes on wonder how many images come from vendor (often 3D rendering of boards instead of photos) and which ones are invented for the purpose of the article.
Not a problem for people who can read 😉
> Not a problem for people who can read
I disagree, Jean-Luc. Under the image it’s written “AI-generated image of a SpacemiT K3 motherboard”, but it doesn’t say whether it’s the one provided by the vendor, which suggests that it roughly matches what they intend to design as the final product, or if it’s how *you* imagine it. In any case it’s not very important, but it makes one feel that information is completed with some padding to make an article look better. I know you like to start an article with an image, but you could equally have shown a cloud with a server and the SoC name next to it, then a VPN with you on the other end for example, just to illustrate that it was a participation to a remote test (which is fine and indicates the hardware at least exists).
Another K3 board from japan…
https://kibidango.com/projects/2921
32GB RAM, M.2 support, 1G+10G ethernet, 3x type-c usb