关键特性 ​

AI 场景创新 ​

智能时代，操作系统需要面向AI不断演进。一方面，在操作系统开发、部署、运维全流程以AI加持，让操作系统更智能；另一方面，openEuler已支持ARM，x86，RISC-V等全部主流通用计算架构，在智能时代，openEuler也率先支持NVIDIA、昇腾等主流AI处理器，成为使能多样性算力的首选。

OS for AI ​

开箱易用 ​

openEuler兼容NVIDIA、Ascend等主流算力平台的软件栈，为用户提供高效的开发运行环境。通过将不同AI算力平台的软件栈进行容器化封装，即可简化用户部署过程，提供开箱即用的体验。同时，openEuler也提供丰富的AI框架，方便大家快速在openEuler上使用AI能力。

1. openEuler已兼容CANN、CUDA等硬件SDK，以及TensorFlow、PyTorch、 MindSpore等相应的AI框架软件，支持AI应用在openEuler上高效开发与运行。
2. openEuler AI软件栈容器化封装优化环境部署过程，并面向不同场景提供以下三类容器镜像。
   • SDK镜像：以openEuler为基础镜像，安装相应硬件平台的SDK，如Ascend平台的CANN或NVIDIA的CUDA软件。
   • AI框架镜像：以SDK镜像为基础，安装AI框架软件，如PyTorch或TensorFlow。此外，通过此部分镜像也可快速搭建AI分布式场景，如Ray等AI分布式框架。
   • 模型应用镜像：在AI框架镜像的基础上，包含完整的工具链和模型应用。

相关使用方式请参考《openEuler AI 容器镜像用户指南》。

XPU Turbo大语言模型异构协同加速运行时 ​

XPU Turbo大语言模型异构协同加速运行时专注于单机多卡环境下大模型推理任务的性能提升，针对鲲鹏+xPU（GPU、NPU等）的异构算力协同，显著提升大模型的吞吐量和并发量：

• CPU推理加速：通过NUMA亲和调度、矩阵运算并行加速、SVE指令集推理算子适配等方式，提升CPU的吞吐量。
• 异构融合调度：XPU Turbo支持PD分离与AF分离两种调度模式。在PD分离模式下XPU Turbo支持在GPU侧任务满载时，动态将推理请求的prefill阶段在GPU上执行，decode阶段放在CPU上执行。在AF分离模式下XPU Turbo会将FFN过程放在CPU上执行。

异构融合GMem ​

在后摩尔时代，GPU、TPU 和 FPGA 等专用异构加速器设备正不断涌现，它们与 CPU 类似，需要将数据放在本地内存（例如 LPDDR 或 HBM）中以提高计算速度。加速器厂商们也不可避免地需要开发复杂的内存管理系统。现行加速器内存管理方案存在诸多缺陷：

• CPU 侧内存管理与加速器侧分离，数据显式搬移，加速器内存管理的易用性和性能难以平衡。
• 大模型场景下加速器设备 HBM 内存（High BandWidth Memory）严重不足，现有的手动 swap 方案性能损耗大且通用性差。
• 搜推、大数据场景存在大量无效数据搬移，缺少高效内存池化方案。

Linux 现有的 HMM 框架，编程复杂度高且依赖人工调优，性能和可移植性差，引发 OS 社区反弹，最终导致 HMM 方案搁浅。异构加速器领域亟需高效的统一内存管理机制。异构通用内存管理框架 GMem（Generalized Memory Management），提供了异构内存互联的中心化管理机制，且 GMem API 与 Linux 原生内存管理 API 保持统一，易用性强，性能与可移植性好。加速器使用 GMem API 将内存接入统一地址空间后，可自动获得 GMem 面向异构内存编程优化的能力。与此同时，加速器驱动无需重复实现内存管理框架，大幅降低开发维护带来的成本。开发者使用一套统一申请、释放的 API，即可完成异构内存编程，无需处理内存搬移等细节。在加速器 HBM 内存不足时，GMem 可将 CPU 内存作为加速器缓存，透明地超分HBM，无需应用手动 swap。GMem 提供高效免搬移的内存池化方案，当内存池以共享方式接入后，可解决数据反复搬移的痛点。

ModelFS模型启动加速 ​

ModelFS 针对大语言模型（LLM）推理启动阶段的模型加载瓶颈进行优化。现有相关工作主要通过优化推理框架来提升模型加载性能，这种方法往往以牺牲兼容性为代价。然而，基于我们的工业实践经验，兼容性是决定一项技术能否在实际场景中广泛应用的关键因素。本工作在保证强兼容性的前提下，通过优化文件系统的缓存策略，实现了模型加载性能的领先水平。ModelFS 在内核中设计了一个非侵入式、灵活且轻量级的可编程页缓存框架，允许用户自定义文件系统的页缓存策略。基于可编程页缓存，我们进一步设计了面向模型加载优化的缓存策略的参考实现。

• ModelFS-K：ModelFS 的内核模块，提供文件系统（FS）页缓存可编辑框架。核心设计是一个堆叠FS，可以挂载到现有 FS 之上，ModelFS-K 将底层文件系统的相关逻辑用 UPS（用户态调用）重定向到用户态实现的 prefetch 和 evict 函数。
• ModelFS-U：ModelFS 的用户态模块，提供缓存策略的运行时。提供一套 VFS-like 的用户态编程框架，模型实现者 /IO 优化者可以根据模型的加载 IO 特性自定义缓存策略。用户需实现 init()，exit()，prefetch()，evict()，ModelFS-U 会将它们注册到 ModelFS-K 中，并在运行过程中负责解析 IO 事件和进行异步数据预取/淘汰。

NPU算力切分 ​

在计算领域，计算能力是推动 AI 技术发展的驱动力之一，为了提升 AI 运算速度，各大厂商纷纷推出了自己的 AI 计算设备。但多数 AI 卡缺乏优先级、公平性、抢占、算力带宽控制等高级调度能力，无法满足中小 AI 模型多任务混部场景的诉求，比如在线-在线推理混部，在线-离线推理混部等。中小 AI 模型独占部署，导致 AI 卡资源利用率低，造成严重的资源浪费。

xSched 是面向中小模型的通用的调度框架，能够为NPU卡提供基础的调度机制，包括任务抢占、时间片切分、组调度、算力带宽管控、显存容量管控等，并构建公平调度策略、实时调度策略等多种调度策略，满足不同 AI 场景调度算法的诉求。

故障快恢 ​

在当今的AI推理生产环境中，推理服务通常以容器化形式部署并长时间运行，然而，运行过程中的故障是不可避免的，传统的故障恢复路径往往需要数分钟甚至更长时间，会导致业务中断过久，造成了资源的浪费。

为AI推理容器提供秒级故障快速恢复能力，将恢复时间从分钟级降低到秒级，基于支持进程状态dump/restore能力的组件（如CRIU），支持npu驱动的状态的导入导出，并实现与k8s生态的对接，实现推理容器的秒级恢复。

AI for OS ​

当前，openEuler和AI深度结合，一方面，基于openEuler操作系统，研发出了Witty，初步实现基于知识库的智能问答、基于语义接口的工作流编排等功能，在此基础上，Witty集成了部分系统服务，让openEuler更智能。

智能问答 ​

Witty目前支持Web和智能Shell两个入口。

1. 智能规划、调度和推荐：智能规划：Witty 的 Agent 应用可以基于用户的输入和当前可用的工具实时规划运行步骤，直至完成用户目标或者达到步骤执行上限。智能调度：Witty支持用户在一个应用中定义多个工作流，基于用户的查询，Witty会自动的提取参数且选择最为合适的工作流进行工作。智能推荐：Witty基于用户的查询和工作流的运行结果，推荐用户接下来可能会使用的工作流，增加任务的完成概率，简便应用的使用。Web入口：用户可以通过Web入口以可视化的形式进行知识库的构建和使用、知识库准确率的自动化测试与评估结果获取、openapi形式的语义接口注册、基于语义接口的工作流应用的构建和使用、mcp的注册安装和激活和基于mcp的Agent应用的构建和使用，Web入口便携了新手用户对openEuler知识的获取和对openEuler AI能力的使用。
2. 工作流：语义接口：语义接口是指含有自然语言注释的接口形式，Witty提供了两种语义接口注册方式。工作流编排及调用：Witty允许用户将系统提供的语义接口以及用户注册的语义接口以可视化的形式连线成工作流，并支持用户对工作流进行调试且以应用的形式进行发布和使用，工作流在调试和使用过程中会展示中间结果，降低用户调试成本，提升用户交互体验。
3. Agent 应用：mcp 注册、安装和激活：mcp 是当前比较主流的一种 AI 相关协议，它支持用 sdk 将复杂多样服务统一封装，带有天然的语义信息，并支持 AI 对基于 mcp 改造后服务下的工具进行比较便捷的调用。Agent 构建和应用：当前 Witty 支持以 mcp 和不同的大模型结合构建 Agent，这些构建完成的 Agent 可以基于配置的大模型信息以及后续用户输入的目标，将用户的目标拆解成阶段性需求，最后使用 mcp 服务下的工具将阶段性需求完成，直至达成用户的目标。
4. RAG：RAG(检索增强技术)是为了增强大模型长期记忆能力和降低大模型训练成本诞生的技术，相较传统RAG，Witty中的RAG技术在检索前处理、知识索引、检索增强算法和检索后处理方面做了改进。
5. 团队管理：团队管理是 Witty 中的 RAG 技术的基础能力之一，其通过 RBAC 的机制来管控团队内成员对角色、成员和资产的访问，以增强知识库整体的易用性。
6. 语料治理：语料治理是 Witty 中的 RAG 技术的基础能力之一，其通过上下文位置信息提取、文本摘要和OCR增强等方式将语料以合适形态入库，以增强用户查询命中期望文档的概率。
7. 自动化测试：自动化测试是 Witty 中的 RAG 技术的基础能力之一，其通过自动化数据集生成和测试评估识别知识库和检索增强算法等配置的不足。

智能调优 ​

Witty 智能调优功能目前支持智能 shell 入口。 在上述功能入口，用户可通过与 Witty 进行自然语言交互，完成性能数据采集、系统性能分析、系统性能优化等作业，实现启发式调优，已支持通过 MCP 协议实现调优意图识别。

智能诊断 ​

系统宕机智能诊断 ​

1. 智能诊断Agent：采用假设生成-并行验证的故障排查范式，基于dmesg 日志、内核源码、故障描述多维度原始输入，调用已知问题分析Agent 检索存量历史案例，同步生成已知故障、未知故障两类假设并行分析：针对已知故障假设，比对当前现场数据与历史案例的分析流程、结论特征完成匹配核验；针对未知故障假设，自动调用crash工具结合源码解析推导底层根因，最终融合两条链路分析结论，自动输出HTML、Markdown、JSON 三类诊断报告，报告完整涵盖根因结论、故障时间线、故障传播链、因果逻辑链、完整排查步骤及修复方案。
2. 已知问题Agent：内置日志智能解析引擎，自动抽取日志中的核心异常特征，包含报错码、异常告警、内核堆栈、寄存器信息等关键线索；融合轻量化RAG检索与多策略混合搜索算法，跨语义案例库、故障指纹库、知识库Wiki、GitHub 开源社区做精准匹配，快速召回同类型历史故障参考案例，为全流程故障排查提供前置高效依据。
3. 案例沉淀：闭环承接已核验、用户确认生效的完整诊断报告、原始故障场景描述、现场原始数据特征，自动化标准化转换为结构化历史案例入库至语义案例库；持续扩充高质量故障样本，构建数据自迭代飞轮，持续优化检索匹配精度、假设生成准确率，达成工具越使用、故障定位越快速精准的正向迭代效果。

容器干扰检测 ​

1. 干扰检测巡检：调用容器干扰检测工具，对节点中存在监控的节点在指定的时间段内的干扰进行检测，报告节点中存在的干扰情况吗，报告存在干扰的容器和对应指标。
2. 干扰源分析：调用容器干扰源分析工具，对节点中存在的所有受干扰容器进行分析，报告各个受干扰容器的 Top3 干扰源容器和对应的关联指标（如CPU run delay）。
3. 干扰恢复建议生成：根据干扰源分析定位结果，调用干扰恢复建议工具，对存在的干扰进行分析并给出干扰恢复建议报告，提供各条建议的依据和示例指令。

AI集群慢节点定界 ​

AI 集群慢节点定位需要实时性和智能性，当前Agent基于sysTrace提供的时序分析算法对AI集群训练任务下的慢节点/慢卡进行检测，对比传统的分析方法具有更高的准确率和泛用性，并且用户可以通过自然语言的形式让Agent自主的对特定集群或集群的特定子集进行诊断和分析，直至定位慢节点。sysTrace的核心能力是时序分析技术，该技术主要功能如下：

1. 配置文件：主要包括待观测指标类型、指标算法配置参数以及数据接口，用于初始化慢节点检测算法。
2. 算法库：包括常用的时序异常检测算法 dbscan 算法，k-sigma 算法，异常节点聚类算法和相似度度量算法。
3. 数据：采集到的各个节点的指标数据，包括python堆栈信息、io相关信息、hccl算子活动跟踪数据。
4. 指标分组对比：包括组内空间异常节点筛选和单节点时间异常筛选。组内空间异常节点筛选根据异常聚类算法输出异常节点；单节点时间异常筛选根据单节点历史数据进行时序异常检测判断节点是否异常。

超节点通断&时延问题定界 ​

UB超节点故障发生后，根据日志、指标等观测数据，推断故障发生的组件，对于明确故障处理参与方、加速故障恢复具有重要的意义。本功能面向超节点KVCache和URMA通信时延和通断故障定界场景，提供了以下能力：

1. 跨组件系统拓扑一键采集：基于UBM调测接口、组件日志等提供的信息，一键采集通信资源拓扑，汇聚全局拓扑信息，用于故障影响面分析，支撑故障定界。
2. 故障事件日志自动解析：以事件为核心的通信故障日志解析，自动提取故障元信息、整合上下游组件日志，大幅降低待分析日志量，聚焦关键故障信息。
3. 故障定界报告分钟级生成：基于拓扑采集和日志解析结果识别通信时延和通断类故障，集成超节点故障案例库和组件知识，分钟级自动生成定界报告，支撑故障快速定界。

智能容器镜像拉取 ​

Witty目前支持通过自然语言调用环境资源，在本地协助用户基于实际物理资源拉取容器镜像，并且建立适合算力设备调试的开发环境。

当前版本支持三类容器，并且镜像源已同步在dockerhub发布，用户可手动拉取运行：

1. SDK层：仅封装使能AI硬件资源的组件库，例如：cuda、cann等。
2. SDK + 训练/推理框架：在SDK层的基础上加装tensorflow、pytorch等框架，例如：tensorflow2.15.0-cuda12.2.0、pytorch2.1.0.a1-cann7.0.RC1等。
3. SDK + 训练/推理框架 + 大模型：在第2类容器上选配几个模型进行封装，例如llama2-7b、chatglm2-13b等语言模型。

超节点场景创新 ​

算力需求指数级增长与高速互联技术突破，驱动硬件从单节点向超节点加速演进，未来数据类、资源类、业务类的核心诉求从单机性能渐变到超节点，具有以下特点：

1. 资源池化：计算、内存、互联和存储等均可池化，支持任意多对多协同。
2. 规模扩展：按需灵活扩展，利用率高，大范围、整系统相同编址机制，控制静态、传输、动态时延。
3. 长稳可靠：10倍提升长稳运行时间，自动避障，自动恢复，易部署，机房环境适应性强，易扩展，从模组到柜级均可扩展。

面对超节点调度、池化、通信、虚拟化等诉求，openEuler异构融合系统升级，支持超节点形态，加速释放超节点异构算力。

超节点 OS 架构 ​

在超节点应用落地过程中，业界面临三大核心挑战：如何简化开发流程，实现业务“零修改”平滑迁移，如何精准匹配多样化算力供给，实现按需高效释放，如何应对系统复杂性提升，保障应用高可用性。openEuler异构融合系统针对上述挑战方案如下：

1. 新增系统高阶服务能力，将业务迁移从“复杂适配”简化为“零修改适配”，大幅降低开发与迁移成本。
2. 强化异构融合核心子系统，提供异构融合通信与虚拟化能力，精准匹配算力需求，实现利用率最大化。
3. 完善池化设备管理体系，通过灵活扩展支持超节点形态，以池化高可靠管理防范故障扩散，筑牢业务稳定运行根基。

灵衢系统架构 ​

超节点是灵衢计算系统的核心，通过灵衢重构计算系统，打破计算主机边界，实现智算和通算超节点扩展并获得性能规格收益，是面向未来 AI 时代的目标计算系统架构。 灵衢超节点打破传统主机边界，在超低时延，多协议归一的灵衢总线级互联的超节点域内，通过计算资源全量池化、平等互联，实现计算资源的灵活组合，超大规模组网和系统高可用性。灵衢计算系统参考架构分为四层，共同发挥灵衢计算系统超节点架构优势：

1. 灵衢硬件系统，实现超节点可定义计算

   • UnifiedBus（UB/UB Firmware/BMC）：灵衢超节点计算系统基础，基于灵衢实现计算集群总线级互联、协议归一、平等系统、全量池化、大规模组网、高可用性。
   • 灵衢互联结构管理器（UBFM）：完成灵衢的互联配置，实现计算资源的灵活、高效聚合，优化计算互联SLA（时延、带宽、可靠性），实现灵衢超节点灵活算力使能。

2. 操作系统灵衢组件（UB OS Component）完成灵衢和设备的使能，进行统一抽象与管理

   • UB OS Component 通过扩展 Linux 内核，原生支持超节点计算系统，实现对灵衢设备的统一抽象和管理。
   • 同时保持POSIX接口兼容，实现现有应用的快速迁移。通过openEuler社区，使能操作系统生态，实现灵衢计算系统的开放创新。

3. 灵衢系统高阶服务（UB Service Core），使能超节点性能最优

   • 充分发挥灵衢计算系统在内存池化、通信、分布式操作等方面的独特优势，同时简化灵衢资源管理与调度的复杂性，提供了系列的灵衢系统高阶服务 UB Service Core，使能计算业务应用，快速发挥灵衢超节点系统优势，获得性能收益。

操作系统灵衢组件 ​

操作系统灵衢组件（UB OS Component）是在 OS 原有内存管理、通信、设备管理和虚拟化框架上扩展支持灵衢，扩展的4个功能分别是：

1. Device Mgmt：提供 UB 总线、UB 设备管理能力，实现计算节点内 UB 设备热插拔、配置。包含模块：UB Device Mgmt、sysfs、udev 和 UB User Driver。
2. Memory Mgmt：提供 UB 总线域内内存语义访问能力，实现跨计算节点跨设备内存借用、共享。包含模块：DMA/SVA Memory Mgmt、Pooled Memory Mgmt、UBMM Lib 和 Memory Allocator。
3. Communication：提供跨计算节点、跨设备通信和远程调用功能。包含模块：Connection Mgmt & Communication、UBComm Lib 和 socket。
4. Virtualization：提供 UB 设备直通虚拟机能力。包含模块：qemu、libvirt 和 vfio-ub。

灵衢设备管理 ​

UB 设备管理包括 UBus Driver、vfio-ub 和 ubutils 三个模块，对用户提供 UB 设备管理接口，包括给 UB 设备驱动提供了基本的设备发现、设备注册、中断使能等总线服务，UB 设备直通用户态的服务，以及给用户提供查询 UB 设备信息和配置服务。各类 UB 设备可以注册到 UB 总线上，对用户提供相应的功能。

在 OS 内，UB 设备的发现、注册、驱动加载均由设备管理实现，分单机和集群场景：

1. 单机场景：单台服务器主机独立工作，每台服务器独享连接在主机上的所有 UB 设备，单机上的 UBus Driver 完成所有 UB 设备的枚举发现和使能，配合 vfio-ub 提供 UB 设备直通用户态能力。
2. 集群场景：超节点形态下 UBus Driver 提供分配给计算节点的 UB Entity 发现和使能，并支持池化设备接入和移除，配合 vfio-ub 提供 UB 设备直通用户态能力。

灵衢内存管理 ​

现有总线采用 Host-Device 模型，以 Host（CPU）为中心，Host 管理每一个 Device。在这个模型之下，Host 访问 Device 内存、Device 访问 Host 内存、Device 访问 Device 内存共三类访存路径有单独实现。UB 统一上述访存模型，根据一个访存发起流程将相关的节点分为 User 和 Home，User 可以通过同步（Load/Store）或者异步（DMA）的方式访问 Home 侧内存资源。 基于 UB 总线的能力，OBMM 模块提供了节点间数据通路配置与跨节点数据一致性维护能力。完成配置后，用户可以在 UB 互联的集群中，在一个节点上访问另一个节点上的内存，实现跨节点内存共享、内存池化与节点间借用等功能。

灵衢通信 ​

灵衢通信库是分布式通信软件库，为数据中心网络、超节点内、服务器内的卡与卡之间提供高性能的通信接口，使能和释放 UB 硬件能力。

• UMS：UMS 支持对接Socket 抽象层，是北向兼容 Socket 编程接口，南向基于灵衢高性能网络进行数据传输的内核网络协议栈，透明加速 TCP 应用，实现性能提升。
• URMA：URMA 是灵衢通信的基础软件库，屏蔽硬件差异，基于灵衢高性能网络提供读写、收发、原子操作等远端内存访问语义，是灵衢通信应用的基础。
• URPC：URPC 是灵衢原生的统一远程过程调用，支持灵衢原生高性能主机间和设备间 RPC 通信，以及 RPC 加速。

IP over URMA ​

IPoURMA提供了一种基于UB协议和硬件传输IP数据包的标准化方法。IPoURMA作为内核模块，基于UB entity创建netdev设备并注册基本的netdev回调函数，以提供内核网络协议栈控制UB硬件的抽象层[ IP over URMA约束当前仅支持IPv6。]。此外IPoURMA还提供了ethtool等维测工具的实现，能够统计基于UB硬件的网络包维测信息。

URMA容器场景通信 ​

该 URMA 容器方案在容器化环境中构建了一种设备级共享、EID 隔离的远程直接内存访问能力。通过硬件虚拟化与内核中介技术，方案允许同一物理 URMA设备同时暴露给指定的多个容器网络命名空间，实现硬件资源的集约复用；同时，URMA设备的每个EID在被绑定至单一命名空间，确保租户或应用间的 URMA 资源无法相互越界访问。

URMA高性能分发通信加速 ​

应用使用URMA通信时，如果在业务的逻辑连接采用Jetty/JFS与JFR一比一配比创建，其JFR接收缓存消耗将随逻辑连接数线性增长。以通信内存按8KB分片管理，并且JFR深度为1024为例，每个业务的逻辑连接需预占用8MB接收缓存，当逻辑连接规模达到1K~10K时，仅接收缓存预留就需要8GB~80GB。为减少内存预占用，UMQ提供基于URMA共享JFR的通信模式，支持应用的多个逻辑连接共享一个JFR接收数据，并使用业务关联的标签高效地分发接收数据到正确的逻辑连接上。 UMQ提供基于URMA共享JFR的通信模式，支持从共享JFR接收的RQE到业务逻辑连接句柄的映射关系配置，便于应用高效分发RQE，也提供了根据共享JFR实时接收缓存深度的流量控制机制，避免出现流量超发。该特性主要功能如下：

1. 使能共享JFR：创建一组UMQ时均指定同一个UMQ作为JFR共享源，则这一组UMQ底层使用同一个JFR，应用监控被共享的UMQ可获取这一组UMQ的收包事件。
2. 支持高性能分发：UMQ创建时可设置应用逻辑连接关联的标签等信息，UMQ上报的接收数据也携带了这个信息，支持应用在获取数据后高效分发到对应的逻辑连接。
3. 自适应流控：接收侧维护共享JFR中接收缓存队列深度关联的信令池，发送侧发送数据时需拥有足够的信令。当信令不足时，发送侧根据历史信令消耗情况自适应调整本次信令申请数量，如果信令发生超时空闲，则需归还信令。

RH2D多级缓存直通加速 ​

RH2D面向异构融合OS、分布式缓存场景，提供将远端Host上的KvCache通过异步流水传输到本端Device的能力。其核心目标是在KVCache等大对象读取过程中，减少传统“远端读取到本地内存、再由客户端拷贝到GPU”的串行等待开销。该能力基于URMA高速传输通道，将远端对象按固定大小的分片切分，通过异步流水实现远端数据搬运与本端GPU写入的并行推进。对于大块数据，RH2D可以边接收、边投递、边拷贝，缩短端到端获取KvCache的时延，提升KvCache从远端写入GPU的效率。

灵衢设备虚拟化 ​

在云计算场景中，通过虚拟化将物理机上的硬件资源隔离给多个虚拟机，极大提升了资源利用率。UB 作为新一代高速互联总线，同样支持虚拟化能力。 当前设备虚拟化的主流技术主要包括如下几种：IO 全虚拟化、IO 半虚拟化、硬件辅助 IO 虚拟化。传统架构下每一台服务器都是通过插在其上的网卡连接到 TOR 交换机，所以最大可支持的带宽是固定的，在实际应用过程中会带来闲时带宽利用率低、忙时带宽不够用、服务器间带宽压力不均衡等问题。

在 UB 总线中，UE（UB Entity）作为一个 UB 设备相对隔离的功能单元，UB 虚拟化的功能同样支持通过直通的方式将其直接分配给虚拟机使用，以达到设备原生的性能，UB 虚拟化的功能同样支持通过直通的方式将其直接分配给虚拟机使用，以达到设备原生的性能，UB 设备虚拟化在传统的硬件辅助 IO 虚拟化之上扩展对池化 UB 设备的直通访问。通过将网卡、DPU 设备资源池化，可以解决上述问题。所有设备资源统一在设备池中，所有服务器通过共用设备池里的网卡资源，可以根据服务器实际的网络负载情况动态申请使用相对应的网卡资源，达到提升设备资源利用率，避免网络带宽瓶颈。同时，灵衢特有的内存管理与大带宽通信特性，能给虚机提供更灵活的内存超分与极速热迁移能力。

• UBNative：基于 UB 协议构建的高性能设备虚拟化解决方案，通过模拟 UB 设备模型，实现虚拟机对 UB 总线的无缝接入。依托 VFIO 技术，将 UB 设备以直通方式给虚拟机使用，确保在虚拟机环境中充分发挥设备原生性能，实现近硬件级的运行效率与资源利用率，为高吞吐、低延迟场景提供稳定支撑。
• 内存超分：随着主机内存规模的增大，内存成本在整体 TCO 占比持续走高，云场景下提升内存利用率的目标越来越重要。实现基于灵衢超节点架构下的内存超分功能，构建面向大页虚拟机、直通虚拟机的内存回收方案，充分回收虚拟机内部的无用内存，转换让其发挥业务价值，从而能提升虚拟化内存利用率，进一步降低云厂商 TCO。
• 极速热迁移：基于 URMA 内存读写语义，利用灵衢高性能网络进行内存数据迁移，减少迁移中断时间、减少资源开销、并提升高内存压力虚拟机的迁移成功率。

QEMU支持NPU卡D2H ​

本功能是UB Memory子系统的一部分，UB Memory位于GuestOS业务驱动与Host UMMU之间，提供接口供GuestOS 上的业务驱动子系统或者模块调用，上层主要为SVM模块。 UB Memory子系统南向使用QEMU模拟的VUMMU硬件，QEMU实现对VUMMU设备的模拟，然后通过UB Memory Mapping Driver提供的接口，完成Guest内map/unmap操作到Host 内存的map/unmap的功能透传。

灵衢系统高阶服务 ​

面向灵衢超节点，为了应用快速使能超节点能力，灵衢系统构建了 UB Service Core，封装 UB 底层能力、集群拓扑等，简化并兼容现有生态，让应用像使用本地资源一样使用超节点资源，简化应用开发，使能灵衢超节点。UB Service Core 构筑5大集群系统服务，释放超节点平等互联架构优势，全面使能应用加速30%~50%，促进灵衢系统软件生态构筑。包含5部分：

1. UB Service Core Engine（简写：UBS Engine）：支持内存、DPU资源池化管理与动态调度，支持分布式自选主，支持 N 节点场景下最多 N-1 节点失效的高可用，是灵衢计算系统的控制面核心参考实现。
2. UB Service Core Memory（简写：UBS Mem）：支持统一内存编程，实现灵衢超节点的共享内存、池化内存。
3. UB Service Core Communication（简写：UBS Comm）：基于超节点提供高性能、高可靠以及生态兼容（用户态 Socket/Verbs over UB）的通信协议。
4. UB Service Core IO（简写：UBS IO）：基于超节点，提供应用亲和的全局数据读写缓存系统高阶 IO 服务。
5. UB Service Core Virt（简写：UBS Virt）：支持虚拟化池化，热迁移策略决策，极速快恢和容灾，虚机/容器间极速通信等能力，使能虚拟化性能提升。

灵衢可靠性 ​

灵衢可靠性插件 ​

当紧急事件（OOM、Panic、reboot等）发生时将相关的紧急事件阻塞，并上报事件到UBPRM中，防止发生数据丢失或业务中断，同时也负责统一管理通过UB event上报的事件。

• 节点故障检测与恢复： 当Home侧节点发生Panic/reboot时，该节点借出的内存将无法访问，会影响User侧的业务进程，在此情况下需要将保存在Home侧内存中的数据迁移出来。

当UBPRM收到sysSentry Service上报的故障通知后，可采取相应的故障隔离和恢复措施，例如将Home侧节点内存迁移至其他节点并解除和故障节点的借用关系，确保使用池化内存的业务不受影响。

• OOM检测、预防与恢复： 在内存借用场景下，UBPRM会按照固定的时间周期检测内存占用水位情况，该水位可配置，根据实际的使用情况采用内存归还/内存借用的策略。当短时间内发生大量的内存占用，导致内存水位迅速上涨时，UBPRM检测机制可能无法及时发现该现象，导致业务节点发生进程被杀死或节点重启，发生业务中断。此时可通过OOM预防机制将OOM事件上报给UBPRM，触发OOM的紧急借用策略。

内存池化故障劫持&通知 ​

操作系统对于访存故障有标准的处理方式，访存故障根据硬件规范上报为SEA或SEI，内核基于规范进行处理，处理方式包括将内核直接panic或隔离对应内存并给使用该内存的用户态线程发送SIGBUS信号。操作系统内核对于在内核内存管理子系统中的内存都可以进行上述故障处理流程。 SEA/SEI针对主动访存（LD/ST指令）操作触发的同步或异步故障事件上报，针对灵衢还有一类影响范围较大的linkdown故障事件。由于所有的灵衢跨节点内存访问都需要经过UB链路，如果链路本身发生断链等故障可能导致所有远端访存失败。UB提供链路断链故障的主动上报，硬件检测到断链故障后可通过BIOS上报给内核UBUS组件，sysSentry订阅该事件后上报给用户态，用户态收到该事件后可进行自定义隔离或修复等操作。 超节点内存池化提供借用和共享两类使用方式，其中借用内存上线至操作系统，受内存管理子系统控制；借用内存与操作系统本地内存故障处理流程类似，由于借用内存通过remote_numa上线当前操作系统，并通过内存管理子系统对外分配使用，业务可通过特定的访存策略申请分配，内存故障时通过现有的SEA/SEI方式上报OS，OS通过已有的memory_failure流程进行内存故障处理，包含内存隔离与杀死进程等操作；共享内存通过独立内存设备上线，绕过内核内存管理子系统，以设备的形式被用户态进程直接mmap使用，这类内存故障需要额外处理。灵衢超节点针对内存故障额外提供UBEvent异步事件上报访存故障信息，该事件由UBUS驱动直接处理，并对外提供钩子函数。sysSentry注册该钩子函数处理上报的UBEvent内存事件，针对上报的故障内存地址及故障进行处理，通过该地址反向查找内存设备文件，在用户态遍历所有映射使用该内存设备的进程并发送sigbus通知线程该内存故障。 通过这一特性补齐共享内存场景下内存故障的业务通知能力，业务感知故障后可自行进行处理。

内存借用文件缓存故障防扩散 ​

pagecache是操作系统提供的，跨进程共享内存的一种方式；灵衢超节点场景下，机器上会存在不和cpu关联的numa node，称之为cpuless node；在cpuless node上分配的内存，物理位置可能不在本机；因为pagecache共享的特质，一旦出现错误，就会导致所有使用这块pagecache的进程均出现问题。 新增一个sysctl参数：vm.filemap_alloc_local，用于控制pagecache的分配策略，该参数配置为1时，pagecache不会分配到cpuless的numa node上，为0时则保持默认分配逻辑。 mempolicy支持： 参数配置为1时，在分配pagecache时，会从进程配置的mempolicy的numa node中，去除所有cpuless的numa node，policy保持不变；如果mempolicy中仅有cpuless的numa node，则会改为取进程的mems_allowed配置并去除cpuless的numa node作为新的mempolicy可用node，policy本身保持不变(bind/prefer/interleave) 如果开启cgroup级别，cpuset的spread_mem，则会按照spread_mem逻辑在非cpuless的numa node上交织分配pagecache 参数配置为0时，则对pagecache分配无影响 。

云原生场景创新 ​

众核高密 ​

服务器芯片由多核进入众核时代（>256C），对操作系统提出新的挑战。提升Rack计算密度、降低数据中心TCO，众核服务器已成为互联网行业主流选择，随着云技术和业务规模发展，容器化部署成为互联网行业的主流业务部署形态，在这种场景下，系统串行开销和同步开销限制可扩展性，干扰问题凸显，资源利用率低，影响容器部署扩展性的串行访问开销和同步开销主要来自软硬共享资源争用。

本期主要采用轻量虚拟化按NUMA分域拆分资源、域内实现资源容器级隔离增强，降低因软硬件资源争用导致的性能干扰，提升容器部署扩展性。关键技术特性包括虚拟机内存 QoS控制、虚拟设备 NUMA 亲和、轻量虚拟化、CPU 分域调度、文件系统块分配干扰隔离、高效 slab 回收、网络 tcp hash 干扰隔离、Cgroup 隔离增强、干扰监测、鲲鹏内存/Cache QoS 管控机制 MPAM、QoS 策略动态配置和IO 混部场景 IO QoS 控制器 IOInflight。

Agent沙箱 ​

1. 极速启动与弹性扩展
   • 百毫秒级冷启动 —— 基于 Firecracker microVM 技术，比传统虚拟机快数百倍。
   • 在单集群下，支持从单个沙箱扩展到数百个并发实例，自动弹性伸缩。
2. 多语言代码执行
   • 支持 Python、JavaScript等任意编程语言。
3. 企业级安全隔离
   • 硬件级隔离：每个沙箱运行在独立的 Firecracker microVM 中，拥有专属内核。
   • 多重安全机制：Jailer 进程、cgroups/namespace 隔离、网络访问控制。
   • 资源限制：CPU、内存、存储配额防止资源耗尽攻击。
4. 完整的环境控制
   • 文件系统：完整的文件读写、上传下载能力。
   • 进程管理：执行任意系统命令、安装软件包。
   • 网络访问：支持发起 HTTP 请求、调用外部 API。
   • 动态依赖：运行时安装 Python/Node.js 等包。
   • 状态保持：变量和状态在多次执行间持久化。
5. 长会话与高级生命周期管理
   • 支持 Pause/Resume/Checkpoint/Fork 等高级操作。
   • 自动超时清理，也可手动销毁。
   • 会话存活时间可配置，最长支持数小时长会话。
   • 优雅停机机制，虚机自动停机启动，高效节省资源。
6. 自定义模板
   • 通过 Dockerfile 构建预装环境的自定义沙箱。

内核创新 ​

openEuler 24.03 LTS SP4基于 Linux Kernel 6.6内核构建，在此基础上，同时吸收了社区高版本的有益特性及社区创新特性。

• openEuler发布64K内核：arm镜像支持4K/64K可选内核安装，在保证arm默认安装4K内核行为不变的前提下，增加安装64K内核的可选行为；默认持平upstream社区特性兼容性，基于64K特性提升OS基础场景性能。

• 文件系统支持可编程页缓存：针对大模型推理场景中模型加载I/O效率低下问题，实现一种页缓存可编程框架。该框架以透明化方式堆叠于当前文件系统之上，将文件系统缺页事件转发到用户态，使应用可以根据负载特性在用户态对文件系统的缓存策略进行定制，从而对不同模型的加载进行I/O效率的显著优化。。

• 跨进程零拷贝数据传输机制：提供高效的节点内进程间数据传输接口，应用可将源进程中的给定虚拟内存地址空间上关联的页面映射到目的进程中的虚拟地址空间上，兼容PMD大页和PTE小页映射。映射后的目的地址访问权限和源地址保持一致。

• FUSE文件系统支持io_uring通信接口：当前FUSE架构中，用户态守护进程与内核态驱动模块通过字符设备/dev/fuse进行通信存在性能瓶颈。

• IO混部场景IO QoS控制器IOInflight：详情见#众核高密。

• 基于Xcall的epoll_wait异步预取：面向特定系统调用的性能优化场景，Dynamic Xcall通过劫持机制执行定制系统调用，允许用户在不侵入式修改内核的情况下，以应用程序ELF文件的粒度进行系统调用劫持，执行定制化系统调用。基于该框架实现了一套非内核侵入式修改的epoll异步预取示例内核模块，可以在Redis等场景获得一定的性能收益。

• sockmap加速同主机tcp流：Redis、Nginx等场景存在大量的回环报文并且都是走完整的tcp协议栈，耗时较长。通过本特性，利用bpf程序将socket pair的ops替换, 将两个socket发送和接收队列连接起来，直接将数据包redirect到对端，以此来bypass协议栈，这样可以减少报文转发流程，降低时延。

• HiSock功能增强：基于原有HiSock能力，针对互联网场景进行功能增强，包括本地加速、包解析逻辑增强、抓包逻辑、地址转换、邻居处理等能力，提升鲲鹏产品在承载高并发、低时延网络负载时的性能表现和吞吐能力。

• copy_from_user优化特性：通过临时关闭 PAN，允许ldp访问用户内存，以单指令16字节替代ldtr双指令加载，拷贝完成后立即恢复 PAN，大幅减少指令条数。提升拷贝吞吐效率。

• 动态SMT：为了提高整机CPU利用率，会把延迟敏感（Latency-Sensitive, LS）任务和尽力而为（Best-Effort, BE）任务的场景部署到同物理核的两个SMT上运行，但BE任务和LS任务会竞争底层物理核资源导致LS任务时延出现大幅劣化。本方案通过针对这一痛点，设计了平衡混部SMT干扰管控力度和提升整机CPU利用率的方案，优先保证LS任务的运行，BE任务自动被节流并让出微架构资源，同时BE任务在主SMT核和空闲从核上插空运行来提高CPU利用率。

• 网络多路径RPS增强特性：网络多路径特性将网卡队列中断按策略绑定到不同NUMA节点的CPU上，并通过识别业务进程的流量特征，使指定业务的网络流量优先由该进程所在NUMA节点的网卡队列接收。RPS增强特性则将Loopback网卡和物理网卡接收的报文，根据配置的RPS策略，分散到与业务进程位于同一NUMA或Cluster的CPU核上处理。前者将中断分散到不同NUMA节点的网卡队列，后者在此基础上将报文处理在同一NUMA或Cluster内进一步打散。两者配合在实现多核CPU负载均衡的同时，兼顾NUMA和Cluster亲和性，有效降低内存访问延迟，提升网络吞吐性能。

• NetKit：NetKit 是一种直通式虚拟网络设备，核心旨在根治传统 veth pair 在高并发、大吞吐场景下引发的时延阶跃与长尾效应。它彻底解决了因数据包跨命名空间内存复制、频繁触发软中断导致的多核上下文切换损耗，以及无效的 MAC 地址解析与二层报头封装等引致网络延迟的历史包袱。该机制原生支持 eBPF 内核级流量治理，支持自定义多 eBPF 程序的链式动态调度。

• Cgroup v2 特性增强：支持开源 cgroupv2 功能，更好的达到k8s等开源三方件对于cgroup的兼容要求；并且在原有功能基础上，支持cgroup级别的异步回收功能；可以解决由于cgroup级别的同步内存回收带来的性能损耗，在缓解内存短高峰带来的性能抖动的同时，按照场景需要，提升业务性能。

• sched_ext 可编辑调度框架：基于 eBPF 技术实现了系统运行时动态加卸载自定义调度算法的能力，无需重新编译内核，降低了调度器开发周期和门槛，实现对特定工作负载极致优化，内置安全保护机制，BPF 程序异常时自动切回系统默认调度器，避免系统卡死异常。

LLVM for openEuler 编译器 ​

LLVM for openEuler编译器基于开源LLVM软件进行深度打造，是面向服务器互联网行业、数据中心新应用、通算AI新场景和视频编解码等高算力场景的高性能编译器。同时在openEuler社区打造国内的LLVM基线，提供高性能、安全可靠、易创新的LLVM下游社区稳定的发行版，已支持主流的系统语言（C/C++）和芯片架构（X86/AArch64/RISCV/LoongArch等）。LLVM for openEuler编译器在openEuler 24.03 LTS SP4版本引入以下编译特性，提升了编译构建效率，削减Debuginfo信息膨胀以及使能Triton-CPU全量支持FlagGems算子。

• Dwarfutils功能增强，削减Debuginfo信息膨胀：ThinLTO优化是编译器里常见的编译优化手段，传统的编译流程是将每个源码文件各自编译生成目标对象文件，最后再链接生成可执行程序，源码文件之间信息不互通，无法进一步优化，而在ThinLTO模式下，源码文件首先编译生成LLVM IR格式的文件，在链接时把所有文件整合成一个文件进行深度优化，类似于所有的源码都写在了同一个文件当中，优化更彻底。但是ThinLTO优化会大幅度增加编译时长，在构建大型应用的时候尤其明显，ThinLTO Split技术通过在编译流程中进一步将编译单元进行分块并行编译，加速编译效率。而使能ThinLTO Split特性后会使得Debuginfo信息膨胀数倍，可能导致链接时寻址溢出，此时可以使用Dwarfutils工具消除冗余的Debuginfo 信息，减少二进制体积。
• Triton-CPU全量支持FlagGems算子：Triton是面向GPU的并行编程语言与编译器，它允许开发者使用类似于Python的语法编写可编译为GPU代码的程序，提供了一种高效灵活的编程方式。Triton构建在LLVM MLIR框架之上，能够充分利用LLVM编译器的优化能力。Triton-CPU是将Triton扩展到CPU后端，扩展了Triton的适用场景，但对于AArch64 SVE/SME等指令的适配程度还不佳，也不支持FlagGems常用算子。本次更新全量支持了FlagGems算子，并亲和了AArch64 SVE/SME等指令能力，提高了在AArch64架构下的实用性。

Go for openEuler 编译器 ​

Go for openEuler是基于开源Golang开发，是一款高性能、高可靠、易开发的Golang发行版，致力于打造生态兼容、极致体验、亲和openEuler的高性能编译器。主要面向云原生、微服务应用等对敏捷开发和运行性能都有要求的容器云场景，围绕业界主流Go业务负载进行优化，解决实际业务中由原生Golang能力不足导致的性能问题，并适配国产龙芯、鲲鹏等硬件平台，充分释放国产硬件算力。

• LoopRotate循环优化增强：原生LoopRotate存在优化后跳转次数变多问题，导致性能提升不明显，通过增强LoopRotate pass，重新调整代码块布局，使其更加紧凑，减少了一次跳转，提升了相关执行效率。
• bytealg函数寄存器传参优化：ARM64平台架构下的汇编函数部分使用ABI0的调用约定，导致执行效率低，将使用ABI0调用约定升级到ABIInternal调用约定，使得优化前ABI0使用出入栈的方式传递函数出入参，优化后使用ABIInternal约定直接使用寄存器进行函数出入参传递。
• 运行时GC优化：在连续内存地址加载和存储过程中，使用LDR/STR效率低，使用LDP/STP等鲲鹏支持的高效指令集，提升连续内存的加载和存储效率。
• 内存块预清理优化：GO对象释放时仅修改标志位，把清理工作遗留到后续逐个对象分配时进行，造成清理开销频繁，在nextFree函数中判断并直接清理整个mspan，同时对标志位清零，将多次小范围清零操作合并为一次大范围清零操作，带来以下收益：优化缓存机制、减少垃圾回收的开销。

毕昇 JDK ​

毕昇 JDK 支持堆内存扩容 ​

容器化部署应用的模式下，大部分客户容器场景下容器资源支持垂直伸缩，当前OpenJDK8的最大堆只能在启动时支持修改，无法支持在线动态扩缩，Java应用无法在线使用到容器扩容出的内存，需要Java应用启动时重新设置最大堆；鉴于此问题，毕昇JDK在毕昇JDK8、毕昇JDK21、毕昇融合JDK中的G1GC、PSGC上实现堆内存上限在线伸缩能力，允许用户在应用运行时动态更新Java堆内存的上限，而无需重启JVM。

毕昇JDK8特性增强 ​

• CompactStrings内存优化：CompactStrings（紧凑字符串）是Java 9引入的一项重要内存优化特性，用于改进字符串的存储方式，显著减少内存占用。在Java 8及之前版本中，字符串内部使用char[]字符数组存储，每个字符占用2个字节（UTF-16编码），无论字符串实际内容如何。这导致在处理大量仅包含ASCII字符的字符串时，内存使用效率低下。目前，CompactStrings已从JDK17回合到毕昇JDK8，进一步提升毕昇JDK8整体性能。

• JProfileCache：Java应⽤启动阶段存在热点⽅法即时编译与业务请求处理对CPU资源的竞争问题，可能因为编译延迟导致系统性能爬坡缓慢。JProfileCache特性基于收集上⼀次运⾏的Profiling信息再次启动时先触发热点⽅法编译使⽤⼾Java进程快速抵达峰值性能。

• AutoCDS：通过本特性，用户只需要通过指定一组参数，JVM会自动识别当前所处的阶段，并根据需要启动相应的参数，自动执行相应操作。AppCDS使能流程由三步简化为一步，减少了手动干预，避免了配置错误的发生。自动化流程不仅减少了操作步骤，还降低了用户配置的复杂度。

• UTF8/16编解码向量化：该特性当前仅在 AArch64 架构下生效，基于鲲鹏平台的向量化指令能力实现，通过使用SIMD指令，对多个字节或字符进行并行加载、转换与写回，从而提升热点路径执行效率。对于满足向量化条件的输入，走 intrinsic 高性能路径；对于不满足条件的场景（比如malformed surrogate），则回退至现有标量实现，以保证功能正确性和兼容性。

毕昇 JDK17 特性增强 ​

支持退优化可观测 ​

JDK17 的 JFR Streaming API 功能，是 JFR 从“事后静态分析”迈向“实时监控”的关键特性。在传统的 JFR 使用模式中，流程是：记录 -> 停止记录 -> 转储为 .jfr 文件 -> 用 JMC 离线分析。这种模式是“事后分析”，对于排查已经发生的问题非常有效。Streaming API 引入了一种全新的模式：它允许 Java 应用程序在不中断 JFR 记录、不生成完整 .jfr 文件的情况下，实时、持续地从 JVM 内部订阅和消费 JFR 事件流。

在使用 Streaming API 的时候，通过本功能可以在 ****** 处获取当前时间之前的一段 jfr event，例如退优化事件。

// 1. 创建一个 RecordingStream
RecordingStream rs = new RecordingStream();
// 2. 启用我们感兴趣的事件并配置设置
rs.enable("jdk.GCPhasePause").withPeriod(Duration.ofSeconds(1));
rs.enable("jdk.Deoptimization").withPeriod(Duration.ofSeconds(1));
// 3. 订阅特定事件并设置事件处理器（回调函数）
rs.onEvent("jdk.GCPhasePause", event -> {
// 从事件中读取字段
Duration duration = event.getDuration("duration");
String name = event.getString("name"); // 例如 "GC Pause"
*****************
shell:   jcmd JFR.start delay=-1 filename=xxx.jfr
*****************
});
// 4. 启动流（这是一个非阻塞调用）
rs.startAsync();

元数据压缩 ​

Java对象的存储会有额外的开销，即对象头，它用于存储与该对象相关的元数据信息。伴随存活对象的增多，以及大量小对象的存在，对象头占用空间问题也会愈发严重。压缩对象头特性由此而来，该特性隶属于OpenJDK Lilliput子项目，旨在研究如何将Hotspot JVM中的Java对象头从128/96 bits降低到64 bits，从而减少Java堆内存（Heap Memory）占用，并且通常还能提升应用程序的工作负载性能。

对象头通常包含两个主要部分：MarkWord和类指针（Class Pointer），如果是数组对象还包括数组长度。其中MarkWord主要包含GC年龄、Hash值、锁等运行时信息。

JProfileCache ​

Java应⽤启动阶段存在热点⽅法即时编译与业务请求处理对CPU资源的竞争问题，可能因为编译延迟导致系统性能爬坡缓慢。JProfileCache特性基于收集上⼀次运⾏的Profiling信息再次启动时先触发热点⽅法编译使⽤⼾Java进程快速抵达峰值性能。

毕昇JDK JProfilecache方案将应用程序的发布分成了两个阶段，分别是记录Profiling信息和预编译。在记录Profiling信息阶段，JVM会接受线上的请求，同时记录JVM即时编译器它所编译方法的信息，并且将这些信息都输出到一个文件之中。等到第二次再去启动的时候，JVM就可以去读取刚刚所记录的这些方法编译的信息，同时会主动的触发即时编译器编译刚刚记录的热点方法，使得在用户请求到来之前，就把热点方法编译成为性能较高的Native Code，避免了在用户请求大量进入的时候做编译，这样就能够进一步提高应用程序的性能，节约CPU使用率。

AutoCDS ​

通过本特性，用户只需要通过指定一组参数，JVM会自动识别当前所处的阶段，并根据需要启动相应的参数，自动执行相应操作。AppCDS使能流程由三步简化为一步，减少了手动干预，避免了配置错误的发生。自动化流程不仅减少了操作步骤，还降低了用户配置的复杂度。

在创建VM时，检查是否启用了AutoSharedArchivePath参数。如果未启用，则按照原有逻辑正常启动，没有任何差异；如果启用了AutoSharedArchivePath，则根据指定路径保存生成的appcds.lst和appcds.jsa文件。

1. 判断是否存在lst文件：首先检查base_path（保存lst和jsa文件假设为base_path）目录下是否已有lst文件。若没有，程序将按照以下参数启动： -XX:+UseAppCDS -XX:DumpLoadedClassList=base_path/appcds.lst -Xshare:off 程序运行结束后，将生成lst文件。
2. 判断是否存在jsa文件：若lst文件已存在，则继续检查是否存在jsa文件。如果jsa文件不存在，则进入生成jsa文件的逻辑。此时，通过fork子进程的方式启动生成jsa文件。
3. 使能AppCDS：若jsa文件已存在，则通过参数直接使能AppCDS，完成AppCDS的启用过程。

UTF8/16编解码向量化 ​

该特性当前仅在 AArch64 架构下生效，基于鲲鹏平台的向量化指令能力实现，通过使用SIMD指令，对多个字节或字符进行并行加载、转换与写回，从而提升热点路径执行效率。对于满足向量化条件的输入，走 intrinsic 高性能路径；对于不满足条件的场景（比如malformed surrogate），则回退至现有标量实现，以保证功能正确性和兼容性。

参考simdutf的native方案，直接intrinsic化其实现，对 UTF-8 与 UTF-16 编解码过程进行批量化组织。其核心思想是利用 SIMD 指令一次处理多个字节或多个 16 位字符，基于鲲鹏平台的向量化指令能力实现，通过使用 ld1、st1、xtn、sli、usra 等指令，对多个字节或字符进行并行加载、转换与写回，从而减少传统逐字符处理中的循环次数和条件分支。

毕昇JDK21 KAE特性增强 ​

KAE加速器支持 ​

KAE加解密是鲲鹏加速引擎的加解密模块，其依托修改OpenSSL库实现对底层KAE硬件的调用。 因此应用代码只需调用OpenSSL库，KAE作为OpenSSL的底层引擎提供加速能力。KAEProvider介于应用和OpenSSL之间，提供一种便利的使用OpenSSL库及使能KAE加速的方式。 KAE压缩模块支持ZLIB、GZIP数据格式压缩，压缩带宽大大提升。现Java应用中或多或少都会使用到压缩解压缩特性，尤其在一些数据存储、http等场景压缩CPU占比可能高达70%+，开源zlib压缩速度成为瓶颈，若Java应用可以使能KAE-zlib将极大提高业务的性能。

元数据压缩 ​

Java对象的存储会有额外的开销，即对象头，它用于存储与该对象相关的元数据信息。伴随存活对象的增多，以及大量小对象的存在，对象头占用空间问题也会愈发严重。本特性在Aarch64平台下将对象头从128/96 bits降到64bits。

在64位Hotspot中，Java 对象具有128位的对象头：一个64位的MarkWord字和一个64位的类指针。对象的平均大小通常为5-6个字，其中两个字始终由对象头占用。该特性利用了正常情况下MarkWord高位未被使用的特点，将类指针移动到MarkWord的高位，并通过缩短HashCode和修改标志位等方式，将对象头压缩至64位。

JIT预热增强 ​

本特性旨在使能Java进程启动后快速抵达峰值性能。Java进程从拉起到最终到达峰值，存在一个较为漫长的过程。其中解释器->采样->编译C1->进一步采样->编译C2的采样与在线JIT编译流程是应用预热过程的重要一环。本特性通过压缩该部分流程，有效加速VM启动与预热，助力应用快速达峰。毕昇JDK JProfilecache方案将应用程序的发布分成了两个阶段，分别是：

1. 记录阶段：在程序运行结束时，把热点方法的Profiling信息(主要是方法调用次数，回边次数)及该方法所属类(包括父类)输出到指定文件中。
2. 预编译：后续启动的时候，JVM读取热点方法所在类并进行预加载，同时会把热点方法加入到编译队列进行提前编译，使得在用户请求到来之前，跨过Profiling阶段，就把热点方法编译成为性能较高的Native Code，减少热点方法的预热开销。

AI 编译器 ​

ANNC（Accelerated Neural Network Compiler）是专注于加速神经网络计算的AI编译器，聚焦于通过计算图优化，高性能融合算子生成和高效的代码生成和优化能力，加速推荐和大语言等模型的推理性能，并且从架构设计角度支持业界主流开源推理框架和不同硬件后端的接入，提高软件的可扩展性。

计算图优化是通过优化神经网络的计算流程，从算法角度减少冗余操作、混合精度改写和自动子图调度优化计算负载和提高缓存利用率，从硬件架构角度优化张量数据布局、算子融合和转换、子图切分调度，进一步优化负载，充分利用硬件资源。

高性能融合算子库生成和对接包括前端计算图模式识别和转换，高性能算子库查询和对接，以及算子库自动生成三部分，从汇编指令层面上通过数据预取、模型并行和新型指令集应用等优化手段，减少访存，提高并行计算效率。

ANNC旨在通过图编译优化和高性能算子生成和对接，提高AI推理速度和降低功耗，达到提高用户单位成本的推理效率的目的，同时通过软件兼容性和易用性设计减少用户的运营成本和环境影响。

安全 ​

CCA 机密计算 ​

ARM CCA（Confidential Computing Architecture）是ARM v9新引入的机密计算架构规范，旨在为下一代计算设备定义标准化的机密计算解决方案。CCA引入了全新的Realm域作为可信执行环境，来保护正在使用中的数据和代码的机密性和完整性，即使面对拥有特权的基础设施软件或云服务提供商，也能得到有效保护。 openEuler基于ARM CCA机密计算架构规范，实现了OS相关组件（KVM、QEMU、libvirt、Guest kernel）对CCA的支持，提供了原生支持Realm机密虚机的社区版本，满足基于Realm机密虚机保护使用中数据的安全诉求，同时提供了兼容传统应用生态及虚机管理软件的易用性。

ARM CCA 通过以下核心组件协同工作，构建一种隔离的、受保护的执行空间，在代码执行和数据访问方面与正常世界完全隔离，成为Realm机密域。

• Realm机密域：Realm是 CCA 的核心抽象，它是一种与正常世界（Non-secure）和安全世界（Secure，原来的Trustzone）并行的新类型执行环境。Realm是硬件隔离的，专为托管敏感代码和数据而设计。它独立于主机操作系统和 Hypervisor，它们可以管理Realm但无法访问其内部内容。
• 动态管理：Hypervisor 可以应客户要求动态创建Realm，并为其分配内存和 CPU 资源。但在Realm初始化后，Hypervisor 会将其控制权移交给一个受保护的安全虚拟化模块RMM（Realm Management Monitor），此后 Hypervisor 便无法访问Realm内的秘密。
• 内存管理：CCA 扩展了系统内存管理单元（MMU），使其能够识别和隔离Realm内存。任何从Realm外部（包括 Hypervisor）发起的访问尝试都会被硬件阻断，从而确保数据的机密性。
• 远程证明：每个支持 CCA 的处理器都有一个基于硬件的唯一身份标识。当Realm启动时，它可以生成一份由硬件密码学签名的证明报告（Attestation Token）。用户可以获得这份报告，并验证其签名及组件度量值，从而确信他们的工作负载正在一个真实的、未被篡改的 ARM CCA 环境中运行。

Global Trust Authority远程证明 ​

GTA远程证明服务组件支持TPM/vTPM、VirtCCA及其IMA的远程证明，分为客户端和服务端。

• 服务端提供了远程证明服务框架兼容可信计算及机密计算，支持证书、策略等的增删改查，Quote验证，随机数，JWT Token生成等能力。
• 客户端支持采集本地TPM证据，并可与服务端交互，验证Quote。

本组件在安全性及易用性上也提供了多种能力。 安全性上支持数据库完整性保护、数据链路加密，验证防重放，SQL防注入，用户隔离，密钥轮换机制等一系列差异化安全竞争力。 易用性上支持护照模式及背调模式。客户端支持定时上报，响应挑战等多种验证模式。客户端及服务端支持rpm包及docker安装部署。

Global Trust Authority - Resource Broker Service ​

Global Trust Authority RBS资源分发服务是与GTA远程证明接口强耦合的配套服务。 RBS提供资源（如密钥）导入导出及其安全存储的能力，并可对该资源绑定安全环境基准值。如将id1的资源映射为机密环境CCA基准值RIM为0x1234...。实际使用时，机密环境获取资源时，RBS会验证GTA远程证明的JWT报告，当且仅当机密环境实际值与预设的基准值完全匹配时，才分发资源到机密环境中。 GTA远程证明 + 机密计算/可信计算TEE + RBS资源分发服务，符合rfc9334对Verifier，Attester, Relying Party的定义，既支持背调模式，也支持护照模式。三者联用，可支持绝大部分机密计算的使用场景，也符合业界对机密计算的通用用法。

以AI推理场景对私有模型的保护为例，模型Owner生成密钥本地加密模型后部署于机密环境如CCA机密虚机，并将密钥导入RBS安全存储，密钥与安全环境基准值绑定，如可定义CCA REM0~3, RIM等寄存器基准值 。运行时，通过GTA远程证明实时验证机密环境是否符合预定义的REM等寄存器基准值。RBS验证通过后，将密钥以安全方式发送至机密虚机中，用于后续解密模型。事实上，资源分发服务在机密计算中与远程证明联用，可解决机密虚机内所有密钥来源，该密钥最常应用于落盘加解密,也可用于传输等其他加解密场景。

virtCCA特性增强 ​

当前virtCCA架构在启动方式上存在特定约束：其仅支持kernel与rootfs分离的启动模式（即内核镜像与根文件系统分别挂载）。然而，在主流云平台环境中，虚拟机的启动流程普遍依赖GRUB引导机制，这要求将UEFI固件（如EDK2）、内核（Kernel）及初始内存文件系统（initramfs）整合至单一磁盘镜像（如QCOW2格式）中。功能要点包括：

1. 单镜像封装
   • 将 EDK2 固件、GRUB 引导程序、内核（Kernel）及 initramfs 整合至单一 QCOW2 磁盘镜像，形成完整启动栈。
   • GRUB 通过配置文件（grub.cfg）定位内核路径，要求内核与 initramfs 必须位于同一文件系统（如 EXT4/XFS）。
2. 安全信任链传递
   • Secure Boot 机制：EDK2 验证 GRUB 及内核的数字签名，确保启动组件未被篡改。
   • 硬件资源协同：依赖 UEFI 运行时服务枚举硬件设备，为虚拟机管理程序（如 KVM）提供虚拟化资源池。
3. 云原生优化
   • 支持快照克隆、根文件系统动态扩容（依赖 initramfs 中的 cloud-init 工具）特性。

virtCCA机密虚机热迁移 ​

机密虚拟机热迁移是指在机密虚机（CVM）业务运行不中断的情况下，将其从一个机密计算环境安全地迁移至另一个经过验证的机密计算环境，并确保机密虚机中的敏感数据在迁移前、中、后始终处于加密或隔离保护之下。 virtCCA机密云主机热迁移通过迁移管理虚机MigCVM和安全世界Hypervisor TMM组件实现热迁移过程中机密虚机状态的机密性和完整性，包括如下功能要点：

• 迁移源平台需要对目标平台进行身份验证，TMM组件需要对MigCVM进行可信度量；
• 身份验证通过后，源平台和目标平台MigCVM完成迁移密钥协商；
• 迁移源平台和目标平台建立加密安全会话，确保迁移数据的安全；
• MigCVM对迁移状态进行管理和跟踪，确保迁移过程状态安全，管理异常状态；
• TMM组件负责导出、导入virtCCA机密虚机内存状态及VCPU状态；
• TMM组件基于迁移密钥对机密虚机状态数据进行加密，并对状态数据进行完整性校验。

Kuasar机密容器 ​

Kuasar 统一容器运行时在支持安全容器的基础上添加了对机密容器的支持。用户可以通过配置 iSulad 的运行时参数，完成对 Kuasar 机密容器的纳管。 当前Kuasar机密容器使用iSulad+Kuasar方案，提高了启动速度，极大降低了内存底噪。一方面 Sandbox API 的实现，使得创建容器不再单独创建 pause 容器，节省了准备pause容器镜像快照的时间；另一方面得益于1:N 的管理模型，Sandboxer 进程常驻，从而节省了冷启动 Shim 进程的时间，这使得容器的启动速度大大提升，带来与Pod数成正比的内存收益。最后，Kuasar使用rust实现，相比golang，内存更安全，语言本身也带来了一些内存收益。

• 支持 iSulad 容器引擎对接 Kuasar 机密容器运行时，兼容 Kubernetes 云原生生态。
• 支持基于 virtCCA 的机密硬件，允许用户在鲲鹏 virtCCA 可信执行环境中部署机密容器。
• 支持secGear 远程证明统一框架，遵循RFC9334 RATS标准架构，允许在机密计算环境中运行的容器向外部的受信任服务证明其可信性。
• 支持在机密容器内部拉取并解密容器镜像，保护容器镜像的机密性和完整性。

secScanner：操作系统安全加固组件 ​

secScanner是一款Linux操作系统安全扫描工具，旨在为操作系统提供安全管理、漏洞扫描、rootkit入侵检测等功能。

secScanner基于“3核心能力+3公共能力”的技术架构，建设全面有效、实时自动、灵活易用的主动防护能力。

• 安全管理：操作系统已有安全能力的使能度管理，针对操作系统安全配置复杂、运维人员安全意识不足、不同场景下安全配置需求不同等问题，安全管理功能可支持多基线选择，亦可根据需求定制安全基线，通过配置文件中预设的参数细粒度控制安全配置项，一键进行安全检测、安全加固、配置还原的功能。
• 漏洞扫描：全面和及时应对操作系统组件已知CVE威胁，针对操作系统组件存在已知的CVE漏洞，潜在攻击者利用已知的攻击路径发起攻击。漏洞扫描功能支持从openEuler安全中心下载安全公告、CVE公告保存在本地漏洞数据库，对系统组件进行全量扫描或者重点组件轻量化定向扫描，报告系统当前存在风险的组件，并给出升级建议。
• 入侵检测：泛化性应对操作系统未知威胁，针对攻击者通过各种未知手段对系统进行入侵，入侵检测功能调用了secDetector工具对系统潜在的恶意rootkit模块进行检测，并给出清理建议。

utpam：基于Rust开发的身份认证模块 ​

utpam是一种用于Linux系统的认证框架。它允许系统管理员定义系统中的不同服务的认证机制，并且可以根据需要组合多种认证方式。utpam通过提供一个统一的接口来处理认证相关的工作，简化了应用程序对用户身份验证的过程。

cu-concrete安全加固工具 ​

cu-concrete安全加固工具平台是面向企业级打造的安全加固框架，主要用于自动化检测和修复系统层面的安全隐患，重点解决信创替代场景下批量加固效率低、安全基线适配难、传统加固脚本耦合度高、参数硬编码、运维成本高等问题，平台采用分层模块化设计，整合CLI命令行、TUI可视化和WEB网页三种交互能力，内置55项标准化加固项，支持参数化配置，无需修改代码即可适配不同安全基线，具备开放式框架能力，可按照规范自主开发并自动集成新增加固模块，实现安全能力持续演进，同时支持按云池、按列表批量下发加固任务，能够实时监控任务执行状态，支持自动化配置生成和配置脚本微调，可留存、查看历史执行日志，实现从任务下发、执行监控到结果查看的全流程可追溯管理，平台整体采用配置化、开放式设计理念，所有加固策略通过YAML文件实现参数化管理，依托统一开发与目录规范保障模块扩展能力，并通过文件化轻量化存储实现加固状态持久化。

cu-scanner漏洞扫描软件 ​

cu-scanner 是一款专为网络安全领域打造的工具，其核心功能是依据操作 CVE（Common Vulnerabilities and Exposures，通用漏洞披露）与安全公告的文件或数据接口，对相关信息进行收集、整理和唯一化处理，进而快速生成 OVAL（Open Vulnerability and Assessment Language，开放漏洞评估语言）格式的 XML 文件以及 SCAF（Security Content Automation Framework，安全内容自动化框架）格式的 JSON 文件。 该工具能够帮助安全人员更高效地处理漏洞信息，为漏洞评估、安全扫描等工作提供标准化的数据支持，有助于提升网络安全防护的准确性和及时性。无论是面对大量的本地文件还是实时的数据接口，cu-scanner 都能稳定、快速地完成数据处理与格式转换，满足不同场景下的安全工作需求。

safeguard审计观测工具 ​

safeguard 是基于 KRSI/eBPF+LSM 的 Linux 安全审计与访问控制工具，面向主机和容器环境提供文件、网络、挂载、进程等关键行为的监控、审计与阻断能力。该工具支持按进程名、父进程名、UID/GID、容器范围等上下文配置安全策略，可在监控模式下记录风险行为，也可在阻断模式下执行访问控制；同时支持白名单策略生成，帮助用户构建细粒度的最小权限运行环境。

sysSentry系统级故障管理框架 ​

sysSentry主要提供故障巡检框架，该框架通过提供统一的北向故障上报接口以及南向提供支持不同巡检/诊断能力的插件，支持对系统中CPU、内存、磁盘、NPU等硬件故障进行巡检和诊断。

• 统一告警/事件通知服务：通过提供一个统一的告警服务，接收各个插件上报的故障信息，并由该通知服务进行统一转发，各个业务订阅服务可以根据需要进行不同故障的消息订阅。
• 统一日志服务：通过提供统一的日志服务，支持各个插件的故障信息进行汇总记录，提升问题定位效率。
• 故障诊断/巡检框架：该框架支持以插件化的方式进行各项巡检任务以及诊断任务的开发和配置，不同插件支持独立启动、停止、状态查询、结果查询以及启动方式设置，并且支持C/C++、Python、Shell等不同编程语言的插件。
• 轻量级数据采集服务：该服务支持通过内核接口、BIOS、BMC等接口，查询硬件的各个状态信息，供各个插件进行分析和使用，并且支持适配底层不同的架构、版本以及数据采集服务。

慢IO/慢盘检测 ​

慢IO检测基于滑动窗口对系统中一段周期内不同硬盘的io时延数据进行分析，当整个窗口中异常周期的数量超过一定数量时，则认为此时该盘发生慢io事件。 目前支持两种类型的慢io检测插件：基于平均时延计算异常阈值的平均阈值插件avg_block_io，和基于AI算法聚类计算阈值的AI阈值插件ai_block_io；两种插件均支持最多10个io阶段：blk-throttle、wbt、iocost、get_tag、plug、deadline、bfq、kyber、hctx、driver。 目前支持检测的硬盘类型有NVMe SSD，SATA SSD，SATA HDD。

磁盘寿命检测和健康监控插件 ​

磁盘寿命检测和监控插件，使用ipmitool工具，通过轮巡方式获取bmc上现有的所有磁盘告警，按照配置文件参数筛选需要的告警信息上报。在直通场景下，通过ipmi接口查询获取问题磁盘的盘符以及对应物理盘SN号，在raid场景下，通过相关的raid工具来获取磁盘盘符和物理盘SN号的对应关系，帮助快速预警硬盘问题。

仅支持鲲鹏平台，华为自研nvme盘，硬盘故障，温度过高，IO性能下降，寿命过低等问题，及时预警，保证系统可靠可用。

超算内存支持Zone粒度内存回收 ​

开启 Zone Reclaim 后，在直接回收前，新增了唤醒kswapd逻辑。在空闲内存不足时，同步唤醒kswapd，进行后台的内存异步回收，将空闲内存回收到 high 水线，避免频繁在缺页处理中进行内存回收，影响内存分配效率，提升了Zone Reclaim 特性的效率。

在一般的2P服务器架构中，每个计算节点包含多个DDR内存节点，单个内存节点配置为一定数量的内容。这种内存节点多但单节点内存容量有限的设计，在内存密集型应用场景下容易因单节点内存不足而触发OOM-killer机制，导致用户态进程被强制终止。 为缓解这一问题，通常建议启用Zone Reclaim机制。该机制能够在单节点内存不足时，优先回收本节点的文件页缓存（File Page Cache），而非跨节点占用难以回收的匿名页（Anonymous Page）。这种本地化回收策略可有效缓解单节点内存不足的情况，提升内存的局部性。 开启本特性后，通过异步的内存回收，避免的同步的内存回收开销，提升了内存申请的效率，从而提升性能。

oeAware采集、调优插件等功能增强 ​

oeAware是在openEuler上实现低负载采集感知调优的框架，目标是动态感知系统行为后智能使能系统的调优特性。传统调优特性都以独立运行且静态打开关闭为主，oeAware将调优拆分为采集、感知和调优三层，每层通过订阅方式关联，各层采用插件式开发尽可能复用。

oeAware的每个插件都是按oeAware 标准接口开发的动态库，包含若干个实例，每个实例可以是一个独立的采集、感知或调优功能集，每个实例包含若干个topic，其中 topic 主要用于提供采集或者感知的数据结果，这些数据结果可供其他插件或者外部应用进行调优或分析。

虚拟化 ​

虚拟化支持vKAE直通设备热迁移 ​

KAE是基于鲲鹏920新型号处理器提供的硬件加速解决方案，包括HPRE、SEC、ZIP设备，可用于加解密和压缩解压缩，能够显著降低处理器消耗，提高处理器效率。KAE直通热迁移是指虚拟机在配置KAE直通设备时，进行热迁移的能力，可以为KAE设备的使用提供更强的灵活性和业务不中断的保障。

smmu脏页跟踪是实现直通设备高效、可靠的热迁移的关键技术。在ARM架构中，通过纯软件方式进行脏页跟踪，会带来了较大的性能损耗。HTTU(Hardware Translation Table Udate)允许硬件自动更新smmu页表状态，在进行写操作时会自动置对应页表项的写权限位，热迁移时扫描页表的写权限位进行脏页统计。

为虚拟机中使用KAE直通设备的场景提供热迁移支持，适用于对数据安全性和处理性能有较高要求的领域，如金融、云计算和大数据处理等，有效增强业务连续性与运行稳定性。

VMAnalyzer：轻量级虚拟化性能监控组件 ​

VMAnalyzer是一款轻量级的虚拟化监测分析工具，围绕如下两个方面进行设计：

• 虚拟化环境监测：通过实时监测虚拟机的CPU、内存、磁盘I/O等关键性能指标，发现性能瓶颈。
• 高可靠性保障：通过分析虚拟机的qemu进程、物理环境配置等信息提供高可靠性的虚拟机维护方案，预测并发现潜在的故障风险。

VMAnalyzer包括监控中心、诊断中心两部分：

• 监控中心: 实时采集虚机的数据，能够细粒度的分析虚拟机的运行状况，检测结果的可灵活通过console、OPS、DW等多平台展示各个云主机数据。
• 诊断中心: 针对虚拟化层面的问题，通过执行命令对虚拟化层进行深度诊断，通过配置分析、状态分析，虚机进程消耗分析等，帮助用户分析虚拟化层面的各类问题，最终通过日志文件展示出来。

GIC超分优化 ​

GICv4.1特性，由于硬件多条VMOVP指令需要串行同步执行限制，在超分&范围绑核等vcpu频繁迁移场景会出现性能劣化； 然而，客户场景普遍存在超分场景使得算力最大化，GICv4.1作为一个虚拟化IO常用优化手段在超分场景下1:2场景下有性能劣化，导致客户在超分场景下不得不关闭GICv4.1，无法解决超分这一类IO场景虚拟化损耗的关键痛点。为了提升该场景性能，设计通过优化VMOVP指令数减少该性能瓶颈，进一步提升整体性能。 使用方式：新增/sys/module/kvm/parameters/enable_vmovp_elision参数控制该功能，如需使用，需设置该参数为Y。

在鲲鹏920新型号机型上，可以优化GICv4.1开启场景，虚拟机同亲和组内频繁核间迁移场景性能。

vTimer直通 ​

传统虚拟机timer中断需在中断到期时陷出，Hypervisor侧注入中断后再陷入Guest，针对timer定时时延敏感类业务可能存在较大影响。vTimer直通通过避免timer中断注入过程中的陷入/陷出操作，从而降低中断注入时延，提升场景性能。

在鲲鹏920新型号及之后机型上，GICv4.1开启场景，对GuestOS的timer时延有极致要求，可通过此技术极大的提升timer时延精度

支持树莓派 ​

Raspberry Pi（树莓派）是由 Raspberry Pi 基金会与 Broadcom 公司合作开发的一系列小型单板计算机。凭借其价格低、体积小、能耗低、高可编程性以及丰富的生态系统等特点，树莓派在工业自动化、机器人技术、物联网、教育以及业余爱好者项目等领域得到了广泛应用。树莓派 4B 和树莓派 5 作为树莓派产品线的经典代表，采用 ARM 架构的处理器。其中树莓派 4B 是极具性价比的普及型单板计算机，树莓派 5 凭借其显著的性能突破和扩展能力成为一款在高性能边缘计算领域颇具竞争力的创新产品。

作为开源硬件领域的一个较为高阶的硬件产品，树莓派 4B 和树莓派 5 支持 Raspberry Pi OS、Ubuntu、openEuler 等多种 Linux 发行版，外设丰富，具有较强的视频编解码能力，以及板载网络等功能，完全可以作为独立计算机系统使用。

海光架构特性增强 ​

HYGON CCP驱动支持SM4-XTS/GCM ​

本特性面向 Hygon CCP（Cryptographic Co-Processor）密码协处理器，升级其内核驱动以支持 SM4 算法的高级模式 SM4-XTS 和 SM4-GCM。SM4-XTS 为可调整密码本模式，适用于块设备加密、磁盘加密等场景，要求 32 字节密钥与 16 字节 IV；SM4-GCM 为带认证的计数器模式，支持 AAD（附加认证数据）与认证 Tag，可同时保障数据机密性与完整性。新增算法以 xts-sm4-ccp、gcm-sm4-ccp 形式注册到 Linux Kernel Crypto API，并保留 xts-sm4-cis 路径以支持 CIS 扩展。测试方面，通过内核模块 ccp_test.ko 直接调用 crypto_skcipher / crypto_aead API，同时基于 libkcapi 提供用户态 AF_ALG 接口测试，测试向量分别引用 GB/T 17964-2021（SM4-XTS）与 RFC 8998（SM4-GCM）。

fastblock分布式块存储 ​

fastblock 是一个专为高性能、极低延迟设计的开源分布式块存储系统。它旨在解决传统分布式存储（如 Ceph）在 NVMe SSD 硬件环境下 CPU 消耗大、单卷延迟高、可用性差等瓶颈。

• 极速 IO 路径：核心基于 SPDK（存储性能开发套件）编写，采用用户态 NVMe 驱动与无锁队列技术，规避了内核态切换，实现极致的单卷读写性能与超低延迟。
• 零拷贝网络：利用 RDMA 技术进行数据传输，支持内核旁路与零拷贝，网络通信无需 CPU 深度干预。
• 强一致性复制：采用 Multi-Raft 协议进行数据复制，既保证了数据的强一致性与高可靠性，又避免了传统主从同步复制在集群抖动时导致的 IO 阻塞。
• 高效元数据管理：利用 Go 语言与 etcd 实现轻量、易定制的 Monitor 集群，确保元数据视图在客户端和存储节点（OSD）之间高度一致。