数字孪生：系统模型、联合仿真与运行闭环

AI Factory 的运行状态同时存在于计算图、网络拓扑、电气回路和冷却回路中。一次加速器扩容会改变作业放置、通信路径、机柜功率和水路负荷；一次泵维护也可能反向改变可分配的计算容量。数字孪生把这些变化放到同一组可关联的模型中，支持设计比较、变更预演和运行优化。

OCP 的数字孪生框架强调行为模型、持续同步和全生命周期的数据联系；AI Fabric 的建模框架则提供设备、端口、链路与工作负载的机器可读描述。把两者结合，才能从“资产在哪里”推进到“这项变更会产生什么后果”。S070 pp. 12–16 S044 pp. 45–55

从资产描述到行为模型#

一个可用于工程决策的模型，需要同时表达对象、关系和行为。对象包括加速器、交换机、机柜、母排、CDU 和传感器；关系包括物理包含、端口连接、供电归属和冷却服务范围；行为则描述负载变化时的通信耗时、功率、流量和温度响应。配置与遥测把当前系统状态投射到模型，仿真器在此基础上评价候选变化。

这里存在三类相互补充的工程资产。BIM 提供建筑和设备的几何与工程信息，DCIM 提供资产及运行数据，行为模型补上物理过程、逻辑依赖和运行响应。空间可视化适合定位设备、检查安装路径和沟通维护范围；拓扑图适合追踪端口、供电路径和故障影响；时间序列与仿真曲线适合分析暂态响应。显示形式随工程任务选择。S070 pp. 12–15, 37–38

设计阶段的数字孪生原型称为 DTP（Digital Twin Prototype），用于比较尚未建成的方案；运行阶段与真实设备绑定的实例称为 DTI（Digital Twin Instance）。贯穿设计、建设、运行、改造和退役的数据联系称为 Digital Thread。设备型号、端口映射、设计容量和验收结果沿着这条链保留下来，运行阶段的异常才能追溯到原来的设计意图。S070 pp. 13, 16–20

统一坐标：设备、连接、工作负载与设施#

InfraGraph 将基础设施表达为图。节点可以是设备，也可以是设备内部组件；复杂设备通过嵌套子图展开。Link 定义连接类型及其属性，Edge 绑定两个实际端点，Path 表达一串设备内和设备间的连接。带宽、时延、功率、成本和可靠性等信息可通过注释挂在同一结构上。S044 pp. 46–50

例如，一个八加速器服务器可以先定义 GPU、CPU、NIC 和内存组件，再实例化具体服务器，最后连接 NIC 端口与交换机端口。这样一条“GPU 到另一台 GPU”的路径，既能回到真实物理端口，也能关联路径带宽、共享上联和故障归属。模型按组件模板复用，设备实例和连接关系则保留项目特有的实际坐标。

工作负载需要另一张图。计算、内存访问与 Collective 操作构成节点，依赖关系构成有向边；每个节点携带运算量、数据大小或通信参与者。Chakra 一类执行轨迹可表达这种信息。硬件图说明资源在哪里、怎样相连，工作负载图说明何时需要哪些资源，映射引擎把两者结合，评估端到端完成时间及资源约束。S044 pp. 52–55

设施模型再补入供电和冷却关系。一个作业分配到若干机柜后，电气模型获得负载输入，热模型获得发热输入，水力模型获得流量需求；它们反馈可持续功率、温度和冗余条件。OCP Open Data Center 倡议把电、热和机械遥测纳入共同运行视野，特别指出 CDU 和 LVDC 配电等设备处在 IT 与设施之间，是跨域模型的重要连接对象。S051 pp. 9–10

表中是对上述白皮书内容的跨域组织；具体项目可从单一高价值子系统开始，逐步增加模型接口。

联合仿真的核心是时间与因果#

网络、配电和冷却具有不同时间尺度。通信仿真可能关注包和事件顺序，电气模型关注电压与功率变化，热流体模型关注温度与流量的连续演化。联合仿真（Co-simulation）让各专用仿真器在约定的同步点交换变量，由上层编排推进整个场景。S070 p. 30

接口必须写清输入、输出、单位、时间戳和采样含义。例如，计算模型交给电气模型的是瞬时功率还是某个窗口的平均功率？热模型接收到的是芯片发热、冷板吸热还是设施总负荷？如果这些量的坐标不同，单个仿真器内部计算再精确，组合结果也会失真。

闭环还会引入反馈。负载增加推高温度，热管理调整泵速或风扇速度，辅助设备功率随之改变；系统可能因此调整作业功率或放置。联合仿真需要协调步长和交换顺序，处理连续系统与离散事件的衔接。白皮书特别列出同步、因果、时间步长和回滚问题：若某个关键变化快于交换步长，模型可能漏掉短时事件；乐观推进的离散仿真遇到迟到事件时，则需要回滚重算。S070 pp. 30–31

FMI（Functional Mock-up Interface）面向模型交换和联合仿真；USD 面向三维场景组织；SysML 面向系统结构、行为与需求追踪；STEP 面向工程产品信息交换。它们在不同层提供接口。一个工程平台可以组合使用这些标准，让几何、资产语义和行为模型沿各自适合的接口交换。S070 pp. 27–29, 37–38

从同步、分析到自主运行#

OCP 给出 Level 0 基线和 Level 1–5 能力层级。读原图时，重点看每层新增的决策能力：第一层让状态可见，第二层进行分析，第三层支持情景仿真，第四层提出主动建议，第五层执行自主优化。

以冷却系统为例，Level 1 展示温度与气流，Level 2 分析冷却使用情况，Level 3 模拟新增硬件后的热影响，Level 4 根据天气和实时负载建议调整设定值，Level 5 自主调整冷却输出和风扇。配电和资产管理也可使用同样的能力递进：先获得可信状态，再形成预测，继而评价动作，最后接入控制。S070 pp. 34–36

实施时按子系统分别确定目标能力更有价值。一个机房可能已经具备冷却情景仿真，同时仍以人工方式维护网络拓扑。联合仿真、数据互操作和三维显示是可以横向增强多个层级的能力，建设顺序取决于目标决策需要什么数据和模型。S070 pp. 35–38

设计选型：让候选方案进入同一评价回路#

白皮书中的南洋理工大学案例，将生成式 AI 与物理仿真协作起来：生成式组件解释目标并生成设备与布局的语义配置，物理模型评价候选方案，评价较好的候选再反馈给生成过程。这个流程把自然语言目标、设备关系和可计算评价连接起来。S070 p. 21

阅读原案例时看三个环节：输入同时包含计算性能和能效目标；生成结果需要形成物理仿真可以消费的配置；反馈来自候选方案的评价结果。案例报告经过五轮迭代，PUE 从 1.35 优化至 1.25，属于该设计研究的结果。

若把这一回路用于 Fabric 选型，候选配置可以替换为拓扑、设备放置和通信参数，评价输出则使用作业完成时间、关键通信等待与故障后可用容量。AI Fabrics 白皮书讨论了仿真搜索、学习预测和两者组合的映射路径：先用领域规则收缩搜索空间，再在域内细化，运行阶段还可根据遥测调整映射。S044 pp. 53–55

从变更预演到运行控制#

设计阶段可以容忍较长的方案比较时间，运行决策则受动作时限约束。将一台 Spine 下线、增加一批服务器或调整光交换拓扑，都需要在允许时间内完成影响评估。AI Fabrics 白皮书提出把 InfraGraph 与集群编排结合，在提交动作前进行在线仿真，评价配置、作业放置和维护影响。S044 pp. 50–51

工程实现可以围绕一条清晰的数据链组织：真实配置与遥测 → 当前模型 → 候选变更 → 仿真评价 → 决策审批或自动执行 → 运行反馈。每次评价保存模型版本、工作负载条件、目标函数和结果；执行后再对照实际变化，积累可复用的验证记录。这条流程是对两份白皮书的工程综合。

模型可信度在这里决定可授权的动作范围。首先校验传感器和配置数据，再用实际测量校准模型，随后用独立场景检验预测能力。对故障切换和超出历史负载的情景，保留足够的安全裕度与回退措施。涉及物理控制时，还需要保护遥测完整性和控制接口；白皮书将伪造数据导致错误动作、双向控制扩大攻击面列为重要风险。S070 pp. 30–32

数字孪生的交付物#

技术规划可以把建设对象拆成四组可验收的工程资产。第一组是结构与身份：设备模型、端口和支路关系、唯一标识、配置版本。第二组是行为与数据：模型输入输出、遥测语义、采样节奏、误差范围。第三组是验证场景：正常扩容、故障切换、维护退出、负载变化和硬件替换。第四组是运行流程：动作审批、权限、回退、审计以及结果反馈。

这些交付物让数字孪生与其他技术域形成实际接口：网络提供拓扑和通信行为，硬件管理提供配置与故障状态，电源与冷却提供可持续运行包络，编排系统提供工作负载与动作入口。围绕同一组模型维护这些接口，AI Factory 才能把架构设计和持续运行连成一条工程链。S044 pp. 45–55 S051 pp. 7–10 S070 pp. 27–38