国内外 CPU 基础软件：操作系统、性能工程与 RISC-V 的技术发展和演进

国内外 CPU 基础软件：操作系统、性能工程与 RISC-V 的技术发展和演进

生成说明：本文由 AI 基于公开的一手规范、上游文档、发行版政策与项目资料生成；其中的工程判断均给出证据边界与验收条件，不将路线图、单板适配或单次跑分表述为通用能力。

版本历史

术语与缩略语

可靠性标记

1. 核心判断（TL;DR）

• 【C】全球 CPU 基础软件的竞争单位已不是“内核是否支持某 ISA”，而是“规范—上游—发行工程—真实硬件 CI—生命周期”的交付闭环。Linux 明确拒绝冻结内核内部 ABI，Arm 以 SBSA/BBR 约束服务器平台，RHEL 以认证与支持政策兑现产品责任。[S01] [S04] [S07]
• 【C*】国内平台已具备发行集成、兼容性门户、SDK 和特定板卡优化能力；但“镜像可启动”不能替代 CPU×固件×内核×发行版 SP×驱动×工作负载的验证矩阵。openEuler、OpenAnolis、openKylin 的公开资料分别证明了集成或社区机制，而非所有硬件场景的统一认证。[S12] [S15] [S17]
• 【C】性能优化应从单次跑分改为可追溯的观测闭环：权限策略、PMU 事件、固件/VMM、采样开销和 SLO 必须共同记录。特别在 RISC-V，SBI PMU 与 Linux 驱动的存在不保证某 SoC 的事件精度或虚拟机可比性。[S19] [S26] [S28]
• 【C*】RISC-V 已拥有 RVA23、psABI、SBI、Linux 向量接口和 LLVM/GCC RVV 的关键上游基线；发行版支持、通用数值库、AI 框架原生 CI 与多硬件性能回归仍处于不均衡成熟阶段。国内应以标准 RVV 和上游接口作为主路径，把私有扩展封装为可回退优化。[S24] [S25] [S29] [S34] [S39]

2. 问题、范围与方法

本报告将“CPU 基础软件”拆分为五个层次：规范与 ABI、上游操作系统和工具链、发行版与云原生集成、真实硬件验证和工作负载交付。研究不以 CPU 型号、包数量或单项跑分排序，而以四个可证伪问题组织：第一，二进制与启动接口是否可跨版本复用；第二，性能是否能被权限受控地观测并复现；第三，发行版是否给出明确的升级、修复和认证边界；第四，RISC-V/RVV 是否已从“能编译”进入 AI 服务“可部署、可回退、可验收”。

资料优先级为规范、主线内核/编译器代码、正式发行版政策和认证文档；厂商发布与公开 issue 仅用于描述特定实现或未完成路径。所有结论均使用【C】、【C*】、【S】、【P】或【?】标记。本文把“支持”拆成上游接口、发行集成、BSP 与应用性能四层，避免由低层证据推导高层成熟度。比较中不把 RHEL/Ubuntu 的商业支持和社区发行版等同，也不把 RISC-V Profile、单板镜像或 FPGA 演示当作生产验收。

方法上先抽取规范和上游约束，再核对发行与国内集成资料，最后以两个可复现实验机制检验观点：PMU 可观测性闭环和 RVV 动态分派。每个建议都落到可验证工件，例如版本清单、time_enabled/time_running、trace drop、镜像 SBOM、真实硬件 CI 结果、模型输入集和 P99。图 1 展示本文采用的交付闭环，后续章节以它作为比较基准。 [S01] [S07] [S10] [S19] [S24]

图 1：CPU 基础软件从规范到工作负载的交付闭环。来源：Linux UAPI 原则、Arm SystemReady、Kubernetes 资源治理与 openEuler 兼容资料的综合整理。[S01] [S07] [S10] [S12]

3. 全球技术基线

3.1 操作系统、发行版与硬件契约

【C】Linux 的长期价值不在于承诺冻结内核内部模块 ABI，而在于维持用户态接口、工具链、设备模型和社区治理的可演进边界。外部驱动或专有内核模块若依赖内部符号，就必须把内核版本、配置和维护责任视为平台契约的一部分；这正是发行版认证和长生命周期的必要性，而不是“上游内核版本越新越好”的简单问题。[S01] [S02]

【C】RHEL、Ubuntu 和 Debian 将同一个 Linux 基线包装为不同的运维契约：RHEL 明确支持与认证流程，Ubuntu 给出 LTS/Pro 生命周期，Debian 以稳定版和社区 LTS 提供较长维护。它们不应横向等价比较，但共同说明用户采购或部署的是内核、驱动、漏洞勘误、镜像、升级路径与支持责任的组合。硬件认证也必须绑定发行版版本、架构、驱动和测试清单，不能由“兼容某个 Linux”替代。[S03] [S04] [S05] [S06]

【C】Arm 服务器的软件可移植性借助 SBSA/BBR/SystemReady 等平台规范前移：启动、硬件发现与基础服务先被约束，通用操作系统才更可能复用。x86 的成熟度则更多体现在长期 PMU 工具、虚拟化和供应链验证，而不是不需要平台差异。无论 Arm 还是 x86，合规都只是进入软件栈的前置条件，外设、NUMA、IOMMU、机密计算与性能事件仍须按整机验证。[S07] [S08] [S09]

3.2 云原生、虚拟化与安全隔离

【C】CPU 基础软件的目标环境已经从裸机扩展到容器和虚拟机。Kubernetes cgroup v2 要求节点内核、systemd 与容器运行时形成统一层级；RuntimeClass 允许按 handler 选择运行时并计入调度开销。它们让 CPU、内存与隔离能力可被编排，但同样放大了节点配置不一致、runtime handler 缺失和资源核算偏差的风险。[S10] [S11]

【C】机密计算进一步证明“CPU 特性可用”与“平台功能可交付”不同：Intel TDX 需要 CPU、固件、VMM、客体内核、I/O 和运维策略协同；Arm CCA 的 Realm 参考栈也跨越 KVM、RMI 与 RMM。对任何国内 CPU 平台，这类能力都应按固件、VMM、CRI、远程证明和升级回滚的组合矩阵验收，而不能仅依据 ISA 宣称支持安全隔离。[S08] [S09]

能力成熟度对比矩阵

主张—证据矩阵

本节的可证伪结论是：若一个平台不能提供可复现的“CPU/固件/内核/发行版/驱动/运行时”组合与升级结果，它就尚未具备发行工程意义上的平台成熟度。证据来自 Linux 对内部 API 的边界、Arm 对硬件接口的前置约束和发行版的认证/生命周期机制；反例是可启动但无驱动、无修复责任或无容器运行时验证的镜像。工程上应把版本契约和验证结果视为交付件，并用上述矩阵审查每次固件、内核和容器基线变更。[S01] [S04] [S07] [S10]

4. 国内发展、差距与机会

4.1 发行集成的现状

【C*】openEuler 的公开兼容门户、24.03 LTS 技术资料和按 SP 标记的下载/支持信息，说明其已把多架构、云原生、虚拟化与软硬件兼容作为发行工程的一部分。对 RISC-V，Pioneer 的安装资料还明确暴露 UEFI/Legacy、内核和硬件组合约束。这是比“系统可启动”更接近平台交付的做法，但仍只证明已列出的版本和硬件路径，不能外推为所有 SoC 的认证结论。[S12] [S13] [S14]

【C*】OpenAnolis 23 公开以 6.6 LTS、RHEL/CentOS 兼容和 SIG/Testfarm/T-One 等社区工程为线索；它说明国内发行版正在将内核基线、兼容目标和自动化测试结合。兼容目标不是二进制成功率的保证，尤其当应用依赖内核模块、特定 glibc 行为、内核配置或加密组件时，仍必须以实际工作负载验证。对企业来说，关键不是名称相似，而是谁对勘误、内核变更和回归结果负责。[S15] [S16]

【S】openKylin 的多架构、容器镜像和 SIG 资料，以及针对 SpacemiT K3 的 ONNX Runtime、vLLM、XNNPACK RVV 优化，表明国内社区已经将发行集成延伸到本地 CPU 和 AI Runtime。该案例的价值是验证技术路线，而非建立跨 CPU 的性能排名：公开公告没有替代模型、量化、输入形状、温度、固件、线程和 P99 的完整复现实验材料。因而应将其纳入平台专用优化档，而非通用产品能力档。[S17] [S18] [S40]

【C*】RuyiSDK 将操作系统、工具链和 IDE 等资源组织给 RISC-V 开发板；玄铁 Linux/OpenSBI 提交展示了厂商 BSP 仍是硬件使能的现实路径。BSP 的商业与工程价值毋庸置疑，但若补丁未上游、扩展未标准化或缺少多版本回归，它会把升级、CVE 和工具链成本留在本地。国内项目应把“厂商分支是否有替代路径”作为选型指标，而不是将其默认当作长期兼容层。[S21] [S22] [S23] [S38]

4.2 差距、机会与可验证判断

国内外的核心差异不是是否拥有 Linux、编译器或容器，而是闭环的可审计程度。国际发行工程普遍把生命周期、认证规则、平台规范和升级责任公开化；国内项目的优势在于更贴近本地芯片、板卡和行业负载，机会在于将这种贴近性转化为版本化验证，而不是累积难以迁移的私有补丁。可证伪判断是：若某 CPU 平台在两个固件版本、两个内核/发行版组合和两个真实工作负载上无法重复启动、容器、性能和升级结果，则其“生态成熟”只能标记为【?】。这不是苛刻定义，而是避免把演示路径与运营能力混淆的最小门槛。[S04] [S12] [S14] [S16]

具体机会集中在四处：第一，建立跨 CPU 的开放硬件 CI，把启动、网络、存储、容器、JIT、PMU 和 AI 推理作为同一测试资产；第二，对发行版公开 firmware/kernel/toolchain/container 的兼容矩阵，压缩问题定位时间；第三，将有价值的驱动、工具链和运行时改动按上游状态治理；第四，用国内模型、数据合规和行业工作负载建立可复现实验，而不是借用不可比较的单一峰值。上述工作既能减少 BSP 债务，也能为国产软硬件协同形成持续数据资产。[S12] [S16] [S17] [S38]

5. 关键机制深挖

5.1 PMU、perf、ftrace 与 eBPF：观测并不等于真相

接口与实现依据：Linux 以 perf_event_open/perf 暴露性能事件，以 tracefs/ftrace 提供动态跟踪，以 eBPF hook 和 verifier 支持受约束的数据采集；权限由 perf_event_paranoid 和 CAP_PERFMON 等策略控制。RISC-V 路径中，Linux SBI PMU 驱动将事件配置、启停、读数与溢出采样下发到 SBI PMU 服务，因此接口能打开只说明调用链存在，不能证明目标 SoC 的所有事件字典、过滤和 overflow 已正确实现。见图 2。[S19] [S20] [S26] [S28]

图 2：从工作负载 SLO 到 CPU/SoC PMU 再回到性能回归的观测闭环。来源：Linux perf/ftrace/eBPF 文档、SBI PMU 与 Linux RISC-V PMU 驱动的接口整理。[S19] [S20] [S26] [S28]

失效边界与验证条件：权限拒绝、计数器多路复用、time_running 远小于 time_enabled、SBI/固件事件未实现、VMM 虚拟 PMU 失真、trace buffer drop、频率漂移或绑核不一致都会使结论失效。验证应固定负载、CPU governor、NUMA 和线程亲和性；同时保存 time_enabled/time_running、可用事件、采样频率、trace drop、内核/固件/VMM 版本与未插桩基线。验收条件不是“perf 能运行”，而是在重复实验中方向一致、计数器利用率合格、应用 SLO 与至少一种独立 trace/profile 指标相互印证。[S19] [S20] [S21] [S22] [S23]

成本与权衡：更高采样频率、更多事件和动态探针提高归因分辨率，却增加中断、缓存扰动、存储与敏感信息暴露；限制非特权访问可降低攻击面，却会降低现场诊断效率。建议将轻量常驻指标、按需 perf 采样和短时 ftrace/eBPF 诊断分层，并把原始记录作为性能回归的附件。该机制的工程成本是维护事件字典、权限策略和实验自动化；收益是将“跑分快慢”转为可定位、可比较、可回归的性能证据。

5.2 RVA23、psABI、SBI 与 Linux RVV：可移植性由多层契约共同决定

接口与实现依据：RVA23 给出应用处理器 Profile 的 ISA 基线，psABI 定义 ELF、调用约定和对象兼容，SBI 定义固件向监督态提供的服务，Linux 为 RISC-V 向量状态和 riscv_hwprobe 提供内核接口，LLVM/GCC 则将 RVV 语言接口和 -march 选项转换为可伸缩向量代码。任何一层缺失都会改变应用的实际可移植性：Profile 不保证固件 PMU；ABI 兼容不保证向量路径；编译器能发射 RVV 也不保证发行版库或应用已按相同假设构建。[S24] [S25] [S26] [S27] [S29] [S30]

失效边界与验证条件：应用若假定所有 RISC-V CPU 均拥有相同 VLEN、PMU 或私有扩展，会在异构 hart、模拟器、旧固件或不同板卡上产生错误或退化。Linux 的向量状态规则、系统调用对向量寄存器状态的影响，以及 hwprobe 的硬件特性查询都要求 Runtime 把特性检测纳入启动路径；xtheadvector 等私有扩展不能替代标准 RVV。验证条件应包括：使用标量 golden 输出校验数值，分别在目标硬件和模拟环境确认 Profile/扩展，覆盖不同输入形状、VLEN/线程配置和异常回退，并记录编译器版本、-march、ELF 属性及固件版本。[S25] [S27] [S29] [S30] [S39]

成本与权衡：fat binary、运行时分派、标量回退和多 shape kernel 可提升兼容与性能上限，但增加包体、测试矩阵、编译时间和调试复杂度；只维护私有扩展可在短期取得单芯片收益，却会提高上游脱节和迁移成本。推荐以标准 RVV/ZVL 路径作为基础实现，将厂商扩展置于显式 feature detection 之后，并用持续的正确性、吞吐、P99、功耗和升级回归决定其是否保留。该取舍直接关系国内 RISC-V 从 BSP 演示走向可维护软件生态的速度。

5.3 AI CPU Runtime：动态分派必须穿透到服务指标

接口与实现依据：AI Runtime 的算子层需要按 CPU 特性选择 scalar、RVV、NEON 或 AVX 等 kernel；运行时层读取硬件能力、核心数、缓存和拓扑；服务层控制并发、batch、内存池、绑核和 NUMA。OpenBLAS 的通用 RVV 1.0 路径仍处于公开议题阶段，PyTorch RISC-V 支持与原生 CI 仍需分辨已实现和计划；IREE 与厂商案例展示了在指定模型或目标上可运行/优化的路径。接口存在、开源 issue 或演示数字不能自动构成端到端生产承诺。[S34] [S35] [S36] [S29] [S30]

失效边界与验证条件：若输入 shape、量化格式、上下文长度、线程数、内存容量或并发与开发假设不同，最优 kernel 可能退化；仅测单 token 或预热吞吐会掩盖 TTFT、TPOT、P99、内存碎片和热约束。验证条件需用固定模型版本、量化、tokenizer、提示词和 golden 输出，分别测试冷启动、预热、单请求、并发以及不同上下文/batch，并记录 CPU/SoC、固件、内核、编译器、Runtime、绑核和频率。验收至少要求正确性、吞吐、TTFT、TPOT、P99、峰值内存和功耗同时达标，而不是宣称“向量指令已生成”。[S17] [S34] [S36] [S40]

成本与权衡：为每个 ISA、量化和 shape 建立专用 kernel 会增加维护、缓存和发布成本；通用实现降低测试压力却可能浪费向量和内存层级能力。国内平台应先把标量/标准 RVV 的基线、回退、观测和测量工件做好，再在可复现的本地行业负载上引入专用优化。这样既可保留硬件协同优势，也避免把单板案例转化为难以维护的框架分叉。

6. 演进方向与情景

【C】操作系统层的主趋势是将 CPU 使能前移到平台规范和升级契约。Arm 的 SystemReady 路径、Linux UAPI 边界、RHEL 认证与长期勘误表明，未来两到三年内，能否稳定交付更取决于固件、驱动、发行版 SP、容器基线和安全修复的组合治理，而非某次内核移植完成与否。国内若要缩小差距，应把兼容矩阵、版本锁定、CVE 响应、驱动上游状态和真实硬件回归公开成基础产品资产。[S01] [S03] [S04] [S07] [S12]

【C】性能工程会从专家手工 profile 演进到 SLO 驱动的持续测量。PMU 的事件语义、权限和虚拟化差异不会消失，异构 CPU 反而会扩大其影响；因此“事件字典+实验谱系+回归阈值”将成为平台能力。Intel、AMD、Arm 的工具链可提供不同微架构的方法参考，却不应被机械迁移。国内应先统一记录格式和校验逻辑，再逐步补足 SoC 事件映射、虚拟 PMU、低扰动采样与自动归因。[S19] [S20] [S21] [S22] [S23]

【P】RISC-V 的 Profile、psABI、SBI、Linux 与编译器共同成熟会继续减少基础碎片化，但应用层将成为最慢的一环。Debian、Fedora、Ubuntu 的 RISC-V 资料呈现出“官方纳入、社区镜像、开发预览”并存状态，表明发行路径仍有分层；数值库、PyTorch、IREE 和生态组织的进展同样应按“规范—代码—CI—性能—维护”逐层检验。国内的合理情景是先建立标准 RVV 主线和多硬件验证，再将本地芯片优化收敛为可选择插件，而不是反向定义生态标准。[S31] [S32] [S33] [S34] [S35] [S36] [S37]

图 3 概括了 RISC-V 软件从 ISA 到工作负载的成熟度闸门。它不是性能排名，而是选择平台时必须逐项回答的依赖关系；任何一层缺少版本、实现或测试证据，整体交付成熟度就应降级处理。

图 3：RISC-V 从 Profile/ABI/固件到内核、工具链、发行版和工作负载的成熟度闸门。来源：RVA23、psABI、SBI、Linux RVV/PMU 与 LLVM/GCC 文档的依赖关系整理。[S24] [S25] [S26] [S27] [S28] [S29] [S30]

7. 建议与验收

建议不应停留在“加强生态”“持续优化”等不可验收表述，而应将国内 CPU 基础软件的优先级压缩为可交付的四项：平台契约、真实硬件 CI、可观测性基线和 AI Runtime 回退。第一项处理兼容和升级，第二项处理真实设备差异，第三项处理性能归因，第四项处理新 ISA 与模型软件的长期维护。每项均应指定负责人、版本窗口、失败阈值和原始工件位置。只有当这些工件随固件、内核和镜像变更自动更新，国内平台的快速适配才会积累为可复用能力。[S04] [S10] [S12] [S19] [S27]

建议—验收矩阵

建议的验收核心是“可重复失败”：性能、兼容和安全问题必须在已知版本、已知负载和已知硬件上被稳定复现，才有资格进入根因分析和修复回归。为避免文档变为清单，应将该矩阵直接连接到 CI 门禁：固件/内核/编译器/容器任一升级先触发基础兼容，再触发性能与 AI 服务回归；没有原始工件的成功不计入发布证据。对于国内外组件混合部署，版本契约和证据可追溯性比单一组件的国产或开源标签更重要。[S01] [S04] [S12] [S19] [S25]

8. 不确定性与研究限制

第一，公开政策和项目页面会更新，Linux LTS 预计结束日期、发行版订阅覆盖、RISC-V 镜像状态和板卡支持范围必须在采购或发布时重新锁定，不应把本文研究截点外推到未来。第二，厂商性能资料与社区公告通常缺少完整控制变量；本文将其标为【S】或【P】，不用于性能排名。第三，RISC-V 的 PMU 事件、SBI 实现、VMM 虚拟化和 RVV VLEN 具有较强硬件相关性，主线代码存在并不证明任一 SoC 或云实例可用。第四，本文未在实际目标硬件上运行数据库、容器或 AI 负载，因此提出的是验收设计而非实测结论。[S02] [S14] [S28] [S34] [S40]

还有两个需要后续补证的风险。其一，国内发行版对特定 CPU、固件、外设和容器 runtime 的认证矩阵可能不完整或不易获取，应在合作方环境中以【?】状态关闭。其二，AI Runtime 对 RISC-V 的支持变化很快，issue、演示和生态计划可能在正式 release 前发生调整；因此任何“已支持”声明都应落到固定 release、提交、CI 日志和可重放模型上。本文对商业 SLA、芯片微架构性能和封闭软件栈不作判断。

参考来源

附录：研究方法

本报告采用“主张—证据—边界—验收”四步法。先按操作系统、性能工程、RISC-V/AI Runtime 列出待证伪主张；再优先检索规范、主线实现、发行版政策和认证资料；对 SDK、公告、issue 和生态组织只给出与其证据等级匹配的表述；最后为每一项工程建议指定可执行的验收物。来源台账中的 Snn 是唯一引用标识，正文每个关键结论均可回溯到台账。

复现时应固定研究截点，并记录访问日期、硬件型号、微码/固件、内核、发行版、容器镜像、编译器、运行时、系统配置、负载和原始日志。性能测试至少保留基线、预热和并发实验；RISC-V 测试同时记录 Profile、hwprobe、-march、ELF 属性和向量/标量回退；发行版测试记录升级前后版本、驱动、容器 runtime 和回滚结果。遇到证据冲突时，优先降低结论标记而不是补写推断；遇到无法在真实硬件复现的厂商结果时，保留为【S】或【?】并明确其限制。