Would You Pay for RISC-V? Doing the Arithmetic in Public

A.C. Jokela — Tue, 08 Sep 2026 14:00:00 GMT

The worst number I ever published was 650.60 seconds.

That was an Orange Pi RV2 compiling my Rust ballistics engine. Nine machines ran the same build and the RV2 came last. The winner, a NanoPC-T6N on an RK3588, finished in 52.55 seconds; a 2011 MacBook Pro running FreeBSD took 131.00. The RISC-V board was 12.38 times slower than the fastest machine on the bench and about five times slower than a fifteen-year-old laptop.

I am about to ask whether you would pay me a monthly fee to rent RISC-V hardware. Publishing that number first is the only thing that earns me the right to ask.

What actually changed

The SpacemiT K3 is the first RISC-V chip you can buy that implements the RVA23 profile: eight X100 cores, four-issue out-of-order, up to 2.4 GHz, ratified RVV 1.0 at VLEN=256, the hypervisor extension at GEILEN=8, AIA, a RISC-V IOMMU, 8 MB of shared L2, on a 12 nm-class process. It is Sv39 only, which caps the virtual address space. There are another eight A100 cores that Linux counts and that you would not schedule general work onto. SpacemiT describes the X100 as an upgraded OpenC910, the same Xuantie lineage as the chip Scaleway rents.

Against the Ky X1 in my 650-second board, the K3 is about 2.6 times faster single-threaded and 3 times multi-threaded. Applied to my benchmark that is 217 to 250 seconds, which is arithmetic, not a measurement. It would move the board from ninth of nine to eighth, beating a Cortex-A53 and still losing to a Banana Pi CM5-Pro.

I also think that estimate is optimistic, because single-core is where RISC-V still loses badly.

All eight K3 cores together are worth roughly one Pi 5. The picture is uneven rather than uniformly bad: in 7-zip the K3 hits 19,680 MIPS, edging an RK3588, and Phoronix found it meeting or beating a Pi 500+ on OpenSSL and crypto work using Zvk. That same review found it trailing the Pi 500+ by a significant margin on compiling code.

That last clause is the shape of the problem. The K3 is good at vector and streaming integer work and comparatively bad at exactly the workload I benchmarked, which is also the workload every Linux distribution needs most.

Why this is not Scaleway

Scaleway's Elastic Metal RV1 is still the only RISC-V bare metal anyone sells to the public by the hour. It launched on 29 February 2024 at €15.99 per month, €0.042 per hour, excluding VAT, and the price has not moved since. Scaleway joined RISC-V International in early March 2024. RISE has said twice, on 12 May and 18 August 2026, that it is working with Scaleway on an EM-RV2. Scaleway itself has announced nothing.

What you rent is a T-Head TH1520: four C910 cores at 1.85 GHz, 16 GB, 128 GB of eMMC, 100 Mbit/s networking, one zone in Paris, a vendor 5.10 kernel, and a 0 percent SLA under Labs beta conditions even though the catalogue flags it generally available.

The gap that matters is not clock speed. It is which instruction set you are actually testing. The C910 implements RVV 0.7.1, an unratified draft that Linux carries as xtheadvector, and Scaleway states plainly that it is not compatible with the final RVV 1.0. They disable it by default; you can switch it on with sudo rv1 update-kernel --enable-vector, and their own documentation discourages it. Separately, GhostWrite (CVE-2024-44067) affects the C910 and names EM-RV1 among vulnerable devices, and Linux 6.14 and later mitigates it by disabling vector. The ISA string in Scaleway's own FAQ is RV64IMAFDC_Zicsr_Zifencei_Zfh_XTheadc. There is no V in it.

So if what you need is ratified RVV 1.0, or the hypervisor extension, or anything else in RVA23, you cannot rent it today. Not from Scaleway, and not from AWS, Azure, GCP, Oracle, Hetzner or OVH, none of which sell RISC-V at all. GitHub and GitLab hosted runners are x64 and arm64 only.

The box, and what it would cost

Two K3 Pico-ITX boards at 16 GB and 128 GB run \$399 each from Banana Pi or Sipeed. The board is 100 by 86 mm and takes 12 V through a two-pin ATX header. Two fit side by side in a 300 mm deep 1U with room left over.

The support gear comes to about \$418: a Mean Well LRS-200-12, a five-port switch pulled from its plastic case so only one Ethernet cable leaves the chassis, three 40 mm fans, and a Raspberry Pi doing the job of the BMC these boards do not have. The Pi holds a USB-UART console to each board and high-side MOSFET switching on each 12 V feed, so I can watch a boot and power-cycle a wedged node without flying to Miami. Add two NVMe drives at about \$120 the pair, and the pilot is roughly \$1,400 of capital.

Colocation would be ServerPronto in Miami, where I had a 1U Dell two decades ago and no complaints, which I recognise is not current information about anybody. Their 1U is \$54.95 a month with one amp of power, 2.5 TB of transfer, three IP addresses and a 100 Mbps port. A \$79.95 setup fee appears on a third-party directory last updated in July 2025 but not on their live page, so treat it as listed rather than confirmed. They publish neither a remote-hands rate nor a bandwidth overage rate, which is the sort of thing you notice only when you need it.

Over 24 months, \$1,400 of capital is \$58.33 a month. Add the colo and the box costs \$113.28, which is \$56.64 per node. Over 36 months the capital falls to \$38.89, the box costs \$93.84, and a node is \$46.92. Call it \$47 to \$57 per node per month, or 6.4 to 7.8 cents an hour.

Scaleway charges €15.99. They publish no dollar price, so pick your own rate; near €1 to \$1.16 that is about \$18.55, making me two and a half to three times more expensive for a machine that would still lose a Rust compile to a Raspberry Pi 5.

That \$47 contains no margin, no spare board, no failure budget and no labour. I also do not know whether one amp is enough, because ServerPronto does not publish the voltage. At 120 V that is 120 W and the budget is tight once you count boards, drives, the Pi, the switch, fans and supply losses; at 208 V, which is what NextArray specifies for its own one-amp plan, it is comfortable. I have written before about what happens when you run cheap hardware without margin.

Which brings up the number I should state plainly, because it changes what I am asking you. This business needs eight to ten customers. Not eight thousand, and not eighty. At two nodes the box costs \$94 to \$113 a month all in, so nine subscribers at \$25 covers it about twice over, and the second cover is what buys the spare board and the failure budget I just admitted I do not have. One of those nine needs to be an anchor tenant: somebody predictable who takes a whole board, pays annually, and whose presence is what makes the other eight survivable. The failure mode here is not that I cannot scale. It is that I get three customers and quietly eat the difference for two years.

The node I would give away

Debian made riscv64 an official release architecture with trixie in May 2025, then built it on nine HiFive Unmatched boards its own porter described as four years old and slow. In January 2025 gcc-14 took five to seven days on those machines and one upload took thirteen. Fedora's riscv64 Koji builders are community hardware sitting in people's homes, and in June 2026 Fedora's RISC-V lead wrote that even current K3 hardware is not quite enough for primary Koji. Rust's RFC to make riscv64gc a Tier 1 target has been open since October 2024, partly because a full stage-2 test run takes three to four hours even spread across six SG2042 machines, over the infrastructure team's three-hour cap.

So the plan I keep coming back to is to give a node away. One of the two, free and permanent, to a project that needs native RISC-V and cannot get it.

The arithmetic of that is ugly at two nodes and I would rather show it than hide it. If one of two nodes is donated, the other carries the entire box: \$94 to \$113 a month, not \$47 to \$57. No single subscriber absorbs that.

The anchor tenant is the answer, and it is the reason that role matters more than the other eight. One tenant on a dedicated board at something near \$100 covers most of the box by itself, and all of it on the three-year amortisation, which is what makes a free node affordable rather than aspirational. The hypervisor extension does the rest: the second board does not have to be one indivisible thing, so it can carry a donated slice and several paying tenants at once instead of choosing.

The shape that follows, if the pilot works, is ten nodes rather than two: one donated, one anchor, eight sold. Firefly sells a 1U carrying exactly that, the CSB1-N10SPK3, ten K3 nodes plus an RK3588 as BMC. That is the same eight-to-ten customers, with the colo bill split ten ways instead of two. The thing standing in the way is power, not demand. Ten K3 nodes at 15 to 25 W of SoC alone, before boards, drives and the BMC, do not fit in one amp at 120 V, and might not fit at 208 V either. That build needs at least ServerPronto's two-amp tier, and I cannot size it properly until they tell me the voltage.

The strongest argument against all of this

It is not a benchmark. It is a decision I already made on my own hardware.

When I built the multi-architecture build orchestration system that compiles my BSD binaries, I found that an emulated ARM64 build on a fast x86_64 host finished in 15 minutes 37 seconds, while the same emulated build on native ARM64 single-board hardware took over 99 minutes. About six times faster, on the wrong architecture. I disabled the native Orange Pi node and kept the emulated one.

A Fedora porter found it in a harsher form: 337 qemu-user-static-riscv processes on an AArch64 desktop beat a native build on 64-bit RISC-V hardware. Free native RISC-V CI also already exists. RISE launched GitHub runners in March 2026, open to anyone, running on Scaleway EM-RV1 with K3 in early access, and logged 24,000 jobs across 116 organisations by Hot Chips. Cloud-V, PLCT and EPCC will each hand an open-source developer a RISC-V shell for nothing.

If all you want is a green checkmark, buying native RISC-V time in 2026 is the wrong move, and I am not going to pretend otherwise. Emulation on a big x86 host is cheaper, faster and already free.

Which is exactly the point

That finding does not kill the idea. It sorts the customers, and the sorting is the whole strategy.

Emulation is a throughput product. You are buying compiled artifacts and you do not care what produced them. For that job I am the wrong vendor.

Bare metal, or a VM close enough to it, is a fidelity product. You are buying the truth about a machine. Those are different businesses that happen to share an instruction set, and the second cannot be served by QEMU on commodity x86 or Arm at any price, because what you need is exactly what the emulator abstracts away.

Four examples, all specific.

The boot chain does not exist in an emulator. QEMU's virt machine hands you a clean device tree and a working memory map; real hardware hands you U-Boot SPL, OpenSBI, an EEPROM and whatever the vendor's defaults were. I lost a week this summer to a corruption bug that turned out to be two physical addresses 4 GiB apart reaching the same DDR, because a blank EEPROM let U-Boot SPL fall back to a private memory default. No emulator would have shown me that, and every OS porter working below userspace hits this class of problem.

Errata do not exist in an emulator either. An emulator implements the specification; silicon implements what the vendor built. GhostWrite is a vector-unit vulnerability in real C910 and C920 parts, and the industry response was to turn the vector unit off. You cannot find that bug, or verify a mitigation for it, on a machine that only ever implemented the spec correctly.

The vector unit you actually ship against is a specific one. The K3 gives you ratified RVV 1.0 at VLEN=256. QEMU will tell you whether your vector code is correct. It will not tell you whether it is fast, because it is not modelling this register width, this issue width, or this memory system. If you are tuning RVV codegen or writing a hand-vectorised kernel, correctness is the easy half.

And timing does not survive translation to another architecture: memory ordering under real concurrency, PMU counters, thermal behaviour, DVFS. Nobody chasing a race that only appears on real cores will find it inside qemu-user on an Arm desktop.

There is a product argument in that, and it is the one that makes the economics less grim. The K3 carries the hypervisor extension at GEILEN=8 alongside a RISC-V IOMMU, so a node can be subdivided into VMs that keep every property above, running real instructions on real silicon over real firmware, rather than sold whole to one tenant. Scaleway cannot offer that: the ISA string they publish for the C910 contains no H. The honest caveat is Sv39, which caps the address space and limits how ambitious the virtualisation story can get. But nobody is currently selling near-bare-metal VMs on RVA23 silicon, and it splits a board's cost across several customers without giving up the fidelity that is the whole reason to be in the rack.

So: would you pay?

Two questions, and I want real answers rather than encouragement.

First, at \$50 a month for eight RVA23 cores at 2.4 GHz with ratified RVV 1.0, root, an out-of-band serial console and a power button I will actually press for you, would you subscribe? I am not asking whether this is a market. I am asking whether you would be one of nine. If the answer is no at \$50, tell me the number where it becomes yes, or tell me that no number works because free runners already cover you. And if you would want the anchor slot, a dedicated board with your name on it and a say in what the next one is, say that, because there is exactly one of those and it decides whether the rest of this happens.

Second, and more useful: what would you run on it that you cannot run under QEMU today? If the honest answer is "nothing, emulation is fine", this box should not exist, and I would rather learn that from you than from an invoice. If the answer involves firmware, a bootloader, a device tree, a vector kernel you need to time rather than merely test, a hypervisor, or a race that only appears on real cores, tell me which. That decides whether the box is two hand-built nodes or ten in a Firefly chassis, whether I sell whole boards or near-bare-metal VMs, and where the donated node goes.

Comments on this post go to Utterances, or reach me at email@tinycomputers.io.

TinyComputers.io (Posts about k3)