SpacemiT K3 “16-core” RISC-V SoC system information and (early) benchmarks

SpacemiT K3 motherboard ai generated
AI-generated image of a SpacemiT K3 motherboard

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:


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:


Let’s add lspci output to see if we can find more devices:


Not much here.

Sander also ran sbc-bench.sh for us:


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”.

SpacemiT K3 btop multi core

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).

Benchmarks SpacemiT K3 vs RK3588 vs Raspberry Pi 5 vs Orion O6

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.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

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.

Radxa Orion O6 Armv9 mini-ITX motherboard

22 Replies to “SpacemiT K3 “16-core” RISC-V SoC system information and (early) benchmarks”

  1. 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

  2. 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…

  3. 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)

    1. > 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).

      1. 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.

        1. 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.

    2. 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.

      1. 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.

  4. 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.

    1. 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.

    1. 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.

        1. > 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).

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon MINI1126B-P AI vision system-on-module wit Rockchip RV1126B-P SoC
Boardcon MINI1126B-P AI vision system-on-module wit Rockchip RV1126B-P SoC