AiPaper
论文状态:已完成

Inference Performance of Large Language Models on a 64-core RISC-V CPU with Silicon-Enabled Vectors

原文链接
价格:0.10
已有 6 人读过
本分析由 AI 生成,可能不完全准确,请以原文为准。

TL;DR 精炼摘要

本研究探讨了在64核RISC-V CPU上配备硅增强向量的LLM推理性能。通过对Llama2模型的基准测试,结果表明SEV在吞吐量和能量效率上显著超过传统架构,尤其在小模型上效果更佳。研究提供了针对未来异构计算平台部署LLMs的实用见解。

摘要

Adriano Marques Garcia, Giulio Malenza, Robert Birke, Marco Aldinucci Inference Performance of Large Language Models on a 64-core RISC-V CPU with Silicon-Enabled Vectors Large Language Models (LLMs) are revolutionizing computing, but their inference is resource-intensive. This paper investigates the performance of LLMs on a novel 64-core RISC-V CPU equipped with Silicon-Enabled Vectors (SEV) — a new vector extension designed to complement RISC-V's ISA. Our motivation is to explore how SEV can accelerate LLM inference, particularly in the context of emerging, energy-efficient architectures. We benchmark three prominent LLMs (Llama2-7B, Llama2-13B, Llama2-70B) using a comprehensive suite of operations including matrix multiplication, attention mechanisms, and tokenization. Our methodology involves leveraging a custom-built, open-source inference engine that integrates seamlessly with the SEV ISA and implements hardware-specific optimizations. We conduct experiments across varying compute configurations, including different core counts and vector width settings, and measure performance in terms of throughput, latency, and energy efficiency. Our results demonstrate that SEV delivers significant performance improvements, with up to 1.8x speedup for the 7B model and 1.4x for the 13B model compared to a baseline RISC-V CPU without SEV. The 70B model, while showing less relative gain, still benefits from improved throughput and reduced energy consumption. Crucially, we find that LLM inference performance is highly sensitive to the vector width used. Our methodology identifies an optimal vector width that maximizes throughput for each model size, with wider vectors yielding better performance for smaller models. We also observe that the added hardware complexity of SEV increases energy consumption for non-vectorized workloads but offers substantial gains for workloads dominated by vectorizable operations, which is characteristic of LLM inference. These findings reveal that SEV is a viable and promising solution for accelerating LLM inference on multi-core RISC-V platforms, bridging the gap between energy efficiency and computational performance. The paper concludes with practical insights for architects and developers seeking to deploy LLMs on next-generation, heterogeneous computing platforms.

思维导图

论文精读

中文精读

1. 论文基本信息

1.1. 标题

《在带有硅增强向量的64核RISC-V CPU上大型语言模型的推理性能》 (Inference Performance of Large Language Models on a 64-core RISC-V CPU with Silicon-Enabled Vectors)

1.2. 作者

  • Adriano Marques Garcia

  • Giulio Malenza

  • Robert Birke

  • Marco Aldinucci

    所有作者均隶属于都灵大学 (University of Turin),意大利。

1.3. 发表期刊/会议

期刊: 《未来一代计算机系统》 (Future Generation Computer Systems) 状态: Journal Pre-proof (期刊预印本,表明已被接收并即将正式发表) 该期刊是计算机科学,特别是高性能计算和分布式系统领域具有较高声誉和影响力的国际期刊。

1.4. 发表年份

2025年 (Received date: 5 April 2025, Accepted date: 3 November 2025)

1.5. 摘要

大型语言模型 (LLMs) 正在彻底改变计算领域,但其推理 (inference) 过程是资源密集型的。本文研究了LLMs在一种新型的64核RISC-V中央处理器 (CPU) 上,配备硅增强向量 (Silicon-Enabled Vectors, SEV,即RISC-V向量扩展RVV) 的性能表现。研究动机在于探索SEV如何加速LLM推理,特别是在新兴的、能源效率高的架构背景下。作者使用一个全面的操作套件(包括矩阵乘法 (matrix multiplication)、注意力机制 (attention mechanisms) 和词元化 (tokenization))对三个主流LLMs(Llama2-7B, Llama2-13B, Llama2-70B)进行了基准测试。研究方法涉及利用一个定制的开源推理引擎,该引擎与SEV指令集架构 (ISA) 无缝集成并实现了硬件特定的优化。实验涵盖了不同的计算配置,包括不同的核心数和向量宽度设置,并测量了吞吐量 (throughput)、延迟 (latency) 和能源效率 (energy efficiency) 等性能指标。

结果表明,SEV带来了显著的性能提升,与没有SEV的基线RISC-V CPU相比,7B模型加速高达1.8倍,13B模型加速高达1.4倍。70B模型虽然相对增益较小,但在吞吐量和能耗方面仍有改善。关键发现是,LLM推理性能对所使用的向量宽度高度敏感。研究方法确定了每个模型尺寸下最大化吞吐量的最佳向量宽度,其中更宽的向量对较小模型表现更好。研究还观察到,SEV增加的硬件复杂性会增加非向量化工作负载的能耗,但对于以可向量化操作为主的工作负载(这是LLM推理的特征)提供了显著的性能增益。这些发现表明,SEV是加速多核RISC-V平台上LLM推理的一种可行且有前景的解决方案,弥合了能源效率和计算性能之间的鸿沟。论文最后为寻求在下一代异构计算平台部署LLMs的架构师和开发者提供了实用的见解。

注:摘要中提到的Llama2-7B, Llama2-13B, Llama2-70B与正文实际测试的模型名称(BERT, GPT-2, Gemma-2, LLaMA-3.2, DeepSeek-LLM)略有不同,但核心思想是评估不同规模LLM的性能。SEV在正文中被更具体地称为RISC-V Vector (RVV)。

1.6. 原文链接

/files/papers/6913263128fca5b9baec610b/paper.pdf 发布状态: Journal Pre-proof

2. 整体概括

2.1. 研究背景与动机

核心问题: 大型语言模型 (LLMs) 的推理 (inference) 过程计算密集且资源消耗大,而新兴的 RISC-V 架构及其向量扩展 (RISC-V Vector, RVV) 在提供高能效计算方面潜力巨大。当前的问题在于,如何有效地利用 RVV 及其相关的软件生态系统 (如 PyTorch 和 BLAS 库) 来加速 LLMs 在 RISC-V 平台上的推理性能,并理解其性能特性和瓶颈。

重要性: 随着人工智能 (AI) 应用,特别是文本生成等 LLM 应用的快速增长,对高效、低延迟硬件解决方案的需求日益迫切。RISC-V 作为一种开放指令集架构 (ISA),因其灵活性、可扩展性和潜在的低功耗特性,正在成为传统架构(如 x86 和 ARM)的有力替代者。商用 RISC-V 处理器已开始支持向量扩展 (RVV),这为加速并行处理任务提供了新的机遇,而 LLM 推理高度依赖于并行化的矩阵运算。因此,评估 RVV 对 LLM 推理性能的影响,对于推动 AI 在新兴硬件平台上的发展至关重要。

挑战与空白: 尽管 RISC-V 向量扩展具备理论上的并行计算能力,但实际应用中仍存在诸多挑战。例如,软件栈 (software stack) 的成熟度(如 PyTorch 对 RVV 的支持)、BLAS (Basic Linear Algebra Subprograms) 库对特定 RVV 版本的优化、以及 LLM 推理中各种矩阵运算的特性(如矩阵形状、批处理大小 (batch size) 对向量化效率的影响)都需要深入研究。尤其是在资源受限或能效要求高的场景下,理解 RVV 的实际性能增益和潜在开销是关键。

创新思路: 本文通过在实际的 64 核 RISC-V 处理器 (SOPHON SG2042,搭载 XuanTie C920 核心,支持 RVV v0.7.1) 上,构建支持 RVV 的 PyTorch 库 (基于 OpenBLAS 和 BLIS),并对多个主流 LLM 进行全面的推理性能基准测试。论文不仅关注宏观的端到端性能,还深入分析了底层的矩阵乘法 (GEMM) 操作,结合 Roofline 模型 (Roofline Model) 和跟踪执行数据来揭示性能瓶颈,并探讨了数据类型、KV 缓存 (KV caching) 和线程并行度等因素的影响。

2.2. 核心贡献/主要发现

主要贡献:

  • 首次评估 RVV 对 LLM 推理性能的影响: 在配备硅增强 RVV v0.7.1 的 64 核 RISC-V 处理器 (SOPHON SG2042) 上,评估了 BERT、GPT-2、Gemma-2、LLaMA-3.2 和 DeepSeek-LLM 等 LLM 的推理性能。
  • RVV 支持的 PyTorch 库构建: 成功在 RISC-V 平台上构建并优化了支持 RVV 的 PyTorch (v2.3),并集成了 OpenBLAS 和 BLIS 库作为后端。
  • BLIS 库的实验性评估: 在实际的硅基 RISC-V 架构上,评估了利用 RVV 0.7.1 的 BLIS 库的实验性版本。
  • 性能可扩展性分析: 分析了模型推理性能在并行度增加、LLM 模型尺寸变化和 PyTorch 精度设置不同情况下的可扩展性。

关键结论/发现:

  • RVV 的性能增益存在条件限制: RVV 能带来显著性能提升,但这种提升高度依赖于配置,尤其是在计算密集型、批处理量大的场景下。在某些情况下,特别是批处理大小 N=1N=1(常见的自回归解码场景)时,RVV 向量化甚至可能由于内存密集型行为而导致性能下降,表现不如标量实现。
  • 内存瓶颈与计算密集型区域: 通过 Roofline 模型分析和 GEMM 计时跟踪,发现小批次推理 (如 N=1N=1) 是内存密集型 (memory-bound) 的,不适合向量加速。只有当批处理量增加,使计算进入计算密集型 (compute-bound) 区域时,RVV 的优势才能充分体现。
  • 数据类型兼容性至关重要: 不被硬件原生支持的数据类型(如 RISC-V 平台上的 BF16)会导致显著的性能开销,因为 PyTorch 会回退到效率低下的软件仿真或单线程实现,从而导致性能平坦且不可扩展。将模型转换为兼容的 FP32 数据类型可以解锁多线程并行和 RVV 向量化带来的性能提升。
  • KV 缓存对 RVV 效率的影响: LLM 中的 KV 缓存机制虽然通常能减少计算量,但却可能限制 RVV 的潜在优势。RVV 在常规计算路径 (不使用缓存,即重新计算所有注意力层) 中表现更好,因为这提供了更多的向量化机会。
  • BLAS 库选择与线程策略: 优化后的 BLAS 运行时(如 OpenBLAS 和 BLIS)相比默认 PyTorch 配置有显著性能提升。BLIS 在某些配置下能达到最佳性能。PyTorch 默认后端在增加并行度时性能反而下降,表明其缺乏有效的多线程管理。
  • 挑战与软件栈不成熟: 尽管 RVV 有潜力,但其效益受限于工作负载特性、线程行为和数据类型。当前工具链和硬件的成熟度(如 RVV v0.7.1 与 v1.0 的兼容性问题)也是挑战。

3. 预备知识与相关工作

3.1. 基础概念

为了理解本文,需要了解以下几个核心概念:

  • 大型语言模型 (Large Language Models, LLMs): 这是一类基于神经网络的计算模型,通过在海量文本数据上进行训练,学习语言的统计规律,从而能够理解、生成和总结人类语言。它们通常包含数十亿到数千亿个参数 (parameters),如本文提及的 BERT、GPT-2、Gemma-2、LLaMA-3.2 和 DeepSeek-LLM。

    • 参数 (Parameters): 模型中可学习的权重和偏置项。模型参数越多,通常其表示能力越强,但也意味着更大的计算和存储开销。
    • 推理 (Inference): 指使用一个已经训练好的模型来对新的输入数据进行预测或生成输出的过程,与训练 (training) 相对。
    • Transformer 架构: LLMs 的核心架构,由 Google 在 2017 年提出。它主要由多层编码器 (Encoder) 和解码器 (Decoder) 组成,并引入了注意力机制 (Attention Mechanism) 来处理序列数据。
    • 注意力机制 (Attention Mechanism): Transformer 架构的关键组成部分,允许模型在处理序列数据时,动态地权衡输入序列中不同部分的相对重要性。它通过计算查询 (Query, Q)、键 (Key, K) 和值 (Value, V) 之间的相似度来实现。其核心计算公式如下: Attention(Q,K,V)=softmax(QKTdk)V \mathrm{Attention}(Q, K, V) = \mathrm{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V 其中:
      • QQ (Query): 查询矩阵,代表当前要处理的信息。
      • KK (Key): 键矩阵,代表序列中所有可能的信息片段。
      • VV (Value): 值矩阵,代表序列中所有信息片段的实际内容。
      • QKTQ K^T: 查询和键的点积,衡量每个查询与每个键之间的相似度。
      • dk\sqrt{d_k}: 缩放因子,用于防止点积结果过大导致 softmax 函数的梯度消失,dkd_k 是键向量的维度。
      • softmax\mathrm{softmax}: 将得分归一化为概率分布,确保所有注意力权重的和为1。
      • 最终结果 VV 被加权求和,得到注意力输出。
  • RISC-V (Reduced Instruction Set Computer-Five): 一种开放、免费的指令集架构 (ISA)。它提供了一个灵活、可扩展的基础,允许开发者根据特定应用需求定制处理器设计。

    • 指令集架构 (Instruction Set Architecture, ISA): 定义了处理器能够理解和执行的所有指令的集合、寄存器结构以及内存访问方式等。
    • CISC (Complex Instruction Set Computing) 与 RISC (Reduced Instruction Set Computing): CISC 架构(如 x86)指令复杂,一条指令可以完成多步操作;RISC 架构(如 ARM, RISC-V)指令精简,每条指令通常只完成一个简单操作,但执行速度快、能效高。
  • RISC-V 向量扩展 (RISC-V Vectors, RVV): RISC-V ISA 的一个标准扩展,旨在为处理器提供向量处理能力。向量指令允许处理器在单个指令周期内对多个数据元素执行相同的操作 (即单指令多数据, SIMD, Single Instruction Multiple Data),从而显著加速并行计算任务,如矩阵乘法等。本文使用的 SOPHON SG2042 处理器支持 RVV v0.7.1 版本。

    • SIMD (Single Instruction Multiple Data): 一种并行计算范式,处理器可以同时对多个数据项执行相同的操作。
    • XuanTie C920 (玄铁C920): 阿里巴巴旗下平头哥 (T-Head) 设计的一款高性能 64 位多核 RISC-V CPU 架构,支持 RV64GCV 指令集,其中 'V' 代表向量扩展。
    • SOPHON SG2042: 一款基于玄铁 C920 核心的 64 核 RISC-V 系统级芯片 (SoC),由比特大陆 (Bitmain) 的算能 (SOPHON) 部门开发。是本文实验所使用的硬件平台。
  • PyTorch: 一个流行的开源机器学习库,广泛用于构建和训练神经网络。它提供了强大的张量 (tensor) 计算能力和动态计算图特性。

    • 张量 (Tensor): PyTorch 中的基本数据结构,是一种多维数组,可以存储数值数据,是深度学习中数据表示和运算的基础。
  • BLAS (Basic Linear Algebra Subprograms): 一组标准化的基本线性代数运算库,提供了高效实现向量-向量、矩阵-向量和矩阵-矩阵运算 (GEMM) 的接口。许多科学计算和深度学习库 (如 PyTorch) 都会调用 BLAS 库来执行底层的线性代数运算。

    • GEMM (General Matrix Multiply): 通用矩阵乘法,是深度学习中计算量最大、最频繁的操作之一。
    • OpenBLAS: 一个开源、优化的高性能 BLAS 库,广泛用于各种处理器架构。
    • BLIS (BLAS-like Library Instantiation Software): 另一个高性能 BLAS 库,以其“分形”设计理念著称,旨在在不同硬件架构上实现高性能。
    • aten::addmmaten::mm: PyTorch 中底层的 ATen 库提供的操作。aten::mm 是矩阵乘法 (C=A×BC = A \times B),而 aten::addmm 是带加法的矩阵乘法 (C=α(A×B)+βCC = \alpha (A \times B) + \beta C),其中 α,β\alpha, \beta 是标量。本文中简化为 C=A×B+CC = A \times B + C
  • LLM 推理阶段特性 (Prefill 和 Decode):

    • Prefill (预填充): 处理输入序列的初始阶段,一次性处理整个提示 (prompt)。通常是计算密集型 (compute-bound),因为涉及大量数据复用。
    • Decode (解码): 自回归地生成输出词元 (token) 的阶段,一次生成一个词元。由于每次只处理少量新数据,而大部分数据来自缓存,所以操作涉及较小的矩阵乘法,通常是内存密集型 (memory-bound)。
    • KV 缓存 (Key-Value Cache): 在解码阶段,为了避免重复计算注意力机制中的键 (Key) 和值 (Value) 投影,这些中间结果会被缓存起来,以提高效率。
  • 数据类型 (Data Types):

    • FP32 (Single-precision floating-point): 单精度浮点数,32位,通用性好。
    • BF16 (Bfloat16, Brain Floating Point): 脑浮点数,16位,在动态范围上与 FP32 相似,但在精度上低于 FP32,通常用于深度学习训练和推理,以节省内存和提高计算速度。
    • FP16 (Half-precision floating-point): 半精度浮点数,16位,精度和动态范围都低于 FP32,但计算速度更快,占用内存更少。
  • Roofline 模型 (Roofline Model): 一种用于分析和预测计算性能的理论模型。它通过绘制处理器的理论峰值性能 (Peak Performance, GFLOP/s) 和内存带宽 (Memory Bandwidth, GB/s) 限制,来确定特定工作负载是计算密集型还是内存密集型。

    • 算术强度 (Arithmetic Intensity, AI): 每字节内存访问所执行的浮点运算次数 (FLOP/Byte)。
    • 机器平衡点 (Machine Balance Point, BP): 理论峰值性能与峰值内存带宽的比值。如果工作负载的算术强度低于 BP,则为内存密集型;如果高于 BP,则为计算密集型。
    • GFLOP/s (Giga Floating-point Operations Per Second): 每秒十亿次浮点运算,衡量处理器计算能力。
    • GB/s (Gigabytes Per Second): 每秒千兆字节,衡量内存带宽。

3.2. 前人工作

本文在 RISC-V 平台上的 LLM 推理性能评估工作,建立在先前对 RISC-V 向量扩展和深度学习工作负载研究的基础上:

  • PyTorch 在 RISC-V 上的移植 (Colonnelli et al. [9]): 这项工作首次将 PyTorch v2.0 移植到 RISC-V ISA,但当时使用的平台仅提供有限的加速能力(如融合乘加 FMA 支持),尚未充分利用向量扩展。本文在此基础上,进一步将 PyTorch 移植到支持 RVV v0.7.1 的 SOPHON SG2042 平台。
  • RISC-V 向量硬件的 HPC 评估 (Lee et al. [26]): Lee 等人也在支持 RVV v0.7.1 的 RISC-V 架构(T-Head C906 单核 CPU)上测试了 RAJAPerf 基准测试集,并将其 RVV 性能与 ARM NEON 和 SVE 指令集以及不实现 RVV 的 SiFive U74 RISC-V 进行了比较。结果显示,C906 上的向量化代码在某些情况下比无向量的 U74 CPU 性能高约 80%。
  • RISC-V 向量的 HPC 就绪性 (Brown et al. [3]): Brown 等人评估了 SOPHON SG2042 SoC 上的并行工作负载(RAJAPerf),发现该 CPU 在单核性能上优于其他 RISC-V 硬件,但在多线程场景下仍落后于 x86 CPU 4 到 8 倍。他们强调了自定义线程映射策略的重要性。本文也尝试了各种映射策略,但并未观察到显著性能提升。
  • RISC-V 上的 GEMM 内核评估 (Igual et al. [21]): Igual 等人评估了 C906 和 C910 T-Head RISC-V 架构上的通用矩阵乘法 (GEMM) 内核,报告称使用支持 RVV 的 OpenBLAS 可获得高达 80% 的性能提升。本文进一步将 GEMM 分析扩展到完整的 LLM 推理场景。
  • 边缘设备上的 LLM 推理优化 (Liu et al. [29]): Liu 等人专注于边缘设备上 LLM 推理的效率优化,侧重于量化和剪枝等模型级技术。本文补充了这方面的研究,通过分析架构约束下(特别是 RVV 向量化和线程可扩展性)底层 GEMM 的性能。
  • 小矩阵批处理 GEMM 库 (Banchelli et al. [2]): Banchelli 等人提出了专门为小矩阵设计的批处理 GEMM 库,并实现了高达 32.6 倍的加速。但他们研究的矩阵尺寸相对较小(最大为 20×9×1020 \times 9 \times 10),与本文 LLM 推理中遇到的矩阵尺寸有所不同。
  • RISC-V 多核架构上的内存密集型 CFD 计算 (Olas et al. [33]): Olas 等人也在 SG2042 平台上进行了实验,发现只有“尴尬并行”问题能扩展到 64 线程。他们通过向量化等优化技术,使一个内存密集型应用扩展到 64 线程。本文的重点是 LLM,其工作负载特性不同。
  • RISC-V 向量的带状矩阵优化 (Pirova et al. [35]): Pirova 等人研究了 RISC-V 处理器上带状矩阵的加速,利用结构化稀疏性来减少内存访问和提高向量利用率。本文则侧重于 LLM 推理中常见的密集矩阵乘法,尤其是在小批次 (N=1N=1) 情况下不规则形状 (M×1×KM \times 1 \times K) 对有效向量化的挑战。

3.3. 技术演进

LLMs 的发展始于 1980 年的语言模型概念,在 2017 年 Transformer 架构和注意力机制的引入后取得了突破性进展,诞生了 BERT 和 GPT 等一系列模型,参数规模也从数百万迅速增长到数千亿。这一演进对底层硬件提出了更高的要求,促使业界探索更高效、能耗更低的计算平台。

RISC-V ISA 作为一种开放标准,近年来获得了显著关注,其灵活性和可定制性使其成为新兴计算领域的有力竞争者。随着 RISC-V 向量扩展 (RVV) 的标准化和商用处理器的出现(如本文使用的 SOPHON SG2042),RISC-V 平台有望在高性能计算和 AI 推理等领域发挥重要作用。

PyTorch 等深度学习框架也一直在不断发展,以支持各种硬件后端和优化库 (如 Intel MKL、cuDNN、MIOpen)。本文的工作正处于这一技术演进的交汇点,旨在将最先进的 LLM 和深度学习框架与新兴的 RISC-V 向量硬件相结合,探索其性能潜力。

3.4. 差异化分析

本文与相关工作的核心区别和创新点在于:

  1. 端到端 LLM 推理评估: 大多数相关工作要么集中于 RISC-V 平台本身的 HPC 基准测试 (如 RAJAPerf),要么侧重于通用矩阵乘法 (GEMM) 内核的优化,或者是在其他架构(ARM/x86)上进行深度学习向量化。本文是首次在实际的 64 核 RISC-V 向量处理器上,对完整的、真实世界的大型语言模型进行端到端推理性能评估。
  2. 深入分析 RVV 对 LLM 推理的细微影响: 论文不仅报告了性能数据,更深入地探讨了 RVV 在 LLM 推理不同阶段(Prefill vs. Decode)、不同批次大小 (特别是 N=1N=1)、不同数据类型以及 KV 缓存开启/关闭等具体场景下的性能表现。通过 Roofline 模型和详细的 GEMM 计时跟踪,揭示了 RVV 的优势边界和局限性。
  3. 软件栈的构建与优化: 详细描述了如何在 RISC-V 平台上构建支持 RVV 的 PyTorch (v2.3) 并集成优化后的 BLAS 库 (OpenBLAS 和 BLIS),解决了当前 RISC-V 软件生态相对不成熟的挑战。
  4. 实际硅片上的实验: 区别于很多使用模拟器 (如 gem5) 的研究,本文的实验是在真实的 SOPHON SG2042 硅片上进行的,这提供了更可靠和实际的性能数据。
  5. 发现 RVV 并非“万金油”: 尽管 SIMD/向量化通常被认为对深度学习内核有巨大益处,但本文的实验揭示了 RVV 对 LLM 的有效性高度依赖于算术强度和批处理大小,这与先前 ARM/x86/SVE 研究普遍报告的 SIMD 收益一致性有所不同,强调了针对 ISA 和工作负载的特定评估的重要性。

4. 方法论

4.1. 方法原理

本文的核心方法原理是,通过在 RISC-V 平台上构建支持向量扩展 (RVV) 的高性能深度学习软件栈 (PyTorch + 优化 BLAS 库),并对主流大型语言模型 (LLMs) 进行全面的推理性能基准测试,来评估 RVV 在 LLM 推理中的实际加速效果、性能瓶颈和适用场景。其直觉在于,LLM 推理高度依赖于矩阵乘法等线性代数运算,而向量指令正是为加速这些并行运算而设计。通过详细的实验和分析,包括微基准测试、全模型推理、Roofline 模型分析以及对不同配置(如线程数、数据类型、缓存机制)的探索,来全面理解 RVV 的性能特征。

4.2. 核心方法详解 (逐层深入)

4.2.1. 构建支持 RVV 的 PyTorch 库

为了充分利用 SOPHON SG2042 (搭载 XuanTie C920 核心,支持 RVV v0.7.1) 的向量处理能力,作者首先需要构建一个能够感知并利用 RVV 指令的 PyTorch 库。

  1. 选择 BLAS 库: PyTorch 能够将计算任务委托给底层的低级库,如 BLAS (Basic Linear Algebra Subprograms) 系列库,以充分利用硬件能力。本文选择了两个流行的开源 BLAS 库:
    • OpenBLAS: 一个高度优化的 BLAS 实现。
    • BLIS: 另一个高性能 BLAS 库,以其在多核和向量架构上的分形优化而闻名。 这两个库都可以选择性地编译以支持 RVV。
  2. 编译器工具链:
    • OpenBLAS (v0.3.26): 使用 XuanTie GNU Compiler Toolchain v2.8.0 编译,并通过设置 TARGET=C910vTARGET=C910v 来启用 RVV 支持。
    • BLIS (v0.9.0 的修改版本 [32]): 由于该 BLIS 版本需要基于 LLVM 的编译器,因此使用 LLVM-EPI v1.0.7 编译,并配置 rv64iv0p7 作为目标架构,以匹配 RVV v0.7.1 标准。
  3. PyTorch 编译 (v2.3):
    • 使用 Xuantie's GCC v13.2 编译器。
    • 启用 OpenMP v4.5 (USE_OPENMP=1) 来利用 SG2042 的多核并行能力。
    • 启用 BLASLAPACK (USE_BLAS=1USE_LAPACK=1) 将线性代数运算分派给之前编译的 OpenBLAS 或 BLIS 库。
    • 其他选项包括 USE_KINETO=ON 用于性能分析,USE_NUMPY=ON 用于 NumPy 支持。

4.2.2. LLM 推理性能基准测试

在构建好 PyTorch 后,作者编写了基于 Hugging Face 平台的文本生成 Python 脚本,用于对一系列 LLM 模型进行推理性能测试。

  1. 模型选择: 评估了以下主流 LLMs:
    • BERT (bert-large-cased)
    • GPT-2 (gpt2, gpt2-medium, gpt2-large, gpt2-xl)
    • Gemma-2 (Gemma-2-2B)
    • LLaMA-3.2 (LLaMA-3.2-1B)
    • DeepSeek-LLM (DeepSeek-LLM-7B-base) 这些模型涵盖了不同的参数规模、架构特性和数据类型 (如 float32bfloat16)。
  2. 输入提示 (Input Prompt): 所有实验均使用相同的输入提示 "The quick brown fox ran",并生成接下来 nn 个词元(实验中通常生成 25 个词元)。
  3. 性能指标: 主要测量推理时间 (inference times),并进一步分析吞吐量、延迟和能源效率(摘要中提及,正文侧重于时间)。实验结果取 10 次运行的平均值,并显示标准差。

4.2.3. 微基准测试:aten::addmm 操作分析

为了理解 RVV 对核心线性代数操作的影响,作者首先使用 aten::addmm 操作进行了微基准测试。

  1. 操作定义: aten::addmm 是 PyTorch ATen 后端提供的一个核心线性代数原语,它将矩阵乘法与矩阵加法融合在一个调用中。其数学表达式为: C=A×B+CC = A \times B + C 其中:
    • AA: 维度为 M×KM \times K 的矩阵。
    • BB: 维度为 K×NK \times N 的矩阵。
    • CC: 维度为 M×NM \times N 的矩阵,既是输入的加法项,也是最终结果矩阵。 此操作利用了现代 CPU 和向量指令集 (如 RISC-V 上的 RVV) 的融合乘加 (Fused Multiply-Add, FMA) 指令,可以在单个指令中完成乘法和加法,减少指令数量和舍入误差。
  2. 矩阵尺寸: 测试了两种方形矩阵尺寸:
    • 768×768768 \times 768: 反映轻量级模型 (如 GPT-2) 的隐藏层维度。
    • 4096×40964096 \times 4096: 对应重量级模型 (如 DeepSeek) 的维度。
  3. 配置比较: 比较了五种 PyTorch 配置:
    • PyTorch default (默认后端)
    • PyTorch + OpenBLAS (无 RVV)
    • PyTorch + BLIS (无 RVV)
    • PyTorch + OpenBLAS (带 RVV)
    • PyTorch + BLIS (带 RVV) 并在不同线程数下(从 1 到 64)进行测试。

4.2.4. LLM 推理特性分析

LLMs 的推理过程可以分为两个不同的阶段,具有不同的计算和内存访问模式:

  • Prefill (预填充): 处理整个输入序列。此阶段受益于注意力层之间高数据复用,通常表现出高算术强度,属于计算密集型 (compute-bound)。但它只在每个提示 (prompt) 开始时发生一次。
  • Decode (解码): 自回归地生成输出词元。每一步都依赖于缓存的上下文并引入一个新词元。操作涉及较小的矩阵乘法,数据复用有限,降低了算术强度,使其成为内存密集型 (memory-bound),尤其是在小批处理大小 (batch size) 下(如 N=1N=1)。 批处理大小在两个阶段都至关重要。在延迟敏感的场景中,批处理大小通常为 1,这可能导致内存密集型的 GEMM 操作,向量化收益有限。

4.2.5. Roofline 模型分析

为了深入理解性能瓶颈,作者对代表性的矩阵乘法进行了 Roofline 模型分析。

  1. 理论峰值性能 (Theoretical Peak Performance): 单精度浮点运算的理论峰值性能 FpPeak32Fp_{Peak}^{32} 计算公式为: FpPeak32 [GFLOP/s]=#C×CF×#FPC Fp_{Peak}^{32} \text{ [GFLOP/s]} = \#C \times CF \times \#FPC 其中:

    • #C\#C: 总核心数。
    • CF: 时钟频率 (Clock Frequency),为 2 GHz/s。
    • #FPC\#FPC: 每周期浮点运算次数 (Floats Per Cycle)。
      • 无 RVV (标量): 单核假设每周期执行一个 FMA 指令,则为 2 FLOP/cycle。
      • 有 RVV (向量): C920 的 128 位向量寄存器每周期可处理四个 32 位 FMA 操作,则为 8 FLOP/cycle。 根据此公式,不同核心数下的理论峰值性能如表 2 所示。
  2. 内存带宽 (Memory Bandwidth): SOPHON SG2042 配备四个 DDR4-3200 内存控制器,理论最大带宽为 25.6×4=102.425.6 \times 4 = 102.4 GB/s。通过工具测量,实际有效带宽为 41.2 GB/s (使用 64 核心)。

  3. 算术强度 (Arithmetic Intensity, AI): 对于矩阵乘法 M×K×NM \times K \times N,算术强度 AI 的近似计算公式为: AIO(2×M×N×K)O(4×(M×N+N×K+K×M))O(1) AI \approx \frac{O(2 \times M \times N \times K)}{O(4 \times (M \times N + N \times K + K \times M))} \approx O(1) 注:原文的公式中,分母的 O(4×(M×N+N×K+K×M))O(4 \times (M \times N + N \times K + K \times M)) 代表访问 A, B, C 矩阵所需内存,每个元素 4 字节。当 N=1N=1 时,算术强度较低,接近 BLAS Level 2,性能受限于内存带宽。

  4. 机器平衡点 (Machine Balance Point, BP): BP=FppeakBpeak[FLOPByte] BP = \frac{Fp_{peak}}{B_{peak}} \quad \left[ \frac{\mathrm{FLOP}}{\mathrm{Byte}} \right] 如果一个内核的算术强度低于 BP,则它是内存密集型 (memory-bound);否则,它是计算密集型 (compute-bound)。

4.2.6. Roofline 模型验证

为验证 Roofline 模型的理论洞察,作者测量了 GPT2-medium 模型在完整推理过程中所有 GEMM 操作的执行时间,包括有 RVV 和无 RVV 的 OpenBLAS 配置。

  1. 模拟程序: 实现了一个程序,模拟模型执行的所有 GEMM 操作,使用完全相同的矩阵形状和顺序。
  2. 批处理大小 (Batch Size): 比较了两种代表性配置:
    • N=1N=1: 对应自回归解码中最常见的情况。
    • N=64N=64: 模拟高批处理负载。
  3. 分析: 比较了不同核心数下 GEMM 内核的平均执行时间,按矩阵形状和批处理大小分组。

5. 实验设置

5.1. 数据集

本文的实验没有使用特定的数据集,而是使用预训练好的大型语言模型 (LLMs) 进行推理性能测试。这些模型本身是在海量文本数据上训练的。实验的输入是统一的文本提示 (prompt)。

输入提示示例: 所有实验均使用以下输入提示: "The quick brown fox ran" 模型将根据此提示生成后续的 25 个词元。

模型列表及其特性: 以下是原文 Table 1 的结果,详细列出了实验中使用的 LLM 模型及其关键参数:

Model Parameters Hidden Dim # Layers # Attention Heads Context Length FFN Dim Data Type
GPT-2 137M 768 12 12 1024 3072 float32
GPT-2 Medium 380M 1024 24 16 1024 4096 float32
GPT-2 Large 812M 1280 36 20 1024 5120 float32
GPT-2 XL 1.61B 1600 48 25 1024 6400 float32
BERT-large-cased 335M 1024 24 16 512 4096 float32
Gemma-2-2B 2.61B 2304 26 8 8192 9216 float32
LLaMA-3.2-1B 1.24B 2048 16 32 131072 8192 bfloat16
DeepSeek-LLM-7B-base 7B 4096 30 32 4096 11008 bfloat16

为什么选择这些模型: 这些模型具有代表性,涵盖了不同规模 (从 137M 到 7B 参数)、不同架构 (如 BERT 的编码器型,GPT-2/Gemma/LLaMA/DeepSeek 的解码器型)、以及不同数据类型 (float32, bfloat16)。这使得研究能够全面评估 RVV 在多种 LLM 工作负载下的性能表现,并分析模型规模、架构和数据类型对 RVV 效率的影响。

5.2. 评估指标

本文主要关注以下评估指标:

  1. 推理时间 (Inference Time):

    • 概念定义: 从输入提示开始到生成指定数量的输出词元 (token) 所花费的总时间,通常以秒 (s) 为单位。这是衡量 LLM 推理性能最直接的指标,越短的推理时间表示越高的效率和更低的延迟。
    • 数学公式: 未直接给出公式,但通常是计时器测量的结果。对于 NN 次运行,平均推理时间 TavgT_{avg} 为: Tavg=1Ni=1NTi T_{avg} = \frac{1}{N} \sum_{i=1}^{N} T_i 其中 TiT_i 是第 ii 次运行的推理时间。
    • 符号解释:
      • TavgT_{avg}: 平均推理时间。
      • NN: 运行次数 (本文中为 10 次)。
      • TiT_i: 第 ii 次运行的推理时间。
  2. 加速比 (Speedup):

    • 概念定义: 衡量优化后的系统或方法相对于基线系统或方法的性能提升倍数。如果加速比为 XX,则表示优化后任务完成时间缩短为原来的 1/X1/X
    • 数学公式: Speedup=TbaselineToptimized \text{Speedup} = \frac{T_{baseline}}{T_{optimized}}
    • 符号解释:
      • TbaselineT_{baseline}: 基线配置下的推理时间。
      • ToptimizedT_{optimized}: 优化配置下的推理时间。
  3. GEMM 占总执行时间的百分比 (% of CPU computation):

    • 概念定义: 衡量核心线性代数操作 (如矩阵乘法) 在整个 LLM 推理过程中所占用的 CPU 计算时间的比例。这有助于识别主要计算瓶颈。
    • 数学公式: 未直接给出公式,但根据上下文,可以理解为: GEMM %=TGEMMTtotal×100% \text{GEMM \%} = \frac{T_{GEMM}}{T_{total}} \times 100\%
    • 符号解释:
      • TGEMMT_{GEMM}: GEMM 操作的总执行时间。
      • TtotalT_{total}: 整个模型推理的总执行时间。
  4. 每秒十亿次浮点运算 (GFLOP/s, Giga Floating-point Operations Per Second):

    • 概念定义: 衡量处理器每秒执行的浮点运算次数,是衡量计算能力的常用指标。在 Roofline 模型中用于表示处理器的理论峰值性能。
    • 数学公式: 在 Roofline 模型部分已给出理论峰值计算公式: FpPeak32 [GFLOP/s]=#C×CF×#FPC Fp_{Peak}^{32} \text{ [GFLOP/s]} = \#C \times CF \times \#FPC
    • 符号解释:
      • FpPeak32Fp_{Peak}^{32}: 单精度浮点运算的理论峰值性能。
      • #C\#C: 总核心数。
      • CF: 时钟频率 (2 GHz/s)。
      • #FPC\#FPC: 每周期浮点运算次数 (2 FLOP/cycle 无 RVV,8 FLOP/cycle 有 RVV)。
  5. 每秒千兆字节 (GB/s, Gigabytes Per Second):

    • 概念定义: 衡量内存系统每秒传输的数据量,是衡量内存带宽的指标。在 Roofline 模型中用于表示内存系统的性能限制。
    • 数学公式: 未直接给出公式,但通常通过基准测试工具测量或由硬件规格给出。
    • 符号解释: 无需额外符号解释。
  6. 算术强度 (Arithmetic Intensity, AI):

    • 概念定义: 每执行一次浮点运算所需访问的内存字节数。高算术强度通常意味着工作负载是计算密集型,反之则是内存密集型。
    • 数学公式: 对于矩阵乘法 M×K×NM \times K \times N,近似公式为: AIO(2×M×N×K)O(4×(M×N+N×K+K×M)) AI \approx \frac{O(2 \times M \times N \times K)}{O(4 \times (M \times N + N \times K + K \times M))} 进一步简化为 AIO(1)AI \approx O(1) 在特定条件下。
    • 符号解释:
      • M, K, N: 矩阵的维度。
      • O()O(\dots): 表示数量级。
      • 分子: 总浮点运算次数 (例如,矩阵乘法 AM×K×BK×NA_{M \times K} \times B_{K \times N} 大约需要 2MK N 次浮点运算)。
      • 分母: 总内存访问字节数 (例如,读取 A, B, C 矩阵的内存,每个元素 4 字节)。
  7. 机器平衡点 (Machine Balance Point, BP):

    • 概念定义: Roofline 模型中的一个关键阈值,用于区分工作负载是计算密集型还是内存密集型。如果工作负载的算术强度低于 BP,则受内存带宽限制;如果高于 BP,则受处理器计算能力限制。
    • 数学公式: BP=FppeakBpeak[FLOPByte] BP = \frac{Fp_{peak}}{B_{peak}} \quad \left[ \frac{\mathrm{FLOP}}{\mathrm{Byte}} \right]
    • 符号解释:
      • FppeakFp_{peak}: 处理器的理论峰值浮点运算能力 (GFLOP/s)。
      • BpeakB_{peak}: 内存系统的峰值带宽 (GB/s)。

5.3. 对比基线

论文将自己的方法(在 RVV 启用的 PyTorch + OpenBLAS/BLIS 配置下运行 LLM)与以下基线进行了比较:

  1. PyTorch default (默认后端): 这是 PyTorch 未使用优化 BLAS 库的默认行为,通常在 CPU 上效率较低,并且并行扩展性不佳。它代表了未进行特定优化的基线性能。

  2. PyTorch + OpenBLAS (无 RVV): 使用优化后的 OpenBLAS 库,但未启用 RISC-V 向量扩展 (RVV) 支持。这用于隔离 RVV 带来的性能提升,并评估 OpenBLAS 库本身相对于 PyTorch 默认后端的改进。

  3. PyTorch + BLIS (无 RVV): 类似于 OpenBLAS (无 RVV),但使用 BLIS 库。这用于比较不同优化 BLAS 库在无 RVV 情况下的性能。

    通过这些对比,作者能够量化 RVV 带来的具体性能增益,评估不同 BLAS 库的有效性,并识别 PyTorch 默认后端的局限性。

5.4. 实验平台

硬件:

  • 开发平台: Milk-V Pioneer Box
  • 主板: Pioneer 主板
  • 处理器: SOPHON SG2042 系统级芯片 (SoC)
    • 核心数: 64 个 RISC-V 核心,分为 16 个簇 (cluster)。
    • 簇架构: 每个簇包含一个 XuanTie C920 4 核 RISC-V CPU。
    • L1 缓存: 每个核心配备 64KB 的 L1 指令缓存和数据缓存。
    • L2 缓存: 每个 4 核簇共享 1MB 的 L2 缓存。
    • L3 缓存: 所有 64 个核心共享 64MB 的 L3 缓存。
    • 内存控制器: 四个 DDR4-3200 内存控制器。
    • PCIe: 32 条 PCIe Gen4 通道。
  • 内存: 128GB DDR4 (3200MHz) RAM
  • 存储: 1TB PCIe 3.0 SSD

软件:

  • 操作系统: Linux fedora-riscv 6.1.31
  • PyTorch 版本: v2.3
  • Python 版本: v3.10.10
  • BLAS 库: OpenBLAS v0.3.26 (使用 XuanTie GNU Compiler Toolchain v2.8.0, TARGET=C910v 启用 RVV),BLIS v0.9.0 (修改版本,使用 LLVM-EPI v1.0.7, 目标架构 rv64iv0p7)。
  • 编译器: XuanTie GNU Compiler Toolchain v2.8.0, LLVM-EPI v1.0.7, Xuantie's GCC v13.2。
  • 并行库: OpenMP v4.5。

实验方法: 所有性能实验报告 10 次运行的平均值,并使用误差线表示标准差。

6. 实验结果与分析

6.1. 核心结果分析

6.1.1. 线性代数操作在 LLM 推理中的主导地位

LLM 推理高度依赖于线性代数操作,其中矩阵乘法 (Matrix Multiplication, MM) 是计算最密集的部分。为了量化这一点,论文分析了 PyTorch 跟踪 (traces) 数据。

以下是原文未编号表格,展示了不同 LLM 中 aten::addmmaten::mm 操作在 CPU 总计算时间中的占比:

Model Name Self CPU % Self CPU CPU total % CPU total CPU time avg. # of Calls
GPT-2 aten::addmm 69.55% 13.785s 70.51% 13.975s 5.823ms 2400
BERT aten::addmm 96.55% 7.190s 97.03% 7.225s 49.489ms 3650
LLaMA aten::mm 90.93% 55.545s 90.94% 55.549s 19.663ms 2825
Gemma aten::mm 95.71% 308.439s 95.71% 308.448s 67.420ms 4575
DeepSeek aten::mm 99.57% 2271.444s 99.57% 2271.452s 430.607ms 5275

分析:

  • 对于 GPT-2,aten::addmm 占据了约 70% 的 CPU 计算时间,而 aten::mm 也贡献了约 20%。
  • BERT 模型中,aten::addmm 的占比更高,超过 96%。
  • 在 LLaMA、Gemma 和 DeepSeek 等较新、较大的模型中,aten::mm 成为主导操作,DeepSeek 的占比甚至超过 99%。 这些数据明确指出,矩阵乘法类操作的效率直接决定了 LLM 推理的整体性能。

6.1.2. aten::addmm 微基准测试结果

下图(原文 Figure 2)展示了在不同 OMP 线程数下,PyTorch 及其优化实现(包括 BLIS 和 OpenBLAS)处理 768×768768 \times 7684096×40964096 \times 4096 矩阵的 aten::addmm 执行时间。

该图像是图表,展示了在不同的OMP线程下,PyTorch及其优化实现(包括BLIS和OpenBLAS)处理768×768和4096×4096矩阵的执行时间。图中显示了不同配置对计算性能的影响,结果表明线程数增加时,优化实现显著降低了执行时间。

分析:

  • 优化 BLAS 的优势: 相比默认 PyTorch 配置,切换到优化后的 BLAS 运行时 (OpenBLAS 和 BLIS) 带来了显著的性能提升。
  • RVV 的额外加速: 启用 RVV (RISC-V Vector) 后,性能得到进一步加速,某些场景下甚至实现性能翻倍。这种趋势在不同矩阵尺寸下都观察到。
  • 线程扩展性: 整体上,性能随着线程数增加而良好扩展,最佳性能通常在 16 到 32 线程之间。这表明 RISC-V 平台能有效扩展并行工作负载。
  • 小矩阵的开销: 对于 768×768768 \times 768 矩阵,当线程数达到 32 和 64 时,性能反而有所下降。这是因为对于较小尺寸的矩阵,生成和管理线程的开销可能超过了矩阵乘法本身带来的收益。

6.1.3. GEMM 在完整模型执行时间中的占比

虽然微基准测试显示 GEMM 操作性能可观,但在完整模型中,GEMM 所占总执行时间的比例会受其他因素影响。下图(原文 Figure 3)展示了 GPT-2 等模型在不同线程数下,GEMM 计算时间占总执行时间的比例。

Figure 3: Time spent exclusively running GEMM computations by GPT-2 models compared to the total execution time across different thread counts. The models were run with PyTorch `+` OpenBLAS with RVV…

分析:

  • GEMM 占比的下降: 当线程数增加时,GEMM 在总执行时间中的占比会显著下降。例如,GPT2-medium 和 BERT 模型在多线程下,GEMM 占比可降至 50% 甚至更低。
  • 其他瓶颈: 这表明,尽管矩阵乘法主导了 CPU 操作,但 LLM 实际执行的是一系列复杂操作,包括不同张量形状、内存访问模式、非线性激活、归一化层和控制流逻辑。增加并行度可能引入其他瓶颈,如计算强度不足和内存流量增加。
  • 微基准测试的局限性: 这一发现强调了仅依赖隔离内核的基准测试不足以完全代表完整模型的行为,需要考虑实际模型执行的复杂性。

6.1.4. 完整模型推理性能

下图(原文 Figure 4)展示了 BERT、Gemma-2 和 DeepSeek 三个 LLM 在生成 25 个词元时的推理性能,比较了五种 PyTorch 配置在不同线程数下的表现。

Figure 4: LLMs inference performance when generating 25 tokens and using PyTorch with different BLAS runtimes over multiple thread counts.

分析:

  • BERT 模型的行为 (Bert-like behavior): 性能随线程数增加而可预测地扩展,并从 RVV 加速中受益。其中 PyTorch + BLIS 表现最佳。然而,默认 PyTorch 后端在并行度增加时性能反而下降。
  • Gemma-2 模型的行为 (Gemma-like behavior): 在单线程下,PyTorch + OpenBLAS (无论是否 RVV) 性能显著差于 PyTorch + BLIS 和默认后端。但在 16 和 32 线程下,PyTorch + OpenBLAS (带 RVV) 实现了最佳执行时间。例如,在 16 线程下,RVV 使执行时间从 82.5 秒降至 60.5 秒,性能提升约 26.7%。这表明 OpenBLAS 在单线程下可能存在特定开销,但 RVV 在多线程时能有效弥补。
  • DeepSeek-LLM 模型的行为 (DeepSeek-like behavior): 在所有配置下,DeepSeek 的执行时间几乎相同,且无明显的可扩展性。这是因为该模型使用 bfloat16 数据类型,而实验平台缺乏对 BF16 的原生硬件支持。PyTorch 会回退到效率低下的软件仿真或单线程实现,导致性能平坦。

6.1.5. 模型规模对 GPT-2 性能的影响

下图(原文 Figure 5)展示了四种不同尺寸的 GPT-2 模型在不同 OMP 线程数下的推理执行时间。

该图像是图表,展示了不同OMP线程数下,基于RISC-V向量的多种LLM(包括openai-community/gpt2和其多个变体)的推理执行时间。图中的数据表明,随着线程数的增加,执行时间在不同配置间存在显著差异。

分析:

  • PyTorch 默认后端的行为: 对于较小模型 (gpt2, gpt2-medium),默认后端性能较好,有时甚至优于其他后端(尤其是在 gpt2-medium 的单线程配置下)。但对于较大模型 (gpt2-large, gpt2-xl),其性能急剧下降,无法扩展。

    • 微架构洞察: 对 gpt2-medium,CPU 的指令每周期 (IPC) 比率为 0.95,停滞周期 (stalled cycles) 较少,表明管线利用率高。而 gpt2-large 的 IPC 降至 0.37,停滞周期显著增加,后端和前端停滞率高,表明数据供给和指令取指/发射存在严重瓶颈。
    • 缓存行为: gpt2-large 的 L1 和 LLC (Last Level Cache) 缓存未命中率增加,LLC 未命中占所有 LLC 访问的 46.8% (gpt2-medium 为 31.1%),表明模型增大导致内存压力增加,缓存未命中惩罚和停滞内存访问增加。
  • RVV 的单线程异常: 对于 gpt2-medium,单线程 RVV 启用时的 OpenBLAS 后端执行时间比非 RVV 版本高三倍。这与一般趋势相反,表明 RVV 在某些特定场景下可能引入额外开销。

  • GPT2-medium 的 GEMM 形状分析: 针对 gpt2-medium 的 RVV 性能下降问题,下图(原文 Figure 6)展示了在不同线程数下,不同 GEMM 形状的执行时间。

    该图像是图表,展示了不同矩阵形状下,使用和不使用 RISC-V 向量扩展(RVV)在不同线程数(1、4、8、16、32、64)下的执行时间(ms)。横坐标为矩阵形状 (M×N×K),纵坐标为执行时间。图中曲线和柱状图显示了 RVV 的性能优势,尤其是在多线程情况下,执行时间明显降低。

    分析:

  • RVV 性能下降并非由单个病态内核引起,而是在模型中所有常见 GEMM 配置(特别是 1024×1×10241024 \times 1 \times 10244096×1×10244096 \times 1 \times 1024 等矩阵形状)中普遍存在。这些操作在自回归解码中以 N=1N=1 顺序执行,证实了小批次 GEMM 的内存密集型特性导致 RVV 效率低下。

6.1.6. 注意力缓存 (KV Cache) 对 RVV 的影响

下图(原文 Figure 7)比较了 GPT-2 模型在启用和禁用 Transformers 库的 KV 缓存机制下的单线程性能。

Figure 7: Single-thread performance of GPT-2 with the transformers caching mechanism (KV cache) enabled and disabled.

分析:

  • RVV 与缓存的关系: 与预期相反,启用注意力缓存 (use_cache=True) 在 RVV 执行下带来的性能收益有限。虽然缓存显著减少了指令数量,但运行时改进不大。
  • 缓存对 RVV 优势的限制: RVV 启用时的缓存加速比 (gpt2-medium 仅 1.2x) 远低于非 RVV (3.2x) 或 PyTorch 默认后端 (11x)。
  • 结论: 这表明 RVV 向量化在重新计算所有注意力层 (即禁用缓存) 的常规计算路径中更有效,因为这提供了更多向量利用的机会。缓存机制减少了计算强度,从而限制了 RVV 的潜在优势。

6.1.7. 不支持数据类型 (BF16 vs FP32) 的处理

下图(原文 Figure 8)展示了 LLaMA LLM 在 SG2042 RISC-V CPU 上的推理性能,比较了其原始 bfloat16 权重表示和转换为 float32 后的性能。

Figure 8: Inference performance of the LLaMA LLM on the SG2042 RISC-V CPU using PyTorch with different BLAS runtimes and thread counts. Results are shown for the model using its original torch. bfloa…

分析:

  • BF16 的性能瓶颈 (左图): 当使用 bfloat16 (BF16) 数据类型时,LLaMA 的性能在所有后端和线程数下都非常平坦,运行时间稳定在 63 秒左右。这是因为 RISC-V 平台不原生支持 BF16,且 OpenBLAS 和 BLIS 库也不支持 BF16 操作。PyTorch 会回退到效率低下(通常是单线程)的非 BLAS 内核或 CPU 实现。
  • FP32 的性能提升 (右图): 将 LLaMA 模型转换为 float32 (FP32) 后,性能显著提升,尤其是在 OpenBLAS 和 RVV 启用配置下。例如,在 4 线程下,OpenBLAS (无 RVV) 的性能从 63 秒 (BF16) 提升到 38 秒 (FP32)。
  • 结论: 对于不支持 BF16 的 RISC-V 平台,将模型转换为 FP32 对于解锁线程级并行和 RVV 向量化至关重要。虽然某些后端 (如 BLIS) 在低线程数下 FP32 性能可能略差,但总体而言,兼容的数据类型是实现硬件优化潜力的关键。

6.1.8. LLM GEMM 性能的 Roofline 模型分析

Roofline 模型分析用于深入理解 GEMM 性能行为。下图(原文 Figure 9)展示了在 1、8、32 和 64 核心下,针对 M=1024,K=1024M=1024, K=1024NN 变化的矩阵乘法的 Roofline 模型。

该图像是图表,展示了不同核数下RISC-V CPU的性能与算术强度的关系。图(a)至图(d)分别代表1核、8核、32核和64核的性能测量,显示了峰值和测量带宽的对比,数据表明RVV在高算术强度下表现优越。

分析:

  • N=1 的内存密集型特性: 在所有核心数配置下,当 N=1N=1 时,内核始终处于内存密集型 (memory-bound) 区域。其算术强度 AI 约为 O(1)O(1),属于 BLAS Level 2 操作,性能受内存带宽限制。
    • 在单核 (Figure 9a) 下,由于 RVV 对内存带宽的需求更高,非 RVV 实现性能优于 RVV。
  • N 增加对算术强度的影响: 增加 NN 值可以提高算术强度。
    • N=8N=8 时,RVV 性能开始超越非 RVV,但仍接近机器平衡点 (BP)。
    • N=64N=64 时,计算完全进入计算密集型 (compute-bound) 区域,RVV 指令的优势得到充分发挥,RVV 和非 RVV 都能接近各自的理论峰值性能。
  • 多核扩展的挑战:
    • 随着核心数增加 (Figure 9b, 9c, 9d),机器平衡点 BP 会向右移动,因为峰值浮点性能 FppeakFp_{peak} 增长速度快于测量到的内存带宽 BpeakB_{peak}
    • 对于 N=1N=1 的内存密集型内核,非 RVV 版本在多核下仍然优于 RVV 版本。
    • 在 8 核配置下 (Figure 9b),即使是 N=4N=4 的内核也仍然是内存密集型。
    • 当核心数增加到 32 或 64 时 (Figure 9c, 9d),虽然 N=64N=64 的内核仍是计算密集型,但每个线程的工作量大幅减少,性能与最优值的差距增大,RVV 的优势减弱。这归因于数据移动和线程同步的开销,这些开销抵消了额外的计算能力带来的收益,尤其是在小批次 (N=1N=1) 这种 LLM 推理主导的工作负载中。

6.1.9. GPT2-medium 上的 Roofline 模型验证

为了验证 Roofline 模型,论文模拟了 GPT2-medium 模型在完整推理过程中所有 GEMM 操作的执行时间。下图(原文 Figure 10)展示了 N=1N=1N=64N=64 两种批处理大小下,GEMM 内核的平均执行时间。

该图像是执行时间的柱状图,展示了不同矩阵形状与线程数对执行时间的影响。上部分为 \(N=1\) 的结果,展示了 RVV 和 No-RVV 下的执行时间对比;下部分为 \(N=64\) 的结果,显示了更高矩阵形状的执行时间变化。图中涵盖了多线程配置的性能差异。

分析:

  • N=1 (上部分):
    • 正如 Roofline 分析预测,在 N=1N=1 的内存密集型区域,RVV 向量指令几乎不提供性能收益,在大多数情况下甚至会因增加内存带宽需求和寄存器压力而降低性能。
    • 在低线程数下,非 RVV 版本始终优于 RVV 实现。
  • N=64 (下部分):
    • NN 增加到 64 时,算术强度显著提高,计算进入计算密集型区域。
    • 在这种条件下,RVV 变得更有效,相对于非 RVV 执行,性能有显著改善,特别是在中低线程数 (1-16 核) 下。
    • 然而,在更高的核心数 (32 和 64) 下,性能差距缩小或在某些情况下反转,可能是由于线程的收益递减、内存通道的竞争增加以及每个线程的工作负载减少,限制了向量寄存器的利用率。
  • 结论: 这些结果再次强调,RVV 指令主要在算术强度足够高且每个核心的工作负载足以分摊向量化开销时才有利。这凸显了在典型 LLM 推理工作负载(通常包含大量 N=1N=1 的小矩阵乘法)中利用 RVV 的挑战。

6.2. 数据呈现 (表格)

本文中主要用于呈现数据信息的表格是 Table 1(模型特性)和 PyTorch 跟踪表(模型中 aten::addmm / aten::mm 的占比)。由于 PyTorch 跟踪表已在 6.1.1 节中呈现,这里不再重复。

6.3. 消融实验/参数分析

论文通过以下方式进行了类似于消融实验或参数分析:

  1. BLAS 库与 RVV 启用/禁用: 比较了 PyTorch 默认、PyTorch + OpenBLAS (无 RVV)、PyTorch + BLIS (无 RVV)、PyTorch + OpenBLAS (带 RVV) 和 PyTorch + BLIS (带 RVV) 这五种配置,以隔离不同优化库和 RVV 向量化带来的性能影响。

  2. 线程数变化: 实验在 1、4、8、16、32、64 等不同 OMP 线程数下进行,分析并行度对性能的影响和可扩展性。

  3. 模型规模变化: 使用 GPT-2 的不同尺寸 (gpt2, gpt2-medium, gpt2-large, gpt2-xl) 来分析模型参数量对性能瓶颈和 RVV 效率的影响。

  4. 数据类型影响: 比较了 LLaMA 模型在原始 bfloat16 和转换为 float32 两种数据类型下的性能,揭示了硬件原生支持数据类型的重要性。

  5. KV 缓存机制: 比较了 GPT-2 模型在启用和禁用注意力缓存 (use_cache) 两种情况下的性能,分析其对 RVV 向量化效率的影响。

  6. 矩阵形状与批处理大小: 通过微基准测试和模拟程序,分析了不同矩阵形状和批处理大小 (N=1N=1 vs N=64N=64) 对 GEMM 性能以及 RVV 效率的影响,并结合 Roofline 模型进行解释。

    这些分析帮助作者深入理解了 RVV 的适用场景、性能边界和潜在瓶颈,并为未来的优化提供了方向。

7. 总结与思考

7.1. 结论总结

本文对在配备 RISC-V 向量扩展 v0.7.1 的 64 核 RISC-V CPU (SOPHON SG2042) 上运行预训练大型语言模型 (LLMs) 的推理性能进行了全面评估。主要结论如下:

  1. RVV 的条件性收益: 启用 RVV 硬件向量化可以为 LLM 推理带来性能提升,但这种收益高度依赖于配置。在计算密集型的工作负载和较大批处理规模下,RVV 表现出显著优势(例如,7B 模型加速高达 1.8x,13B 模型加速高达 1.4x)。

  2. 内存密集型瓶颈: RVV 启用时的矩阵乘法在推理工作负载为小批处理大小 (例如 N=1N=1) 时,往往比标量实现慢。Roofline 模型分析和实验验证表明,这是因为此类 GEMM 具有低算术强度,属于内存密集型,向量化无法充分利用。

  3. 数据类型兼容性至关重要: LLMs 使用 bfloat16 等不被硬件原生支持的数据类型会导致性能平坦且不可扩展,因为 PyTorch 会回退到低效的软件仿真。将模型转换为 float32 可以解锁线程级并行和 RVV 向量化带来的性能提升。

  4. KV 缓存对 RVV 的影响: 虽然 KV 缓存通常能减少计算量,但它可能限制 RVV 的潜在优势。RVV 在常规计算路径(即不使用缓存,重新计算所有注意力层)中表现更好,提供了更多向量利用的机会。

  5. BLAS 库与线程管理: 优化后的 BLAS 运行时(如 OpenBLAS 和 BLIS)相比默认 PyTorch 配置有显著性能提升。然而,线程开销、内存带宽饱和以及核心级竞争会影响 RVV 的效率,尤其是在高核心数和低工作负载场景下。

    综上所述,RVV 在 RISC-V 平台上加速 LLM 推理方面具有潜力,但其有效性严格依赖于工作负载特性(如矩阵形状、批处理大小、算术强度)、数据类型兼容性以及是否有效避免了缓存机制带来的计算强度降低。

7.2. 局限性与未来工作

作者指出的局限性:

  • BF16 到 FP16 转换的性能问题: RISC-V 架构支持 FP16 数据类型,但初步实验显示将 BF16 模型转换为 FP16 相比转换为 FP32 导致了显著的性能开销,这需要进一步调查。
  • RVV 可扩展性不一致: 在某些模型和线程数下,RVV 性能出现平台期甚至下降,这表明线程开销、内存带宽饱和和核心级竞争会影响 RVV 效率。
  • 当前 RVV 版本的局限性: 论文主要评估的是 RVV v0.7.1,而更稳定的 v1.0 版本已发布,可能会带来不同的性能特性。

作者提出的未来研究方向:

  • 深入研究 FP16 转换性能: 调查将 BF16 模型转换为 FP16 时的性能开销原因。
  • 优化线程调度和内存管理: 深入理解线程开销、内存带宽饱和和核心级竞争如何影响 RVV 效率,以期进行未来的优化。
  • 评估量化模型和稀疏表示: 探索量化模型 (quantized models) 和稀疏表示 (sparse representations) 是否能进一步放大 RVV 的优势。
  • 跨架构比较不支持数据类型: 进一步研究在 RISC-V 平台上运行不支持数据类型 (如 BF16) 对性能的影响,并与 x86 和 ARM 等其他先进架构进行比较。
  • SG2042 NUMA 设计的影响: 调查 SG2042 系统的 NUMA (Non-Uniform Memory Access) 设计对性能的影响,可能通过测试更复杂的任务调度策略和理解相关开销来实现。

7.3. 个人启发与批判

个人启发:

  • 硬件-软件协同设计的重要性: 这篇论文再次强调了在 AI 时代硬件架构 (如 RVV) 和软件栈 (如 PyTorch 和 BLAS 库) 协同优化的极端重要性。仅仅拥有高性能硬件是不足的,还需要匹配的软件生态才能充分发挥其潜力。
  • 细致分析工作负载的价值: LLM 推理并非单一均匀的工作负载。它由不同特性的阶段(Prefill, Decode)和不同规模的矩阵操作组成。深入的微基准测试、Roofline 模型分析以及对 KV 缓存、数据类型等细节的考量,对于发现真正的性能瓶颈和指导优化方向至关重要。不能简单地认为“向量化总是有益的”。
  • 新兴架构的挑战与机遇: RISC-V 作为一个开放的 ISA,在能效和定制化方面具有巨大潜力。然而,其软件生态的成熟度、对不同数据类型的支持、以及在复杂多核环境下的性能扩展性仍是挑战。这为学术界和工业界提供了广阔的探索空间。
  • 实践优于理论: 论文通过实际在硅片上运行完整的 LLM,并发现与隔离内核基准测试结果的差异,强调了在真实场景下进行评估的重要性。

批判与可以改进之处:

  • 能源效率的缺失: 摘要中提到了测量能源效率,但在正文的实验结果与分析部分,主要侧重于吞吐量和延迟(通过执行时间体现)。如果能提供具体的能耗数据,将更能支持 RISC-V 作为“能效高架构”的论点,并提供更全面的评估。
  • RVV 版本差异的讨论不足: 论文提到 RVV v0.7.1 和 v1.0 之间的差异,以及大多数商用硬件仍支持 v0.7.1。但对于这两个版本在指令集、功能或性能上的具体差异,以及这种差异可能如何影响实验结果,可以进行更深入的讨论。
  • 更广泛的 LLM 架构和优化: 论文主要关注了基于 Transformer 编码器-解码器和解码器架构的 LLM。未来的工作可以探索更广泛的 LLM 架构(例如混合专家模型 MoE)以及更先进的优化技术(如更细粒度的量化、剪枝等)与 RVV 的结合。
  • 软件栈成熟度的量化: 论文多次提到 RISC-V 软件栈不成熟。除了具体问题的发现,可以尝试提供一些量化的指标或框架来衡量这种成熟度,并提出更具体的改进建议。
  • NUMA 效应的初步探索: 尽管作者在未来工作中提到了 NUMA 效应,但在当前分析中,对于 64 核系统,NUMA 的影响很可能已经存在。如果能在实验设计阶段,对 NUMA 亲和性 (affinity) 进行初步控制或分析,可能能避免一些多核扩展性下降的问题,或至少能更好地解释现象。
  • 最佳向量宽度 (Vector Width) 的具体报告: 摘要提到“识别了最佳向量宽度”,但正文中并未具体报告这些最佳宽度是什么,以及如何随模型尺寸变化。如果能提供这些具体信息,将对硬件设计者更有价值。

相似论文推荐

基于向量语义检索推荐的相关论文。

暂时没有找到相似论文。