← Back to Blog
RISC-V Development

deepin 25 Ships an RVA23 Baseline for SpacemiT K3: Offline 30B Inference on a RISC-V Desktop

RISC-V deepin SpacemiT K3 RVA23 GCC-15 LLVM-21 GGML llama.cpp IME

Published: 2026-09-18 · Category: RISC-V Development · Reading time: ~5 min · Status: DRAFT

Why a second repository instead of a rebuild

The deepin-ports SIG has published a K3 experience image for deepin 25, built on top of a new overlay repository called Next (RVA23). The underlying problem is one every RISC-V distro hits: deepin 25's mainline is built to an RVA20 baseline. Its GCC, LLVM and glibc are stable, but they cannot emit or tune for the extensions that RVA23 parts expose.

Rather than fork the distribution, the SIG added Next as an upper-layer overlay alongside the existing deepin 25 repositories. The RFC lives at deepin-community/rfcs#18. Next builds for four architectures — amd64, arm64, riscv64 and loong64 — but only riscv64 gets the RVA23 global optimisation turned on. That asymmetry matters: RVA23 is treated as an architecture-specific raise of the floor, not a whole-distro migration.

The K3 core map, as documented by deepin

Per the adaptation notes, the SpacemiT K3 integrates three classes of core in one die:

Both X100 and A100 implement RVV 1.0, with VLEN 256 on X100 and VLEN 1024 on A100. The part is quoted at 15–25 W typical, and also integrates a Vulkan / OpenGL ES 3D GPU, a 4K codec video engine, PCIe Gen3 and USB 3.0.

That mixed VLEN is the key engineering detail: any runtime using vector code across both core types must dispatch per-core, not per-chip — the same constraint the OpenSBI K3 series hit at firmware level.

What the Next toolchain baseline actually is

The overlay raises the core toolchain rather than patching individual packages:

ComponentVersion in NextStated reason
GCC15 (default) + 16First versions with native, complete RVA23 profile support via standard -march
Binutils2.46Assembler and linker support for the RVA23 profile
Glibc2.42RISC-V RVA23 string and memory-operation optimisations
LLVM21 (default) + 22Fast-moving RISC-V backend; lets Rust and Clang-built packages pick up current optimisations
OpenSSL3.5RISC-V Vector / Zbb assembly-level optimisations for SM3, SM4, SHA-512 and ChaCha20

Every package in the repo is built against the RVA23 baseline. The SIG also backported SpacemiT K1/K3 IME matrix-extension support into GCC 15/16 and binutils — the practical consequence being that a stock compiler in this repo can target the vendor's matrix instructions without a separate vendor toolchain.

The stated maintenance policy is to carry as few downstream patches as possible and track upstream versions directly, and to use Next as a proving ground for the next deepin major version.

The AI path: deepin-modelhub, GGML and core dispatch

The headline claim is that this is the first time a RISC-V desktop OS has out-of-the-box offline large-model inference. The chain is toolchain → runtime → application:

Kernel-side, the SIG maintains a 6.18 kernel branch and U-Boot for K3 in deepin-ports-kernel, plus the GPU driver and firmware in deepin-ports, described as tested working on real hardware.

The image is published in the deepin-ports image list (riscv64), and the standard flow is partition, flash bootloader, flash system image.

What is not disclosed

Several numbers a buyer would want are absent from the published material and are not inferable from it:

Treat ">10 tok/s at 30B" as a vendor capability number attached to the silicon, not a deepin benchmark result.

Engineering takeaway

Two things here are portable beyond deepin. First, an overlay repo with a raised profile baseline is a low-risk pattern any distribution can copy: mainline stays stable, RVA23 users opt in, and the delta gets validated before a major-version jump. Second, backporting IME into mainline GCC and binutils is the difference between a vendor extension that needs a private toolchain and one a distro can rebuild from source — worth watching as the RISC-V matrix extensions (IME/VME/AME) move through standardisation.

For evaluation, flash the published image and run your own GGUF model through llama.cpp on it. The published numbers do not substitute for that.


Sources

Verification notes