RISC-V 跑 CUDA 准入：规范『建议』，NVIDIA 要『必须』

2026 年 8 月 23 日，工程师云集的 Hot Chips 大会上，NVIDIA 的 Frans Sijstermans 在 RISC-V 专场里公开列出了一份标题为 "CUDA requirements for RISC-V CPUs" 的清单。新闻标题很容易把它写成"NVIDIA 为开放指令集多支持了一种架构"，好像加个编译器后端、重新编译一次就能跑。这篇专题想把这件事讲清楚：NVIDIA 不是在做指令翻译，而是在给 RISC-V 服务器平台立一份准入合同。合同里每一道门槛，都不是"建议"，而是"必须"。我们从最直觉的误解开始拆。

一、开放 ISA 加一次重编译，就能跑 CUDA 了吗？

拆掉"重编译"直觉

RISC-V 是开放指令集，CUDA 是 NVIDIA 的 GPU 编程与运行软件栈。把这两句话放一起，最顺手的理解是：给 CUDA 的编译器接一个 RISC-V 后端，让主机侧代码生成 RISC-V 指令，就"支持"了。

这个理解只对了一半。CUDA 跑在 GPU 集群上，CPU 能执行主机代码只是起点。它背后还挂着驱动、固件、DMA 引擎、多设备拓扑这些系统语义。你部署 GPU 服务器时应该有过这种经验：插第二张卡、换一块主板、升一次固件，都可能让 CUDA 栈突然"不认识"机器。决定能不能跑的，是整台机器被操作系统和驱动"看懂"的方式。这套约定有一个名字：平台 ABI（Platform ABI），比 ISA 高一层，覆盖设备发现、固件接口与互连语义的整套约定。

平台 ABI：CUDA 要跑通的是整台服务器

RISC-V 自己把"一台服务器长什么样"写成了规范。RISC-V Server Platform v1.0 开篇的架构图，把这套约定画得明明白白：

图注：RISC-V 自家规范画的服务器分层：应用与 OS 在上层，虚线框里的 Server Platform 把 Boot and Runtime Services、平台固件、安全模型和 SoC 硬件打包成可描述、可测试的契约，底部 BMC 带外管理。CUDA 要跑通的是这张图代表的整台机器。Server SoC v1.0

注意这是 RISC-V 官方规范的图，不是 NVIDIA 的材料。它说明"服务器平台 ABI"不是抽象名词，而是被规范逐层定义、可以逐条检查的实体。CUDA 要跑在上面，就得先让整台机器符合这张图。

NVIDIA 公开的那页纸：门槛清单

在 Hot Chips 现场，NVIDIA 正是拿这层结构当准入清单。公开的 slide 上写着两组要求：第一组"遵守 RISC-V 服务器相关规范"，点了四份 RISC-V 自有规范的名字：RVA23（CPU 配置档案，规定哪些指令扩展必须在场）、BRS（引导与运行时固件契约）、Server SoC（服务器级片上系统的硬件要求）、Server Platform（板级平台结构）；第二组是"CUDA 专属要求"，现场概括只有一句：mostly related to data movement between memories（主要是内存之间的数据搬运）。完整的合同大约两页纸，只提供给合作伙伴，细节在 NDA 之下。Chips and Cheese

图注：NVIDIA 在 Hot Chips 2026 公开的那页 "CUDA requirements for RISC-V CPUs"：左栏两组 bullet 点出四份 RISC-V 规范与"数据搬运"概括，右栏是 Applications 到 BMC 的分层栈图，与上图 RISC-V 自家规范画的结构几乎同构。这张图是"准入清单真实存在"的事件证据，右栏不要读成六道关卡的顺序。ServeTheHome

这些规范全是最近两年密集落地的：RVA23 在 2024 年 10 月批准，Server SoC 在 2025 年 2 月，ACPI 6.6 在 2025 年 5 月给 RISC-V 补上了设备发现表格，BRS 在 2025 年 8 月，Server Platform 在 2026 年 5 月。NVIDIA 清单里的每一项，都指向一份刚出笼的真实规范，而不是什么未来的许诺。NVIDIA 现场还确认，RISC-V 侧唯一公开的硅片合作方是 SiFive，他们计划带一台跑 CUDA 的系统来展示，这台机器随后在 Hot Chips 期间随之揭晓为 BigSky。

把门槛摊成一页纸：

第一章的答案已经明确：CUDA 进 RISC-V 不是一次重编译，而是一份指向 RISC-V 服务器平台规范的准入合同。它真实存在，条款由 NVIDIA 定义。那么问题来了：这些门为什么是硬的？缺了它们，CUDA 软件栈到底会怎样？下一章从故障讲起。

二、缓存旧数据、绕行主存、不被认识的主板：门槛为什么是硬的

故障一：DMA 读到缓存里的旧数据

场景是这样的。CPU 把数据写进内存，但写完后数据还留在 CPU 缓存里，来不及回写主存。CUDA 这时发起一个 host 到 device 的 DMA 拷贝，DMA 引擎直接去 DRAM 读，读到的却是旧版本；反过来，GPU 把结果写回主存之后，CPU 从缓存里读到的也可能还是旧数据。没有硬件级一致性，软件就只能显式做 cache flush 和 invalidate。NVIDIA 在现场给出的拒绝理由很直接：把缓存失效操作写进 CUDA 驱动栈非常难，而且 PCIe I/O coherency 在其它主流服务器 CPU 里都是标配。现场分析师 Chester Lam 的笔记补了关键一句：RISC-V 的服务器 SoC 规范只是"建议"硬件实现一致性，而 NVIDIA 要的是保证（guarantee）。Chips and Cheese

时序是这样的：

图注：没有 I/O 一致性时的脏缓存时序：CPU 写入的数据停留在缓存，写回被推迟；DMA 从主存读到的是旧副本。要避免这个结果，要么硬件做一致性协议，要么软件显式清缓存，NVIDIA 选择前者。

NVIDIA 那页专门讲这一条的 slide 给出了"为什么必须"的理由：

图注：NVIDIA 的 "PCIe coherency" slide：硬件级 I/O 一致性可以避免频繁的 cache flush 与 invalidate，从而简化软件、改善延迟、把负担从 CPU 卸下，而且大多数现代服务器 CPU 已经支持。右侧只是 CPU 与 GPU 的简化拓扑概览，并不含有 DMA 流向的故障时序。Chips and Cheese

那么规范把这道责任钉在哪个部件上？Server SoC 规范的 PCIe 子系统图给出了精确位置：

图注：Server SoC 规范自带的 PCIe root complex 图：CPU 与内存经 SoC 互连进入 Root Complex，内部是 Host Bridge、IOMMU、Root Port 与下游端点。缓存一致性条款 CCS_040 的责任在 Host Bridge，P2P 控制条款 ACS_030 / ACS_040 在 Root Port，SoC 集成端点的 SID_060 在端点：故障发生的位置就是条款作用的位置。Server SoC v1.0

故障二：多卡数据绕行主存

第二个故障发生在多 GPU 之间。CUDA 的多卡互相拷贝缓冲区，如果平台不支持 PCIe P2P，数据只能先经 CPU 内存转一手。Chester Lam 转述得很直白：缓冲区在两个设备间拷贝要经过 CPU 内存，既费性能又增加复杂度，因为要多一层同步信号。你在训练集群上的经验可以对照：卡间流量每绕一次主存，延迟和带宽立刻难看。

NVIDIA 那页 P2P slide 上的框图，恰好就是没有 P2P 时的拓扑：

图注：NVIDIA 的 "PCIe P2P" slide：CPU 居中，GPU 0 与 GPU 1 只与 CPU 相连，两卡之间没有直接连线。没有 P2P 时，卡间数据只能绕 CPU；有 P2P 时，两卡之间才会多出一条直连路径。Chips and Cheese

直通与绕行的差别，一张小图说清：

图注：绕行与直通的对比：没有 P2P，GPU 0 的数据要经主存中转，多一次拷贝和同步；有 P2P，两卡直连，旁路主存。上一节的 Root Complex 图里，这条路径的开关控制在 Root Port 上（ACS_040）。

故障三：操作系统认不出这块主板

第三个故障不在数据路径上，而发生在开机后的第一秒。操作系统要靠固件提供的表格发现硬件：有几个核、中断控制器在哪、PCIe 层级长什么样、NUMA 距离是多少。这套表格规范叫 ACPI（Advanced Configuration and Power Interface）。RISC-V 起步时没有 ACPI，只能靠 device tree，通用内核和驱动无法可靠地"认识"一块主板。NVIDIA 软件团队在移植 CUDA 时为此吃过亏，Chester Lam 记录说，RISC-V 硬件刚起步时没有 ACPI，直到 2025 年 UEFI Forum 才把 RISC-V 写进 ACPI 规范。这就是 ACPI 6.6：MADT 表新增四个 RISC-V 中断控制器结构（RINTC、IMSIC、APLIC、PLIC），并引入描述每个 hart 能力的 RHCT 表，规范明确要求每个 hart 在 MADT 里有一条 RINTC 记录。ACPI 6.6

ACPI 6.6 想标准化的发现链路长这样。这张图来自 Ventana Micro 在 RISC-V Summit 2024 的演讲，这家公司正是 ACPI 6.6 里 RISC-V 章节的作者：

图注：RISC-V 中断控制器的发现层级：每个 hart 挂一个 IMSIC，平台上再挂 APLIC 域，PCIe 网卡、NVMe 等设备通过 MSI 或 wired IRQ 接入。ACPI 6.6 把这套结构写进 MADT，操作系统才能在启动时按表发现它们。ACPI 6.6

把三个故障钉成一张表：

这三道门槛不是 NVIDIA 挑剔。缺了它们，CUDA 软件栈会读到脏数据、绕远路、找不到主板，所以硬件级 I/O 一致性、P2P 和统一的 ACPI 描述是必需品而不是加分项。不过这些"必须"目前都是 NVIDIA 的转述，RISC-V 规范自己到底是怎么写的？下一章逐字对照。

三、规范原文写着 SHOULD 和 MAY，NVIDIA 要的是 MUST

先把规范语言的三个等级说清楚

RISC-V 规范正文里，英文大写的关键词按 RFC 2119 解释，分三个等级：MUST（必须实现，不实现就不合规）、SHOULD（建议实现，有合理理由可以不做，后果自负）、MAY（可选，厂商自己决定）。Server SoC 与 Server Platform 两份规范的引言都写明了这一解释规则：这些关键词只有在全部大写时才有规范效力。Server SoC v1.0

关键在最后一步：只有 MUST 能写进测试套件、能开出合规证书。SHOULD 和 MAY 无法被机器测试，所以也无法成为准入的门槛。这正是接下来对照的核心。

逐字对照：SHOULD 对 MUST

把 Server SoC v1.0 里与 CUDA 最相关的三条拿出来，逐字对照 NVIDIA 的准入：

有意思的是规范内部自己在收紧：ACS_030 已经把 P2P request redirect 写成 MUST，SID_060 对 SoC 集成端点也是 MUST，只有根端口的出口控制（ACS_040）还停在 SHOULD。也就是说 RISC-V 留给实现的自由空间正在缩小，但 NVIDIA 不等它缩完，直接把剩下的 SHOULD 收编成 MUST。Chester Lam 的现场记录是这一动作的最直白证据：规范"建议"硬件实现缓存一致性，NVIDIA 要的是 guarantee（保证）。Chips and Cheese

MUST 链条与 CPU 端入门票

Server Platform v1.0 走得更远。它不满足于单条条款，而是把三份 RISC-V 自有规范直接绑成一条 MUST 链：

这条链意味着：一块想进服务器市场的 RISC-V SoC，在 ISA 层、SoC 层、固件层已经没有"我实现得不一样"的余地。Server Platform v1.0

链的最上游是 CPU 端"入门票"RVA23。RVA23U64 把 V（向量扩展）从 RVA22U64 的可选升成强制，Zvfhmin（向量半精度浮点）、Zvbb（向量位操作）、Zvkt（向量常数时间执行）同样是新晋强制项：RVA23 Profile

图注：RVA23 规范文档里的 RVA23U64 强制扩展清单：V 向量扩展（旁边标注 "V was optional in RVA22U64"）、Zvfhmin、Zvbb、Zvkt 全部升格，底部只剩两类本地化可选项 Zvkng / Zvksg。页面上的铅笔图标是文档编辑标注，不是规范条款。RVA23 Profile

为什么 NVIDIA 这么在意这份强制清单？怕的是"最弱公分母"（lowest common denominator）。道理很朴素：写 CUDA 库的编译器，如果无法保证目标机器的向量扩展一定存在，就只能退回最保守的路径，为每种可能缺扩展的硬件写带分支的代码。向量扩展提供 predication（谓词执行），让内层循环可以无分支，性能受益巨大。RVA23 规范自己的前言也用了同一个词：如果不主动对齐，每个生态都会按"市场上观察到的最弱公分母"来写软件，所有实现一起吃亏。NVIDIA 在 Hot Chips 上直接把立场写进了 slide 标题。看这一页：

图注：NVIDIA 的 slide "RISC-V Server specifications enable the SW ecosystem"：四个小节里写着 "RVA23 profile guarantees key extensions are present"（RVA23 保证关键扩展在场）、"Optimization without code branches" 和 "No problematic lowest common denominator"。这是 NVIDIA 公开引用 RVA23 强制化的核心理由。Chips and Cheese

CPU 端之外，固件端同样被拧紧。BRS v1.0 在 2025 年 8 月批准，把规范分成两个 recipe：BRS-I（可互操作，目标是让一个通用 OS 镜像在所有合规机器上启动）和 BRS-B（定制场景，宽松得多）。BRS-I 的配方表把 ACPI ≥ 6.6 写成版本下限，第五章的 ACPI 要求表 ACPI_010060 与 AML_010100 几乎全是 MUST，连处理器拓扑表 PPTT 都强制要求实现。换句话，ACPI 从"有没有"变成了"必须有且可测试"。BRS v1.0

第三章的答案已经完整：NVIDIA 没有改写任何一份 RISC-V 规范，而是把规范里留给实现的"建议"和"可选"逐条收编成准入的"必须"。兼容性的决定权，从"指令能否译码"移到了"平台能否通过可测试的契约"。这引出一个更值得琢磨的问题：一个 GPU 厂商凭什么能这样收编开放标准？在 RISC-V 之前，有人这么干过吗？下一章把时间拨回 2014 年。

四、2014 年 Arm 就趟过这条路：平台标准换生态，代价是实现自由

2014：一份规范换单一 OS 镜像

2014 年 1 月 29 日，Arm 发布了一份叫 SBSA（Server Base System Architecture）的规范，第一天就拉来软件公司（Canonical、Citrix、Linaro、Red Hat、SUSE）、OEM（Dell、HP）和硅片厂（AMD、AppliedMicro、Broadcom、Cavium、TI）。公告的第一句目标写得极直白：确保足够的标准系统架构，让一个单一 OS 镜像（single OS image）跑在所有符合这份规范的硬件上。Arm SBSA

这句话换个主语，就是 NVIDIA 现在对 RISC-V 干的事：让一个 CUDA 软件栈覆盖所有合规的 RISC-V 服务器。12 年前的命题和 2026 年的命题，连分层结构都一样：

图注：Arm 2014 年 SBSA 规范配图：左侧三条项目符号写着"单一 OS 镜像覆盖所有 ARMv8-A 服务器"，右侧 Applications 之下是 OS 的几种形态、Firmware + Network Boot，最底层 SoC Platform，虚线框圈住的就是 SBSA Specification 要约束的范围。把它和第一章的 RISC-V Server Platform 图并排看，几乎是同一张图。AnandTech 存档

从规范到认证：SBBR 的五年

规范要有配套才能落地。固件侧 Arm 又出了一份 SBBR（Server Base Boot Requirements），两条腿一起才可测试。SBBR 的版本演进很能说明这套路子的节奏：

最后一行是熟人：PPTT 从"建议"升"必须"，正是 RISC-V 今天 CCS_040 从 SHOULD 变 MUST 的 Arm 版先例。2018 年 Arm 把规范升级成带证书的认证计划 ServerReady，用架构合规测试套件（ACS）考核 SBSA + SBBR；2020 年又扩成 SystemReady，分四个 band 覆盖从服务器到边缘的设备。规范文本、固件契约、测试套件、认证证书，四件套齐了，生态才真正规模化。

代价：压缩实现自由

这套路子的代价当年就被看穿了。SBSA 公告里 Open Compute Project 主席 Frank Frankovsky 的背书话说得很直白：标准化要消除的是"设备枚举与引导流程这类领域的无谓差异化"。字面意思就是：厂商不能再拿"我们家实现不一样"当卖点。AnandTech 当年报道下的评论已经预言，这份规范会限制 licensee 做多 socket、单片多处理器这类实现自由。Arm 用这份约束换来的，是五年后 64 位 Arm 服务器终于让 OS 发行方愿意认真支持。

把 2014 年和 2026 年并排放，结构清晰得惊人：

RISC-V 不是 NVIDIA 发明的新战场，而是 Arm 12 年前趟过的同一条路：平台标准换生态规模化，代价是实现自由的压缩。那么这条路走到 2026 年，真的有人在走吗？有没有一台机器真的把 CUDA 跑起来了？下一章看那台唯一的机器。

五、BigSky 跑通了 CUDA，但「跑通」不等于「达标」

唯一一台真正跑起来的机器

2026 年 8 月 24 日，Hot Chips 2026 大会首日，SiFive 发布 BigSky SF-2U870，自称 "world's first enterprise-grade, rackable 2U RISC-V server"（业界首台企业级 2U RISC-V 服务器；这个称号由 SiFive 自称，The Register 指出难以独立核实，中国厂商 Sophgo 等也有同类 2U 机器）。规格：32 颗 P870-D 核（2.0 GHz，TSMC N6 工艺）、256 GB DDR5-5600、4 个 PCIe Gen5 x16 槽（合计 64 lane）、出厂支持 Ubuntu 26.04 LTS 与 RHEL 10，并声明完全符合 RVA23。SiFive 新闻稿

图注：BigSky 的 2U 机架外观：正面 8 个 PCIe 槽位与六边形通风孔，品牌标识是 "SiFive | BigSky"。照片只能证明"门槛背后有一台物理机器"，看不到内部芯片，也看不到 CUDA 运行状态。SiFive BigSky 产品页

真正关键的一句在新闻稿里：SiFive 现在让 CUDA 跑在了 P870-D 驱动的 BigSky 上，作为 NVIDIA GPU 上现代 LLM 工作负载的 head node（头部节点，负责 CPU 侧调度、工具调用与 KV cache 管理）。注意这个角色定位：CUDA 软件栈在 RISC-V CPU 上运行，把任务交给 GPU、控制训练和推理，但 GPU 计算本身仍然在 NVIDIA 卡上。这不是"RISC-V 取代 GPU"，而是"RISC-V 第一次有资格当 GPU 服务器的 CPU"。同场还有一记回忆杀：Futurum 转引 Frans Sijstermans 的现场陈述，一年多前 NVIDIA 实验室里一台 RVA23 CPU 都没有，现在至少三台。Futurum

P870-D 的芯片框图说明了"门槛走完一半"的硬件依据：

图注：SiFive 官方博客的 P870-D 框图：P870-D cluster 自带向量 ALU、共享 L2、RAS 与 IMSIC，簇间走 CHI 一致性互连，CPU 簇内部的缓存一致性已在芯片内解决；NVIDIA 清单关心的 Host Bridge 与 Root Port 一段（CCS_040 / ACS_040）不在这张图上，也还没有公开验证结果。SiFive 官方博客

「跑通」与「达标」之间隔着什么

BigSky 的四件套，RVA23 合规、商业 Linux 启动、64 lane PCIe Gen5、CUDA head node 演示，是公开报道里唯一一台全中的 RISC-V 服务器。但"跑通"与"达标"之间，还有三处没有兑现：

• Server Platform v1.0 合规没有官方声明。SiFive 只宣布 RVA23 合规，独立媒体 XenoSpectrum 明确指出：SiFive 没有声明 BigSky 符合 Server Platform v1.0，而完整符合这份规范恰好在 NVIDIA 的清单里。
• CUDA demo 的细节没有披露。GPU 型号、驱动版本、跑的 LLM、性能与稳定性数字全部未知。"It ran"（它跑起来了）不能被延伸成"it's production-ready"（它可以上生产）。
• NVLink Fusion 不在这一台。SiFive 与 NVIDIA 在 2026 年 1 月 15 日宣布合作，把 NVIDIA 的 NVLink C2C 互连（约 88 条 PCIe lane 当量的高速连接）集成进未来的 SiFive 平台；Jensen Huang 当时的原话是"把我们的高带宽一致性 NVLink 互连带到 RISC-V 生态"。BigSky 这一台只有 PCIe。

这套"跑通 vs 达标"的落差，正是判断工具该出场的地方。独立分析师 Chase Na（vlsi.kr）在 2026 年 8 月 26 日提出一个框架，把提问方式从"能不能跑"改成"哪些合同已经闭合"：

图注：vlsi.kr 原创的资格栈（独立分析师框架，不是 NVIDIA 官方材料）：图上四层可见模块，应用与框架、CUDA 运行时与驱动、OS 与固件、服务器平台；副标题点明 ISA 移植只是第一层，底部结论是只有当每一层都对上，资格认证才算完成。VLSI Korea

这套框架把第一章的四份规范、第二章的三个故障、第三章的 MUST 链条全部收进一张图：ISA 移植只是第一层；ACPI 表有没有被自动校验、DMA 端点是否都在 IOMMU 策略之下、P2P 路径能不能被观测到、reset 与 AER 恢复是否达标，每一层都是一份合同。判断一块板卡值不值得买，看的是合规与支持矩阵，而不是"RISC-V"这个 ISA 标签。vlsi.kr 还给了两个可追踪的观察窗口：2026 年 9 月 30 日期待 NVIDIA 披露支持矩阵（只有 session title 不算数），2026 年 12 月 31 日期待独立的 P2P 拓扑数据。VLSI Korea

Chester Lam 的现场判断值得最后引用一次：现有 RISC-V 硬件绝大多数不满足 NVIDIA 的要求，他甚至怀疑未来一段时间内任何消费级 RISC-V 硬件都过不了线。

结语：谁有权定义并认证这套契约

把五章穿起来看：NVIDIA 用一张两页纸的准入清单，把 RVA23、Server SoC、Server Platform、BRS 里那些"建议"逐条拧成"必须"，让 RISC-V 收敛成可验证的服务器平台 ABI。这不是 RISC-V 独有的现象，Arm 2014 年用 SBSA 走过一模一样的路，代价是实现自由的压缩。BigSky 证明这条路能走通，也证明"跑通"与"达标"之间还隔着固件测试矩阵与生产支持范围。

这里藏着整套戏真正的主线：谁有权定义并认证这套服务器契约。RISC-V 开放的是指令集，但"开放"如果换不来一台能被通用工具链稳定驾驭的机器，它就只是纸面上的自由。短期别追板卡新闻，追测试矩阵；长期要盯的是契约的定义权和认证权落在谁手里。下次再看到"某 RISC-V 板卡支持 CUDA"的标题，别问它用什么 ISA，问一句：它的 ACPI 表通过自动校验了吗？P2P 拓扑有独立数据吗？准入测试矩阵对公众开放了吗？"支持"两个字，已经从"能译码"变成了一份需要逐层盖章的合同。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Hot Chips 2026: CUDA Targets RISC-V（Chips and Cheese，Chester Lam 现场观察）：https://chipsandcheese.com/p/hot-chips-2026-cuda-targets-risc
2. RISC-V Server SoC Specification v1.0（RISC-V International）：https://docs.riscv.org/reference/server-soc/v1.0/index.html
3. RVA23 Profile v1.0（RISC-V International）：https://docs.riscv.org/reference/rva23/v1.0/index.html
4. RISC-V Boot and Runtime Services Specification（BRS）v1.0：https://docs.riscv.org/reference/brs/v1.0/index.html
5. ACPI Specification 6.6（UEFI Forum）：https://uefi.org/specs/ACPI/6.6/
6. The Cost of CUDA on RISC-V Is Platform Qualification, Not the ISA Port（vlsi.kr, 2026-08-26）：https://www.vlsi.kr/en/cuda-riscv-server-platform-qualification-economics-en/
7. Hot Chips 2026: CUDA Targets RISC-V（Chips and Cheese 分析师视角 + NVIDIA 演讲 slide 图组）：https://chipsandcheese.com/p/hot-chips-2026-cuda-targets-risc
8. ARM Ecosystem Collaborates to Deliver Initial Server Platform Standard（SBSA, 2014-01-29；原文页面已改版，经 AnandTech 存档与第三方转载核验）：https://www.arm.com/company/news/2014/01/arm-ecosystem-collaborates-to-deliver-initial-server-platform-standard
9. SiFive BigSky SF-2U870 Datacenter Development Platform（发布新闻稿 + 产品页 + Futurum 复盘）：https://www.sifive.com/press/risc-v-in-the-datacenter-bigsky-development-server