MilkV Jupiter 2 / SpacemiT K3 (RISC-V 向量计算)

# MilkV Jupiter 2 / SpacemiT K3 来源：https://taoofmac.com/space/reviews/2026/06/11/1830 2026年6月11日 (https://taoofmac.com/space/reviews/2026/06/11/1830)· 22分钟阅读 · #ai #硬件 #homelab #linux #评测 #riscv #sbc #spacemit 这是一款迷人的盒子——玩了将近三周后，我积累了如此多的素材，差点决定把评测分成两部分，但最终我还是决定稍微压缩一下，发一篇比平时更长的文章，即使这意味着几乎一半内容都在广泛探讨如何在其上运行AI工作负载。 金属外壳中的MilkV Jupiter 2 剧透：我们离在SBC上实现可用的非GPU推理仅一步之遥，而且令人惊讶的是，RISC-V目前比ARM更有趣。 过去几年我测试过大量ARM开发板 (https://taoofmac.com/space/site/review_policy)，但只接触过几台RISC-V设备——而MilkV Jupiter 2是一套相当强大的系统：十六个核心（带点花样）、宽敞的32GB内存、10GbE SFP接口、Wi-Fi 6、具备实际DRM节点的GPU，所有这些都集成在Pico ITX规格中。 > **免责声明：**Radxa的朋友们免费为我提供了一台Jupiter 2 (https://milkv.io/jupiter2?utm_source=taoofmac.com&utm_medium=web&utm_campaign=unsolicited_traffic&utm_content=external_link)，像往常一样，本文遵循我的评测政策 (https://taoofmac.com/space/site/review_policy)。 从纸面上看，这是第一款不让人觉得是科学实验的RISC-V开发板。 实际到手时，与我收到的大多数SBC不同，Jupiter 2是一款成品，装在一个整洁的小盒子里，完全组装好，置于低调的金属外壳中，仅有外置天线作为额外部件。没有电源适配器，但由于它带有USB-C PD接口，我毫不费力地从我的一个显示器为其供电。 ## 硬件 (https://taoofmac.com/space/reviews/2026/06/11/1830#hardware)小心拆解后，板子本身相当密集：1×DP输出、1×eDP排线、1×USB-C PD电源输入、3×USB-A 3.0、1×GbE RJ-45、1×10GbE SFP+插槽、一个M.2插槽以及一个看起来像是第二个M.2存储插槽。还有我未测试的MIPI/eDP排线连接器。 主板上方被散热器覆盖，我没敢拆下。 SoC是SpacemiT K3——一种big.LITTLE风格的布局，包含8个2GHz的A100核心和8个2.4GHz的X100核心，这使其成为我接触过的第一款具有非对称核心集群的RISC-V芯片。由于还有其他一些采用相同参考设计的设备，我之后将Jupiter简称为K3。 ### 规格 (https://taoofmac.com/space/reviews/2026/06/11/1830#specs)我测试的这台机器配备了丰富的功能： - 16个RISC-V核心（8× Spacemit A100 + 8× Spacemit X100） - 32GB 内存 - 128GB UFS - RTL8852BE Wi-Fi 6 + 蓝牙 - 1 GbE RJ-45 + 10 GbE SFP（通过PCIe的RTL8127 10GbE） - IMG (PowerVR) GPU - NOR闪存用于引导加载程序（SPI，8MB：bootinfo + FSBL + env + eSOS + OpenSBI + U-Boot） - PWM风扇 - Pico ITX规格 ### ISA (https://taoofmac.com/space/reviews/2026/06/11/1830#the-isa)如果你之前从未接触过SpacemiT的产品（我只对K1有一丝了解），我强烈推荐查阅公开的SpacemiT K3文档 (https://developer.spacemit.com/?utm_source=taoofmac.com&utm_medium=web&utm_campaign=unsolicited_traffic&utm_content=external_link)以及他们的GitHub仓库 (https://github.com/spacemit-com/docs-chip?utm_source=taoofmac.com&utm_medium=web&utm_campaign=unsolicited_traffic&utm_content=external_link)，因为架构在那里有详细说明，并且很容易获得高层次的理解。特别是K3 SoC数据手册 (https://github.com/spacemit-com/docs-chip/blob/main/en/key_stone/k3/k3_docs/k3_ds.md?utm_source=taoofmac.com&utm_medium=web&utm_campaign=unsolicited_traffic&utm_content=external_link)提供了相当不错的概述： K3技术简介中的框图 关键点在于A100核心与X100核心*根本不同*。它们拥有扩展的向量指令集、专用事务内存，当然还有……AI。 那份文档似乎也是营销说法的原始来源，宣称K3提供60 TOPS的AI计算能力，并能以超过10 tokens/s的速度运行30B模型。嗯，算是吧——作为另一个剧透，我可以分享我遇到了一个硬性上限，实际只有*有效的*3B（这似乎是实用极限），但我们稍后会谈到…… ### 硬件信息 (https://taoofmac.com/space/reviews/2026/06/11/1830#hardware-info)开发板在设备树中标识为“SpacemiT K3 Pico ITX”，核心信息如下： ``` 架构： riscv64 字节序： 小端 CPU(s): 16 厂商ID： 0x710 型号名称： Spacemit(R) A100 每核心线程数： 1 每插槽核心数： 8 CPU 最高 MHz： 2000.0000 CPU 最低 MHz： 614.4000 型号名称： Spacemit(R) X100 每核心线程数： 1 每插槽核心数： 8 CPU 最高 MHz： 2400.0000 CPU 最低 MHz： 614.4000 L1d 缓存： 1 MiB (16个实例) L1i 缓存： 1 MiB (16个实例) L2 缓存： 10 MiB (4个实例) ``` 这台设备的一个优点是其配备了10GbE Realtek网卡。我目前还无法测试其全速，因为我的10GbE接口都在服务器机柜里，但下面报告的802.11ax与我的Wi-Fi 6设置配合完美： ``` # lspci 0000:00:00.0 PCI 桥: SpacemiT X100 PCIe Root Complex (rev 01) 0002:00:00.0 PCI 桥: SpacemiT X100 PCIe Root Complex (rev 01) 0002:01:00.0 以太网控制器: Realtek Semiconductor Co., Ltd. RTL8127 10GbE Controller (rev 08) 0004:00:00.0 PCI 桥: SpacemiT X100 PCIe Root Complex (rev 01) 0004:01:00.0 网络控制器: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller ``` USB方面没什么好说的（以下大部分是连接到我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 ``` 它配备的闪存存储也组织得很合理： ``` # 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 ``` 那个`sda`（型号TY7B-128）最初让我误以为是SATA SSD——但这块板子上没有SATA控制器，而我后来测得的3.4 GB/s读取速度远非SATA III（约600 MB/s）所能企及。它实际上是128GB板载UFS，通过内核的SCSI层工作，因此像SATA盘一样枚举为`sda`（NVMe会是`nvme0n1`，eMMC则是`mmcblk*`）。`mtdblock`设备是8 MB NOR闪存分区（bootinfo、FSBL、env、eSOS、OpenSBI、U-Boot）。 ``` # sensors pwmfan-isa-0000 适配器： ISA adapter pwm1: 60% MANUAL CONTROL thermal_cluster3-virtual-0 适配器： Virtual device temp1: +60.0°C thermal_cluster1-virtual-0 适配器： Virtual device temp1: +60.0°C thermal_gpu-virtual-0 适配器： Virtual device temp1: +63.0°C thermal_top-virtual-0 适配器： Virtual device temp1: +62.0°C cros_ec-isa-000c 适配器： ISA adapter fan1: 3208 RPM thermal_cluster2-virtual-0 适配器： Virtual device temp1: +63.0°C thermal_cluster0-virtual-0 适配器： Virtual device temp1: +64.0°C thermal_vpu-virtual-0 适配器： Virtual device temp1: +60.0°C ``` `sensors`输出有点奇怪，但它确实涵盖了所有CPU核心（A100是集群0和1，X100是2和3）。关于风扇我稍后还会多说几句。 但我有点超前了——这些显然是在插电后收集的，值得回退一下，先谈谈这部分： ## 首次启动 (https://taoofmac.com/space/reviews/2026/06/11/1830#first-boot)这是一次一流的体验，我希望所有SBC都能这样工作：我将DP接口插入我古老的LG Ultrafine显示器，打开显示器电源，在初始徽标出现后不到5秒就看到了Bianbu首次启动向导。 一路点击——语言、时区、用户账户——然后进入了可用的加速桌面。就是这样。无需修补GRUB，无需寻找DTB，无需调整文件系统大小，无需串口控制台。这是我今年在SBC上遇到的最流畅的首次启动。 该开发板预装Bianbu 4.0（“Resolute Raccoon”）——SpacemiT基于Debian的发行版，与我最近使用的大多数ARM板不同，它实际上运行着现代6.18.3内核。 MilkV Jupiter 2 上基于Wayland的LXQt - 注意只有前8个核心活跃 桌面运行LXQt on Wayland，SDDM作为显示管理器，整体感觉足够流畅，以至于我没有立刻去碰终端。这不是我经常对SBC桌面说的话，尽管随后三周我大部分时间都是通过`ssh`访问它，但日常使用完全没问题。 标准的`apt`正常工作（仓库似乎位于`spacemit.com`），Debian工具链存在，内核命令行包含一些有趣的RISC-V特定提示：`unaligned_scalar_speed=fast`和`unaligned_vector_speed=fast`，我*认为*它们与RVV扩展向量指令集以及内核的线程分配方式有关。 我进一步研究了一下，启动链经过NOR闪存（OpenSBI + U-Boot）→ UFS，这比我测试过的大多数SBC基于SD卡的设置更干净，而且它能够顺利自我更新： ``` 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. ``` 不是UEFI，但相比大多数ARM SBC强加给你的U-Boot-on-SD-card体验，拥有一个带有OpenSBI → U-Boot → 板载UFS的完整NOR闪存启动链是一个进步，因为这意味着你可以搞坏操作系统分区，而无需在另一台机器上重新刷写SD卡来恢复（没错，Rockchip，说的就是你）。 而且由于一切开箱即用，我没有尝试添加NVMe（有一个M.2 M-Key插槽）或从它启动（目前），不过既然有官方Ubuntu支持 (https://github.com/spacemit-com/K3-Ubuntu-Images?utm_source=taoofmac.com&utm_medium=web&utm_campaign=unsolicited_traffic&utm_content=external_link)，我完全打算将来试试。 ### 工具链 (https://taoofmac.com/space/reviews/2026/06/11/1830#toolchains)大多数读者最关心的将是RISC-V的开发工具，所以我可以马上告诉你，我目前正在广泛使用以下工具： - GCC 15.2 (riscv64) - Go 1.25.7 – 开箱即用，这对我来说很重要 - Python 3.14.3 - Make 4.4.1 遗憾的是（对我来说），Bun不可用，因为目前还没有官方的`riscv64`构建版本，但`node`可以正常工作。我主要关注Go (https://taoofmac.com/space/dev/golang)。 ## 性能 (https://taoofmac.com/space/reviews/2026/06/11/1830#performance)为了开始评估，我运行了一小套测试，以了解它与Orange Pi 6 Plus (https://taoofmac.com/space/reviews/2026/04/11/1900)（CIX P1，12个ARM核心）——我已经使用数月 (https://taoofmac.com/space/reviews/2026/04/11/1900)的板子相比处于什么水平。 ### CPU (https://taoofmac.com/space/reviews/2026/06/11/1830#cpu)测试 | MilkV Jupiter 2 (16× RISC-V) | Orange Pi 6 Plus (12× ARM) | 备注 --- | --- | --- | --- 7-Zip 多线程 | 17,547 MIPS | 42,346 MIPS | ARM 是 2.4倍 总计 `sysbench` CPU (1线程) | 2,329 ev/s | 2,800 ev/s | ARM 每核心IPC 1.2倍 `sysbench` CPU (所有核心) | 16,980 ev/s (8个可用) | 25,746 ev/s (12t) | 7.3倍 vs 9.2倍 缩放 fib(42) GCC -O2 | 1.110s | 0.649s | ARM 快 1.7倍 Go 50M 三角函数运算 | 2.68s | 0.483s | ARM 快 5.5倍 (Go arm64 成熟) Python 10M 循环 | 4.74s | 1.07s | ARM 快 4.4倍 注意这些基准测试只在X100集群（核心0-7）上运行。A100核心（8-15）被内核隔离用于AI工作——`htop`显示它们空闲，并且`sched_setaffinity`从普通shell静默拒绝将任何进程绑定到那里。原因多种多样且引人入胜，我将在下面详细说明。 `sysbench`单线程数字很有意思：2,329 对 2,800。每个X100核心的差距只有1.2倍。7-Zip的数据（17.5k vs 42.3k MIPS）看起来糟糕，但当你意识到A100核心完全没有被使用时，Jupiter 2实际上是用8个通用线程对抗P1的12个线程。 *真正*的差距出现在Go和Python（4-5倍），这可能更多地说明了`riscv64`运行时后端还很年轻，而不是硬件本身的问题。 ### 内存带宽 (https://taoofmac.com/space/reviews/2026/06/11/1830#memory-bandwidth)测试 | MilkV Jupiter 2 | Orange Pi 6 Plus (A720最佳) --- | --- | --- sysbench 内存读取 | 3,051 MiB/s | 15-17 GB/s (libc memcpy) sysbench 内存写入 | 2,694 MiB/s | 35-47 GB/s (memset) 我回去在CIX P1上并行运行了这些测试，K3的内存带宽*低得多*——读取大约只有五分之一。这很可能是最大的单一性能差距，无论每个周期能塞进多少指令，它都会给CPU的能力设置一个上限。对于内存受限的推理工作负载，这影响很大。不过，K3有几种变通方法，我们稍后会看到。 ### 存储 (https://taoofmac.com/space/reviews/2026/06/11/1830#storage)测试 | MilkV Jupiter 2 --- | --- 顺序写入 | 1.2 GB/s 顺序读取 | 3.4 GB/s 4K随机写入 | 113 MB/s (~28K IOPS) 内置UFS存储