企业官网建设流程全解析

大家读完觉得有帮助金蝶关注和点赞！！！

摘要。
现代 AI 和 HPC 系统在机架尺度上集成了加速器、高速网络和管理控制器。为此类基础设施开发软件通常需要访问稀缺且昂贵的硬件，而软件抽象可能会掩盖工作负载如何依赖于跨服务器和加速器的资源。本文介绍了 Cnuas，一个开源的实验性机架级仿真平台，其基线架构遵循开放计算项目（OCP）Open Rack v3 规范。通过功能仿真，它支持在学术和工业研发中进行实验、学习和软件开发，而非追求与物理硬件匹配的吞吐量或延迟。其基于 Web 的用户界面可视化机架、设备及其互连，帮助开发者构建支撑其工作负载的基础设施的系统级心智模型。

Cnuas 的核心是 CnuasNIC 和 CnuasSwitch，它们实现了一个客户机可见的远程直接内存访问（RDMA）适配器和一个同时支持 RoCEv2 和原生 InfiniBand 的宿主驻留混合软件交换机。该平台还提供了一个专用的 AI/ML 加速器（GPU）对等网络结构，以及基于 OpenBMC 的机架管理，并在 RS-485 上运行可执行的电源和电池备份固件。这些组件支持在商用主机上研究设备、驱动程序和固件接口。加速器软件栈仍处于早期研究原型阶段，使用 OpenUSD 进行设施建模是一项探索性扩展。本文介绍了架构、接口和有界原型结果，作为核心平台及其扩展的社区协作基础。

关键词： AI/HPC 基础设施仿真、Open Rack v3、OpenBMC、RDMA、加速器仿真、探索性设施建模、虚拟时间

1. 引言

AI 机架软件依赖于硬件特定的接口。设备驱动程序绑定到 PCI 功能；verbs 提供程序使用其队列和门铃布局。子网管理器配置网络结构；机架固件通过边带总线与电源架通信。这些路径通常在硬件安装后一起进行测试。这延迟了机架级软件集成，并限制了其用于持续集成的可用性。采购成本和交付周期进一步限制了对交换机、适配器和加速器的访问。共享设施提供的是按计划分配的资源，而非持续由研究人员控制的机器（Duplyakin 等，2019；Keahey 等，2020）。

Cnuas 旨在为学术和工业研发拓宽对机架级 AI/HPC 系统的访问。在此背景下，它支持实验、学习和软件开发。其目标是暴露和测试整个软件栈中的设备接口、协议和交互，而非重现物理硬件的吞吐量或延迟。本文评估了已实现的软件功能。

Cnuas 是对物理测试台和硬件辅助虚拟化的补充，而非作为性能等效的替代品。这一区别包括单根 I/O 虚拟化（SR-IOV）：支持的 NIC 和 GPU 暴露 PCI Express（PCIe）虚拟功能（VF），这些功能可以分配给虚拟机，或通过主机驱动程序作为 VF 支持的设备提供给容器工作负载。这些路径仍然依赖于物理设备；Cnuas 则提供已实现设备接口和协议的可修改软件模型。

采用 Open Rack v3（ORV3）架构（开放计算项目基金会，2022）的另一个动机是为开发者和工程师提供其工作负载所依赖的基础设施的具体心智模型。软件接口通常隐藏了计算刀片、加速器、网络适配器、交换机和共享电源设备的布局。Cnuas Web 界面将设备和连接置于可视化机架环境中；图 2 显示了底层参考部署。其目的是帮助用户将应用程序执行与设备放置、数据移动、通信路径和共享基础设施联系起来。这对于分布式 AI 和 HPC 工作负载尤其重要，因为其执行可能跨越多个加速器和服务器。因此，机架既作为仿真的架构基础，也作为理解所编程系统的参考。

现有仿真器主要支持性能和架构分析。周期级 GPU 仿真器为建模架构生成时序估计（Bakhoda 等，2009；Khairy 等，2020；Sun 等，2019）。网络仿真器在离散事件框架中重现协议行为和排队（Riley 和 Henderson，2010；Varga 和 Hornig，2008）；一些还将真实软件栈连接到仿真网络（ns-3 项目，n.d.）。Cnuas 则专注于跨越应用程序、提供程序库、内核驱动程序和仿真适配器的客户机可见设备边界。例如，ibv_rc_pingpong 通过 libibverbs 和绑定到枚举 PCI 设备的内核驱动程序运行。这保留了与物理适配器一起使用的软件层边界。

Cnuas1 为此目的使用功能设备仿真。每个面向客户机的适配器或加速器都是通过仿真 PCI 总线呈现给运行原生内核的客户机的模型，该客户机带有 Cnuas 驱动模块，其余为用户空间标准环境。因此，所研究的软件跨越与物理系统相同的应用程序、驱动程序和设备边界。仿真重现了编程接口和协议行为，但其本身并不重现物理时序；第 6 节描述了单独的分析时序模型及其局限性。Cnuas 可以演示什么是队列对、子网管理器如何启动网络结构、集合操作如何分解，以及内核如何访问加速器。已实现的能力和未完成的工作总结在表 1 中。

Cnuas 正在作为开源软件产品和可扩展研究框架进行开发。其范围超出了当前已实现和评估的能力。现有组件包括通过聚焦功能测试评估的研究原型；更广泛架构的很大一部分仍在开发中或已规划。加速器软件栈处于早期实验阶段。公开发布旨在支持核心平台及其扩展的协作开发。

机架级开发还依赖于管理、电源和冷却。一个早期设施建模原型探索将仿真的 OpenBMC 电源架遥测连接到 OpenUSD 场景（OpenUSD 联盟，2025）和简化负载计算。第 4 节描述了这一探索性扩展。

本文的贡献有三方面。

(1) 一个配对的 RDMA 设备和网络结构实现：CnuasNIC 呈现一个带有 Linux 驱动程序和标准 verbs 提供程序的客户机 PCI 适配器，而 CnuasSwitch 实现一个宿主驻留的混合软 RoCE 和软 InfiniBand 交换机。该配对在仿真系统内暴露了两条协议路径，使设备、驱动程序和交换机行为可用于联合开发，而非将 RDMA 代理到物理主机适配器。
(2) 一个基于 Open Rack v3 规范的垂直集成机架架构，呈现客户机可见的 RDMA 和加速器设备、独立的网络和加速器网络结构、真实的 OpenBMC 镜像、在 RS-485 多站总线上可执行的 PSU 和 BBU 固件。该架构还为探索性设施建模提供了集成点。
(3) 一个可复现的平台验证工作流，结合组件测试和固件演示，未满足的环境要求被报告为明确的关卡而非成功结果。

评估结合了命名的组件测试和记录的固件演示。这些确立了所测试的行为；更广泛的集成和应用适用性需要单独评估。未完成的测试和未实现的能力在全文中有标识。

表 1. 实验平台的实现状态和评估范围。

2. 相关系统与范围

2.1. 加速器仿真

GPGPU-Sim 建立了 GPU 工作负载的详细仿真，并且仍然是微架构研究的参考点（Bakhoda 等，2009）。Accel-Sim 通过经过验证的框架和更广泛的前端支持扩展了该方法（Khairy 等，2020）。MGPUSim 解决了多加速器系统及其之间的互连问题（Sun 等，2019），Multi2Sim 对组合的 CPU 和 GPU 执行进行建模（Ubal 等，2012）。这些工具使用跟踪或仿真指令流来回答有关性能和架构的问题。Cnuas 优先考虑客户机设备和驱动程序接口，而非周期精确的微架构时序。

MIAOW 是加速器模块级别最接近的开放 RTL 先例。它用 RTL 实现了一个 AMD Southern Islands GPGPU，用于低级架构实验和 OpenCL 兼容性（Balasubramanian 等，2015）。MIAOW 和 Cnuas 暴露不同的实验表面：前者是开放 GPU RTL，后者是集成的软件仿真机架平台。

2.2. 全系统仿真与模拟

gem5 提供全系统仿真，包括设备和操作系统启动（Binkert 等，2011），FireSim 使用云中的 FPGA 加速周期精确的横向扩展仿真（Karandikar 等，2018）。两者都提供了 Cnuas 不尝试的保真度，代价是墙钟时间，对于 FireSim 而言还有基础设施成本。QEMU 提供了 Cnuas 所构建的机器仿真（Bellard，2005），Renode 提供了用于管理平面外设的嵌入式仿真（Antmicro，n.d.）。Cnuas 贡献的是设备模型而非新的仿真器。该设计目标是在工作站上交互式执行集成机架软件栈；当前评估在第 7 节中描述。

2.3. 共享测试台

Emulab 开创了可配置网络实验（White 等，2002），CloudLab 和 Chameleon 为研究社区提供裸机、可重构资源（Duplyakin 等，2019；Keahey 等，2020）。这些支持物理测量，但提供的是分配式而非持续由研究人员控制的访问。Cnuas 支持本地控制的接口和集成工作；物理测试台对于硬件测量仍然是必要的。

除了可用性之外还有第二个区别。访问物理 AI 或 HPC 测试台通常允许在其已安装加速器暴露的接口之上进行实验；它不会给用户提供专有加速器 RTL、内部固件、数学模块或网络结构逻辑的可修改实现。Cnuas 以物理保真度换取垂直开放的研究表面，其中变更可以跨越设备模型、指令集、编译器、内核驱动程序、运行时、库、网络结构和机架管理，设施建模作为探索性扩展。这为固定集群无法提供的跨层协同设计问题提供了基础，而物理测试台对于时序、功耗、可制造性和兼容性测量仍然是必要的。

2.4. 软件 RDMA 和网络结构仿真

Linux SoftRoCE 驱动程序在普通以太网接口上以软件方式实现 RoCE 传输（Linux RDMA 项目，2016），SoftiWARP 对 iWARP 也是如此（Metzler 等，2010）。两者都使 verbs 编程无需 RDMA 适配器即可实现。它们在主机内核中终止传输，而非在仿真 PCI 适配器中，并且它们本身不建模交换机或网络结构。主机传输机制，包括 SoftiWARP 的 TCP 拥塞控制，与交换机级转发和网络结构管理不同。CnuasNIC 是 PCI 功能背后的仿真适配器，具有自己的内核驱动程序和 verbs 提供程序。其与 CnuasSwitch 的连接暴露了转发表、子网管理和管理数据报，以供修改和研究。

QEMU 的 pvrdma 是在 PCI 功能背后呈现 RDMA 的接近先例。它实现了 VMware 的半虚拟化 RDMA 接口，注册基址寄存器和 MSI-X 向量，并在客户机中绑定树内 vmw_pvrdma 驱动程序（QEMU 项目，2024）。它将传输代理到主机：QEMU 的文档将其描述为“像客户机驱动程序和主机 ibdevice 接口之间的代理”，将每个客户机队列对和完成队列映射到从主机 RDMA 设备请求的资源，该设备本身可以是 SoftRoCE。该设备模型未实现网络结构或交换机；InfiniBand 管理流量需要外部多路复用器，该设备在 QEMU 8.2 中被弃用，并在 9.1 中被移除。Cnuas 在仿真设备内部终止传输，并通过仿真网络结构承载它，因此所研究的协议行为属于模型而非其下的主机栈。

2.5. 集群的单机仿真

Phantora 通过拦截加速器和集合库调用来研究单机上的分布式训练（Qin 等，2026）。它将这些调用以下的行为替换为用于机器学习系统性能估计的模型。Cnuas 则保留其仿真设备边界之上的驱动程序、提供程序、运行时和应用程序。其当前时序模型产生分析估计，而非物理系统性能的经过验证的预测。因此，Phantora 解决训练时间估计问题，而 Cnuas 强调设备接口和跨层集成行为。

2.6. 集合通信和编程模型

加速器软件栈遵循 CUDA（Nickolls 等，2008）建立的形态，以及 NCCL 等集合库（NVIDIA，n.d.-a）和 OpenSHMEM 中标准化的分区全局地址空间消息传递（Chapman 等，2010）。ASTRA-sim 对仿真平台上的分布式训练进行建模，是集合层意图上最接近的工作（Rashidi 等，2020）。Cnuas 还提供了一个可调用的集合库，其有效载荷穿越其对等网络结构。

2.7. 设施建模

仓库规模计算确立了将数据中心作为一台机器来推理的学科，包括其电源和冷却（Barroso 等，2018），电源使用效率是标准效率指标（ISO/IEC，2026）。设施数字孪生是行业和研究中的既定实践，OpenDT 是最近的一个例子，它结合实时遥测和仿真来研究数据中心性能和可持续性（Nicolae 等，2026）。此类孪生通常由来自物理站点的跟踪或遥测驱动。Cnuas 探索使用仿真的机架固件遥测作为园区场景的输入。这个早期原型未作为本文献中研究的经过验证的设施孪生的替代品进行评估。

2.8. 差距

先前的工作在各个层面提供了成熟或专门的产物，而这些层面通常被分开研究。本文综述的文献表明，这些系统主要在建模边界的位置和所解决的研究问题方面存在差异，如表 2 所总结。在本综述中未发现任何先前的系统集成了客户机可见的加速器和 RDMA 设备、独立的网络和加速器网络结构、可执行的 Open Rack v3 管理和电源架固件，以及通向设施建模的可扩展路径。Cnuas 研究这种组合，其仿真边界位于普通客户机软件之下、建模设备之上。其贡献是实验性机架级产品、其集成接口和有界原型结果。

表 2. 与代表性系统的范围比较。“物理”意味着结果来自分配的硬件而非时序模型。

3. 系统架构

图 1. 实验性 Cnuas 架构及其仿真接缝。接缝之上的普通软件测试其下的建模平台。加速器栈处于早期阶段，设施扩展为探索性。代表性替代边界对应于表 2 中比较的系统。

3.1. 部署模型

图 1 显示了架构和集成接口，而非其组件的一致成熟度。参考部署如图 2 所示，遵循开放计算项目 Open Rack v3 布局（开放计算项目基金会，2022）。设备高度以 Open Rack 单位（OU）表示。每个机架容纳两个 1-OU 架顶交换机、一个运行守护进程的管理主机和八个 2-OU 刀片作为计算节点。每个刀片是一个客户机虚拟机，具有一个仿真 RDMA 适配器和一个或多个仿真加速器。当前树中建模了两个机架，通过机架间网络结构链路连接。

主机要求是 x86-64 机器，具有 AVX2、最低 16 GB 内存（推荐 64 GB）和启用 KVM。AVX-512 在存在时用于加速器计算后端。这些要求适用于 KVM 加速的 x86-64 机架部署；其他主机架构尚未验证。

图 2. Cnuas 参考部署，基于开放计算项目 Open Rack v3 建模的两个机架。每个机架承载两个 1-OU 架顶交换机，一个用于 RoCE 和 InfiniBand 网络结构，一个用于加速器网络结构，一个管理主机和八个 2-OU 刀片。每个刀片是一个具有仿真 RDMA 适配器和一个或多个仿真加速器的客户机；当前评估的范围在第 7 节中描述。

3.2. 平台组件族

表 3. 平台组件族和角色。实现和成熟度见表 1。

前四个族实现下面描述的计算和通信数据平面。CnuasBMC 解决机架管理（第 5 节）；早期设施扩展在第 4 节中单独讨论。

3.2.1. CnuasNIC

CnuasNIC 是一个功能性的软件仿真 RDMA 网络适配器，与 CnuasSwitch 网络结构同时支持 RoCEv2 和原生 InfiniBand。cnuas-vnic QEMU PCIe 设备向两个客户机 Linux 模块暴露内存映射控制寄存器和中断：cnuas_net 提供网络设备接口，cnuas_ib 注册 RDMA 设备。提供程序实现 rdma-core verbs 应用程序二进制接口（ABI），允许应用程序通过 Linux ib_uverbs 接口使用标准 libibverbs 调用。

已实现的操作包括发送和接收、RDMA 读取和写入，以及原子比较交换和取加。适配器支持可靠连接（RC）和不可靠数据报（UD）队列对、共享接收队列和 InfiniBand 多播。多包传输遵循协商的路径最大传输单元。不变循环冗余校验（ICRC）在传输时计算，在接收时验证。管理队列对 QP0 和 QP1 支持子网管理和通用服务，包括管理数据报处理和子网管理代理。内存注册涵盖主机内存和用于对等内存集成的实验性 DMA-BUF 导入接口。

RoCEv2 通过 UDP/IPv4 和以太网承载 RDMA 数据包，使用 UDP 目标端口 4791。原生 InfiniBand 路径则承载本地路由头（LRH）、基础传输头（BTH）和 InfiniBand 操作码，保留自己的寻址和管理行为，无需以太网/IP 封装。这些是适配器中的两条协议路径，而非同一以太网传输的替代标签。

当前 CnuasNIC 端点需要客户机中的仿真 PCI 功能。在 rdma-core 源代码树之外构建其提供程序不会消除内核驱动程序依赖。其贡献是连接到仿真交换机的可修改设备、驱动程序和提供程序路径；记录的集成覆盖范围和剩余客户机环境关卡在第 7 节中区分。

3.2.2. CnuasSwitch

CnuasSwitch 是一个混合软 RoCE 和软 InfiniBand RDMA 交换机。其 cnuas-vswitchd 守护进程直接在主机上运行，呈现十个逻辑端口：八个网络结构端口、一个以太网上行链路和一个控制台/可观测性端口。一个守护进程服务于两个链路层，每个网络结构端口可选择仅以太网、仅 InfiniBand 或自动分类。

以太网路径在 IEEE 802.3 以太网系列中建模 MAC 帧转发（IEEE 802.3 工作组，n.d.），包括 VLAN 感知的源地址学习和转发数据库（FDB）中的目标查找。它承载普通以太网流量以及 RoCEv2 数据包。原生 InfiniBand 管道使用目标本地标识符和线性转发表（LFT）转发 LRH/BTH 帧，保留单独的寻址和管理路径。

为以太网路径建模了选定的数据中心桥接（DCB）机制：基于优先级的流控暂停处理（PFC，IEEE 802.1Qbb）（IEEE 802.1 工作组，n.d.-a）和增强传输选择（ETS，IEEE 802.1Qaz）的配置（IEEE 802.1 工作组，n.d.-b）。ETS 流量类别映射和带宽设置通过管理暴露；带宽强制调度仍是开发工作。IPv4 显式拥塞通知（ECN）标记遵循 IETF RFC 3168 的字段语义（Ramakrishnan 等，2001）；ECN 与 IEEE DCB 修正案不同。这些模型涵盖这些选定的协议机制，而非完整的 IEEE 一致性或物理链路行为。

集成子网管理器和子网管理代理支持子网扫描、定向路由管理数据包、本地标识符分配和路由表编程。这在没有单独 OpenSM 进程的情况下启动建模的 InfiniBand 网络结构。JSON 管理接口暴露端口、转发、流控和子网管理器状态，并具有可观测性遥测。

网络结构端口使用 UNIX 域 SOCK_SEQPACKET 套接字。因此，实现端口帧格式的 QEMU 设备和主机进程可以连接到同一交换机。仅主机客户端支持协议和转发实验，无需虚拟机；它们本身不暴露 Linux verbs 设备。与 CnuasNIC 一起，这将宿主驻留的网络结构开发与客户机设备/驱动程序集成分开，同时保留 RoCEv2 和原生 InfiniBand 路径。

3.2.3. CnuasGPU

CnuasGPU 提供机架的实验性加速器组件。它呈现一个具有设备内存的软件仿真 PCI 设备。在客户机中，Linux 驱动程序暴露一个字符设备 /dev/cnuasgpuN，其中 N 是设备索引。CnuasDev 提供设备访问接口，CnuasRT 提供其上的应用程序运行时。其加速器对等连接使用 CnuasLink，与 CnuasNIC 网络路径分开。独立 Soft-GPU 模式在主机 CPU 上保留这些应用程序接口，无需 QEMU 或客户机。cnuasgpu_host 内核模块暴露 /dev/cnuasgpu_hostN，由内核拥有的主机内存支持，供需要 Linux 设备节点的应用程序使用。进程内模式则使用调用进程中的 arena，既不需要内核模块也不需要设备节点。默认发现优先选择客户机 PCI 设备，然后是主机字符设备，最后是进程内模式。

实验性 FPGA 设计工作正在进行中；RTL 实现已规划。单独的 CnuasGPU 论文计划描述其架构、软件栈、数值验证和性能评估。

计算 Express Link（CXL）集成计划先于 UALink。CXL 规定了处理器、内存和加速器之间的缓存一致性连接（计算 Express Link 联盟，n.d.）。计划的 Cnuas 工作解决主机/设备内存互连实验，从选择规范修订版和设备配置文件、评估 QEMU 和 Linux 支持以及可复现的验证路径开始。

UALink 仍然是较晚的加速器到加速器连接。这一顺序是开发优先级；两种互连服务于不同角色。两者仍然是计划中的扩展。PCIe 提供现有的客户机设备连接，而 CnuasLink 承载当前建模的加速器对等流量。

图 3. 主机和客户机数据路径。应用程序跨越普通用户空间、内核驱动程序和仿真设备边界。RoCEv2 和 InfiniBand 流量使用 CnuasSwitch，而加速器对等流量使用独立的 CnuasLink 网络结构。

3.2.4. CnuasLink

加速器到加速器流量使用单独的网络结构，具有自己的交换机守护进程、帧格式、转发数据库和发现协议，建模多加速器节点的对等互连，而非重用网络结构。将两个网络结构分开反映了此类系统的实际构建方式，并允许其控制平面和数据平面独立更改。

3.3. 控制平面

一个命令表面驱动交换机网络结构、加速器网络结构、加速器、适配器和客户机生命周期，并且同一服务层作为 REST 接口暴露用于自动化。组件守护进程通过 UNIX 套接字上的 JSON 访问。这种统一性避免了不相关组件工具的集合，并为自动化提供了一个控制表面。

基于 Web 的前端通过机架和交换机机箱视图补充这些编程接口。它显示设备放置、机架间链路和交换机端口状态，为用户提供检查建模系统的可视化上下文。

4. 超大规模数据中心的探索性设施建模

使用 OpenUSD（OpenUSD 联盟，2025）和 NVIDIA Isaac Sim（NVIDIA，n.d.-b）进行设施建模是一个早期探索性方向。最初的 Cnuas 设施孪生原型研究场景生成、简化负载计算和到仿真机架遥测的连接。

该原型以声明方式描述园区，从建筑和数据大厅到机架行、支持室、工厂和景观区域。它生成 OpenUSD 几何体用于在 Isaac Sim 中探索。图 4 说明了这一场景生成工作。

图 4. 探索性设施原型的示意性园区布局。设备放置和工厂表示是临时的。

负载算术对配置的机架额定值求和，并应用假设的电源使用效率（PUE）乘数。PUE 在形式上是共同测量周期内的能量比（ISO/IEC，2026）；此处将其用作功率乘数是简化的场景假设。热负荷和工厂数量计算同样使用简化假设。

一个实验性桥接读取仿真 Open Rack v3 电源架通过 Modbus RTU，并将 PSU 测量值和 BBU 状态写入 OpenUSD 属性和时间样本。这探索了固件与场景之间的连接。

大量场景特定验证仍然是必要的。这包括检查几何体和设备假设、将电气和热行为与适当的参考数据进行比较、测试遥测时序和故障条件，以及在保留场景上评估校准模型。现有软件测试检查指定的算术、配置处理、场景结构和遥测处理。工程或操作使用需要超出当前工作的物理和场景验证。早期原型将可用于研究和社区开发，发布后继续进一步开发和验证。

5. CnuasBMC 机架和平台管理

机架管理将计算节点连接到 Open Rack v3 的电源架构和边带总线（开放计算项目基金会，2022）。CnuasBMC 重现这些接口，以便电源控制和遥测工作流可以与仿真机架的其余部分一起测试。

5.1. OpenBMC 移植

CnuasBMC 是 Cnuas OpenBMC 移植（OpenBMC 项目，n.d.）。其 meta-cnuas Yocto 层定义了三种机器：sled、架顶交换机和机架管理控制器。每种都有 Cnuas 设备树和品牌固件镜像。镜像在仿真 ASPEED AST2600 上启动真实的 Linux 内核和引导加载程序。用户空间是 OpenBMC 而非替代品：传感器在 D-Bus 上发布并通过 bmcweb 在 Redfish 上提供，库存来自 Entity Manager，主机电源通过正常电源控制服务，受管控制台使用 Serial over LAN，IPMI 通过网络应答。Redfish 和 IPMI 电源请求驱动 GPIO 转换，控制单独的 QEMU 刀片，并接收电源良好和 POST 状态作为回报。

5.2. RS-485 多站电源架总线

仿真 RS-485 段保留共享总线拓扑：一个主站寻址多个外围节点，每个节点接收每个请求，只有被寻址的节点回复。Cnuas Renode 插件建模该共享线路，并向 AST2600 UART 暴露一个 TCP 主站端点。电源外设在 Renode 中作为 Cortex-M 机器运行（Antmicro，n.d.），而 QEMU 运行 OpenBMC。这种分离保留了 QEMU 串行字符设备单独无法表达的多站拓扑。

仿真电源架包含六个 PSU 固件实例，地址为 0xC0 到 0xC5，以及六个 BBU 固件实例，地址为 0x40 到 0x45。一个便携式固件镜像使用 straps 为十二个 Cortex-M 实例中的每一个选择角色、槽位和地址。它们以 19,200 波特率使用 Meta rackmon 的寄存器映射（Meta Platforms，2026）进行 Modbus RTU 通信。帧格式、CRC-16、地址过滤、保持寄存器读取、保护写入、异常响应、PSU 负载行为、市电丢失、电池放电和故障状态都在被寻址节点上的固件中执行。

cnuas-rackmond 主站扫描十二个节点，将寄存器转换为工程单位，并发布 56 个 D-Bus 传感器对象，用于功率、电压、电流、温度、风扇转速和电池充电状态。bmcweb 通过未修改的 Redfish 机箱传感器集合提供这些对象。第 4 节中的探索性桥接可以消费源自响应 Modbus 请求的固件的测量值。这种来源将数据与仅显示值区分开来。物理精度和设施场景验证仍然是单独的研究要求。

图 5. 机架管理接口和探索性设施遥测路径。仿真 PSU 和 BBU 读数通过正常 OpenBMC 传感器服务；场景连接是早期原型。

6. 虚拟时间和校准模型

时序分析是补充性研究能力，与 Cnuas 作为学术和工业研发功能平台的主要角色分开。功能仿真重现接口和协议行为。物理性能模型则估计时序。主机墙钟时间不能在两者之间提供可靠的映射：动态翻译、主机调度、加速模式和开发机器上的工作负载都会影响它。QEMU 指令计数提供确定性客户机时钟（Bellard，2005；QEMU 项目，n.d.），但指令计数不能说明 PCIe、DMA、设备队列、加速器内存、网络结构跳、中断或争用需要多长时间。

Cnuas 包含 Cnuas 校准虚拟时间和性能模型。版本化配置文件为每个组件提供固定成本和其消耗资源的速率：指令、周期、字节、数据包和操作。资源可以重叠，在这种情况下，瓶颈项设定动态服务时间，或者串行执行。整数皮秒离散事件调度器将工作分配给稳定的组件通道，并记录提交、排队、开始和完成时间。重复输入产生相同的事件跟踪。初始配置文件涵盖客户机 CPU、PCIe、CnuasNIC、CnuasSwitch、CnuasGPU 计算和内存、CnuasLink、CnuasBMC RS-485 段和探索性设施更新节奏。

对于重叠资源，未校准的服务时间遵循资源瓶颈或 roofline 风格模型（Williams 等，2009）：

(1) t_a = t_0 + max(I/R_I, C/f, 8B/R_B, P/R_P, O/R_O).

这里 t_0 是固定延迟；I、C、B、P 和 O 分别是指令、周期、字节、数据包和操作计数。速率 R_I、f、R_B、R_P 和 R_O 分别以指令/秒、周期/秒、比特/秒、数据包/秒和操作/秒为单位；因子八将字节转换为比特。使用最大值是因为重叠资源在其最慢的必需资源完成时完成。对于配置为串行的资源，调度器改为相加其服务时间。然后目标特定校准使用普通最小二乘法将仿射校正

(2) t_p = max(0, α t_a + β)

拟合到训练测量值，其中 α 是比例因子，β 是常数偏移，外部最大值防止负预测持续时间。单独的验证操作报告保留观测值上的平均绝对误差、均方根误差、平均绝对百分比误差和最大绝对误差。目标名称和拟合系数成为组件配置文件的一部分。此设计遵循性能模型应经过验证而非假设的一般要求（Khairy 等，2020；Karandikar 等，2018），同时将一个事件模型扩展到网络、加速器、管理和设施领域。

该实现有 46 个自动化案例，涵盖单位转换、串行和重叠资源、队列争用、并行通道、确定性重放、严格配置文件加载、QEMU icount 映射、拟合和保留误差。这些案例涵盖所列模型行为，而非物理目标的预测精度。不由协议固定的出厂值被标记为建模假设。未提供物理校准数据集，因此未报告测量的预测误差。当前实现离线评估显式管道，发出确定性 QEMU TCG 和 icount 配置，并映射提供的指令计数。它不同步 QEMU、Renode 和主机交换机守护进程的实时时钟。因此，诸如每秒十个虚拟数据包到每秒一个物理数据包的固定转换不可移植，也不受当前结果支持。

7. 评估

7.1. 方法论

评估使用验证矩阵将每个组件与其测试覆盖和记录结果相关联。通过的测试仅确立在其记录配置下所测试的行为。

需要不可用设备或环境的测试报告为跳过，并记录缺失的要求。它们不计为通过。

7.2. 结果

表 4 总结了从单工作站上记录运行中选择的平台相关套件。自动化测试运行器记录主机和工具版本、确切命令、退出代码、持续时间、原始日志、JUnit 记录和不可用环境要求。它从这些记录生成 CSV、Markdown 和 LaTeX 摘要，并包含 SHA-256 校验和用于文件完整性验证。

Python 套件涵盖控制平面、工具、设施原型、校准虚拟时间模型、交换机数据平面和端到端 RDMA 路径。CnuasBMC 为其 Open Rack v3、机架控制器和前面板固件添加原生主机检查。

表 4. 记录的平台测试结果。需要不可用设备、客户机或实验室设置的案例报告为跳过。

设施案例检查原型内的软件行为；它们不是物理或场景验证。

测试计数来自 JUnit 测试用例记录或原生测试程序发出的总数。仅构建检查通过其命令、退出状态和日志报告，无测试用例计数。完整的双节点 RDMA 测试需要客户机环境，未在此主机运行中执行。运行清单记录其先决条件和复现命令。

7.3. 实验室测试台规格

实验室测试台包括两台 Lenovo ThinkStation P520 工作站。每台工作站具有 Intel Xeon W-2133 CPU，主频 3.60 GHz，六个物理核心和十二个硬件线程，128 GB DDR4 内存和 1 TB SSD。每个 CPU 核心具有 32 KiB L1 数据缓存、32 KiB L1 指令缓存和 1 MiB L2 缓存，每台工作站的聚合 L1 数据、L1 指令和 L2 容量分别为 192 KiB、192 KiB 和 6 MiB。共享 L3 缓存报告为 8.3 MiB。处理器支持 AVX-512F、AVX-512DQ、AVX-512CD、AVX-512BW 和 AVX-512VL。

每台工作站配备一个 Mellanox MCX354A-FCCT ConnectX-3 Pro 适配器，位于 PCIe x8 接口上。该适配器提供两个 QSFP 端口，支持 FDR InfiniBand 和 40 千兆以太网。

8. 局限性

表 1 总结了组件级局限性。以下局限性支配结果的解释。

研究成熟度。 Cnuas 是一个实验性软件产品。加速器栈处于早期阶段；更广泛平台的大量开发仍在进行中或已规划。一般可靠性、可用性和生产就绪需要更广泛的评估。

物理性能预测。 第 6 节展示了确定性虚拟时间、排队语义、版本化配置文件、校准拟合和保留误差计算。提供的配置文件未拟合到命名物理目标的测量值。因此其持续时间是分析估计。物理目标预测精度仍有待评估。

可执行规模。 仓库的参考拓扑定义了两个机架，每个机架八个刀片槽。当前记录的主机测量启动一个刀片，主机测试运行不包括完整的双节点 RDMA 执行。所有十六个刀片的并发执行仍有待演示。

设施建模。 设施扩展是探索性原型。场景特定参考比较、校准和故障研究仍然是评估物理精度和工程适用性所必需的。

高级 InfiniBand 管理。 集成子网管理器分配本地标识符并编程已实现的网络结构路由。子网管理 PathRecord 响应、perfquery 的性能管理代理支持以及与外部 OpenSM 实例的互操作性不在当前验证表面内。

9. 结论

本文介绍 Cnuas 作为机架级 AI/HPC 仿真的实验性贡献：一个正在开发中的开源软件产品，具有可扩展架构、明确接口和有界原型结果。现有的设备、网络结构和机架管理实现为进一步工作提供了基础。主要目标是为学术和工业研发提供对 AI/HPC 软件栈的可访问功能实验，而非与硬件执行速度对等。加速器软件栈仍处于早期阶段，设施建模是探索性扩展。

CnuasNIC 和 CnuasSwitch 是这一贡献的核心：它们将双 RoCEv2/原生 InfiniBand 适配器和混合软件交换机置于一个可修改的机架环境中，同时保留应用程序使用的 Linux 设备、驱动程序和 verbs 接口。

预期的开发模式是协作式的，允许社区在公开发布后对 Cnuas 核心、加速器栈和扩展做出贡献。早期设施原型将本着这种精神提供。进一步工作包括全机架功能集成、主机资源使用表征和更广泛的可靠性测试。

计划中的组件特定后续论文将更深入地描述该架构的四个部分：CnuasSwitch 及其 RoCEv2 和原生 InfiniBand 数据路径；CnuasGPU 及其加速器架构和软件栈，包括计划的 CXL 和后续 UALink 集成；CnuasNIC 及其 RDMA、InfiniBand 和 RoCEv2 设备、驱动程序和提供程序实现；以及 CnuasLink 作为单独的加速器对等网络结构。

计划的通信软件工作包括评估和集成 Berkeley 的 UCCL（UC Berkeley Sky Computing Lab，n.d.）到 Cnuas 的仿真 RDMA 接口上，从传输兼容性和有界传输及集合正确性实验开始。UCCL 支持仍然是未来集成目标，与现有 CnuasCCL 库不同。