
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 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 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 |
Starting to examine hardware/software for review purposes... Average load and/or CPU utilization too high (too much background activity). Waiting... Too busy for benchmarking: 03:38:13 up 2 days, 17:20, 1 user, load average: 1.64, 1.59, 0.92, cpu: 0% Too busy for benchmarking: 03:38:18 up 2 days, 17:20, 1 user, load average: 1.51, 1.57, 0.91, cpu: 0% Too busy for benchmarking: 03:38:23 up 2 days, 17:20, 1 user, load average: 1.39, 1.54, 0.91, cpu: 0% Too busy for benchmarking: 03:38:28 up 2 days, 17:20, 1 user, load average: 1.28, 1.51, 0.90, cpu: 0% Too busy for benchmarking: 03:38:33 up 2 days, 17:20, 1 user, load average: 1.17, 1.49, 0.90, cpu: 0% Too busy for benchmarking: 03:38:38 up 2 days, 17:20, 1 user, load average: 1.08, 1.46, 0.89, cpu: 0% sbc-bench v0.9.72 Installing needed tools: distro packages already installed... (can't build cpuminer) Done. Checking cpufreq OPP... Done. Executing tinymembench... Done. Executing RAM latency tester... Done. Executing OpenSSL benchmark... Done. Executing 7-zip benchmark... Done. Throttling test: heating up the device, 5 more minutes to wait... Done. Checking cpufreq OPP again... Done (15 minutes elapsed). Results validation: * Measured clockspeed not lower than advertised max CPU clockspeed * Too much background activity (%system): 1% avg, 5% max -> https://tinyurl.com/mr2wy5uv # spacemit Tested with sbc-bench v0.9.72 on Fri, 23 Jan 2026 03:53:16 +0100. ### General information: Kernel: riscv64, Userland: riscv64 CPU sysfs topology (clusters, cpufreq members, clockspeeds) cpufreq min max CPU cluster policy speed speed core type 0 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 1 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 2 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 3 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 4 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 5 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 6 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 7 0 0 614 2400 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 8 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 9 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 10 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 11 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 12 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 13 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 14 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 15 0 8 614 2000 rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt 32128 KB available RAM ### Governors/policies (performance vs. idle consumption): Original governor settings: cpufreq-policy0: performance / 2400 MHz (conservative ondemand userspace powersave performance / 614 819 1000 1100 1200 1300 1400 1500 1600 1700 1800 1850 1900 2000 2100 2150 2200 2300 2400) cpufreq-policy8: performance / 2000 MHz (conservative ondemand userspace powersave performance / 614 819 1000 1100 1200 1300 1400 1500 1600 1700 1800 1850 1900 2000) Tuned governor settings: cpufreq-policy0: performance / 2400 MHz cpufreq-policy8: performance / 2000 MHz ### Clockspeeds (idle vs. heated up): Before: cpu0 (rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt): OPP: 2400, Measured: 2395 After: cpu0 (rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbc_zbs_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt_sdtrig_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt): OPP: 2400, Measured: 2396 ### Performance baseline * memcpy: 5947.7 MB/s, memchr: 8466.8 MB/s, memset: 15975.9 MB/s * 16M latency: 157.2 155.2 157.9 155.0 157.6 155.7 154.9 159.0 * 128M latency: 179.2 175.5 179.1 175.7 179.1 173.9 176.0 185.0 * 7-zip MIPS (3 consecutive runs): 17947, 17663, 16988 (17530 avg), single-threaded: 2736 * `aes-256-cbc 296715.03k 588878.70k 777993.81k 846785.88k 867243.35k 869624.49k` * `aes-256-cbc 300223.15k 589692.31k 778451.80k 846529.54k 867188.74k 869520.73k` ### Storage devices: * 119.2GB "128GB SSD" SSD as /dev/nvme0: Speed 2.5GT/s (downgraded), Width x4, 10% worn out, 13 error log entries, drive temp: 39°C, ASPM Disabled * 59.6GB SAMSUNG KLUCG2U1DC-B0F1 SPC-4 compliant UFS module: /dev/sda, Driver=ufshcd-spacemit-k3 * Gigadevice GD25LQ64C 8MB SPI NOR flash, drivers in use: spi-nor/spacemit-k1-qspi/simple-pm-bus "nvme error-log /dev/nvme0 ; smartctl -x /dev/nvme0" could be used to get further information about the reported issues. ### Software versions: * Ubuntu Resolute Raccoon (development branch) (resolute) * Compiler: /usr/bin/gcc (Ubuntu 15.2.0-11ubuntu1) 15.2.0 / riscv64-linux-gnu * OpenSSL 3.5.3, built on 16 Sep 2025 (Library: OpenSSL 3.5.3 16 Sep 2025) ### Kernel info: * `/proc/cmdline: clk_ignore_unused nohlt plymouth.prefer-fbcon plymouth.ignore-serial-consoles splash loglevel=8 cros_ec_espi.disable=1 mtdparts=spi-flash:128K@0(bootinfo),512K@128K(fsbl),64K@640K(env),1M@704K(esos),384K@1728K(opensbi),-@2112K(uboot) rootfstype=ext4 root=UUID=fe62cacd-a6b5-4dbe-8cdc-3ecfb2d098be earlycon=sbi console=ttyS0,115200 random.trust_bootloader=1` * Kernel 6.12.16-generic / CONFIG_HZ=250 All known settings adjusted for performance. Device now ready for benchmarking. Once finished stop with [ctrl]-[c] to get info about throttling, frequency cap and too high background activity all potentially invalidating benchmark scores. All changes with storage and PCIe devices as well as suspicious dmesg contents will be reported too. Time CPU load %cpu %sys %usr %nice %io %irq Temp 03:53:24: 2400MHz 12.62 0% 0% 0% 0% 0% 0% °C 03:54:24: 2400MHz 4.63 0% 0% 0% 0% 0% 0% °C 03:55:24: 2400MHz 1.70 0% 0% 0% 0% 0% 0% °C 03:56:24: 2400MHz 0.62 0% 0% 0% 0% 0% 0% °C 03:57:25: 2400MHz 0.23 0% 0% 0% 0% 0% 0% °C 03:58:25: 2400MHz 0.08 0% 0% 0% 0% 0% 0% °C 03:59:25: 2400MHz 0.12 0% 0% 0% 0% 0% 0% °C 04:00:25: 2400MHz 0.04 0% 0% 0% 0% 0% 0% °C 04:01:25: 2400MHz 0.01 0% 0% 0% 0% 0% 0% °C 04:02:25: 2400MHz 0.00 0% 0% 0% 0% 0% 0% °C |
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).