SpacemiT K3：一款具备 60 TOPS AI 算力的 RVA23 RISC-V AI CPU
SpacemiT 预览版本
### 摘要
本文介绍了 SpacemiT（进迭时空）的第二代边缘 CPU 计算子系统 K3。该系统采用同构融合范式：在一个统一的 RISC-V 指令集架构（ISA）下，集成了一个高性能 RISC-V CPU 集群（X100）和一个 AI 优先的 RISC-V AI-CPU 集群（A100），并运行单一的 Linux 操作系统。K3 探索了如何在资源受限的边缘硬件约束下，通过紧凑的软硬件协同设计栈，同时提供通用计算和 AI 能力。本文描述了 X100 和 A100 的工程选择与实现，特别强调了 RVA23 的启用以及针对高效 LLM（大语言模型）推理的软硬件协同设计。文章还概述了基于 K3 构建的 OS 调度、资源治理以及 AI 软件栈，形成了一套面向边缘 AI 和机器人的集成解决方案。
关键词
RISC-V，AI-CPU，RVA23，同构融合，高性能 CPU，IME 扩展，Triton
### 1. 引言
随着边缘计算进入由本地 LLM 和机器人技术驱动的新阶段，关键挑战在于单一系统中同时提供强大的通用性能和强大的 AI 性能，并将其转化为可扩展、具有成本效益的商业产品。为解决这一问题，我们提出并实现了面向边缘 AI 时代的**同构融合计算范式**：在统一的 RISC-V ISA 和扩展框架下，我们将高性能 RISC-V CPU 与 AI 优化的 AI-CPU（或 ISA 集成的 AI 计算单元）相结合。两者运行相同的操作系统（Linux），并支持以线程或任务为基本调度单元的统一调度和资源治理，从而实现“一个平台、一套栈、一个操作面”的系统级交付模式。
这项工作对应于我们的第二代芯片。在第一代中，我们在实际部署中验证了同构融合的可行性和客户价值：一方面，通用 RISC-V CPU 确保了系统和生态的兼容性、控制平面的确定性以及工程的可维护性；另一方面，ISA 集成的 AI 计算资源可以在同一地址空间和进程模型内以低开销被调用，大幅降低了边缘部署的系统复杂度和生态碎片化。这一演进路径类似于移动互联网时代：为了在智能手机上同时实现高性能和低功耗，业界在运行单一操作系统的 Arm 生态基础上引入了 big.LITTLE 设计。在 AI 时代，我们的同构融合旨在同时实现高性能和高 AI 吞吐量，同时将异构性引入的系统碎片化成本压缩在可控范围内。
SpacemiT, 2026/01/29
与第一代相比，第二代产品在三个清晰且可衡量的维度上进行了改进：
* 更强的通用计算能力： 第二代大幅提升了 CPU 性能和系统响应速度，提供更强的单线程和多线程能力，以支持边缘控制平面、系统服务和复杂的应用逻辑。同时，通过将 ISA 兼容性和软件生态对齐锚定在 RVA23 上，实现了更好的工具链和 OS 兼容性以及长期的可演进性，为框架、驱动和应用的持续迭代提供了更稳健的平台基础。
* 部署规模： 为满足模型侧的扩展需求，它支持在边缘端稳定部署和持续演进更大的 LLM 或更多数量的智能体（Agent）。
* 更高效的软硬件协同设计： 包括但不限于针对不同应用场景定制的、跨越片上 SRAM 和片外主存（LPDDR）的分层存储系统；针对交互式工作负载的低延迟执行路径；以及端到端的性能驱动型异构调度策略，避免仅通过孤立的内核或峰值 TOPS 来描述真实的用户体验。
本文其余部分组织如下：第 3 节描述整体系统架构；第 4 节详述硬件设计和关键机制；第 5 节介绍软件栈；第 6 节报告评估方法和性能结果。
### 2. 系统概览与设计理念
#### 2.1 设计目标与系统权衡
为了基于 RISC-V 架构交付一款面向两种代表性边缘形态（AI 计算机和 AI 机器人）的量产 AI CPU，我们将芯片的工程约束最终收敛为以下三点：
* 12 nm 工艺： 采用已进入长期量产且明确为高效能边缘设备定位的 12 nm 级 FinFET 平台（例如量产中的 12FFC+；或面向 AI 使能的 IoT/边缘设备的 N12e），从而降低制造和成本风险。
* 晶圆面积预算 (<150 mm²)： 将晶圆尺寸限制在 <150 mm² 以降低单颗芯片成本和良率风险（业界广泛使用的模型表明，芯片成本随面积呈显著的超线性增长，且良率随面积增加而下降），并避免依赖供应链受限的资源，如超大封装和高层数基板。
* 30 W 功耗： 将 TDP 设定为 30 W，与边缘 AI/机器人模块的主流功耗包络一致，使其能够在既定的散热方案和产品形态（例如 Jetson AGX Orin 系列提供的 15 W / 30 W / 50 W 等功耗档位）内实际部署。
在上述工艺、面积和功耗的约束下，我们将架构实现进一步收敛为第二代芯片的计算系统设计，主要组件如下：
* 8 个 X100 核心： 一个完全符合 RVA23 标准的高性能 RISC-V CPU 子系统，针对控制平面的确定性、生态兼容性和系统服务的长期可维护性。
* 8 个 A100 核心： 60 TOPS 级的通用 AI 计算能力，作为边缘推理工作负载的主要引擎。
* 系统级使能器和场景优化： 消除端到端吞吐量、延迟和可部署性方面的关键系统瓶颈，包括：
* 内存和高速 I/O 子系统： 例如 2×32-bit LPDDR5 控制器和 UCIe 接口，在边缘面积和功耗包络内最大化有效带宽和扩展能力。
* 低延迟响应与控制： 例如双 RT24 设计，用于隔离电机控制和传感等实时任务；关键事件通过 MSI 中断传递并快速触发唤醒，从而稳定延迟并减少抖动。
* AI 数据通路关键组件： 例如 AI-DMA，减少数据移动开销，提高有效带宽利用率，并为多智能体和多模型并发下的资源治理提供可控的原语。
需要强调的是，设计一款量产级的边缘 AI CPU 本质上是一项软硬件协同设计的系统工程。仅满足硬性的硬件约束（如工艺节点、面积和功耗）不足以交付规模化的产品。实际的可部署性和商业可用性最终由软件栈决定，包括编译器/算子库和运行时、操作系统和驱动程序，以及用于模型部署和性能分析的工具链，以及它们与底层微架构的协同优化融合。基于第一代客户部署积累的软件栈资产和工程验证，我们将软件的通用性和易用性作为第二代架构设计的首要门槛约束。
#### 2.2 系统概览
本文重点介绍 K3 计算子系统：一个由 2 个 X100 集群（通用）和 A100 核心（AI）组成的同构融合计算平台。我们描述其关键能力，包括 ISA/Profile 配置、外部和本地中断子系统（MSI/APIC）、指令追踪（Trace）基础设施以及通过 IOMMU 实现的 I/O 隔离和虚拟化。
为了提供高通用性能，K3 SoC 在 2 个集群中集成了 8 个 X100 核心，提供 130K DMIPS 的聚合计算能力。X100 核心是根据 RISC-V 应用处理器标准 RVA23 Profile 设计的，并完全实现了 RVA23U64（用户模式）和 RVA23S64（监管者模式）规定的所有强制性 ISA 扩展。此外，该核心主动支持可选扩展，包括向量加密（如 Zvkng, Zvksg, Zvbc）以及 FP16/BF16 计算相关扩展（如 Zfh, Zvfh, Zfbfmin, Zvfbfmin, Zvfbfwma）。作为 RISC-V 生态系统中的关键标准，RVA23 Profile 旨在协调 64 位应用处理器的实现，以便可以在广泛保证的 ISA 扩展集上构建二进制软件生态系统，同时通过少量可发现的粗粒度选项保持灵活性。通过全面兼容 RVA23，X100 核心确何了与基于此规范构建的操作系统和应用程序的无缝兼容，从而能够快速集成到日益成熟的 RISC-V 软件生态系统中。
为了提供高 AI 性能，K3 SoC 集成了 8 个 A100 核心（2 个集群），提供 60 TOPS 的 AI 算力。A100 同样建立在 RVA23 Profile 定义的标准化 ISA/工具链基线上：一方面，RVA23U64 将 V（Vector）提升为强制性扩展，连同 Zvfhmin/Zvbb/Zvkt 等强制性向量子扩展；另一方面，RVA23U64 将与 AI 混合精度密切相关的 BF16 相关扩展（Zfbfmin, Zvfbfmin, Zvfbfwma）列为可选，为 AI/ML 数据类型和算子的演进提供了可发现且可移植的标准接口路径。K3 上的 A100 提供的典型 AI 计算规格总结在表 1 中。
表 1: K3 AI 计算能力
| K3 | 稠密 (TOPS) | 稀疏 (TOPS) | 备注 |
| :--- | :---: | :---: | :--- |
| INT4 | 30 | 60 | 支持块缩放 (block scaling) 以保持 INT4 量化模型的精度 |
| INT8 | 15 | 30 | 加速卷积以提高卷积核吞吐量 |
| BF16/FP16 | 7.5 | N/A | 支持 IEEE FP16 和 bfloat16 (Brain Float 16) 格式 |
| FP8 | 7.5 | N/A | FP8 操作数在计算前转换为 BF16 |
为了支持基于 MSI（消息信号中断）的外部中断以及本地中断（软件中断和定时器中断），K3 SoC 集成了 SpacemiT 自研的中断控制器 APIC。APIC 由 APLIC 和 ACLINT 组成：
* APLIC (Advanced Platform-Level Interrupt Controller) 遵循 RISC-V 高级中断架构 (AIA)。
* ACLINT (Advanced Core Local Interruptor) 遵循 RISC-V 高级核心本地中断器 (ACLINT) 规范。
MSI 将“外部中断”实现为设备向指定地址发出的内存写入消息。从机制上讲，这避免了传统基于引脚的中断（如共享 IRQ 线）的常见问题，以及 IRQ 共享下扫描多个处理程序的开销。MSI 还可以利用消息传递的排序语义，有助于减少在观察到中断时可能需要的额外同步或回读路径，然后再使其对应的数据写入可见。此外，MSI/MSI-X 支持多个中断向量，并且可以配置为针对特定的 CPU/核心，这对机器人工作负载非常有益：来自关键传感器和控制回路的中断可以被引导至隔离的核心，以减少抖动并提高实时确定性。
为了启用处理器核心的指令追踪 (Trace)，K3 SoC 为 X100 和 A100 集成了 RISC-V Trace 编码器和相应的接收组件。X100 和 A100 的指令追踪接口符合 RISC-V Hart-to-Trace Interface 规范；Trace 编码器根据 RISC-V N-Trace (Nexus-based Trace) 规范 (Version 1.0) 设计；Trace 组件寄存器定义与 RISC-V Trace Control Interface 规范 (Version 1.0) 兼容，支持通过系统互连进行配置。X100/A100 Trace 编码器实现了以下标准功能：
* BTM 模式编码输出；
* 基于调试触发器 (Debug Triggers) 的 Trace 启用/禁用和事件发射；
* 基于地址压缩的编码优化；
* Trace 数据溢出时的事件传输；
* 所有权事件消息，便于区分和跟踪 Linux 及其他 OS 中的进程执行流。
为了实现 I/O 子系统的安全隔离和可管理性，K3 SoC 集成了 SpacemiT 自研的 T100 IOMMU。T100 遵循 RISC-V IOMMU 架构规范和 RISC-V 服务器 SoC 规范。在硬件层面，它提供设备 DMA 地址转换、访问控制和隔离保护；对于虚拟化，它进一步提供硬件辅助的 I/O 虚拟化，支持设备直通 (PCIe Passthrough) 和设备虚拟化 (如 SR-IOV)。
图 1: K3 系统概览
(图注翻译：图 1 展示了 K3 的系统架构。包括 X100 集群、A100 集群、第三方一致性互连、DMC（内存控制器）、PCIe-RC、IOMMU、UCIe、AI-DMA、APIC、MSI 路径、Trace Funnel 等组件。)
### 3. 硬件设计
在 K3 计算系统中，X100 和 A100 在统一的 RISC-V 架构框架下实现了互操作性；其直接价值体现在通用和 AI 工作负载能够在同一软件栈内协同执行的能力。更重要的是，这种方法避免了传统异构架构典型的“双 OS / 双栈”配置并存，以及由此产生的资源占用、跨边界开销和维护复杂性。
我们观察到 AI 软件栈正不断向更高的复杂度和对开源依赖的更深依赖演进：涵盖内核和设备驱动、容器和运行时、编译器和框架，以及更广泛的模型生态系统，关键能力日益由一组快速演进的上游开源组件组成。这种趋势使得硬件供应商难以长期维持“独立重建封闭专有栈”的方法；相反，系统软件必须能够随时间跟踪上游社区的迭代和升级，以保持在功能、性能和安全性方面的竞争力。在此背景下，采用 Linux 作为底层操作系统来托管和集成这些开源组件，是构建 AI 软件栈最自然、最可持续的选择。
在当今主流的 RISC-V 软件生态系统中，主机 CPU 域通常使用 Linux 作为通用软件基底；同时，为了支持 AI 框架和运行时并保持与上游开源组件的长期兼容性，设备侧/加速器侧的 AI 软件栈从执行单元的角度来看，实际上也被迫采用 Linux。如果遵循传统的异构“主机 CPU + 加速器”设计，这本质上等同于在同一系统内运行两个很大程度上相同的 Linux 实例（在内核和基础用户空间组件上都有大量重叠），并通过跨边界机制协调它们。这种重复的栈不仅会产生额外的资源消耗（内存、存储和驻留服务），还会引入边界导致的数据通路和同步开销（IPC、数据拷贝和上下文切换），并显著增加版本维护、安全补丁和验证矩阵的复杂性——从而破坏整体系统效率、可维护性和长期可演进性。
#### 3.1 X100
X100 是一款基于 RISC-V 指令集架构的高性能处理器核心，完全符合 RVA23 Profile。它采用 4 宽分发、乱序执行微架构，在实现高计算性能的同时平衡了能效和芯片面积成本。该设计有效地针对高性能边缘工作负载，也适用于入门级服务器部署。为了满足高性能计算和可扩展多核集成的需求，X100 包含了多核互连、虚拟化支持、可靠性/可用性/可服务性 (RAS) 和安全机制等关键特性。
从架构角度看，X100 以 OpenC910（玄铁 C910 的开源版本）为初始参考点，并在多个子系统中引入了广泛的优化和功能增强。主要改进包括：增加前端取指带宽并提高分支预测准确性；加宽解码和分发并利用多种技术提高执行效率；重构加载/存储子系统以增加内存带宽同时大幅降低访问延迟；增加符合 RISC-V Vector Extension v1.0 的向量执行单元；以及优化多核互连以提高可扩展性和一致性支持。
除了性能，X100 在 ISA 支持方面保持了高度的一致性和前向兼容性。对于通用计算，X100 不引入任何额外的专有 ISA 扩展，完全依赖官方 RISC-V 标准指令集。在此基础上，它通过支持 RVA23 Profile 的所有强制性组件来跟踪最新的行业标准演进，同时还实施了选定的可选扩展和 Profile 中未明确列出的附加扩展，确何适应未来的软件生态系统和硬件平台演进。
3.1.1 前端
X100 分发宽度的增加对前端的指令取指带宽提出了更高的要求。为了解决这个问题，X100 处理器核心实施了一系列关键微架构优化，旨在显著提高有效指令取指带宽。这些增强确保了向后端执行单元持续高效地供应指令流。优化主要集中在两个关键维度：提高分支预测器性能和增加取指并行度。
* 分支目标预测： X100 对 L0 分支目标缓冲 (BTB) 的时序路径进行了针对性优化，并适度扩大了其条目容量。此外，通过引入更适合程序分支访问局部性特征的复杂替换算法，有效地提高了 L0 BTB 的命中率。这一增强直接减少了由目标地址误预测引起的前端气泡和相关的取指流水线中断。
* 条件分支方向预测： 对于条件分支方向预测，X100 采用了更先进的 TAGE (Tagged Geometric History Length) 预测器，取代了之前的 Bi-Mode 算法。TAGE 预测器利用长全局历史模式进行预测，显著提高了复杂控制流行为的预测准确性。
* 返回地址预测： 对于函数调用返回，X100 实现了一个基于链表结构的返回地址栈 (RAS)。这种设计更稳健地支持涉及多线程或深层嵌套函数调用的乱序执行场景中的返回地址预测，从而提高了返回指令的预测性能。
* 指令取指带宽优化： 为了提高取指带宽，X100 将指令缓存 (ICache) 的组织结构从 2 路组相联扩展到 4 路组相联。这一修改有效地减少了因路冲突导致的缓存未命中概率，从而增强了指令供应的连续性。为了进一步减轻访问延迟，X100 将 ICache 和 L2 Cache 之间的数据传输带宽从每周期 128 位增加到 256 位。这减少了下级缓存访问通道的争用和占用。
* 指令分发与融合： 为了充分利用后端的乱序执行能力，X100 将指令分发带宽从每周期三条指令加宽到四条。这确保了解码和分发阶段能够持续向后端供应充足的指令流。此外，X100 前端集成了多种静态确定的指令融合模式。这些模式将常见指令序列组合成更高效的微操作。这种指令融合机制有效地增加了有用的指令分发带宽，而无需引入新的 ISA 扩展，从而保持了完全的 RISC-V 兼容性。
* 可靠性增强： 除了性能改进，X100 前端还包含了可靠性增强。鉴于 ICache 中不存在脏缓存行，X100 为 ICache 引入了奇偶校验机制。该机制能够实时检测缓存指令数据中的单比特错误，显著增强指令存储的可靠性。同时，当前端检测到错误时，错误信息会通过官方 RISC-V RERI (Reliability, Availability, and Serviceability Error Reporting Interface) 报告。此功能允许准确记录和报告各种前端可靠性事件，为系统级诊断和恢复机制提供关键支持。总的来说，这些特性增强了 X100 处理器的整体 RAS 特性。
图 2: X100 核心框图
(图注翻译：图 2 展示了 X100 核心的模块框图。包括前端（PC 生成、ICache、TAGE、L0/Main/Ind BTB、RAS、指令缓冲、融合）、中端（解码&拆分、重命名表、ROB、发射队列、寄存器堆）、以及后端执行块（整数、浮点、向量、加载/存储、MMU 等）。)
3.1.2 中端
中端包括指令解码、重命名、分发和发射阶段。我们在这一阶段的微架构重新设计的一个主要重点是从 3 宽过渡到优化的 4 宽流水线结构。
在基线 OpenC910 架构中，指令解码 (ID) 阶段是 3 宽的，而后继的指令就绪 (IR) 阶段已经扩展到 4 宽以适应源自 ID 阶段的潜在指令拆分。为了使前端吞吐量与后端容量对齐，我们重新设计了解码逻辑以支持 4 路并行解码。
解码宽度的增加需要下游流水线结构进行相应的增强，以处理更高的指令吞吐量。我们相应地增加了发射队列的深度，以容纳更多数量的在途指令，从而防止因队列容量限制导致的结构性冒险。同时，我们集成了一个额外的算术逻辑单元 (ALU) 以缓解因执行资源不足引起的结构性冲突。
流水线的加宽、缓冲区的加深以及执行单元的增加不可避免地引入了确定性的时序挑战。为了缓解与这些扩展相关的潜在关键路径退化，我们为新 ALU 采用了资源共享策略。新 ALU 不增加专用的寄存器堆读端口，而是复用分支处理单元 (BRU) 的读端口。具体来说，当没有分支指令发射时，两个整数发射队列可以利用 BRU 的寄存器读端口向额外的 ALU 分发指令。这种端口共享方法增强了并行执行能力，同时有效地控制了关键时序路径的增长，降低了时序恶化的风险。
为了进一步利用微架构的乱序执行潜力，我们在中端实施了几项关键优化：
1. 立即操作数消除： 添加逻辑以消除某些立即操作数的物理寄存器分配，从而减轻寄存器堆压力。
2. 提前唤醒： 采用一种策略，在长延迟操作（如除法或 L1 缓存未命中）执行期间提前释放依赖资源，有效减少指令停顿时间。
3. 误预测时的前端资源提前释放： 前端流水线中的资源在误预测路径上更早释放，减少了与分支误预测相关的性能损失。
4. 增强的发射队列管理： 修改了发射队列的平衡策略，并引入了提前解除分配机制。这些更改提高了发射队列的利用效率，有效地提供了额外的队列深度。总的来说，这些优化显著增强了处理器在乱序执行期间的指令调度效率和资源管理能力。
图 3: X100 前端分支预测器流水线
图 4: X100 3-ALU 流水线结构
3.1.3 内存子系统
内存子系统是处理器微架构的关键组成部分，负责内存指令的地址生成、虚拟到物理地址转换、缓存查找以及片外内存访问事务的调度。其性能（通常通过带宽和延迟指标衡量）代表了限制现代设计中整体处理器效率的主要瓶颈之一。X100 处理器具有重新设计的内存子系统，在执行带宽、总线带宽和总线延迟方面较其前代架构有显著改进。
X100 包含两条通用流水线，每条都配备专用的加载/存储单元。相应地，数据缓存 (DCache) 的结构和组织被重新配置以使其访问带宽翻倍。然而，增加的带宽通常会提升内存指令的乱序执行程度，可能引入更多的内存冒险——特别是虚假的读后读 (RAR) 和读后写 (RAW) 冒险——这会导致大量的流水线刷新和重填惩罚。为了缓解这个问题，X100 实现了一个监听（Snoop）监视器来过滤虚假冒险，并采用微操作 (uop) 粒度的冒险预测器。该预测器主动识别潜在的数据依赖冲突并延迟冲突指令的执行，从而显著减少与内存冒险相关的延迟惩罚。
X100 将总线宽度升级至 256 位，并利用类似 CHI 的协议与多核互连单元接口，增强了互连效率。关键优化包括重构几个关键缓冲区：
* 写合并缓冲区 (WMB) 经过重新设计，以在保持相同条目数的同时提高合并效率和总线利用率。
* 行填充缓冲区 (LFB) 和牺牲缓冲区 (VB) 合并为一个统一的填充与牺牲缓冲区 (FVB)。这种资源共享方法在提高利用效率的同时减少了总缓冲区资源开销，解决了以前限制未完成请求容量的结构性冲突，从而增强了核心的整体未完成事务能力。
这些缓冲区优化使得在 WMB 和 FVB 中同一缓存索引下的多行访问能够并发进行，大幅提高了数据密集型工作负载（如 AI 张量操作）中的总线带宽利用率。
X100 实施了几项针对延迟的优化：
* 提前唤醒机制 减少了 L1 未命中/L2 命中场景下的加载到使用 (load-to-use) 延迟。
* 原子内存操作 (AMOs) 以更原子化的方式执行，无需指令拆分，显著降低了 AMO 执行延迟并减少了锁获取期间的活锁概率。
* 数据预取器 结合了基于流的页面预取 (SPP) 算法以提高不规则访问模式的覆盖率，并结合总线负载反馈机制动态调整预取距离，以平衡及时性与带宽消耗。
X100 增加了对 Hypervisor 虚拟化扩展的支持。为了提高多级页表遍历效率，它在 TLB 中缓存中间页表项，有效减少了虚拟化环境中的地址转换开销。该设计还实现了 DCache 的 ECC 保护，并支持处理由外部总线接口支持的数据检查错误 (Data Check errors) 中的 Poison 报告，同时符合 RISC-V 标准可靠性、可用性和可服务性错误报告接口 (RERI)。这些特性为服务器级应用提供了必要的支持。
图 5: X100 内存子系统微架构
3.1.4 向量 (Vector)
X100 集成了一个高效的向量处理子系统，为数据并行工作负载带来显著的性能优势。该子系统的特点是完全符合 RISC-V Vector Extension Version 1.0 (RVV 1.0) 和 RISC-V Vector Crypto Extension，以满足数据密集型计算和高性能安全应用的需求。
从根本上说，X100 向量单元遵循 RVV1.0 标准，具有 256 位的固定向量长度 (VLEN) 和 64 位的主元素长度 (ELEN)，支持从 INT8 到 INT64 和 FP16/BF16 到 FP64 的数据类型。该架构通过具有独立向量流水线进一步提高吞吐量，包括两条算术流水线和两条加载/存储流水线，每条流水线处理 128 位数据，可以并发操作以最大化数据处理效率。
解耦微架构。 在微架构层面，X100 VPU 采用了相对于标量核心的解耦方法。在主流水线中进行初始解码和标量操作数重命名后，向量指令被分发到一个独立的向量单元进行后续的拆分和执行。与标量核心紧密耦合的模块相比，向量单元在功能上更加分离，并占据了显著的硅片面积。解耦的向量单元不仅提供了增强的灵活性和可配置性，还简化了核心的物理布局和布图规划。
向量指令首先被推入专用的向量指令缓冲，用于将其与主流水线解耦。然后指令从该缓冲区发出以进行进一步处理。向量单元支持并发发射最多两条内存指令和两条计算指令。每个发射端口每周期可以处理 128 位粒度的指令微操作，这意味着 LMUL=1 的指令作为两个 128 位微操作发射。采用双 128 位数据通路而非单 256 位路径的设计选择，主要是为了有效地平衡硬件资源成本。鉴于向量操作种类繁多且计算复杂度高，更细粒度的数据通路宽度能够更高效和均衡地在不同指令类型之间分配资源。例如，复杂的排列操作可能只有一个 128 位执行单元，当两条此类指令并发发出时，只有较旧的一条能获取资源。这种粒度也促进了不同功能资源之间的并行性，例如，允许一条加法指令和一条移位指令同时发射并在各自的单元上执行。
内存访问效率对于向量应用至关重要。X100 解耦了向量加载/存储指令的地址生成和数据处理：地址阶段由主流水线的加载-存储单元 (LSU) 处理以进行地址计算和内存访问启动，而数据阶段由向量单元处理以进行操作数拆分和向量寄存器依赖性检查。两者之间的通信和数据交换通过指令 ID 进行协调。LSU 利用其两条现有的内存流水线并行发出和处理两条向量内存指令。相应地，向量单元配备了两个匹配的拆分电路来处理这两条内存指令的数据通路。通过解耦地址和数据处理，主流水线可以在地址准备好后立即将指令转发给 LSU，而无需等待向量寄存器依赖性解决。这允许 LSU 迅速启动内存访问，从而加速数据检索并提高整体内存效率。此外，为了处理复杂的向量内存模式（如段访问），LSU 集成了专用的转置缓冲区以加速数据重组，显著提升执行效率。
3.1.5 多核互连
X100 架构对其多核互连系统实施了系统且全面的升级，针对高性能计算和服务器工作负载中的关键瓶颈。此次升级实现了跨越延迟、带宽和整体系统效率的协同优化，涵盖了包括缓存层次结构、内存子系统、可靠性机制和一致性协议在内的关键层。
图 6: X100 的多核互连
X100 从包含式 (inclusive) 缓存策略转变为独占式 (exclusive) 缓存策略。此外，它为每个核心引入了卓越的缓存标签备份机制，能够精确跟踪多核环境中的缓存行状态。通过消除缓存层级之间的冗余数据副本，这种方法有效地增加了可用缓存容量。采用了 1:1.5 的扩展比率以减少反向无效 (back-invalidations) 的频率。在延迟优化方面，架构支持对 L2 缓存的提前访问，并在检测到地址冲突时取消流水线操作。这一优化显著减少了关键的加载到使用延迟，因为返回数据可以直接传递给核心，绕过了访问事务队列引入的额外延迟。经过这些优化，L1 未命中但 L2 命中的加载到使用延迟可低至 17 个周期，加速了数据依赖的解决。预取机制也得到了增强。内存子系统集成了下一行预取器和最佳偏移 (best-offset) 预取器。前者基于指令和页表遍历 (PTW) 未命中进行训练，而后者基于数据访问模式进行训练。这种组合方法提高了空间局部性预测和对复杂访问步长的适应性，从而提升了整体缓存命中率。
内存子系统将缓存库 (Bank) 数量翻倍，支持最多 4 个 Bank 的并行访问。这显著提高了内存级并行度和内部数据带宽。为了匹配这一设计，内部总线宽度扩展至 256 位，进一步释放了内存带宽的潜力。
多核一致性协议受益于几个关键优化。旁路优化技术将常见监听事务的延迟减少了 4 个周期。架构支持自监听 (self-snooping)，有效解决了核心内的缓存别名问题，并支持精确的 Bank 监听以降低功耗。事务队列的内部状态机经过重新设计，缩短了常见多核事务的生命周期并提高了整体互连效率。针对高并发锁获取场景，引入了独占的 CleanUnique 事务类型。这策略性地避免了重负载下的活锁问题，增强了高竞争环境下的系统稳定性。
为了实现服务器级可靠性、可用性和可服务性 (RAS)，X100 引入了符合 RISC-V RERI 规范的标准错误报告机制。这与基础软件层集成，以实现更准确的错误处理和系统恢复。关于数据完整性，架构实施了用于错误标记和传播的 Poison 机制。这与数据检查技术相结合，以检测总线传输错误。系统可以灵活选择通过 RERI 接口延迟报告错误信息，或立即返回传统错误信号。这种灵活性允许系统平衡可靠性要求与实时性能约束。
#### 3.2 A100
A100 是一款以 AI 为中心的 RISC-V AI-CPU，通过 SpacemiT-IME 指令集扩展提供原生 AI 计算能力。其微架构针对算子级并行性、内存带宽和数据局部性进行了刻意优化，以确保真实世界 AI 工作负载的高效执行。此外，它完全支持 RVA23 定义的通用 CPU 功能（不包括 Hypervisor 扩展），从而能够在统一的 RISC-V 编程模型下支持大模型推理和广泛的 AI 应用。硬件设计沿三个主要轴向开发：
* 系统维度（集成）： AI 单元作为一个紧耦合协处理器嵌入到 CPU 流水线中，采用单一 ISA 模型，减少了驱动开销和上下文切换延迟，并消除了“异构税”。
* 计算维度（计算）： 针对 Transformer 工作负载，设计追求模型-硬件协同设计；通过向量化微架构和增强的低/混合精度算术，增加了算子并行度并提高了能效。
* 内存/数据流维度（数据流）： 数据流和微架构以带宽为中心目标进行规划，设计实现了软件管理的本地内存和解耦的访问-执行操作——具体来说，通过异步 DMA 预取将内存移动与计算重叠，从而减少执行停顿。
每个集群包含四个标量核心、两个向量核心、两个本地内存库和一个共享 L2 缓存。两个向量核心共享一个 Tensor Core 和一个本地内存库，目标是在严格的面积和带宽预算下提高张量计算资源利用率和数据重用效率。K3 芯片集成了两个 A100 集群。
3.2.1 向量 (Vector)
A100 向量单元由两条并行向量流水线驱动，执行向量指令拆分、依赖处理和向量寄存器堆读写，结果主要在 VE3-VE5 阶段产生。从执行组织的角度来看，向量单元根据“指令类型 + 数据通路特征”将算子分类为五类：INT, FP, CRYPTO, FDV 和 IME-1.0。
寄存器堆配置有 VLEN = 1024 位的向量寄存器，包含 32 个架构向量寄存器 (v0-v31)。此寄存器宽度决定了单个向量指令每个实例最多可操作 1024 位数据，大幅增加了可实现的吞吐量。
计算资源配置遵循一个简单的指导策略。高频、吞吐量关键的算子（加/减、比较、移位、逻辑和窄宽乘累加）优先映射到能够双发射的更宽执行资源，并调度为在 VE3（或 VE4）尽早产生结果。混合执行宽度遵循“以主流精度固定宽度、按精度切片/打包、为稀有宽度重用资源”的原则：主流数据类型如 INT8/INT16/BF16 定义了关键数据通路宽度和通道数；通道切片和元素打包增加了窄精度的并行度；相对不频繁的更宽数据通路通过跨通道合并或多周期时分复用来实现，以避免为峰值宽度过度配置。低频或结构复杂的算子（如置换/重排序、部分宽位数据通路和迭代除法）刻意限制发射带宽和数据通路宽度，以提高面积和能效。表 2 总结了使用统一的“通道数 × 每通道位宽”表示法的 A100 计算资源配置：
SpacemiT-IME 提供了两级矩阵乘累加能力。每核私有的 IME-1.0 执行单元重用向量单元的低吞吐量数据通路 (VLEN = 256/512)，针对 INT8×INT8→INT32 的轻量级小矩阵 MAC 操作。相比之下，双核共享的 IME-2.0 执行单元采用 VLEN = 1024/2048 的专用高吞吐量数据通路，针对更高的吞吐量需求，并覆盖多种混合数据类型和混合精度模式下的矩阵 MAC。表 3 统一总结了支持的数据类型和矩阵形状定义。
在 12 nm 工艺上实现 RVV VLEN = 1024（超宽数据通路）使得时序收敛通常难以仅通过“默认综合”一次通过实现，通常需要结合物理实现进行有针对性的迭代。例如，寄存器堆读/写端口和旁路/选择网络可能需要在结构上进行分区和/或分层流水线化；关键路径随后通过重定时 (retiming) 和扇出控制进行压缩。在后端，利用布图规划、关键块放置和约束驱动的指导来减少长互连和拥塞造成的时序退化。最终，A100 在 2.1 GHz 下实现了 VLEN=1024 相关关键路径的 PPA 收敛。
3.2.2 张量核心 (Tensor Core)
Tensor Core 由两个计算核心共享，每个周期可以从每个核心接受一条矩阵乘累加 (MMA) 指令。MMA 指令的操作数和结果存储在向量寄存器中。向量子系统提供 32 个向量寄存器，每个宽度为 128B。每个核心配备一个独立的 512 位加载通道。前端支持双发射形式：每周期 1 个 512 位加载 + 1 个 MMA 指令。我们将计算强度（即计算存储比）定义为 $I = \frac{W}{Q}$ (MAC/Byte)，其中 $Q$ 表示传输到向量寄存器的字节数。为了近似 MAC 单元的稳态利用率，我们使用 $U = \frac{N_{mac}}{\max(N_{mac}, N_{ld})}$。其中 $N_{mac}$ 和 $N_{ld}$ 分别表示花费在发射 MMA 指令和内存加载上的周期数。考虑一个参数为 M=N=8, K=16 的 INT8 到 INT32 MMA 微内核。每个 MMA 的总操作数为 $W = M \times N \times K = 1024$ MAC。
情况 1：单 MMA 指令（无切片 / 无重用）：矩阵 A 包含 8 × 16 INT8 元素，即 128 B，需要两个 512 位加载周期。每个 MMA 消耗 A 的一个新实例（即跨 MMA 调用无重用）：$U = 1/2 = 50\%$。此时的内存流量：$Q = 128B$，导致 $I = \frac{1024}{128} = 8$ MAC/B。
情况 2：带面板化加载和寄存器分块的切片 (Tiling)：我们接下来考虑切片执行，其中 A 和 B 均被面板加载，然后通过寄存器级 $r_m \times r_n$ 寄存器分块重用，从而放大计算重用。假设分配 16 个向量寄存器来保存 C-tiles。每个 C-tile 需要两个向量寄存器，因此 8 个 C-tiles 同时存储在向量寄存器中。设同时累加的 tile 数量为 $r_m \times r_n$，约束为 $r_m r_n \le 8$。在该方案下，必须加载 $r_m$ 个 A 面板和 $r_n$ 个 B 面板。进行 $r_m r_n$ 次 MMA 操作，结果累加到驻留的 C-tiles 中。因此，$Q = 128(r_m + r_n)$，$W = 1024 r_m r_n$，$I = 8 \cdot \frac{r_m r_n}{r_m + r_n}$。在 $r_m r_n \le 8$ 的约束下，最大计算强度在 $(r_m, r_n) = (2, 4)$ 时达到，产生 $I_{max} \approx 10.67$ MAC/B。对于最大化器，加载和 MAC 周期为 $N_{ld} = 12$ 和 $N_{mac} = 8$，因此 $U = \frac{8}{12} \approx 66.7\%$。
图 7: A100 模块框图
图 8: A100 向量执行单元
图 9: A100 张量核心
表 2: A100 向量执行单元的执行资源
(表格内容展示了 INT, FP, CRYPTO, FDV 各域的单元、条件、资源配置和结果阶段。)
表 3: SpacemiT-IME 执行模式和支持的 MMA 形状
(表格内容展示了 IME 1.0 和 IME 2.0 (INT/FP) 的模式、执行宽度、操作和形状。)
表 4: 不同执行场景下的 MAC 利用率和系统级效率
(表格展示了单核单 MAC 指令与切片寄存器分块下的效率对比，双核共享达到 100% 利用率。)
注意：当两个核心的总 MAC 吞吐量超过 1 MAC/周期时，共享 MAC 引擎的有效吞吐量饱和至 1 MAC/周期。对于此 $8 \times 16 \times 8$ 微内核，即使单个核心通过切片实现了 $\approx 10.67$ 的计算强度，其生成 MAC 请求的速率可能仍低于共享 MAC 单元的峰值服务速率，从而导致面积和功耗昂贵的 MAC 资源利用率不足。相比之下，当两个核心可以并行加载数据并持续向共享 MAC 单元发出 MMA 指令时，共享 MAC 引擎的聚合利用率可以被驱动到 100%，即完全饱和（如表中所反映的两种情况）。
3.2.3 内存子系统
A100 的内存系统优化集中在两条访问路径：本地内存和主内存。当从 LLM 计算的不同阶段来看时，前者主要服务于以高算术强度和强数据重用（即核心向量/矩阵算子）为特征的计算密集型阶段，目标是尽可能让工作集驻留在近核存储中，以提供稳定的数据供应并最小化停顿。后者主要覆盖更多的内存密集型阶段，如参数读取和缓存更新（特别是解码期间的流式访问模式），目标是从主内存子系统提供强大的持续读取带宽，同时提供足够的延迟隐藏能力。
本地内存的容量配置通常不是将单一指标优化到极致的结果；相反，它是在目标系统目标下的性能收益与实现成本之间的多目标权衡中产生的，其中成本包括但不限于面积、功耗和带宽开销。该配置也在物质上受到物理实现因素的限制，如时序收敛强加的频率上限以及宏放置和互连布线决定的面积边界。因此，这种设计选择可以形式化为一个典型的帕累托最优多目标优化问题：在可行的设计空间内，选择一个在所有目标上不被任何其他替代方案同时支配的折衷方案。
图 10: A100 本地内存大小分析
在架构设计阶段，我们要为多类代表性工作负载（包括 CNN、LLM 和 ViT）构建了一个统一的性能-成本模型，并进行了参数扫描以确定各自的拐点，即超过该操作区域后，进一步增加本地内存容量产生的边际性能回报急剧减少，而实现成本继续呈线性（或更快）增长。考虑到算法演进趋势、目标应用覆盖范围和实现成本约束，我们最终选择了 Qwen-30B-A3B 的拐点作为本地内存配置的工程参考，从而在设计目标上优先考虑推理期间 30B-80B 规模模型的缓存/工作集驻留需求。
主内存设计在工程意义上受利特尔定律约束：在稳态下，$Lambda = \frac{WIP}{Lat}$。
这里，$Lambda$ 对应于可持续的吞吐量/带宽，$WIP$ 表示在途并发请求的数量，$Lat$ 是平均服务延迟。对主内存优化的含义是直接的：一方面，增加可维持的 $WIP$（即更多的在途请求以覆盖 DRAM 延迟并减少带宽气泡）；另一方面，减少或摊销有效 $Lat$（即缓解冲突和排队延迟）。
A100 的实现遵循这两个原则。在集群级别，$WIP$ 规模约为 100，设计采用非对称共享：单个核心不受固定静态配额的限制，当工作负载需要时，可以借用并占用超过其等份的在途窗口份额。在系统级别，通过通道/链路延迟优化进一步降低有效 $Lat$。因此，在内存受限的情况下，A100 更可能维持高在途并发，并稳定地接近可实现的可持续带宽。
#### 3.3 K3 中对新 RISC-V 特性的支持
在我们公司芯片产品的迭代演进过程中，上一代 K1 芯片集成了 X60 处理器核心，完全符合 RVA22 Profile 定义的 ISA 扩展要求。在新一代 K3 芯片中，采用的 X100 处理器核心进一步提供了对 RVA23 规范要求的所有强制性扩展的全面支持。然而，由于我们要独特的调度架构——在此架构下，AI 工作负载专门分发给 A100 进行计算，而 A100 核心不承担诸如管理程序管理等功能——A100 计算核心未在硬件中实现 RISC-V H 扩展（Hypervisor 扩展）。尽管如此，除了 H 扩展外，RVA23 标准规定的所有其他强制性扩展均在 A100 硬件上完全实现。
我们还在 RVA23 规范的可选扩展中进行了选择性抉择，并实现了一个子集，旨在确保芯片生命周期内强大的前瞻能力和适应性。
3.3.1 虚拟化 (Hypervisor)
虚拟化抽象了物理硬件资源，使得多个虚拟机 (VM) 可以在单一物理平台上并发执行，从而显著提高资源利用率，增强隔离性，并实现灵活的多租户部署。在 RISC-V 生态系统中，虚拟化通过 Hypervisor 扩展（H 扩展）启用，它为 CPU 和内存虚拟化提供了高效的硬件支持。此外，高级中断架构 (AIA) 引入了 IMSIC，使 CPU 核心能够接收 MSI 中断并直接向 Guest VM 传递中断，大幅减少了虚拟化环境中的中断处理开销和延迟。
在 K3 平台上，X100 核心实现了 Hypervisor 扩展，每个物理核心最多可支持 7 个活跃 VM。然而，虚拟化所需的两阶段地址转换引入了额外的转换开销，这可能会实质性地影响 VM 内的应用程序性能。为了减轻这种性能损失，X100 核心在转换后备缓冲 (TLB) 层面结合了多项优化。首先，指令 TLB (ITLB) 和数据 TLB (DTLB) 直接缓存从客户机虚拟地址 (GVA) 到系统物理地址 (SPA) 的转换，因此在 L1 TLB 命中时，虚拟化不会产生额外的转换延迟。其次，L2 TLB 不仅保留 GVA→SPA 映射，还缓存客户机物理地址 (GPA) 到 SPA 的映射以扩展地址转换覆盖范围。此外，页表遍历器 (PTW) 缓存存储用于 GVA→GPA 转换的非叶页表项，加速了客户机 TLB 未命中时的页表遍历。总的来说，这些机制旨在减少内存访问延迟并提高虚拟化下的整体执行效率。在启用上述虚拟化支持后，本文第 6.1 节报告了 X100 核心的详细性能比较。
关于中断支持，K3 平台中的 X100 核心和 A100 核心都支持以 MSI 形式接收外部中断。具体来说，在 X100 上，机器模式 (M-mode) 和监管者模式 (S-mode) 均支持 ID 为 1–511 的 MSI 外部中断；此外，通过 Hypervisor 扩展，在虚拟监管者模式 (VS-mode) 下运行的每个 VM 可以支持 ID 为 1–63 的直接 MSI 直通。对于 A100，M-mode 和 S-mode 同样支持 ID 为 1–511 的 MSI 外部中断；然而，由于该核心未实现 Hypervisor 扩展，它无法提供面向 VM 的中断直通。
3.3.2 向量加密 (Vector Crypto)
加密操作是数据安全和通信隐私的基础。然而，标量 ISA 在大规模或高吞吐量加密工作负载中通常面临吞吐量和能效瓶颈。为了解决这个问题，RISC-V 引入了向量加密扩展，提供面向向量的加密指令，显著提高了并行性和执行效率。
该扩展涵盖了国际标准算法（如 AES, SHA-2）和中国商用密码算法（如 SM4, SM3）。通过在结构化向量元素组 (Element Groups) 上操作，它高效地支持加密/解密、密钥扩展和哈希。其 ISA 设计强调数据独立的执行延迟，提高了对时序侧信道攻击的抵抗力。它还支持多种配置“套件”（如 Zvkn, Zvksg），在灵活性与专用硬件优化之间取得平衡。
在 K3 中，X100 和 A100 均实现了向量加密模块。它们共享相同的实现策略：SM3 和 SHA2-64 使用 256 位元素组，而所有其余指令使用 128 位元素组。启用向量加密后，典型的加密/解密内核可以实现比标量执行高达 60 倍的性能提升；详细数据将在 6.1 节中报告。
3.3.3 精度转换扩展
为了满足大模型训练和推理日益增长的需求，高效的低精度计算变得至关重要。X100 和 A100 均完全兼容 RVA23 针对半精度浮点计算的可选扩展子集，包括用于 FP16 标量/向量操作的 Zfh, Zvfh，以及用于 BF16 和 BF16 矩阵操作的 Zfbfmin, Zvfbfmin, Zvfbfwma。这种统一的 ISA 支持确何了基础 FP16/BF16 操作的软件兼容性和可移植性，为 AI 工作负载提供了必要的低精度计算能力。
值得注意的是，A100 进一步集成了针对 FP8 的定制向量转换指令，支持 E4M3 和 E5M2 格式。FP8 作为一种新兴的更低精度格式，可以在保持关键应用可接受的数值稳定性的同时，将存储和传输成本减半。通过紧密的微架构集成，A100 将这些转换实现到执行流水线中，大幅降低了 FP8 到 FP16/BF16 的转换延迟，并将转换效率提高了几个数量级。
在 K3 设计之时，RISC-V 尚无官方 OFP8 扩展；在撰写本文时，RISC-V 正在定义相应的 OFP8 标准。一旦获得批准，未来的核心将迁移到官方标准化扩展。
硬件级精度转换提供了除转换速度之外的好处。现代 AI 模型广泛采用混合精度策略，因为不同的层/算子具有不同的数值敏感度，并且可能采用不同的量化方法。A100 的精度转换指令支持跨阶段或计算单元的动态、高效、按需精度切换，大大降低了软件模拟转换的高开销。由于数据仅在必要时才以更高精度存储——而在其他情况下以低成本进行转换——这有效地降低了片外带宽需求，这对带宽受限的 AI 加速场景至关重要。
### 4. 软件栈
#### 4.1 操作系统
从硬件架构角度来看，虽然 X100 和 A100 处理器共享同构核心血统，但它们的功能角色存在实质性差异，形成了一种典型的非对称计算架构。X100 优先考虑通用计算性能，而 A100 专门针对 AI 和高吞吐量向量计算进行了优化。这种专业化反映在 ISA 特性集和硬件配置上：X100 实现了 Hypervisor 扩展，适用于需要硬件辅助虚拟化的通用服务器场景；其向量长度 (VLEN) 为 256 位，针对通用向量处理。相比之下，A100 不实现 Hypervisor 扩展，但将 VLEN 增加到 1024 位，为大规模矩阵操作和张量计算带来了显著的吞吐量优势。
这种不对称性给 OS 内核调度带来了挑战。为了利用融合异构平台的灵活性，同时保持确定性的执行行为，我们设计并实现了一种基于核心亲和性的调度方案。在当前系统中，X100 和 A100 上的所有 16 个核心均由 Linux 内核作为一个 SMP 系统进行管理，OS 暴露出统一的 16 核逻辑视图。然而，调度策略是明确分区的：8 个 A100 核心被指定为 AI 专用加速器核心，仅服务于特定的 AI 算法和向量计算密集型任务，并被排除在通用工作负载处理之外。相应地，用户线程默认在创建时绑定到 X100 核心组。即使 X100 组饱和，系统也不会将这些工作负载迁移到 A100。相反，当任务（例如 AI 推理或优化为利用 1024 位向量的算法）需要 A100 时，应用程序必须在线程创建后将相应线程绑定到 A100 核心组。一旦绑定，这些线程在其整个生命周期内被限制仅在 A100 上执行，并被禁止迁移到 X100。
虽然该策略解决了 X100 和 A100 之间混合调度的基线问题——确保 ISA 兼容性（例如，防止仅由通用指令组成的线程被错误地调度到仅支持 AI 相关指令子集的 A100 核心上，否则可能触发异常）——但它也引入了系统级和工程级的复杂性。首先，从负载均衡的角度来看，该策略不是最优的：它可能导致 A100 组空闲，而 X100 组保持完全利用，降低了整体资源利用率。其次，跨核迁移受到严格避免在不同核心类型之间调度不匹配的向量上下文（例如不同的 VLEN 状态）的需求的限制，增加了调度器的复杂性。第三，从软件生态系统的角度来看，当前的方法依赖于修改 Linux 内核代码，这不利于长期维护，也难以向上游主线内核社区提交。此外，应用程序开发人员必须了解底层的硬件感知调度行为才能有效优化，提高了开发门槛。
为了解决这些挑战，我们正在探索一种基于 Linux cpuset 机制的改进方法。该方法通过划分处理器亲和性域来实现严格的调度管理：X100 核心 (CPU0–7) 配置为默认域，而 A100 核心 (CPU8–15) 配置为 AI 专属域。系统工作负载默认运行在默认域中。只有当任务被应用程序显式标记为 AI 任务时，才允许将其放入 AI 专属域。这种方法将策略执行从内核修改转移到用户空间配置，利用 Linux 原生的资源隔离和管理框架，有望提供更清晰、更可持续的异构调度支持，同时降低整体系统复杂性。
#### 4.2 AI 算法与软件栈
一个实现了完整 RVV 和张量扩展 ISA 集的 AI-DSA 处理器核心运行在 Linux 之上。它利用多线程调度来表达 AI 推理中的并行、基于 Tile 的计算模式，而通用 X100 核心调节跨 A100 核心的负载均衡并提供快速响应同步，还可以处理选定的异步内存事务任务。在此基础上，我们构建了一个集成了手工调优算子库、AI 编译器和运行时系统的 AI 计算软件栈。该栈遵循务实的演进路径：首先通过手写内核实现专有场景的峰值性能，然后引入基于编译器的生成来推广这些性能优势。具体而言，该系统实现为一个基于 ONNX Runtime 且带有私有后端的推理引擎，以及一个基于 Tile 的 Triton 算子编译器；两者共享相同的运行时系统以及统一的线程和内存优化策略。
图 11: K3 AI 计算系统的软件栈
在 K3 AI 软件栈启动的早期阶段，我们优先考虑手工调优的算子层以及 Tile 级运行时调度器，并将其直接与主流推理生态系统 ONNX Runtime 对接。这使得能够快速端到端地启用广泛的 AI 模型，同时积累可复用的资产——包括用于手写内核的最佳指令/计算序列以及多线程、多集群调度策略——这反过来为后期过渡到更通用的以编译器为中心的 AI 软件形式提供了充分的方法论基础。
4.2.1 端到端部署形态与工程实现亮点
统一 API 算子库。 在 AI 软件开发之初，我们致力于两条并行轨道：手写内核推理引擎和 AI 编译器。算子库 API 与 MLIR meta-op 定义对齐，确保了语义完整性和跨框架兼容性。同时，它暴露了一个 C API，供早期版本的 AI 编译器调用。这允许在基于 IR 的完整代码生成到位之前运行完整的编译流水线，这是 K3 在芯片后早期阶段快速启动 AI 推理和 AI 编译的关键推动力。
X100 运行时系统。 AI 编译器路径和推理引擎路径都依赖 X100 将 AI 工作负载调度到两个 A100 集群上。在推理抽象中，所有算子——如卷积和 GEMM，以及 Triton 编译的内核——使用一个 A100 集群作为硬件调度单元，这等效地映射到一组四个 A100 Linux 线程。对于两个 A100 集群，系统形成两个组，总共八个 A100 Linux 线程，概念上类似于 CUDA 多流执行。X100 运行时动态地将推理引擎和 Triton 发出的 Tile 级计算任务分发到当前负载最轻的 A100 集群线程组上。在后续设计中，K3 将进一步支持分布式推理，届时运行时将具有拓扑感知能力，并以局部最优的方式调度 Tile 任务，从而在保持透明编程模型的同时提高推理引擎的可扩展性。
### 5. 评估
#### 5.1 CPU 性能
5.1.1 基准测试
在 K3 设计中，通用计算工作负载主要由 X100 核心执行。为了准确评估和量化 X100 的通用处理能力，我们使用行业标准 SPEC CPU2006 整数套件 (SPEC CINT2006) 作为基准测试。该套件由一组近似真实应用行为的整数计算密集型程序组成，并提供了对处理器特性的广泛覆盖，如整数执行效率、分支预测有效性和不同工作负载下的内存子系统性能，包括编译、解释、文件操作和路径搜索。
图 12: X100 的 SPEC CPU 2006
图 12 报告了 X100 的整体单核 SPEC CINT2006 分数以及每个基准测试的分数细分。对于所有测量，X100 核心运行在 2.4 GHz 的固定频率下，系统内存配置为 LPDDR5。
5.1.2 虚拟化性能
为了进行虚拟化性能评估，我们使用相同的硬件配置（X100 核心在 2.4 GHz，配备 LPDDR5-6400），并使用 SPEC CPU2006 整数套件 (CINT2006) 量化虚拟化下的通用计算性能。结果表明，由于计算特性的不同，各个基准测试的虚拟化开销差异很大，性能损失范围从 0.1% 到 16% 不等。总体而言，虚拟化使总 SPEC CINT2006 分数降低了 5.48%，如表 5 所总结。
表 5: VM 中 SPEC2006 峰值对比
| benchmark | SPEC2006 peak | peak in VM | decrease(%) |
| :--- | :---: | :---: | :---: |
| 400.perlbench | 21.10 | 20.60 | -2.33% |
| 401.bzip2 | 17.83 | 17.72 | -0.64% |
| 403.gcc | 17.95 | 16.15 | -10.03% |
| 429.mcf | 15.38 | 12.84 | -16.54% |
| 445.gobmk | 19.57 | 19.34 | -1.16% |
| 456.hmmer | 48.72 | 48.65 | -0.14% |
| 458.sjeng | 16.85 | 16.34 | -3.03% |
| 462.libquantum | 101.11 | 98.48 | -2.60% |
| 464.h264ref | 37.78 | 37.14 | -1.69% |
| 471.omnetpp | 12.12 | 10.84 | -10.53% |
| 473.astar | 14.20 | 12.85 | -9.49% |
| 483.xalancbmk | 18.73 | 17.61 | -5.99% |
| GEOMEAN | 22.88 | 21.62 | -5.48% |
仔细检查每个基准测试的结果表明，性能损失与工作负载的内存访问行为和控制流复杂性密切相关。具有限制硬件预取有效性的不规则内存访问模式的基准测试（如 429.mcf），以及具有复杂控制流和难以预测分支的基准测试（如 403.gcc），在虚拟化下表现出更明显的减速。根本原因是虚拟化引入的额外地址转换阶段（例如，通过 EPT 或影子页表机制进行的两阶段转换）增加了 TLB 未命中的惩罚。当工作负载的访问流无法被 TLB 有效覆盖时，每次转换未命中都会触发从客户机物理地址到主机物理地址的额外映射步骤，这增加了有效内存访问延迟并加剧了内存子系统的压力，从而进一步降低性能。
5.1.3 密码学性能
为了评估 Vector Crypto 对加密工作负载的性能影响，我们使用 OpenSSL 作为基准测试套件，它集成了广泛的加密算法实现并提供了标准化的测试环境。具体来说，我们使用 OpenSSL 内置的 speed 命令对多种算法进行基准测试。该命令量化了算法的吞吐量和操作延迟；在测试期间，我们扫描了可变的消息大小（例如，从 16 字节到 16,384 字节）以模拟不同的工作负载状态。为了便于跨算法比较，所有结果均归一化为标量基线，即标量实现设为 1，优化变体报告为相对加速比。
表 6: OpenSSL 向量加密加速比
| benchmark | 16 bytes | 256 bytes | 16384 bytes |
| :--- | :---: | :---: | :---: |
| chacha20 | 0.5 | 1.1 | 2.1 |
| sha256 | 1.8 | 3.8 | 10.5 |
| sha512 | 1.4 | 1.7 | 2.3 |
| SM3 | 1.5 | 2.1 | 2.6 |
| aes-128-cbc | 4.7 | 12 | 13.9 |
| aes-256-cbc | 4.8 | 12.1 | 13.7 |
| SM4 | 3.5 | 5.9 | 6.2 |
| GHASH | 2.5 | 21.3 | 46.6 |
| hmac(sha256) | 1.9 | 3.2 | 10.2 |
结果清楚地表明，对于像 AES, SHA, SM3, SM4 和 GHASH 这样的算法，Vector Crypto ISA 定义了专用的加速指令，相比标量实现和通用向量化实现都产生了数量级的增益。以 AES 为例，Vector Crypto 引入了专门的查表指令，有效地消除了与传统查表方法相关的常见缓存访问开销；在消息较大的场景下（例如 8 KB 块），归一化性能达到标量基线的近 14 倍。对于 GHASH，X100/A100 架构高效实现了 Vector Crypto 指令 vghsh。该指令采用深度流水线设计，仅用 3 个周期即可完成每次迭代，将归一化性能提高到标量基线的 46 倍，这突显了 Vector Crypto 在特定应用领域的优势。
相比之下，ChaCha20 由移位和模加运算主导，提供的向量加速潜力相对有限。它只能从一小部分指令（如向量旋转 vror）中获得适度的增益。结果是，其优势仅在足够大的消息大小（例如 > 64 KB 块）时才变得明显，此时向量并行性带来的吞吐量提升逐渐摊销了指令级开销。
#### 5.2 AI 性能
5.2.1 内存读取带宽
对于 LLM 推理，解码阶段的 TPS 通常受有效读取带宽的主导：生成每个 token 都会触发一次全模型前向传递，如果权重/中间数据无法随时间驻留在缓存中，瓶颈就会从计算转移到从内存读取数据的持续吞吐量。
一种更紧密匹配“充分利用内存控制器”硬件目标的内存访问模式是线程分片的多流顺序读取。在这种模式下，一个连续的物理地址范围（或页面/块分区区域）被分为 N 个非重叠流（块）；N 个线程/核心被固定，每个核心线性扫描其自己的流，具有缓存行步幅（可选地由预取辅助）。这些流以最小的屏障同步并行运行，持续发出读取请求，以便内存控制器可以通过排队和重排序使读取数据通路饱和。这种模式对预取器友好，增加了 MLP（内存级并行度），并且随核心数量良好扩展，通常接近 LPDDR5 接口的峰值带宽。在 LLM 解码阶段，A100 的参数读取本质上是组织为结构化到多核、分段线性流中的逐层权重访问，利用这种多流顺序读取模式不断驱动内存系统趋向带宽饱和。
下面我们报告在 K3 测试设置下，通过逐步启用 A100 的读取带宽相关硬件优化旋钮测得的带宽（系统级优化仍在进行中；以下结果不代表最终峰值性能）：
表 7: A100 主内存带宽
| | Read Bandwidth | Relative to normal |
| :--- | :---: | :---: |
| normal | 10139 | 1.00x |
| vector | 32412 | 3.20x |
| opt v1 | 32654 | 3.22x |
| opt v2 | 33226 | 3.28x |
| opt v3 | 32360 | 3.19x |
| opt all | 33214 | 3.28x |
5.2.2 1024-bit 向量的优势
当 RVV 配置为 VLEN=1024 和 32 个架构向量寄存器时，编程模型可以被视为提供了一个有效的 4 KB 超快本地暂存器（Scratchpad），这在某些特定场景下实现了更强的局部性优化。
* Norm 风格的广播计算。 这种模式通常采取 $C = A[..., C] * Scale[C]$ 的形式，其中通道维度 C 通常为 128/256/512/768。对于 VLEN=1024，16 个向量寄存器足以容纳 C < 512 的 Scale 向量，因此 Scale 张量只需全局加载一次。通过避免在主计算循环期间重复提取 Scale，这减少了 L1/L2 缓存的压力。
* FlashAttention。 在 FlashAttention 中，隐藏维度通常为 128 或 64。在 FP16 精度下，两个向量寄存器可以容纳一个序列块的隐藏维度。即使没有张量扩展指令，仅 RVV 就可以消除隐藏维度上的内循环，并将 $V \cdot QK$ 累加保留在 2-4 个向量寄存器中，使得计算路径在累加阶段很大程度上独立于 L1/L2 缓存。
* 减少 VPR 溢出的可能性。 在编译器寄存器分配期间，大量使用 LMUL=4 或 LMUL=8 的代码——特别是在超越函数近似（如 exp 和 tanh）中——容易发生向量寄存器溢出，从而降低指令调度和整体性能。使用 VLEN=1024，使用 LMUL=1 可以提供相当于使用 LMUL=4 的 VLEN=256 的计算宽度，大幅降低向量寄存器溢出的概率并提高内核鲁棒性。
5.2.3 典型 CNN 性能
1024 位向量数据通路实现了更高的每核数据级并行性，并提高了计算密集型内核（例如卷积/GEMM）的 Tile 级并行执行效率。在实践中，这转化为更高的单流吞吐量，以及在增加软件并行性（线程）和适度增加批处理大小时更强的扩展性，如表 8 所示。
表 8: 典型 CNN 性能
| Model/Inference Config | Batch = 1<br>Thread = 1 | Batch = 1<br>Thread = 4 | Batch = 2<br>Thread = 4 |
| :--- | :---: | :---: | :---: |
| ResNet50 | 52 | 129 | 165 |
| RepVGG | 207 | 451 | 570 |
| YOLOv8s | 9 | 31 | 44 |
### 6. 致谢
我们感谢 RISC-V 开源生态系统，它使 K3 芯片能够快速集成到相对完整和成熟的软件栈中。我们也感谢为开放生态系统做出贡献的组织和公司。基线 X100 实现基于玄铁 (Xuantie) 的开源 OpenC910；基线 RT24 实时核心基于 openhwgroup 的开源 CVA6。在 X100 收敛和迭代期间，我们利用了香山 (Xiangshan) 工具链，包括用于前端建模、架构探索和性能分析的 xs-gem5 建模工具；香山的基于 NEMU 的切片流程、DRAMSim 环境和自顶向下的分析工具，以加速基准测试分析和迭代。我们还利用了大量社区开源工具和测试套件，包括但不限于 spike, force, rv-dv, rv-arch-tests，以加速 K3 通用 CPU IP、AI CPU IP 和实时 CPU IP 的收敛。
参考文献
TBD
