Model Runner V2 EPLB 架构¶

Ascend 上的 Model Runner V2 使用上游 vLLM 专家并行负载均衡器（EPLB）控制平面，并增加了一个小型的 Ascend 特定集成平面。上游代码负责负载窗口、策略执行、放置状态和重排事务。vLLM Ascend 负责设备路由、已执行负载记录、量化专家权重视图，以及异步 Gloo 暂存移动适配器。

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

心智模型¶

EPLB 包含控制平面和数据平面：

• 控制平面决定每个逻辑专家放置在哪里，以及放置何时变化。其真实来源是上游 EplbState。
• 数据平面将每个 token 的逻辑专家选择映射到本地 rank 上安装的物理专家，运行融合 MoE，并记录实际执行的专家。
• 移动平面暴露真实的量化专家存储，并使用 Gloo 暂存 worker 通过上游重排事务移动它；模型运行器线程在两次前向传播之间提交已完成的层。

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 -->|"default-policy placement"| G["Quantization-owned weight views"]
    G <-->|"Gloo-staged transfer"| H["Peer EP ranks"]
    G -->|"main-thread commit"| B

组件边界¶

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

请求与层流程¶

在运行器初始化时，平台验证会检查 Model Runner 版本、EPLB 模式、量化布局和执行特性。不支持的组合会在服务前失败。Model Runner V1 保留其传统 EPLB 路径；Model Runner V2 使用上游控制平面。V1 专用控制项和 V2 EPLB 配置不能混合使用。

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

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

1. 上游路由器选择逻辑专家并生成路由权重。
2. 绑定到实例的 Ascend 路由器适配器从该层的设备查找中收集物理专家 ID。
3. 量化方法接收路由权重和物理 ID，并运行融合 MoE。它不会再次选择专家。
4. 当收集阶段启用时，同一设备操作会在上游负载缓冲区中记录所选物理专家，然后融合 MoE 执行。

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

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

重排与权重视图¶

当上游负载窗口关闭时，vLLM 的默认策略会计算新的放置，上游异步 worker 通过 Gloo 逐层暂存专家张量。模型运行器线程安装每个已发布的层，提交其放置，并在确认暂存缓冲区之前刷新设备查找。路由永远不会观察到未提交放置的查找。

专家存储是量化特定的。某些内核消费独立的每专家张量，而其他内核消费打包张量或关联的 scale 和元数据布局。每种受支持的量化方法都会暴露一个权重视图，表示计算实际读取的精确存储。重排通过该视图操作；它不假设规范模型参数是活动内核存储。

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

• 可以识别计算张量和耦合元数据；
• 视图保持上游移动契约预期的顺序；
• 移动更新融合内核使用的同一存储；
• 移动后的执行在重复重排中保持有效。

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

通信与同步¶

AscendGlooEplbCommunicator 实现了上游异步通信器 接口。专家张量通过 CPU 内存暂存，因为后台 工作线程不发起 HCCL 集合通信。前台 MoE 通信仍保持 在常规设备路径上。

仅支持异步 EPLB。上游工作线程每次发布一层， 并等待模型运行器线程确认消费后， 才复用暂存工作区。Ascend 提交适配器会延迟该 确认，直到该层的设备查找已刷新。

不变量¶

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

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

扩展与调试锚点¶

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

重排后出现过期或不正确的专家选择时，检查已提交的 EplbState 以及就地查找刷新。移动成功但模型行为未变化时，检查由量化拥有的权重视图。对于 缺失或偏移的负载统计，验证融合路由操作 记录的是物理 ID 并排除填充。启动拒绝应根据 用户指南支持矩阵和 附加配置参考进行检查。

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