篇二 · 灵衢软件深度分析系列
上一篇分析了灵衢的内核层——UB OS Component 如何让 Linux 理解超节点。内核层解决了"系统能看见硬件"的问题，但没有解决"硬件怎么协同工作"的问题。
8192 张 NPU，每张有自己的 HBM 和固件。没有服务层，它们就是 8192 个孤岛。灵衢服务层的官方名字叫 UB Service Core（UBS Core），开源在 openEuler 社区。五个核心子组件：Engine、Mem、Comm、IO、Virt。这些服务操作的是物理内存地址、DMA 描述符、NPU 计算队列，不是 HTTP 请求和 JSON。
本文逐一拆解五个子组件，然后分析训练到推理的应用对接全链路，最后对比 NVIDIA 的对标方案。
一、UBS Engine：超节点的分布式大脑
1.1 Engine 管什么
8192 张卡的资源分配、故障隔离、动态调度需要一个控制面。UBS Engine 就是这个控制面——整个超节点的"分布式 OS 内核"，管理硬件资源的全局视图和动态调度。
1.2 架构
分布式自选主，不依赖外部协调服务。 没有 ZooKeeper，没有 etcd。Engine 自己做选主。这意味着它不引入额外的运维组件，但也意味着选主算法的正确性和性能全部由华为自己保证。
N-1 高可用。 N 个管理节点，最多允许 N-1 个同时故障。这个容错等级非常激进——意味着只要有一个管理节点活着，整个超节点的控制面就不会中断。代价是管理节点的资源开销和一致性协议的复杂度。
资源池化管理。 内存、NPU 算力、DPU 加速器、SSU 存储单元——所有硬件资源在 Engine 里被抽象为可调度的池。上层服务（Mem、Comm、IO）向 Engine 申请资源，Engine 根据拓扑亲和性和负载做分配。
软件定义计算。 资源的按需组合与分配——你可以把 A 节点的内存 + B 节点的 NPU + C 节点的 SSU 组合成一个逻辑计算单元，对上层应用呈现为一个完整的执行环境。
1.3 和 UBM 的分工
内核层的 UBM（UB Manager）以固件形式运行在独立芯片上，管理的是硬件拓扑——物理层的链路发现、路由配置、故障隔离。
UBS Engine 管理的是逻辑层——在 UBM 发现的物理拓扑之上，做资源的逻辑调度和分配。
两层分离的好处：物理拓扑变了（比如拔掉一块 UB Switch），UBM 自动重新配置路由，Engine 只需要更新资源视图。Engine 不需要理解 UB 协议的物理细节。
1.4 未解的问题
几个关键问题仍然没有答案：
- 选主时间是多久？ 8192 卡的集群，管理节点之间的一致性协议延迟是多少？如果当前主节点故障，备份节点接管需要多久？
- 资源视图的更新频率。 NPU 利用率、内存占用、链路带宽——Engine 多久采集一次？采集粒度是节点级还是设备级？
- 跨超节点调度。 一个 Engine 管一个 8192 卡超节点。如果两个超节点之间需要协同（比如跨 Pod 的 AllReduce），谁来协调？
这些问题的答案直接影响灵衢在生产环境中的可靠性。
二、UBS Mem：把 128 个机柜的内存变成一个池
2.1 512TB 分散在 128 个机柜里
8192 张 NPU，每张 64GB HBM，总共约 512TB。物理上分散在 128 个机柜里，每个机柜有自己的 CPU 和 DDR。训练时模型并行需要跨机柜共享参数，推理时 KV Cache 需要跨实例共享上下文。RDMA 能做到但延迟在微秒级（2-5μs），而且需要应用显式管理内存注册、QP 连接、数据搬运。
灵衢的方案：让远端内存看起来像本地内存。
2.2 三个层次的服务
SHMEM（共享内存）。 多个进程/节点访问同一块物理内存。编程接口类似 POSIX shared memory，但底层数据搬运由灵衢硬件完成，不需要 OS 介入。典型场景：模型参数服务器、Embedding 表共享。
MemCache（全局内存缓存）。 类似分布式 LRU cache，但缓存媒介是远端内存而不是磁盘。当本地 HBM 不够用时，冷数据自动迁移到远端节点的空闲 HBM。对应用透明——分配器觉得还是从本地 HBM 拿到的，实际上可能来自三个机柜外的另一个 NPU。
MemStore（持久化内存存储）。 类似分布式 KV store，但后端是灵衢互联的内存而非 SSD。用途：高频访问的元数据、小型索引、推理请求的状态信息。
2.3 MemFabric：内存编织层
三个服务的底层是 MemFabric——把物理上分散的内存资源编织成一个统一地址空间的中间层。
MemFabric 做的事情：
- 全局地址分配。 为每一块物理内存分配一个全局唯一地址（基于 UB 虚拟地址格式
{NodeID, UASID, VA}） - 访问路由。 应用访问一个全局地址时，MemFabric 知道这个地址在哪个物理节点上，通过灵衢硬件完成数据搬运
- 一致性管理。 共享内存场景下的数据所有权管理——同一块内存在同一时刻只有一个 owner 可以写入，但多个节点可以同时读取
MemFabric 不是灵衢独有的概念。CXL Type 3 设备也在做类似的事情（CXL.mem 协议），但 CXL 的覆盖范围是机柜内（CXL 交换机的级联限制），灵衢的覆盖范围是整个超节点（128 个机柜）。
2.4 关键性能数据
已确认的性能数据：
| 操作 | 延迟 | 对比 |
|---|---|---|
| 跨节点内存访问（灵衢） | 300-400ns | 跨 NUMA 慢约 2 倍，RDMA 快 5-10 倍 |
| 内存借用性能损耗 | <5%（借用比例 25%） | 对应用基本透明 |
| 共享内存映射耗时 | 2-5s | 首次映射，后续访问走硬件路径 |
300-400ns 的跨节点内存访问是灵衢服务层最核心的性能卖点。这意味着一个运行在机柜 A 的进程，可以用一条 load 指令直接读取机柜 Z 的 NPU HBM 上的数据，延迟只比跨 NUMA node 慢 2 倍。
但要注意：这是硬件级延迟，不包含 MemFabric 的软件开销。实际应用中还需要加上地址翻译、权限检查、一致性协议的耗时。真实工作负载下的有效延迟需要生产数据验证。
2.5 和 CXL 内存池化的对比
| 维度 | 灵衢 MemFabric | CXL Type 3 池化 |
|---|---|---|
| 覆盖范围 | 整个超节点（128 机柜） | 机柜内（CXL 交换机级联） |
| 延迟 | 300-400ns | 100-200ns（机柜内） |
| 编程模型 | 统一地址空间 + NUMA 扩展 | CXL.mem 协议 + 上层软件管理 |
| 生态开放性 | 仅华为硬件 | 芯片/服务器厂商广泛支持 |
| 成熟度 | v26.03 刚集成到 K8s | PCIe 6.0 CXL 3.1 规范已发布 |
灵衢覆盖范围大但延迟高，CXL 延迟低但覆盖范围小。两者不是直接竞争关系——灵衢解决的是"跨机柜内存统一"，CXL 解决的是"机柜内内存池化"。理论上可以共存：机柜内走 CXL，机柜间走灵衢。但目前没有看到这种混合方案的实际实现。
三、UBS Comm：用灵衢总线替代以太网和 InfiniBand
3.1 HCCL：华为的集合通信库
对标 NVIDIA 的 NCCL。AllReduce、AllGather、Broadcast、ReduceScatter——这些集合通信操作是大模型训练的核心通信模式。HCCL 的性能直接决定训练的 MFU（Model FLOPs Utilization）。
HCCL 在灵衢超节点上的通信路径：
PyTorch/MindSpore → torch_npu/CANN → HCCL → URMA → 灵衢硬件
对比 NVIDIA 的路径：
PyTorch → NCCL → cuMLIB → NVLink（机内）/ IB（机间）→ 以太网/IP
灵衢路径的优势：统一协议栈。机内和机间都走 URMA，不需要像 NVIDIA 那样在 NVLink 和 IB 之间切换协议。HCCL 不需要关心通信对端是在同一个机柜还是三个机柜之外。
但这个优势的前提是灵衢互联的拓扑无关性——任意两个 UBPU 之间的通信延迟和带宽都足够均匀。如果存在明显的热点（比如某些机柜间的链路带宽成为瓶颈），HCCL 的 ring/tree 算法需要做拓扑感知优化，复杂度就不比 NCCL 低了。
3.2 URPC 和 Socket over UB
URPC：基于 URMA 的高性能 RPC。编程模型类似 gRPC，但底层走灵衢共享内存而非 TCP。适用于微服务架构下的低延迟跨节点调用。
Socket over UB：传统 TCP 应用无感加速。应用层代码不变，Socket 调用被重定向到灵衢总线上。延迟从 TCP 的百微秒级降到 2-3μs。
Verbs over UB（RoUB）：传统 RDMA 应用（MPI、NCCL 等）可以不修改代码跑在灵衢总线上。这是兼容层，让现有 RDMA 生态的应用可以零修改迁移到灵衢硬件。
兼容层的意义在于降低迁移门槛。但兼容层的性能上限取决于灵衢硬件对 RDMA 语义的模拟效率。如果 RoUB 只是"能用"但性能不如原生 URMA，用户最终还是要走 SDK 适配路径。
3.3 通信性能的公开数据
已公开的通信性能数据：
- UB 容器网络延迟：1.7-2.5μs（比 TCP 低 90%）
- Verbs over UB 延迟：接近原生 RDMA 水平
缺少的关键数据：
- HCCL AllReduce 在 8192 卡规模下的实际带宽利用率
- 不同拓扑下的通信性能差异（ring vs tree vs 自适应）
- 长时间训练中的通信稳定性（是否有抖动、降速）
四、UBS IO：NPU 绕过 CPU 直连存储
4.1 NPU Direct：推理场景的杀手级能力
NPU Direct SSD/SSU 是灵衢 IO 层最有价值的能力。NPU 绕过 CPU 和系统 DRAM，直接读写 SSD 或存储服务单元（SSU）。
大模型推理的 Decode 阶段，KV Cache 占用的显存随序列长度线性增长。一个 70B 模型、128K 上下文、batch size 32 的推理实例，KV Cache 可能占用 40-60GB HBM——接近一张 910B 的全部 HBM。如果能把 KV Cache 直接从 HBM 刷到 SSD，推理的显存瓶颈就被打开了。
传统路径：NPU HBM → PCIe → CPU DDR → NVMe SSD。两次内存拷贝，两次 PCIe 传输，CPU 还要做 DMA 管理。
灵衢路径：NPU HBM → UB → SSU/SSD。一次灵衢传输，不经过 CPU。
这个能力不是灵衢独创的。NVIDIA 的 GPUDirect Storage 做的是同一件事。但 GPUDDirect Storage 走的是 NVMe-oF 协议（基于 RDMA 或 TCP），需要配置 NVMe target、网络拓扑、权限。灵衢的 NPU Direct 走的是 UB 协议，在超节点内部不需要额外配置网络——因为灵衢总线已经把 NPU 和 SSU 连在一起了。
4.2 IO Cache 和 UBS OVS
IO Cache：全局读写缓存。频繁访问的数据块（比如模型权重文件、Tokenizer 词表）可以缓存在灵衢互联的远端内存中，减少 SSD 读取次数。
UBS OVS：虚拟网络交换。类似 Open vSwitch，但数据面走灵衢总线。用于容器和虚拟机的网络隔离。
这两个组件属于基础设施完善性功能，不构成核心差异化。
五、UBS Virt：跨节点的"超级虚拟机"
5.1 把多台物理机合成一台虚拟机
传统虚拟化把一台物理机分成多个虚拟机。灵衢的虚拟化反过来——把多台物理机合成一台虚拟机。
"超级 VM"利用灵衢内存统一编址，让一个虚拟机横跨多个物理节点。虚拟机内的进程看到的内存地址空间跨越了多个机柜的 DDR 和 HBM。
5.2 技术路径
- UB 设备直通虚拟机（类似 SR-IOV / vfio）：虚拟机直接访问灵衢设备
- 跨节点设备直通：虚拟机可以使用其他物理节点上的 NPU/SSU
- VirtAgent：虚拟化管理代理，负责跨节点的设备协调
- 超级容器 / 超级进程：类似超级 VM，但粒度更细
5.3 边界：通算场景的卖点，AI 场景配角
超级 VM 的核心场景是通算——需要超大内存空间的传统数据库和数据仓库。GaussDB 已适配了 TaiShan 950 超节点的池化内存，利用跨节点统一编址把分散的 DDR 聚合成单一地址空间，避免分库分表。
AI 场景里，容器（K8s + openFuyao）是主流部署方式。超级 VM 提供的跨节点内存对推理的帮助有限——推理的瓶颈在 NPU HBM 容量和 KV Cache 管理，不在 CPU 侧内存大小。训练场景中超级 VM 的隔离粒度也太粗。UBS Virt 在灵衢软件栈里是通算场景的差异化功能，不是 AI 的核心。
六、应用对接：从训练到推理的全链路
灵衢服务层的价值最终体现在应用能不能跑起来、跑得好不好。从公开资料可以还原两条主要应用链路。
6.1 训练链路
PyTorch/MindSpore
↓
torch_npu / MindSpore CANN 插件
↓
CANN（华为计算加速库）
↓
HCCL（集合通信）
↓
UBS Comm → URMA → 灵衢硬件
已验证的：华为与 DeepSeek 的合作证明了 MoE 架构在昇腾平台上的训练可行性。具体验证了什么：
- MoE 的动态专家路由在灵衢超节点上的通信效率
- DeepSeek 的 Multi-head Latent Attention 在昇腾 NPU 上的算子适配
- 端到端训练的 MFU 水平
缺少的：
- 第三方训练框架（Megatron-LM、DeepSpeed）的适配进度
- 非 MoE 架构（Dense 模型）在灵衢上的训练效率
- 从零训练一个模型的完整案例（包括数据处理、checkpoint 管理、断点续训）
6.2 推理链路
推理框架（vLLM-Ascend / MindIE）
↓
CANN
↓
UBS IO（NPU Direct SSD/SSU） + UBS Mem（池化内存）
↓
灵衢硬件
推理场景对灵衢服务层的依赖更深：
KV Cache offloading。 Decode 阶段的 KV Cache 直接从 NPU HBM 刷到 SSD/SSU，绕过 CPU。这是长上下文推理的关键优化。
推理 Decode 阶段的显存池化。 利用 UBS Mem 的共享内存，多个推理实例可以共享同一份模型权重。每个实例只需要保存自己的 KV Cache 和激活值。
Speculative Decoding 的并行推理。 利用灵衢低延迟互联，多个小模型可以并行做推测，主模型验证。
6.3 适配现状与缺口
已打通的：
- PyTorch + torch_npu + CANN：训练基本可用
- MindSpore + CANN：华为自研框架，适配最深
- GaussDB：已适配超节点池化内存
- openFuyao + K8s：容器编排已验证
正在打通的：
- DeepSeek 系列：华为重点投入的适配方向
- vLLM-Ascend：推理引擎适配进行中（vllm-ascend 0.11~0.14）
- Mooncake KVCache：分布式缓存 V3 架构已合入部分能力
明显缺口：
- TensorFlow / JAX 等非 PyTorch 框架
- 非 openEuler 操作系统（Ubuntu/Debian/RHEL）
- 非华为硬件上的灵衢服务层运行
- 第三方 ISV 的应用适配
七、和 NVIDIA 的服务层对比
| 维度 | 灵衢 UBS Core | NVIDIA（NCCL + GPUDirect + MIG） |
|---|---|---|
| 控制面 | UBS Engine（分布式自选主） | 无统一控制面，依赖上层调度 |
| 内存池化 | MemFabric（跨 128 机柜） | GPUDirect（机内 NVLink，机间 CX） |
| 通信库 | HCCL + URMA | NCCL + NVLink/IB |
| 存储直连 | NPU Direct SSD/SSU | GPUDirect Storage（NVMe-oF） |
| 虚拟化 | UBS Virt（超级 VM） | MIG（GPU 切分） |
| 编程模型 | 统一（URMA 全栈） | 拼接（NVLink + PCIe + IB + GPUDirect） |
| 生态 | 华为生态圈 | 全行业 |
灵衢的优势在"统一"——一个协议栈贯穿机内和机间，应用不需要关心通信对端的物理位置。NVIDIA 的优势在"生态"——每一段都有成熟的标准和开源实现，适配成本远低于灵衢。
这个对比的核心判断和内核层一样：统一的代价是封闭，拼接的代价是复杂。 灵衢在软件层面做了正确的技术选择（统一编程模型、统一内存空间），但这些选择的商业价值取决于生态规模。如果只有华为自己的硬件用灵衢，统一的优势就被封闭的劣势抵消了。
八、服务层的开源替代判断
结合本系列的开源替代分析素材，服务层各组件的替代性评估：
| 组件 | 有无替代 | 关键瓶颈 |
|---|---|---|
| UBS Engine | 无直接替代（etcd/consul 可做部分功能） | 与灵衢硬件的深度绑定 |
| MemFabric | 近似（CXL Type 3、Lambda 的池化内存方案） | 覆盖范围远小于灵衢 |
| HCCL | 有（NCCL、RCCL、oneCCL） | 后端需要适配灵衢 URMA |
| NPU Direct | 有对标（GPUDirect Storage） | GPUDirect 走 NVMe-oF，不依赖灵衢 |
| UBS Virt | 近似（Kata Containers、跨节点 CXL） | 超级 VM 的使用场景窄 |
最不可替代的是 MemFabric。 128 机柜规模的统一内存编址，目前市场上没有等价方案。CXL 的覆盖范围不够，RDMA 的延迟不够低，没有其他技术能在 300-400ns 延迟下提供跨机柜的内存池化。
最容易替代的是 HCCL 和 UBS IO。 NCCL 已经是事实标准，GPUDirect Storage 已经在广泛使用。如果第三方芯片厂商想绕过灵衢，这两个组件有成熟的替代方案。
九、服务层的功能规格缺口
篇一从内核层推演了 32 条 FR。服务层在内核层之上，解决的是"硬件怎么协同工作"的问题。根据本篇前八章的分析，服务层有自己独立的功能规格缺口。
9.1 控制面
| ID | 功能规格 | 推演来源 | 状态 |
|---|---|---|---|
| SL-1 | UBS Engine 选主时间可测量，主节点故障到备份接管 <SLA | §1.4 选主时间未公开 | ❓ |
| SL-2 | 资源采集粒度可配置：节点级 vs 设备级，采集频率可调 | §1.4 采集粒度未公开 | ❓ |
| SL-3 | 跨超节点调度：多个 8192 卡超节点协同的协调机制 | §1.4 谁来协调跨 Pod 通信 | ❓ |
| SL-4 | Engine 全局视图的一致性延迟：资源状态变更到全集群可见的时间 | §1.2 分布式自选主 + N-1 高可用的一致性代价 | ❓ |
9.2 内存服务
| ID | 功能规格 | 推演来源 | 状态 |
|---|---|---|---|
| SL-5 | MemFabric 软件开销可观测：纯硬件 300-400ns 之上加了多少 | §2.4 硬件级延迟不包含软件开销 | ❓ |
| SL-6 | 共享内存 owner 切换延迟的软件协议开销可量化 | §2.3 一致性管理——set_ownership 是软件协议 | ❓ |
| SL-7 | MemCache 淘汰策略可配置（LRU/LFU/自定义），淘汰触发条件透明 | §2.2 "类似分布式 LRU cache"但策略未公开 | ❓ |
| SL-8 | MemStore 的持久性语义：掉电后数据是否可恢复 | §2.2 "持久化内存存储"但后端是内存非 SSD | ❓ |
9.3 通信服务
| ID | 功能规格 | 推演来源 | 状态 |
|---|---|---|---|
| SL-9 | HCCL AllReduce 在 8192 卡规模下的实际带宽利用率 | §3.3 关键数据缺失 | ❓ |
| SL-10 | HCCL 拓扑感知：ring/tree/自适应策略的选择逻辑和切换条件 | §3.1 拓扑无关性假设需要验证 | ❓ |
| SL-11 | 长时间训练的通信稳定性：抖动和降速的发生条件 | §3.3 无公开数据 | ❓ |
| SL-12 | RoUB 兼容层的性能开销：verbs API 映射到 URMA 的延迟损失 | §3.2 兼容层性能上限 | ❓ |
9.4 IO 服务
| ID | 功能规格 | 推演来源 | 状态 |
|---|---|---|---|
| SL-13 | NPU Direct 的传输带宽和延迟：HBM→SSU 的实际吞吐 | §4.1 只有路径描述，无数据 | ❓ |
| SL-14 | NPU Direct 的并发度：多少 NPU 可以同时直连同一 SSU | §4.1 多实例共享存储场景 | ❓ |
| SL-15 | IO Cache 的命中率可观测，缓存容量和淘汰策略透明 | §4.2 "全局读写缓存"但无细节 | ❓ |
9.5 服务层规格总结
| 状态 | 数量 | 占比 |
|---|---|---|
| ✅ 已实现 | 0 | 0% |
| ❓ 未公开 | 15 | 100% |
| ❌ 缺失 | 0 | 0% |
15 条全部未公开。这和篇一内核层的模式一致——架构蓝图清晰，工程细节空白。
但服务层的"未公开"比内核层更严重。内核层的 11 条"已实现"至少证明核心能力在跑。服务层的 5 个子组件，公开数据只有延迟标尺（300-400ns、1.7-2.5μs）和借用比例（25%）。控制面的选主时间、内存服务的软件开销、通信的带宽利用率、IO 的传输吞吐——生产环境运行必需的四组数据，一条都没有。
篇三将从云化层视角收拢三篇的功能规格（SR-1 到 SR-41），把内核层 FR 和服务层 SL 合并为全栈视图。
下一篇将分析灵衢云化层——openFuyao 如何把灵衢能力封装给 K8s 用户、InferNex 推理集群编排的商业价值、以及灵衢软件栈的整体战略判断。
素材来源：灵衢系统软件架构&部署公开课 PPT（牛涛）、openEuler UB Service Core 白皮书 2.0、APNet'21 "Huawei UB: Towards Compute-Native Networking" 技术报告（Bojie Li）、华为全联接大会 2025 徐直军主题演讲、comentropy 超节点产业链分析、KADC 2026 openFuyao 分论坛、openFuyao v26.03 Release Notes、ubs-core GitHub 仓库（atomgit.com）