The MilkV Jupiter 2/SpacemiT K3

Jun 11th 2026 · 22 min read · #ai #hardware #homelab #linux #reviews #riscv #sbc #spacemit This is a fascinating box–so much so that after almost three weeks playing with it, I amassed so much material that I nearly decided to split my review into two parts, but in the end I decided to condense it a bit and post a longer piece than usual, even if that means almost half of it is a fairly wide-ranging exploration of how to get AI workloads on it. The MilkV Jupiter 2 in its metal case Spoiler: We’re tantalizingly close to having usable non-GPU inference on SBCs, and surprisingly enough, RISC-V is more interesting than ARM right now. I’ve tested a lot of ARM boards over the past few years, but only a couple of RISC-V machines–and the MilkV Jupiter 2 is quite a substantial system: Sixteen cores (with a twist), a refreshingly roomy 32GB of RAM, a 10GbE SFP, Wi-Fi 6, a GPU with actual DRM nodes, all in a Pico ITX form factor. Disclaimer: my contacts at Radxa supplied me with a Jupiter 2 free of charge, and as usual, this article follows my review policy. On paper, this is the first RISC-V board that doesn’t feel like a science project. In person, and unlike most of the SBCs I get, the Jupiter 2 is a finished product, and came in a neat little box, fully assembled and contained in an unassuming metal case with external antennae as the only extra parts. No power brick, but since it has a USB-C PD port, I had zero trouble powering it from one of my monitors. HardwareAfter some careful disassembly, the board itself is pretty dense: 1× DP out, 1× eDP ribbon, 1× USB-C PD power input, 3× USB-A 3.0, 1× GbE RJ-45, 1× 10GbE SFP+ cage, an M.2 slot and what looks like a second M.2 for storage. There are also MIPI/eDP ribbon connectors I haven’t tested.

The board is dwarfed on the top side by the cooler, which I dared not remove The SoC is SpacemiT’s K3–a big.LITTLE style arrangement with 8×A100 cores at 2GHz and 8×X100 cores at 2.4GHz, which makes it the first RISC-V chip I’ve handled that has asymmetric core clusters. And since there are a few other devices out there with the same reference design, I will henceforth refer to the Jupiter as the K3 for short. SpecsThe machine I’m testing has a nice assortment of features: 16 RISC-V cores (8× Spacemit A100 + 8× Spacemit X100) 32GB RAM 128GB UFS RTL8852BE Wi-Fi 6 + Bluetooth 1 GbE RJ-45 + 10 GbE SFP (RTL8127 10GbE via PCIe) An IMG (PowerVR) GPU NOR flash for bootloader (SPI, 8MB: bootinfo + FSBL + env + eSOS + OpenSBI + U-Boot) PWM fan Pico ITX form factor The ISAIf you’ve never come across SpacemiT’s stuff before (I had only a bare inkling of the K1), I heartily recommend the public SpacemiT K3 documentation and their GitHub repository since the architecture is laid out there, and it was fairly easy to get a high level grasp. In particular, the K3 SoC datasheet has a pretty good overview: Block Diagram from the K3 Technical Brief A key thing that needs to be taken into account is that the A100 cores are fundamentally different from the X100 ones. They have extended vector instruction sets, dedicated transactional memory, and, well… AI.

That documentation also seems to be the original source of the marketing claims that the K3 provides 60 TOPS of AI compute and can run 30B models at over 10 tokens/s. Well, sort of– as another spoiler, I can share that I hit a hard cap at an effective 3B (which seemed to be the practical limit), but we’ll get there… Hardware InfoThe board identifies itself as “SpacemiT K3 Pico ITX” in the device tree, and cores are reported like so: Architecture: riscv64 Byte Order: Little Endian CPU(s): 16 Vendor ID: 0x710 Model name: Spacemit(R) A100 Thread(s) per core: 1 Core(s) per socket: 8 CPU max MHz: 2000.0000 CPU min MHz: 614.4000 Model name: Spacemit(R) X100 Thread(s) per core: 1 Core(s) per socket: 8 CPU max MHz: 2400.0000 CPU min MHz: 614.4000 L1d cache: 1 MiB (16 instances) L1i cache: 1 MiB (16 instances) L2 cache: 10 MiB (4 instances) One of the nice things about this box is that it comes with a 10GbE Realtek NIC. I wasn’t able to test that at full speed yet since my 10GbE interfaces are all in my server closet, but the 802.11ax reported below worked flawlessly with my Wi-Fi 6 setup: # lspci 0000:00:00.0 PCI bridge: SpacemiT X100 PCIe Root Complex (rev 01) 0002:00:00.0 PCI bridge: SpacemiT X100 PCIe Root Complex (rev 01) 0002:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8127 10GbE Controller (rev 08) 0004:00:00.0 PCI

bridge: SpacemiT X100 PCIe Root Complex (rev 01) 0004:01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller There isn’t a lot to report on the USB front (most of the below is what is plugged into my LG Ultrafine): # lsusb Bus 005 Device 002: ID 043e:9a46 LG Electronics USA, Inc. USB2.1 Hub Bus 005 Device 003: ID 043e:9a48 LG Electronics USA, Inc. Bus 005 Device 004: ID 043e:9a42 LG Electronics USA, Inc. USB Audio Bus 005 Device 009: ID 046d:085e Logitech, Inc. BRIO Ultra HD Webcam Bus 005 Device 010: ID 043e:9a40 LG Electronics USA, Inc. USB Controls Bus 007 Device 004: ID 04d9:0006 Holtek Semiconductor, Inc. Wired Keyboard Bus 007 Device 005: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse The flash storage it ships with is also sensibly organized: # lsblk NAME SIZE TYPE MOUNTPOINT MODEL sda 119.3G disk TY7B-128 ├─sda1 256M part ├─sda2 256M part /boot └─sda3 118.8G part / mtdblock0 8M disk mtdblock1 128K disk mtdblock2 512K disk mtdblock3 64K disk mtdblock4 1M disk mtdblock5 384K disk mtdblock6 5.9M disk

That sda (model TY7B-128) initially fooled me into thinking it was a SATA SSD–but there’s no SATA controller on this board, and the 3.4 GB/s reads I measured later are well past anything SATA III can do (~600 MB/s). It’s actually 128GB of onboard UFS, which rides the kernel’s SCSI layer and so enumerates as sda exactly like a SATA disk would (NVMe would be nvme0n1, eMMC mmcblk*). The mtdblock devices are the 8 MB NOR flash partitions (bootinfo, FSBL, env, eSOS, OpenSBI, U-Boot). # sensors pwmfan-isa-0000 Adapter: ISA adapter pwm1: 60% MANUAL CONTROL thermal_cluster3-virtual-0 Adapter: Virtual device temp1: +60.0°C thermal_cluster1-virtual-0 Adapter: Virtual device temp1: +60.0°C thermal_gpu-virtual-0 Adapter: Virtual device temp1: +63.0°C thermal_top-virtual-0 Adapter: Virtual device temp1: +62.0°C cros_ec-isa-000c Adapter: ISA adapter fan1: 3208 RPM thermal_cluster2-virtual-0 Adapter: Virtual device temp1: +63.0°C thermal_cluster0-virtual-0 Adapter: Virtual device temp1: +64.0°C thermal_vpu-virtual-0 Adapter: Virtual device temp1: +60.0°C The sensors output is a bit weird, but it does cover all the CPU cores (A100 are clusters 0 and 1, X100 are 2 and 3). And I will have a bit more to say about the fan. But I’m ahead of myself here–these were gathered after plugging it in, obviously, and it’s worth rewinding and going over that part: First BootThis was a first-class experience, and I wish all SBCs worked this way: I plugged the DP port into my ancient LG Ultrafine, powered on the monitor, and got a Bianbu first-boot wizard in less than 5 seconds after the initial logo.

Clicked through it–language, timezone, user account–and landed on a working accelerated desktop. That’s it. No GRUB patching, no DTB hunting, no resize-filesystem bugs, no serial console required. The smoothest first boot I’ve had with an SBC all year. The board ships with Bianbu 4.0 (“Resolute Raccoon”)–a Debian-based distribution from SpacemiT, which, unlike most ARM boards I’ve used recently, is actually running a modern 6.18.3 kernel. MilkV Jupiter 2 LXQt on Wayland - note how only the first 8 cores are active The desktop runs LXQt on Wayland, SDDM as the display manager, and the whole thing felt responsive enough that I didn’t immediately reach for the terminal. That is not something I say about SBC desktops often, and even though I then spent most of the past three weeks accessing it via ssh, I would likely have zero issues using it. Standard apt works (repos seem to be at spacemit.com), Debian toolchain is present, and the kernel command line includes some interesting RISC-V-specific hints: unaligned_scalar_speed=fast and unaligned_vector_speed=fast, which I think are related to the RVV extended vector instruction set and the way the kernel does thread allocation. I dug around a bit more and the boot chain goes through NOR flash (OpenSBI + U-Boot) → UFS, which is cleaner than the SD-card-based setups on most SBCs I’ve tested, and it was able to update itself without any issues: Setting up spacemit-ec-firmware (1:0.0.22)… spacemit-ec-firmware: payload installed successfully. Current EC firmware 'SPACEMIT_PICO_ITX-V00.14' is older than packaged firmware 'SPACEMIT_PICO_ITX-V00.16'. Starting automatic EC firmware update during package installation... [INFO] Automatic EC firmware update triggered during package installation. [INFO] Current RW: SPACEMIT_PICO_ITX-V00.14 [INFO] Target FW : SPACEMIT_PICO_ITX-V00.16 [WARN] Do not remove power, reset the system, or interrupt the tool while flashing. [

INFO] 1. Erasing flash region... Erasing 262144 bytes at offset 0... done. [ OK ] Erase completed. [INFO] 2. Writing firmware image... Reading 242688 bytes from /lib/firmware/k3-pico-itx/ec.bin... Writing to offset 0... Writing: [########################################] 100% done. [ OK ] Write completed. [INFO] 3. Reading back flash contents for MD5 verification... Reading 242688 bytes at offset 0... Reading: [########################################] 100% done. [ OK ] MD5 verification passed. [ OK ] Automatic EC firmware update finished successfully. [INFO] This reboots the EC firmware only. Linux is not rebooted automatically. [WARN] The power LED may blink and ectool may be unavailable briefly after the command. [INFO] Sending EC reboot command... [ OK ] EC reboot command sent. [INFO] Waiting 10 seconds for EC reboot to settle... [WARN] Reboot Linux manually now to restore EC communication. [INFO] After Linux reboots, verify with: ectool version Automatic EC firmware update completed. Not UEFI, but compared to the U-Boot-on-SD-card experience that most ARM SBCs inflict on you, having a proper NOR flash boot chain with OpenSBI → U-Boot → onboard UFS is a step up, because it means you can brick the OS partition and still recover without reflashing an SD card on another machine (and yes, Rockchip, I’m looking at you). And since it all worked out of the box, I did not try adding an NVMe (there’s an M.2 M-Key slot for one) or booting from it (yet), although since there is official Ubuntu support I fully intend to try that out in the future.