华体会hth体育平台:
但细心一看，这一个项目却好像并不简略，值得更多重视。X 网友 gm8xx8 谈论以为这表明 DeepSeek 正在处理正确性和吞吐量瓶颈问题，为下一版模型发布做准备。
望文生义，LPLB 是一个并行负载均衡器，它使用线性规划（Linear Programming）算法来优化 MoE（混合专家）模型中的专家并行作业负载分配。
动态重排序： 根据作业负载核算信息对专家进行重排序（Reordering）。
求解最优分配： 针对每个批次（Batch）的数据，求解最优的 Token 分配计划。
更详细而言，LPLB 的专家重排序进程由 EPLB 帮忙完结。而实时作业负载核算信息能够由用户更好的供给、通过 torch.distributed 搜集，或直接从 Deep-EP 缓冲区的内部通讯器中获取。至于求解器，则使用了内置的 LP（线性规划）求解器，其完成了单 SM（Streaming Multiprocessor）内点法（IPM），并使用了NVIDIA的 cuSolverDx 和 cuBLASDx 库进行高效的线性代数运算。
如此一来，MoE 负载不均的问题能得到有用处理，即在 MoE 模型中，某些「专家」或许比其他专家接收到更多的 Token，导致某些 GPU 繁忙而其他 GPU 闲暇。
X 网友 big goose 指出这与英伟达的用于调度 SM (Streaming Multiprocessor，是英伟达 GPU 的中心核算单元) 的计划十分类似，仅仅将笼统提高到了 pipeline 层级。LPLB 着重「单 SM」，意味着它的求解进程十分轻量化，不会占用过多核算资源。
不过需求指出，LPLB 现在应该还未被用来生产流程。DeepSeek 在 Readme 文件中表明：「LPLB 现在处于前期研讨阶段，功能改善状况仍在评价中。」
LPLB 是在 EPLB（专家并行负载均衡器）基础上的扩展，旨在处理 MoE 练习中的动态负载不均衡问题。
EPLB： 首要处理静态不均衡（例如，由于数据散布特性，某些专家总是长时刻过载）。
LPLB： 专心于处理动态动摇（由练习进程中小批次数据的随机性引起的瞬时负载颤动）。
冗余专家 (Redundant Experts)： 每个冗余专家（副本）都链接到一个原始专家，从而在 GPU 之间构成衔接边。
边容量 (Edge Capacity)： 一条边的容量界说为当时批次平分配给该冗余专家的 Token 数量，这决议了用于平衡负载的最大 Token 流量。
LP 优化 (LP Optimization)： LPLB 求解一个线性规划问题，在遵守边容量约束的前提下，沿着这些边重新分配 Token，以最小化专家并行（EP）组内的负载不均衡。
疏忽非线性核算本钱： 当时的规划器仅平衡 Token 总数，未考虑分组矩阵乘法（Grouped GEMM）时刻本钱的非线性特征。这或许会引起在某些状况下功能并非肯定最优。
求解推迟： 求解器在节点内（intra-node）优化大约需求 100 µs（跨节点时刻更长）。关于十分小的 Batch Size，这个推迟或许不行疏忽。
极点不均衡状况： 在大局负载极点不均衡的状况下，LPLB 的体现或许不如 EPLB。这是由于 LPLB 在分配冗余专家时存在必定的差异（LPLB 防止将多个副本分配给同一个原始专家）。
LPLB 答应通过细心修正 r2o 矩阵来界说专家副本的散布方法。以下是几种典型的拓扑：
立方体 (Cube)：在 GPU 子集上仿制专家，构成带有对角边的立方体图。这要求每个 GPU 至少 2 个专家。适用场景： 合适在 8 GPU 的 EP 子组内进行平衡，且不会献身跨节点通讯功能。
超立方体 (Hypercube)：类似于 Cube，但不包括对角边。这需求 16 个 GPU。适用场景： 合适跨 16 个 GPU 的专家并行。
环面 (Torus)：在同一节点内的街坊 GPU 上仿制一个专家，在邻节点的 GPU 上仿制另一个专家，构成环面图。其要求 每个 GPU 至少 2 个专家。优缺点： 对大局平衡有用，但由于触及更多的节点内通讯，功率一般低于 Cube。
DeepSeek 开源的这个 LPLB 库，本质上是在企图处理大模型练习中「木桶效应」的问题，即练习速度往往取决于最慢（负载最重）的那个 GPU。
它的立异点在于引入了线性规划这一数学东西来实时核算最优分配，并使用底层的 NVSHMEM 技能来打破通讯瓶颈。关于正在研讨 MoE 架构练习加快的开发者来说，这是一个十分有价值的参阅完成。
