篇一 · 灵衢软件深度分析系列
灵衢（UnifiedBus）超节点的内核软件栈要回答一个硬问题：8192 张卡、128 个机柜、跨越上百米的光互联，在 Linux 内核眼里到底是"一台机器"还是"128 台机器"？
如果超节点是一台机器，Linux 需要全新总线类型、跨节点地址翻译硬件驱动、超越 NUMA 的内存管理——现有内核子系统都不够用。如果是 128 台机器，只需要更快的网络，软件用标准 RDMA 就行。
灵衢选了前者。它必须在 Linux 内核里植入选题级的改动：ub_bus_type 总线、UMMU 地址翻译驱动、跨节点内存借用/共享、URMA 通信原语。能做这件事的前提是全栈自研互联硬件——物理层（112G/224G SerDes）、协议栈（10 部分规范）、芯片（UB Switch、UMMU、UDMA）全部自研。2026 年的数据中心互联版图里，物理层到软件全栈覆盖的只有两家：NVIDIA（NVLink+NVSwitch+IB）和华为（灵衢 UB）。
NVIDIA 走"多层协议拼接"——NVLink 管机内、PCIe 管设备、IB 管节点间、GPUDirect 管存储，四套驱动拼出完整路径，CUDA 统一上层 API。灵衢走"单一协议归一"——所有互联走 UB 协议，一套驱动覆盖全程。拼接的代价是复杂，归一的代价是封闭。
本文聚焦内核层：部署设计 → UB OS Component 逐模块解剖 → NVIDIA 对比 → 能力边界推敲。后续两篇分析服务层和云化层。
一、部署设计：两条路径，一个 ISO
1.1 通算超节点（鲲鹏 950 SuperPoD）
硬件安装。 UB Switch、光模块物理连接。
OS 安装。 openEuler 标准 ISO。设计决策：通用服务器和超节点共用同一个 ISO。 通用服务器装完就结束。超节点额外 patch UB OS Component——UBMM 驱动、7 种 UBPU 驱动（NPU/DPU/SSU/UDMA/UMMU/UNIC）、用户态工具链 ubctl、灵衢网络配置（拓扑发现、路由表初始化）、UBM 启动。
按需部署服务。 UBS Engine（控制面核心），按需 UBS Mem/Comm/IO/Virt。
共用 ISO 的工程意图明确：通用服务器和超节点可以混跑在同一个数据中心，运维不维护两套 OS 镜像。但"额外 patch"掩盖了实际体量——UB OS Component 是对内核总线模型、内存管理子系统、通信栈的系统性扩展，不是装几个 .ko。一次内核大版本升级（openEuler 24.03 → 下一个 LTS），UB OS Component 的适配回归测试范围远大于普通驱动更新。共用 ISO 降低了初始部署风险，但没有降低长期维护复杂度。
1.2 智算超节点（Atlas 950 SuperPoD）
硬件预装程度更高：UBM 和 PodManager 出厂内置在独立芯片，Atlas 850/850E 出厂内置灵衢总线设备。用户不自己装 UB Switch 和光模块。
OS 同样 openEuler ISO，额外部署灵衢业务面和开发面组件 + UBS Engine。
DeviceOS 固件-OS 分离。 NPU 固件（DeviceOS）自带灵衢驱动，HostOS 只装用户态服务和开发工具链。NPU 固件升级不等于 HostOS 升级。
代价是三层版本矩阵：
| 层 | 内容 | 升级频率 | 透明度 |
|---|---|---|---|
| DeviceOS 固件 | NPU 内的 UB OS Component | 跟 NPU 驱动版本走 | 最不透明 |
| UBM 固件 | 独立芯片上的拓扑管理器 | 跟硬件固件周期走 | 升级/回滚未公开 |
| HostOS 软件 | 用户态服务 + 开发工具链 | 跟 openEuler 版本走 | 最透明 |
三个版本能不能独立升级？跨版本兼容性谁测？DeviceOS 升级引入新 UB 协议特性，UBM 固件不支持怎么办？HostOS 的 UBS Engine 版本不匹配怎么办？灵衢把 128 个机柜变成"一台机器"的代价是：这台"机器"有三个独立演进的固件/软件层，版本兼容性矩阵的复杂度是 O(n³)。
1.3 部署的隐性成本
- 拓扑规划。 160 个机柜、柜间全光互联。拓扑结构直接影响通信性能。8192 卡 AllReduce 的通信模式决定最优拓扑——胖树有利于 all-to-all，Mesh 有利于 neighbor communication。灵衢 UB Switch 支持哪些拓扑？是否可编程路由？没有细节。
- UBM 收敛规模。 8192 个 UBPU 的拓扑发现和路由收敛速度——零公开数据。
- 选主延迟。 UBS Engine N-1 容错，选主耗时多少？对运维 SLA 有直接影响。
- 故障隔离粒度。 一个 UBPU 故障，UBM 隔离单设备还是整个机柜？单设备隔离→路由表更新波及多少条目？机柜级隔离→损失多少算力？
二、UB OS Component：在 Linux 内核中植入超节点
| 模块 | 扩展的内核子系统 | 核心能力 |
|---|---|---|
| Device Mgmt | bus/device/driver 模型 | ub_bus_type，UBPU 设备发现与热插拔 |
| Memory Mgmt | NUMA/DMA/SVA | 跨节点内存借用与共享，UMMU 地址翻译 |
| Communication | —（新增中间件） | URMA 通信原语（load/store/dma/rpc） |
| Virtualization | KVM/vfio | UB 设备直通虚机，超级 VM |
| UBM（固件） | —（独立芯片） | 拓扑发现、路由、故障隔离 |
2.1 Device Mgmt：ub_bus_type
Linux 设备驱动模型是 bus_type → device → driver 三层。PCIe 有 pci_bus_type，USB 有 usb_bus_type。CXL 没有独立总线类型——它在 PCIe 枚举上叠加 CXL.mem/CXL.cache。灵衢直接新增 ub_bus_type。
两种设计哲学：CXL 走增量路线（物理层是 PCIe，复用 PCIe 枚举，叠加内存语义），好处是 Linux 上游能接受——内核从 5.12 逐步 merge CXL 子系统，到 6.13 已相当完整。灵衢走重构路线（物理层不是 PCIe，直接定义独立总线），架构干净，代价是永远进不了 Linux 上游。
上游化不可能。 内核合并标准：多厂商、多产品、通用价值。drivers/accel/ 被接受因为 Intel、AMD、Apple 都有硬件。ub_bus_type 只有华为硬件，灵衢硬件不对外零售（只随 Atlas 整机出货），第三方无法测试和贡献。
后果：
- 内核组件永远在 openEuler fork，华为独力维护
- 内核大版本升级时 fork 的 merge 冲突由华为独自解决
- CVE 发布到 openEuler fork 修复之间的窗口期取决于华为响应速度
- CXL 子系统更新会不会和
ub_bus_type内存管理代码冲突？
openEuler fork 是灵衢内核层的隐性税。 NVIDIA 闭源驱动也有维护成本，但跑在标准内核上，不需要 fork。灵衢选了 fork。
UBPU 对等模型。 所有灵衢总线上的设备叫 UBPU——CPU、NPU、DPU、SSU 地位平等，任何 UBPU 都可以主动发起通信、访问其他 UBPU 内存、借用资源。对等模型没有单点瓶颈（不像 PCIe 的 root complex），但路由表规模 O(n²)——8192 个 UBPU 全互联路由表超过 6700 万条。灵衢用交换拓扑而非全互联，路由表按目的 NodeID 聚合到 8192 条目量级，但多路径路由（ECMP）成倍增加。
内核态驱动：
| 驱动 | 管理对象 |
|---|---|
| UBMM driver | UB Memory Manager 配置 |
| NPU driver | NPU 加速器 |
| DPU driver | 数据处理单元 |
| SSU driver | 存储服务单元 |
| UDMA driver | UB DMA 引擎（跨节点搬运） |
| UMMU driver | UB MMU（地址翻译） |
| UNIC driver | UB 网络接口 |
用户态 ubctl 对标 lspci——设备发现、热插拔、拓扑查询、配置管理。
2.2 Memory Mgmt：跨节点统一编址
内核层技术密度最高的模块。标准 Linux struct page 对应本机物理内存，NUMA 扩展到多 socket 但止步于一个机箱。灵衢要让远端 NPU 的 HBM 成为本地 NUMA 拓扑的一部分。
UMMU：跨节点地址翻译
UMMU 硬件单元翻译跨节点地址。工作流：
- CPU load/store 访问虚拟地址
- 本地 MMU 翻译为物理地址
- 物理地址落在灵衢地址空间 → UMMU 接管
- 翻译为
{NodeID, UASID, VA} - 总线路由到目标节点
- 目标节点执行操作，返回数据
全程无 OS 介入。应用感知不到远端和本地的区别——只有延迟差异。
{NodeID, UASID, VA} 三层结构天然支持多地址空间隔离。UASID 类似 x86 PCID 但扩展到跨节点。8192 UBPU × N 并发 UASID 的地址翻译表规模——UMMU 的 TLB 容量和 miss penalty 是关键性能参数，未公开。
延迟标尺与能力边界。
| 操作 | 延迟 | 备注 |
|---|---|---|
| 本地 DDR（同 NUMA） | 100-150ns | 基线 |
| 跨 NUMA（同机箱） | 200-300ns | x86 QPI/UPI |
| 灵衢跨机柜 | ~400ns | OBMM 实测 |
| RDMA Read（同 DC） | 2-5μs | RoCEv2/IB |
| NVLink（同机箱） | <100ns | NVLink 5.0 |
能力边界推演。 400ns 的位置：比跨 NUMA 慢一倍，比 RDMA 快 5-10 倍，比 NVLink 慢 4 倍。
推一个具体场景：8192 卡 AllReduce reduce-scatter，每张卡从其他 8191 张卡各取一块数据。同步 load：400ns × 8191 = 3.3ms。NVLink 同机箱等价操作：<100ns × 8191 = 0.8ms。差距 4 倍。
灵衢的应对：UDMA 批量搬运 + URMA 异步 DMA——多次小 load 合并为一次大块传输，摊薄 400ns 启动延迟。对大块数据有效（1MB KV Cache，400ns 被 128 GB/s 带宽摊薄到可忽略），对小粒度随机访问无效。
结论：灵衢的"单机语义"是编程模型的简化，不是物理性能的等价。 硬件给你单机 API，但 400ns 告诉你它不是真的单机。性能敏感路径仍需感知数据位置——热数据本地 NUMA，温数据跨机柜 UB，冷数据远端存储。
内存借用（Memory Borrow）
节点 A 内存不够，临时借用节点 B 空闲 HBM/DRAM。借用内存通过 UMMU 映射为本地 NUMA.remote。对应用和内存分配器完全透明。
OBMM 管理策略：触发阈值、借用比例、回收时机。实测：最佳借用比例约 25%，性能损耗 <5%。
为什么是 25%？ 推演：借来的远端内存 400ns，本地 DDR 100-150ns。均匀分布假设下（大部分应用不是，但作上界），借入 25% 意味着 25% 访问命中 400ns，75% 命中 100-150ns。加权平均 ≈ 0.25 × 400 + 0.75 × 125 = 194ns，比纯本地 125ns 慢 55%。但实际应用有局部性（热数据倾向留在本地），所以实际损耗 <5%。25% 不是硬限制，是局部性假设下的经验最优值。 局部性差的应用（大规模图计算 random walk）应该更低。
借用独占——借入方拥有完整数据所有权。没有多写者 → 不需要 CC → cacheable。CC 问题被限制在共享场景，借用完全回避。 硬件简单（不需要跨机柜 cache coherence 电路），但借用只适合独占使用。
内存共享（Memory Share）
多节点访问同一块数据（共享权重、分布式推理 KV Cache），set_ownership 控制写入权：任意时刻只有一个 owner 可写，其他只读。写入权转移通过软件协议。
灵衢没有跨节点硬件缓存一致性。 刻意选择。跨 128 个机柜的硬件 CC：
- Snoop filter 规模：128 节点 × 数十 TB 内存的 snoop 状态追踪，存储和查询延迟不可控
- Coherence traffic：每次写入广播 invalidation 到所有可能缓存该行的节点，带宽随节点数平方增长
- 延迟不可预测：invalidation ack 取决于最慢节点
灵衢选了软件一致性 + 硬件透明访问。代价：owner 切换不是原子操作。两个节点高频交替写入同一块内存（训练的 gradient accumulation），set_ownership 来回切换成为瓶颈。
能力边界：灵衢共享内存适合低频写入-高频读取（推理：一个节点写 KV Cache，多个节点读），不适合高频写入-高频读取（训练：多节点交替写梯度）。 推理是灵衢超节点首要目标，这个权衡是合理的。
与 CXL Type 3：问题域不同
| 维度 | CXL Type 3 | 灵衢 UBM |
|---|---|---|
| 物理范围 | PCIe 链路（1-2m） | 灵衢总线（跨机柜，>100m） |
| 设备类型 | CXL 内存扩展器（同类） | CPU/NPU/DPU/SSU（异构） |
| 一致性 | CXL.cache（硬件 CC） | 软件所有权管理 |
| 编程模型 | 需感知 CXL 内存类型 | 统一 NUMA 节点，透明 |
| 生态 | PCI-SIG 标准，多厂商 | 华为专属 |
CXL 硬件 CC 在 PCIe 链路内可行。灵衢放弃硬件 CC 是因为物理范围差了两个数量级。
HMM / ZONE_DEVICE 的上限
Linux HMM 通过 ZONE_DEVICE + DEVICE_PRIVATE 给设备内存提供 struct page，hmm_range_fault() 处理 CPU 访问设备内存缺页。NVIDIA/AMD 实现 Unified Memory 的基础。
HMM 范围是单机。跨节点扩展需要：新页表项类型、新迁移路径、新一致性模型。技术上可行，需多家厂商联合推动——3-5 年，目前没有厂商在推。HMM 是灵衢 UBM 最接近的开源对应物，单机天花板是它跨不过的墙。
2.3 Communication：URMA 通信底座
UMDK 提供三种原语：URMA（RDMA 类比）、RPC（gRPC 类比）、Message（MPI 类比）。
URMA 三种模式：同步 load/store（指针操作）、异步 DMA（UDMA 引擎）、消息传递。
URMA vs RDMA 的物理路径：RDMA 走 NIC→交换机→NIC，过 IP/UDP 封装。URMA 走 UDMA→UB Switch→UDMA，无网络协议栈。少了 IP/UDP 封装和网卡协议栈，延迟从微秒级降到百纳秒级。
兼容层。 URMA 只跑灵衢硬件。RoUB 封装为 libibverbs 兼容接口。Socket over UB 封装为标准 socket。
三级适配路径的假设推敲。
| 适配程度 | 收益 | 来源 | 隐含假设 |
|---|---|---|---|
| 零修改 | ~10% | 底层传输更快 | 瓶颈在数据传输非计算 |
| SDK 适配 | ~30% | 去掉 verbs 层 | 值得改代码换 30% |
| 深度改造 | 50%+ | 显式传输→指针操作 | 架构适合指针操作 |
10% 零修改：走 RoUB 仍然过 verbs API，verbs 层开销没消失，只是底层传输从 IB 变成灵衢。如果应用瓶颈在计算非通信，收益趋近零。
30% SDK 适配：xcopy(gva) 替代 ibv_post_send + ibv_reg_mr + ibv_poll_cq，省掉 MR 注册、CQ 轮询、工作请求构造。收益取决于通信占比。
50%+ 深度改造：统一编址下显式 send/receive 改成直接指针操作。架构级改动，收益上限高但成本也最高。
冷启动。 10% 零修改不够驱动迁移——现有 IB 够用的用户没动力。URMA API 比 verbs 简洁得多，但"简洁"到"值得重写"之间距离很大。
2.4 Virtualization：vfio + UMMU 的协同
KVM + vfio 扩展。UB 设备直通虚机：NPU 直通、虚机内存横跨多物理节点（"超级 VM"）、容器热迁移 100ms → 50ms。
vfio + UMMU 协同的难点。 标准 vfio 通过 IOMMU 将设备 DMA 地址映射到 Guest 物理地址。灵衢设备的 DMA 地址是 UB 地址空间 {NodeID, UASID, VA}——不是标准物理地址。vfio 的 iommu 映射需要扩展到 UMMU 格式：要么增加 vfio_iommu_ub 类型修改 vfio 核心代码，要么通过 vfio platform 包装。
核心问题：Guest 物理地址空间包含远端节点内存。 标准 vfio 只处理本地 IOMMU。灵衢的 vfio 扩展需要同时处理本地 IOMMU 和跨节点 UMMU。VM live migration 时不仅要迁移本地内存页，还要迁移 UMMU 映射关系。这些实现细节未公开。
2.5 UBM：独立芯片上的总线管理器
UBM 固件部署在独立芯片内：拓扑发现维护、路由配置更新、故障检测物理隔离、运维监控。HostOS 崩溃不影响总线拓扑。
UBM 规模上限推敲。 8192 个 UBPU 的拓扑管理：
- 路由表规模。 全互联 8192 × 8191 / 2 ≈ 3350 万条。交换拓扑按目的 NodeID 聚合到 ~8192 条，多路径 ECMP 成倍增加。
- 故障检测。 8192 个 UBPU 心跳探测，单次 ~50μs（UB 总线往返），单轮 ~409ms，加处理开销秒级合理。
- 故障隔离粒度。 单设备隔离→路由表更新；机柜级隔离→损失 64 卡（假设单柜 64 卡）。
推论：千卡级拓扑收敛秒级，8192 卡可能十秒级。 初始化和故障恢复不在毫秒级 SLA 范围内。训练任务（可容忍短暂停顿）可能 OK，在线推理（亚秒级故障切换）需要看 UBS Engine failover 设计。
三、内核路线对比：灵衢 vs NVIDIA
互联架构
NVIDIA：多层协议拼接。NVLink（GPU-GPU 闭源）+ PCIe/Grace C2C + IB/Spectrum-X + GPUDirect Storage。四套驱动，CUDA 统一上层。
灵衢：单协议归一。所有互联走 UB，ub_bus_type + UMMU + URMA 一套驱动。
内存语义
NVIDIA ICMSP（CES 2026）：三级 KV cache。HBM（~100ns, ~$20/GB）→ DRAM（~150ns, ~$3/GB）→ NVMe SSD（~10μs, ~$0.3/GB）。BlueField-4 DPU 做层级间搬运和预取。存储语义——runtime 管理数据在哪一级。
灵衢 MemFabric：全局虚拟地址空间。内存语义——load 指令直达远端 NPU HBM，硬件/OS 决定数据位置。
| 维度 | ICMSP（存储语义） | MemFabric（内存语义） |
|---|---|---|
| 数据位置管理 | runtime 显式 | 硬件/OS 隐式 |
| 热度匹配 | 天然分层 | 依赖 page migration |
| 编程复杂度 | 高 | 低 |
| 适用场景 | 热度可预测（推理） | 热度不可预测（通用） |
边界。 推理中 KV Cache 热度可预测——prefill token 热、历史 token 温度递减。存储语义可精确匹配每级成本/延迟。内存语义交给 page migration——如果迁移粒度太粗（4KB 页面）或触发延迟太高，热数据可能落在慢存储上。灵衢的 UCM（下一篇分析）是否在内存语义上加了类存储语义的显式管理层，值得跟踪。
四、能力边界总判断
无替代：UB 总线驱动 + UBM 内存管理。 直接依赖灵衢硬件。最接近的开源对应物是 Linux CXL 子系统，但物理范围和语义范围不在一个层级。等价方案 150-200 人月，前提是有自己的互联硬件。
可近似：URMA → UCX。 等价编程接口，但走网络（微秒级）vs 走总线（百纳秒级）。不需要百纳秒级延迟时 UCX 完全可用。
成熟替代：虚拟化 → KVM/vfio/CRIU。 灵衢加速来自 UB 共享内存（100ms→50ms），标准 100ms 对大多数业务够用。
核心判断：灵衢内核层的不可替代性不在软件，在硬件。 UB 驱动和 UBM 的价值来自灵衢物理互联的独有能力——跨机柜统一编址、百纳秒延迟、异构设备对等访问。开源了代码但没有开放硬件生态，等于公布了蓝图但没有卖建材。
开源程度本身也值得推敲。灵衢内核层开源在 openEuler，显著高于 NVIDIA 闭源驱动。但 UBS Core 仓库只有 24 个 commit，全来自华为。没有第三方灵衢硬件，没有人能测试和贡献。开源了代码，没有建立社区。
五、值得跟踪的信号
1. UBS Core 社区活跃度。 24 个 commit 全来自华为。拐点是第三方芯片厂商提交 UBPU 驱动——哪怕只是一个 DPU 的驱动。
2. 灵衢 2.0.1 规范采纳。 2026 年 5 月精修版（基于 3 万+企业反馈）细化了 112G/224G SerDes 参数。有没有第三方基于它做芯片？
3. Linux 内核异构内存上游进展。 CXL Type 3 持续推进（6.13 重要更新），HMM 在 GPU 厂商推动下成熟。如果上游解决跨节点异构内存——目前看不到方向——灵衢护城河被削弱。
4. 8192 卡生产验证数据。 UMMU 延迟分布、内存借用稳定性、UBM 拓扑收敛速度——零公开。没有生产数据的架构蓝图，说服力有限。
5. openFuyao K8s 化封装的边界。 内核层价值最终通过 K8s 暴露。openFuyao 的 UB 内存池化插件只能跑灵衢硬件，影响力被限制在华为生态圈。能不能在标准 K8s 上提供降级但可用的体验，决定了灵衢内核能力的影响边界。
六、从推演反推：内核层的功能规格应该长什么样
前五章分析了灵衢内核层做了什么、能力边界在哪。现在反过来：如果我们从零开始写一份"超节点内核软件功能规格书"，根据前面的推演，应该列出哪些功能需求？哪些灵衢已经做了，哪些是推演揭示的缺口？
这不是灵衢的实际规划，是本文分析得出的功能规格视图。用 FR（Functional Requirement）编号，按模块组织。
6.1 总线与设备管理
| ID | 功能需求 | 来源 | 灵衢现状 |
|---|---|---|---|
| FR-1 | 独立总线类型（ub_bus_type），支持异构 UBPU 对等发现与热插拔 |
单协议归一设计要求 | ✅ 已实现 |
| FR-2 | 路由表可编程：支持胖树 / Mesh / 自定义拓扑，按通信模式动态调优 | §1.3 拓扑规划推演——160 机柜的拓扑结构直接影响 AllReduce 性能 | ❓ 未公开是否可编程 |
| FR-3 | 路由表规模上限：8192 UBPU 的聚合路由表 + ECMP 多路径，总条目数可管理 | §2.1 路由表 O(n²) 推算——全互联 6700 万条不可行，交换拓扑聚合是必需 | ❓ 无数据 |
| FR-4 | ubctl 拓扑可视化：显示 8192 UBPU 的完整拓扑图、路由路径、瓶颈链路 |
§1.3 运维需要感知拓扑——160 机柜的故障定位不能靠猜 | ✅ 基础功能有，可视化程度未知 |
| FR-5 | 内核模块独立版本号，与 openEuler 内核版本解耦 | §2.1 fork 维护——UB OS Component 的回归测试不应绑定每次 openEuler 小版本升级 | ❌ 目前是 openEuler fork 的一部分 |
FR-2 是关键缺口。 静态拓扑意味着部署时就要确定最优结构，后续不能根据业务负载调优。8192 卡的集群不是单一负载——训练和推理的通信模式完全不同。如果灵衢超节点要同时服务训练和推理（分时复用），可编程路由是刚需。
6.2 跨节点内存管理
| ID | 功能需求 | 来源 | 灵衢现状 |
|---|---|---|---|
| FR-6 | UMMU 地址翻译：虚拟地址 → {NodeID, UASID, VA}，硬件完成 |
超节点=一台机器的核心能力 | ✅ 已实现 |
| FR-7 | UMMU TLB 容量可配置，miss penalty 可观测 | §2.2 8192 UBPU × N UASID 的翻译表规模——TLB miss 可能成为延迟尖刺来源 | ❓ 未公开 |
| FR-8 | 内存借用策略可调：触发阈值、借用比例上限、回收超时、局部性检测 | §2.2 25% 是经验值——局部性差的应用需要更低比例 | ✅ OBMM 框架存在，策略可调程度未知 |
| FR-9 | 借用内存的 NUMA distance 精确标注（反映实际延迟，不是固定值） | §2.2 远端 HBM vs 远端 DRAM 延迟不同——NUMA distance 应区分 | ❓ 未公开 |
| FR-10 | 共享内存 owner 切换延迟可测量，提供切换计数和等待时间指标 | §2.3 set_ownership 的软件开销是训练场景的瓶颈——需要可观测才能调优 |
❓ 未公开 |
| FR-11 | 共享内存的批量 owner 转移：一次调用转移多个区域的写入权 | §2.3 训练中 gradient accumulation 涉及大量区域交替写入——逐个 set_ownership 开销叠加 |
❓ 未公开 |
| FR-12 | 数据位置感知 API：应用可查询某个虚拟地址的物理位置（本地/跨节点/远端存储），并可主动触发迁移 | §2.2 "单机语义是编程简化不是性能等价"——性能敏感路径需要感知位置 | ❓ 未公开 |
| FR-13 | 跨节点内存 cgroup 限额：限制单个容器/进程可借用的远端内存总量 | §2.2 多租户场景下，一个租户不能无限借用其他节点的内存 | ❓ 未公开 |
FR-7 和 FR-12 是最重要的缺口。 FR-7 决定了 UMMU 的可调试性——如果 TLB miss 导致延迟尖刺，运维需要知道。FR-12 决定了应用能不能做到"热数据本地、温数据远端"的分层策略——没有这个 API，应用的性能优化全靠猜。
FR-11 值得单独说。灵衢共享内存的 set_ownership 是单次操作。训练中一个 gradient accumulation 步骤可能涉及数百个内存区域的 owner 切换。如果每次切换都走一次软件协议（请求→确认→生效），数百次串行切换的延迟不可忽视。批量转移接口（一次调用转移 N 个区域）可以把 N 次协议开销压缩为一次。这不是优化，是训练场景的刚需。
6.3 通信与兼容
| ID | 功能需求 | 来源 | 灵衢现状 |
|---|---|---|---|
| FR-14 | URMA 三种模式（同步 load/store、异步 DMA、消息传递） | 通信基础 | ✅ 已实现 |
| FR-15 | RoUB 兼容层：libibverbs 接口兼容 | §2.3 零修改迁移路径 | ✅ 已实现 |
| FR-16 | Socket over UB 兼容层 | §2.3 TCP 应用无感加速 | ✅ 已实现 |
| FR-17 | 通信性能可观测：每次 URMA 操作的延迟分布、带宽利用率、UDMA 队列深度 | §2.3 三级适配路径的收益需要实测验证——没有可观测性就无法证明 10%/30%/50% 的假设 | ❓ 未公开 |
| FR-18 | RDMA 应用兼容性认证矩阵：哪些主流 RDMA 应用（NCCL/oneCCL/MPI）在 RoUB 上验证过 | §2.3 冷启动问题——用户需要知道现有应用能不能直接跑 | ❓ 未公开 |
| FR-19 | URMA → UCX 适配层：让 UCX 应用跑在灵衢硬件上 | §4 开源替代分析——UCX 是最接近的跨平台通信框架 | ❓ 未公开 |
FR-17 和 FR-18 是冷启动的命门。 灵衢生态冷启动依赖用户迁移。用户迁移的前提是：知道现有应用能不能跑（FR-18）、跑了能快多少（FR-17）。没有这两个数据，10% 零修改收益只是纸面数字。
6.4 虚拟化
| ID | 功能需求 | 来源 | 灵衢现状 |
|---|---|---|---|
| FR-20 | UB 设备 vfio 直通，支持 NPU/DPU 直通虚机 | §2.4 合规场景 | ✅ 已实现 |
| FR-21 | 虚机内存跨节点映射 + live migration | §2.4 "超级 VM" | ✅ 100ms→50ms |
| FR-22 | vfio UMMU 映射的独立类型（vfio_iommu_ub），不修改 vfio 核心代码 |
§2.4 vfio+UMMU 协同——修改 vfio 核心会增加上游兼容风险 | ❓ 实现方式未公开 |
| FR-23 | 超级 VM 的内存限额：限制单个 VM 可使用的跨节点内存总量 | §6.2 多租户——一个 VM 不能吃掉整个超节点的内存 | ❓ 未公开 |
6.5 总线管理（UBM）
| ID | 功能需求 | 来源 | 灵衢现状 |
|---|---|---|---|
| FR-24 | 拓扑发现与路由配置 | 基础能力 | ✅ 已实现 |
| FR-25 | 故障检测周期可配置，收敛时间可测量 | §2.5 千卡秒级→8192 卡可能十秒级——运维需要知道实际的收敛时间 | ❓ 未公开 |
| FR-26 | 故障隔离粒度可选：单设备隔离 vs 机柜级隔离，可按 SLA 需求配置 | §1.3 隔离粒度影响损失算力——训练可接受单设备隔离（更精确但收敛慢），推理可能需要机柜级隔离（损失更多但恢复快） | ❓ 未公开 |
| FR-27 | UBM 固件独立升级/回滚，不影响 HostOS 和 DeviceOS | §1.2 三层版本矩阵——三层必须可独立升级 | ❓ 未公开 |
| FR-28 | UBM 拓扑变更事件通知：路由变更时通知 HostOS，触发应用层重路由 | §2.5 拓扑收敛期间，应用需要知道哪些路径不可用 | ❓ 未公开 |
FR-25 是判断灵衢超节点规模上限的关键参数。 8192 卡的拓扑收敛时间如果是十秒级，意味着：初始化 >10 秒，单设备故障恢复 >10 秒，大规模拓扑重计算可能 >30 秒。这些数字直接影响运维 SLA 和业务可用性设计。
6.6 版本与运维
| ID | 功能需求 | 来源 | 灵衢现状 |
|---|---|---|---|
| FR-29 | 三层版本（DeviceOS / UBM / HostOS）兼容性矩阵自动检查 | §1.2 O(n³) 兼容性——人工检查不可行 | ❓ 未公开 |
| FR-30 | 固件热升级：UBM 和 DeviceOS 固件升级不中断业务 | §1.2 三层版本——冷升级意味着业务中断 | ❓ 未公开 |
| FR-31 | 版本回滚：任意层升级失败可回滚到上一版本，回滚时间 <SLA | §1.2 生产环境必需 | ❓ 未公开 |
| FR-32 | 内核模块 ABI 稳定性：UB OS Component 的用户态-内核态 ABI 跨版本稳定 | §2.1 fork 维护——如果 ABI 每个版本都变，用户态工具链要跟着改 | ❓ 未公开 |
6.7 规格总结：已实现、缺口、未知
统计上面的 FR：
| 状态 | 数量 | 占比 |
|---|---|---|
| ✅ 已实现 | 11（FR 1/6/8/14/15/16/20/21/24） | 34% |
| ❓ 未公开/未实现 | 21（FR 2-5, 7, 9-13, 17-19, 22-23, 25-32） | 66% |
| ❌ 明确缺失 | 0 | 0% |
34% 已实现，66% 未知。这个比例本身就是一个信号：灵衢公开了架构蓝图，但没有公开工程细节。 架构蓝图告诉你系统长什么样，工程细节告诉你它能不能用。
66% 的未知中，优先级最高的五个：
- FR-25（UBM 收敛时间）——决定超节点规模上限
- FR-12（数据位置感知 API）——决定应用能不能做性能优化
- FR-7（UMMU TLB 可观测）——决定延迟问题能不能诊断
- FR-18（RDMA 兼容性矩阵）——决定冷启动能不能发生
- FR-29（版本兼容性自动检查）——决定 128 机柜的运维是不是噩梦
这五个功能不会出现在架构图上，但会出现在运维工单里。
下一篇分析灵衢服务层——UBS Engine 控制面、MemFabric 128 TB + 48 TB 混合池、UCM TTFT -90% 和 throughput 22x、NPU Direct Storage 绕过 CPU 直连存储，以及训练链路到推理链路的应用对接全貌。
素材来源：灵衢系统软件架构&部署公开课（牛涛）、openEuler UB Service Core 白皮书 2.0、APNet'21 "Huawei UB: Towards Compute-Native Networking"（Bojie Li）、华为全联接大会 2025 徐直军主题演讲、灵衢互联社区规范文档、openEuler SIG-Long 异构融合 SIG 资料、KADC 2026 openFuyao 分论坛、CLK 2025 技术演讲、Linux 内核 CXL/HMM/ZONE_DEVICE 文档、UCX 项目文档、comentropy 超节点产业链分析、ubs-core 仓库（atomgit.com）