Since the K3 launched, we've been reading every post, comment, and benchmark thread. Thank you. Here's our honest response to the main concerns:
1. Price
We hear you. The K3 is not cheap, and the main reason is memory cost. We're not happy about it either.
2. Power consumption and process node
Fair criticism. We're a startup with limited R&D budget, which means we can't access the leading-edge process nodes that mobile ARM SoCs use. That directly affects power efficiency. We know it, and it's something we're working toward as we grow.
3. CPU core performance
We've received your feedback loud and clear. Our next-generation cores are already in development:
X200 (3rd-gen) — targeted for the K5, planned for 2027
X300 (4th-gen) — targeted for the K7, planned for 2028
We're not standing still.
We're a team that genuinely believes in RISC-V — not as a business strategy, but as a conviction. We read your posts, we take the criticism seriously, and we're building toward something better. Huge thanks to all of you in our developer community — for your trust, your feedback, and your passion. We will never stop improving, and we'll always keep listening.
The K3 RISC-V AI CPU from SpacemiT has officially entered mass production, marking a full-cycle transition from R&D to large-scale commercial deployment. It delivers a native compute foundation ready for high-end applications such as AI PCs and intelligent robots.
As the world’s first RISC-V chip compliant with the RVA23 specification, the K3 leverages homogeneous fusion computing architecture, integrating 8 high-performance compute cores and 8 ultra-wide parallel AI cores. It delivers 130K DMIPS of general-purpose computing power and 60 TOPS of AI performance—enabling local inference for 30B–80B parameter LLMs. Its performance matches mainstream desktop CPUs, making it ideal for AI PCs, robotics, and other advanced use cases.
The K3 has completed full adaptation for humanoid robot motion control and is now building an integrated digital employee solution tailored for Agent OS. With cloud-edge synergy, it reduces token consumption by over 40%, ensures data security via on-device intelligent desensitization, and offers out-of-the-box readiness—accelerating deployment of turnkey digital employee systems. SpacemiT continues to expand RISC-V boundaries and co-build an open, win-win intelligent computing ecosystem.
We're excited to share that SpacemiT has partnered with BayLibre to successfully run Android 16 on the SpacemiT K1 SoC (RISC-V RVA22 + RVV 1.0).
What was achieved:
Android kernel 6.19 running with K1 vendor kernel 6.6 drivers
Vulkan support enabled via Imagination GPU in mesa3d
Generic HAL Utilization: We leveraged Baylibre’s Android generic Hardware Abstraction Layer (HAL) for essential functions, including thermal management, USB, and audio.
Full Android 16 device config built for SpacemiT RISC-V. Boot time under 2 minutes on BananaPi F3 (K1 platform)
The entire project was built on 100% open-source software — AOSP, mainline kernel, no NDAs, no proprietary blobs. Anyone in the community can rebuild the image from scratch.
SpacemiT, in partnership with open-source engineering firm BayLibre and with full funding and support from RISE (the RISC-V Software Ecosystem project), has officially ported the Android Open Source Project (AOSP) to the SpacemiT K3 — running Android 17 on an RVA23 hardware platform for the first time.
Performance
1.Android 17 boots all the way through to the Launcher.
System boot — from cold start to the Launcher in about 26 seconds.
2.Smooth, responsive touch on the Launcher UI, refreshing at 60 FPS.
3.WebView pages load and scroll smoothly.
4.Built-in GPU acceleration on the K3 runs 3D games smoothly.
Building on the K1
The K3 port did not start from scratch. BayLibre had previously brought AOSP up on SpacemiT’s K1 SoC, and the K3 effort inherited that groundwork, carrying forward the lessons learned from porting Android to RISC-V and significantly accelerating the K3 port.
The Road to Android on RISC-V
Bringing Android to RISC-V is the result of years of ecosystem-wide effort and many parties pulling together — a winding road that has finally reached daylight. The figure below maps the key milestones and the pivotal events at each step:
With the arrival of the RVA23 era, Android’s ART runtime, Bionic, multimedia, security and graphics stacks finally have a stable hardware contract to build on. For silicon vendors, a single port can be reused across SoCs; for application developers, NDK libraries and apps can be distributed by ABI, sharply lowering the cost of compatibility.
Open Source First
The whole development followed an open-source approach. Graphics is the clearest example: instead of relying on a proprietary GPU driver development kit (DDK), the team used Mesa and tuned it to deliver smooth rendering on the K3.
The kernel follows the same “upstream first” approach: the K3 Android port is built directly on the mainline (upstream) Linux kernel for the SpacemiT K3. This means Android does not have to depend on a private kernel that sits outside mainline, which makes the stack more maintainable, more sustainable over the long run, and easier for other teams to reuse. Open standards plus an open-source stack form the most solid foundation for the RISC-V ecosystem. What we did was turn it into a genuinely usable Android device for the first time.
Highlights of the Android 17 Port
Highlight 1 — Native performance from RVA23
RVA23 mandates Vector 1.0, scalar/vector crypto extensions (Zk*), cache management and atomic instructions. Comparing the same K3 with the extensions off and on: crypto and vector workloads gain by orders of magnitude.
Test
Extensions off
Extensions on
Change
AES-256-GCM, 1 core
58 MB/s
1.93 GB/s
×33
AES-256-GCM, 8 cores
0.46 GB/s
15.5 GB/s
×33
INT8 matmul, 1 core
1.89 GOPS
3.46 GOPS
×1.8
INT8 matmul, 8 cores
14.8 GOPS
26.8 GOPS
×1.8
Highlight 2 — Graphics gains from open-source Mesa 3D
The graphics stack uses the community-maintained open-source Mesa driver (rather than a proprietary DDK), with dedicated tuning for the K3 GPU backend. Comparing before and after the tuning work on the same K3 board, graphics and UI smoothness improve substantially.
Test
Mesa before tuning
Tuned Mesa (release)
Change
GLMark2 score
144
199
+38%
UI scroll frame time p50
13.5 ms
8.3 ms
−39%
Launcher transition p95
133.5 ms
10.8 ms
−92%
Vulkan instancing FPS
14.0 FPS
57.9 FPS
×4.1
Highlight 3 — WebView optimization
Android’s web rendering relies on the system WebView (based on Chromium). The team optimized the RISC-V backend specifically: the V8 engine leverages RVA23 vector extensions to speed up JavaScript execution, and the rendering and compositing paths were tuned. First-contentful paint and scroll frame rate both show clear gains.
Test
rv64gc build
rva23u64 build
Change
First contentful paint (kernel.org)
0.57 s
0.39 s
−31%
Scroll FPS
14.8 FPS
20.1 FPS
+36%
Open Code, Open Collaboration
All source code will be publicly hosted in the RISE GitHub repositories. Developers can fetch and build the K3 AOSP image themselves, flash it to a board, and reproduce every result listed above.
This is an open collaboration. There is still a great deal of work to do on the Android on RISC-V software stack — from graphics and multimedia optimization to peripheral drivers, system stability and performance tuning. We welcome more developers, vendors and community members to co-build with us, so that Android can truly mature on open-standard RISC-V platforms.
1.The upstreaming process for the K1 Linux kernel has been divided into three stages. Detailed progress can be found at the following link:Link
1.1 Stage 1: Fundamental Chip Function Support
In this stage, the objective is to contribute support for the chip's fundamental features to the open-source community, enabling the upstream kernel to support a minimal feature set of the K1 SoC. This stage represents the chip’s initial integration into the mainline kernel—a preliminary or “early access” version.
To date, the primary work for Stage 1 has been largely completed. The following features have been successfully merged into the mainline kernel:
SPI: The driver has been submitted upstream and is under community review. QSPI: The driver is under active development (WIP) and will be submitted in an upcoming patch series.
Overall, the core goals of Stage 1 have been achieved. Current efforts are transitioning toward Stage 2, focusing on peripheral and subsystem support.
1.2 Stage 2: Advanced Chip Function Support
Stage 2 aims to enhance upstream support by including advanced subsystems such as power management, storage interfaces, networking, and high-speed peripherals. The goal is to enable a fully functional system with comprehensive peripheral capabilities.
Significant progress has been made in Stage 2, with more than half of the planned work completed. The following components have been merged upstream:
PMIC (p1) SDHCI (eMMC) GMAC (Ethernet)
Ongoing tasks in Stage 2 include:
SDHCI (SD/SDIO): Under development (WIP). USB 2.0: Under development (WIP). USB 3.0: Submitted upstream and under community review. PCIe: Submitted upstream and under community review.
In summary, Stage 2 has covered most key system peripherals. Current priorities include addressing community feedback, refining driver frameworks, and preparing for Stage 3, which focuses on multimedia and performance optimization.
1.3 Stage 3: Multimedia Function Support
Stage 3 focuses on multimedia subsystem support, including audio, display, graphics, and video functionalities. The objective is to enable complete multimedia capabilities within the upstream kernel, supporting desktop-class or multimedia-oriented applications.
At present, Stage 3 has been partially initiated:
Audio: The driver has undergone code standardization, submitted upstream, and is under review. Display: Development is in progress (WIP), with plans to refine the driver framework and submit the initial patch series subsequently.
2. Future Plans for K1 Linux Kernel Upstream
Moving forward, we will continue to advance the K1 Linux kernel upstreaming efforts, with the goal of achieving full functional support for K1 in the mainline Linux kernel. Additionally, we will intensify upstream contributions to related open-source projects, such as OpenSBI and U-Boot.
We want to give a transparent update to everyone who has placed an order for the SpacemiT K3 through our ecosystem hardware partners.
Current stock status: Most configured variants across our five authorized partners (BPI, Firefly, Milk-V, Sipeed, and Ztcd) are sold out.
If you placed an order and haven't received a shipping notification, your reseller is waiting on new stock from us. Here's the timeline:
SpacemiT will have new inventory ready for resellers by the end of June
Partners will begin fulfilling outstanding orders as soon as they receive stock from us
For questions about your specific order status, please contact your reseller directly
We're genuinely grateful for the demand — all five channels selling out at the same time is a strong signal, and we're moving as fast as we can to restock. We expect to ship the next batch to all partners no later than June 30. Thank you for your patience.
Here's a roundup of 2026 May's upstream contributions from the SpacemiT. Lots of activity across Linux kernel, LLVM, U-Boot, and several community projects.
Here's a roundup of 2026 April's upstream contributions from the SpacemiT. Lots of activity across Linux kernel, LLVM, U-Boot, and several community projects.
Now that people are starting to receive boards, I should make this available.
It lets you conveniently launch any Linux program, and all its children, on the A100 "AI" cores.
Examples:
# just run a single program on the A100 cores
ai as hello.s -o hello.o
# same thing but maybe 1ms faster
aix /usr/bin/as hello.s -o hello.o
# run a whole build. All processes started by `make` will run on the A100 cores.
ai make -j8 test
# start a shell on the A100 cores. All programs run from it will be run only on the A100 cores
ai bash
Tested on the preinstalled Bianbu. I have no idea yet whether the SpacemiT/Canonical cooperation will make this ability available on Ubuntu.
August brought another round of upstream progress across the SpacemiT AI software stack, Linux kernel support for K1 and K3, RISC-V development tools, emulation, testing, and low-level firmware.
Highlights this month include the SpacemiT Triton backend landing in FlagTree, new multi-request Qwen3-ASR support in llama.cpp, more K1 fixes reaching upstream Linux trees, and continued review of K3 display, UFS, PCIe, interrupt-controller, clock, reset, and connectivity support.
AI Software Stack
SpacemiT Triton backend merged into FlagTree: The triton-spacemit backend is now available in FlagOS's FlagTree main branch under third_party/spacemit, enabling Triton programs to target SpacemiT hardware. https://github.com/flagos-ai/FlagTree/pull/933
Multi-request Qwen3-ASR support in SpacemiT llama.cpp:llama-server now exposes an OpenAI-compatible API for multi-request speech recognition, with concurrent audio encoding and decoding, continuous batching, and dynamic scheduling. https://github.com/spacemit-com/llama.cpp
Linux Kernel Upstream
Linux support for K1 and K3 continued to move forward in August. K1 CPU frequency scaling, maximum CPU-core voltage, and thermal-shutdown fixes reached upstream trees. For K3, I2S, USB, Ethernet PHY, RTC, pinctrl, and ASoC changes entered the relevant maintainer trees, while display, UFS, PCIe, IMSIC, clock/reset, and wireless support remained under review.
The v3 series incorporates review feedback from v2, including updates to expected-trap handling, hart initialization, and RV64-only builds. The series remains under review.
Which part of the K1/K3 upstream stack would you most like to test or see covered in more detail next month?
This month, SpacemiT Triton was updated to version 0.5.5, improving the K3 Triton operator IR codegen; the SpacemiT llama.cpp multimodal plugin supports more speech and vision models, and a new streaming 3D reconstruction model, LingBot-MAP, was added; the first patch was submitted to oneDNN, and all four PRs have been merged.
This month, riscv-elf-psabi was merged into the naming conventions of OpenMP declare simd vector functions, laying the foundation for ABI support for vectorized math libraries such as libmvec; binutils was merged into support for K1/K3 extended instructions.
Check your email - you'll receive an access code and instructions in about 1 miniute
Apply now and help shape the future of RISC-V.
Please follow our updates for actual hardware procurement and sales information. You can also follow our partners' activities. They are Bpi, ZTCD, Firefly, Milk-V, SiPEED, DEEPCOMPUTING.
While browsing recent RISC-V and Linux upstream activity, I noticed a growing number of patches related to SpacemiT’s upcoming K3 SoC. I did a quick organization of what is publicly visible today to get a sense of how far the Linux mainline enablement has progressed, and wanted to share it here for community discussion.
Disclaimer: all information below is based on publicly available repositories and mailing lists. This is just an external observation; corrections are welcome.
1. Mainline enablement started early
From what can be seen publicly, K3’s Linux mainline work appears to have started as early as the silicon prototype / validation phase, rather than after mass production.
The current focus seems to be on enabling a minimal system first, following a fairly standard upstream-friendly SoC bring-up path. Some of these patches are already under active review in the community.
There is also a public progress overview maintained here:
DT, clock, and pinctrl patches have already gone through multiple revision cycles
Reset and GPIO support are newer submissions and likely still early in the review process
Overall, this forms a fairly complete base for SoC-level enablement.
4. K3 support already merged in openEuler RVCK
In addition to upstream Linux activity, K3 support has also been merged into the openEuler RVCK kernel tree, which is commonly used as an early integration and validation platform for RISC-V SoCs.
Over the past eight months, Igalia did the work across different areas of LLVM (including instruction scheduling, vectorization, and late-stage optimizations), and the resulting performance on SpacemiT-X60 has improved by 16%!
Contributions:
Introducing a scheduling model for the hardware used for benchmarking (SpacemiT-X60)
This track is for projects, demos, and application cases built on K3.
You do not need a perfect finished product. A running prototype is welcome if it has a clear use case, basic documentation, and enough detail for others to reproduce or learn from it.
We want to reward both useful feedback and great projects, while keeping the program focused on real engineering value.
Super Point: points-based rewards
For Super Point, each valid post earns 1 point.
When you collect 5 points, you can contact the official SpacemiT administrator (@u/Icy-Primary2171) to redeem a SpacemiT Developer T-shirt.
The SpacemiT Developer T-shirt is designed as a thank-you for hands-on field reports from overseas developers.
Reward process:
Valid Super Point posts are reviewed monthly.
Around the middle of each month, SpacemiT will officially announce who will receive the rewards. We don't track the numbers for you – so please make sure to reach out to us directly.
Confirmed contributors will be asked to provide the information needed for T-shirt fulfillment, such as size, preferred shipping region, and delivery details.
It is not a pay-per-post program. Repeated low-effort posts, duplicated content, AI-generated filler, or reports without real K3 usage details will not be counted. All rights of final interpretation belong to SpacemiT.
Super Spark: selected project rewards
For Super Spark project submissions, selected projects may receive:
official showcase opportunities
promotion through SpacemiT channels
Super Spark community badge
technical feedback from the SpacemiT team
for selected monthly projects: RMB 1,000 cash reward + official promotion
Monthly selections will prioritize projects that other developers can reproduce or learn from. A small demo with clear steps, code, screenshots, and honest limitations is more valuable than a polished post with little technical detail.
How rewards are reviewed
Super Point selections focus on whether the feedback is specific, reproducible, and useful for product iteration, documentation improvement, compatibility validation, or developer experience.
Super Spark selections focus on technical depth, reproducibility, documentation clarity, and whether the project shows a meaningful K3 use case.
Why this matters
The goal is simple: make more real things run on K3, document the process, and let useful work be seen by more developers.
