跳转至

Model Runner V2 EPLB 架构

Ascend 上的 Model Runner V2 使用上游 vLLM 专家并行负载均衡器 (EPLB) 控制平面，并添加了一个小的 Ascend 特定集成平面。上游代码负责负载窗口、策略执行、放置状态和重排事务。vLLM Ascend 负责设备路由、已执行负载记录、量化专家权重视图和 HCCL 通信。

本页描述当前的同步架构。有关此所有权模型背后的决策，请参阅 RFC #13410。有关用户可见的配置和支持的功能矩阵，请参阅 EPLB 用户指南。

心智模型

EPLB 具有控制平面和数据平面：

  • 控制平面 决定每个逻辑专家的放置位置以及放置何时更改。其事实来源是上游的 EplbState。
  • 数据平面 将每个 token 的逻辑专家选择映射到本地 rank 上安装的物理专家，运行融合 MoE，并记录实际执行的专家。
  • 移动平面 暴露真实的量化专家存储，并通过使用 HCCL 支持的 torch.distributed 集合的上游重排事务来移动它。

Ascend 集成适配了这些平面之间的边界；它不实现第二个策略或放置生命周期。

flowchart LR
    A["Upstream EPLB controller"] -->|"committed placement"| B["Ascend EPLB state"]
    B -->|"refresh in place"| C["Device lookup table"]
    D["Router logical expert IDs"] --> C
    C -->|"physical expert IDs"| E["Quantized fused MoE"]
    E -->|"executed expert counts"| F["Load recorder"]
    F --> A
    A -->|"rearrangement plan"| G["Quantization-owned weight views"]
    G <-->|"torch.distributed over HCCL"| H["Peer EP ranks"]
    G -->|"commit"| B

组件边界

组件 职责
上游 EPLBController 和 EplbState 负载窗口、策略、放置计算和重排排序
AscendEPLBController 批量负载收集阶段过滤和 Ascend 状态构建
AscendEplbState 和 AscendEplbLayerState 从已提交的上游放置派生的稳定设备查找
路由器适配器 每个实例的逻辑到物理 ID 映射，而不替换上游路由器类
融合 MoE EPLB 辅助函数 设备查找和计算后物理负载记录
量化方法 其内核实际消耗的专家张量和元数据的视图
HcclEplbCommunicator 通过 HCCL 上的 torch.distributed 实现的上游通信器契约
平台补丁 能力适配以及上游未暴露的窄构建/提交钩子

平台补丁是一个入口适配器。运行时路由、状态管理和通信位于显式组件中，以便补丁不会成为 EPLB 的替代实现。

请求和层流程

在 runner 初始化时，平台验证检查 Model Runner 版本、EPLB 模式、量化布局和执行功能。不支持的组合在提供服务之前失败。Model Runner V1 保留其旧版 EPLB 路径；Model Runner V2 使用上游控制平面。仅限 V1 的控件和 V2 EPLB 配置不能混合使用。

在 Model Runner V2 批次开始时，runner 告知 AscendEPLBController 该批次是否属于配置的负载收集阶段。该阶段可以收集所有批次、prefill 批次或 decode 批次。包含 prefill 工作的混合批次被分类为 prefill。此决策每个批次做出一次，而不是每个 token 或 MoE 层做出一次。

然后每个 MoE 层遵循一条路由路径：

  1. 上游路由器选择逻辑专家并生成路由权重。
  2. 绑定实例的 Ascend 路由器适配器从层的设备查找中收集物理专家 ID。
  3. 量化方法接收路由权重和物理 ID 并运行融合 MoE。它不会再次选择专家。
  4. 计算后，当上游负载窗口的收集阶段启用时，已执行的物理专家计数的本地切片被添加到该窗口中。

阶段选择仅过滤由 rank 提交的负载。每个 rank 仍然以相同的顺序推进上游 EPLB 状态机并参与其集合操作，即使本地批次属于不同的阶段。

查找是一个固定形状的设备张量，其对象身份保持稳定。当放置更改时，AscendEplbLayerState 构建新值并将其复制到现有张量中。因此，长期存在的路由器实例和编译的调用点保持有效的引用，而无需在层热路径中重建 Python 对象。

重排和权重视图

当上游负载窗口关闭时，控制器评估策略，并在必要时启动上游重排事务。该事务使用通信器在专家并行 rank 之间交换专家张量，提交新放置，然后刷新设备查找。路由永远不会观察到未提交放置的查找。

专家存储是特定于量化的。某些内核消耗独立的每专家张量，而其他内核消耗打包张量或关联的缩放和元数据布局。每个受支持的量化方法都暴露了计算读取的确切存储的权重视图。重排通过该视图进行操作；它不假设规范的模型参数是活动的内核存储。

因此，支持一种格式需要满足以下所有条件：

  • 可以识别计算张量及其关联的元数据；
  • 视图保持了上游移动契约所期望的顺序；
  • 移动更新了融合内核所使用的同一存储；
  • 移动后的执行在重复重排时仍然有效。

无法满足这些条件的格式会在验证期间被拒绝。 当前格式和执行模式支持表位于 EPLB 用户指南， 而非本架构页面。

通信与同步

HcclEplbCommunicator 通过进程组的 torch.distributed 操作实现上游通信器接口。 即使上游配置将其通用 torch-distributed 通信器后端命名为 HCCL， NPU 进程组仍会选择 HCCL。Ascend 特有的能力差异， 例如性能分析缓冲区预留，保持在通信器内部。

支持的路径是同步的：权重移动和放置提交在推理继续之前完成。 异步 EPLB 配置在启动时被拒绝。层状态刷新钩子附加在提交边界上， 以便未来的异步实现可以保持相同的读取保证， 但目前并不启用异步执行。

不变量

对此集成的更改必须保持以下不变量：

  1. 上游放置状态是 Model Runner V2 的唯一事实来源。
  2. 专家选择只运行一次；量化计算使用物理专家 ID。
  3. 设备查找仅在相应放置提交后更改。
  4. 负载在物理专家 ID 空间中的计算后记录。
  5. 权重移动更新活动量化内核所使用的确切存储。
  6. 不支持的模式在初始化期间失败，而不是静默降级。
  7. 禁用 EPLB 的执行和 Model Runner V1 EPLB 路径保持隔离。
  8. 路由热路径避免主机循环、设备到主机同步和可变 Python 映射工作。

扩展与调试锚点

添加量化格式时，从其专家权重视图开始，并证明融合内核读取移动后的张量。 不要向控制器或路由器添加布局知识。添加执行模式时，检查其放置提交边界 以及路由器实例是否保持稳定的查找。

对于重排后过时或错误的专家选择，检查已提交的 EplbState 和就地查找刷新。 对于成功移动但模型行为不变的情况，检查量化拥有的权重视图。 对于缺失或偏移的负载统计，验证计数是在融合 MoE 之后记录的，并使用物理 ID。 启动拒绝应对照用户指南支持矩阵和 附加配置参考 进行检查。

仓库测试放置和注册规则记录在 测试指南 中。