Table of Contents
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:
- 8 × X100 general-purpose: 4-wide issue, out-of-order, 64-bit, RVA23-compliant, >9.0/GHz SpecINT2006, up to 2.4 GHz, 8 MB shared L2, roughly 130 KDMIPS for the whole part.
- 8 × A100 AI cores: RISC-V AI-CPUs using SpacemiT's own IME matrix extension, about 60 TOPS (INT4 sparse) combined, spec'd to run up to a 30-billion-parameter model at >10 tokens/s.
- 2 × RT24 real-time cores for system management and low-power control.
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:
| Component | Version in Next | Stated reason |
|---|---|---|
| GCC | 15 (default) + 16 | First versions with native, complete RVA23 profile support via standard -march |
| Binutils | 2.46 | Assembler and linker support for the RVA23 profile |
| Glibc | 2.42 | RISC-V RVA23 string and memory-operation optimisations |
| LLVM | 21 (default) + 22 | Fast-moving RISC-V backend; lets Rust and Clang-built packages pick up current optimisations |
| OpenSSL | 3.5 | RISC-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:
- The bundled local assistant (小U同学, formerly UOS AI) runs on deepin-modelhub, a local AI runtime built against RVA23 plus the SpacemiT matrix extension. It performs CPU dispatch for riscv64 and selects an operator implementation based on detected chip capability.
- GGML, the compute library behind llama.cpp, has been built with SpacemiT instruction-set support enabled. The SIG states all variants were built in the RVA23 repo and RVV acceleration verified.
- In use, inference tasks are dispatched to the eight A100 cores.
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:
- Memory configuration of the K3 board used for the demo — not stated.
- Which 30B model, which quantisation, and what prompt/batch settings produced ">10 tokens/s" — not stated. The 60 TOPS figure is explicitly INT4 sparse; no dense INT8 equivalent is given.
- Tokens/s in deepin specifically. The >10 tok/s figure is quoted as a chip capability; the deepin article does not publish its own measured throughput on K3.
- Whether llama.cpp performance was measured, only that GGML builds and RVV acceleration was verified.
- Which GCC/LLVM actually produced the shipped image — the repo ships two of each; the defaults are stated, not the image's build compiler.
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
- OSChina — "小板子运行大模型:deepin 25 RVA23 版本适配进迭时空芯片 SpacemiT K3", published 2026-09-17 — https://www.oschina.net/news/502538
- AIBase (English rewrite of the same adaptation note) — https://www.aibase.com/news/31122
- deepin-ports riscv64 image list — https://deepin-community.github.io/sig-deepin-ports/images/riscv64
- deepin-ports device support matrix — https://deepin-community.github.io/sig-deepin-ports/matrix
- Next (RVA23) repo RFC —
deepin-community/rfcs#18(referenced in the adaptation note)
Verification notes
- All figures (8 × X100 @ 2.4 GHz / >9.0 SpecINT2006 per GHz / 8 MB L2 / 130 KDMIPS; 8 × A100 / 60 TOPS INT4 sparse / 30B / >10 tok/s; 2 × RT24; VLEN 256 vs 1024; 15–25 W; GCC 15+16, Binutils 2.46, Glibc 2.42, LLVM 21+22, OpenSSL 3.5; 6.18 kernel branch) are quoted from the deepin-ports adaptation note reproduced by OSChina on 2026-09-17. Nothing was interpolated.
- Single-source caveat: the Sohu, AIBase, ChinaZ and ai-damn.com versions are all rewrites of the same deepin-ports note, not independent reporting. There is, as yet, no independent third-party measurement of the K3 + deepin combination.
- 60 TOPS is INT4 sparse per the source. It is not comparable to a dense INT8 TOPS figure from another vendor; the draft says so explicitly.
- ">10 tokens/s at 30B" is a chip capability statement carried in the K3 description section, not a deepin-measured benchmark. The draft separates the two.
- No process node, no memory configuration, no board model for the K3 are given in the source; those fields are listed as not disclosed rather than guessed.
- The K3 was first announced in January 2026; this draft is about the 2026-09-17 deepin enablement milestone, not the chip launch.
- Language: terms like "小U同学" and "国产" appear in the Chinese source. This draft deliberately frames the story as an open-standard / multi-source-supply engineering milestone and avoids domestic-industry framing, per house style for the overseas audience.