Latency-Optimal Load Balancing For Distributed MoE Inference

framework moe-lb-interai25
moeinferenceload-balancingexpert-parallelismoptimization

Latency-Optimal Load Balancing For Distributed MoE Inference #

Venkata Pavan Kumar Miriyala, German Sviridov, Bingxu Chen, Haris Javaid | 2025-12 | https://doi.org/10.1145/3769695.3771675 Category: framework | Tags: moe, inference, load-balancing, expert-parallelism, optimization Read: 2026-04-16

Core Contribution #

Proposes a latency-optimal algorithm for expert replication and reallocation during distributed MoE inference that jointly minimizes load imbalance and data movement overhead, formulated first as ILP then solved via a polynomial-time heuristic, achieving up to 12.5% latency reduction and 2× more frequent load balancing than prior approaches.

Summary #

Expert parallelism (EP) is the dominant strategy for distributing Mixture-of-Experts (MoE) model inference across multiple devices, where each device hosts a subset of experts. However, the dynamic nature of token routing means some experts receive far more tokens than others, creating workload imbalance — all devices must wait for the slowest one, wasting hardware utilization and increasing latency. Prior approaches either (a) add auxiliary loss functions during training to encourage uniform token distribution, which constrains model quality, or (b) dynamically replicate/reallocate experts across devices at inference time, which introduces high data movement overhead from shuffling expert weights.

This paper addresses the data movement overhead problem head-on. The authors formulate the expert replication and reallocation problem as an Integer Linear Programming (ILP) optimization that jointly minimizes two objectives: the load imbalance across devices AND the total data movement cost incurred during the rebalancing phase. This joint optimization is the key insight — prior work treated these objectives separately, leading to suboptimal tradeoffs where rebalancing itself became a bottleneck. The ILP formulation establishes the theoretical optimum but is too expensive to solve at runtime. The authors then design a lightweight heuristic algorithm that solves the problem in polynomial time, making it practical for online use during inference serving.

Experimental results demonstrate up to 12.5% reduction in MoE execution latency over naive expert assignment. Critically, because the heuristic is fast enough, it enables load balancing to be performed 2× more frequently than existing approaches, further improving responsiveness to shifting workload patterns. The method is designed for scale-up network environments (e.g., within a single node or tightly-coupled accelerator cluster). During the workshop Q&A, the authors noted it could be adapted to heterogeneous environments via a normalization step.

Key Findings #

Key Figures #

Figure 1: Expert Parallelism and Load Imbalance (Conceptual) #

What it shows: Illustration of how MoE expert parallelism distributes experts across devices, and how uneven token routing creates load imbalance where the slowest device becomes the bottleneck.

Why it matters: Establishes the core problem — in EP, each device processes tokens for its assigned experts, but dynamic routing means some devices get overwhelmed while others are idle.

Detailed description: Diagram showing N devices, each hosting a subset of E experts. Input tokens flow through a router that assigns each token to top-k experts. The resulting distribution is skewed — some devices receive many more tokens than others. The execution time is determined by the max-loaded device (the "straggler"), leaving other devices idle. This is the fundamental waste that motivates the paper.

Figure 2: ILP Formulation for Joint Optimization (Conceptual) #

What it shows: The optimization framework that jointly minimizes load imbalance and data movement cost during expert reallocation.

Why it matters: This is the core technical contribution — prior work optimized these objectives independently, leading to suboptimal solutions.

Detailed description: The ILP has decision variables for expert-to-device assignments. The objective function combines two terms: (1) a load balance term minimizing the maximum workload across devices (min-max formulation), and (2) a data movement cost term penalizing expert weight transfers between devices. Constraints ensure each expert is assigned to at least one device and capacity limits per device are respected. The joint formulation means a rebalancing action is only taken if its benefit (reduced imbalance) exceeds its cost (data movement).

Figure 3: Heuristic Algorithm vs ILP Performance (Conceptual) #

What it shows: Comparison of the polynomial-time heuristic against the optimal ILP solution across different workload distributions.

Why it matters: Demonstrates that the heuristic achieves near-optimal results while being orders of magnitude faster — the key enabler for practical deployment.

Detailed description: Performance comparison showing the heuristic's latency closely tracks the ILP optimum across varying load distributions, while the solve time drops from ILP's exponential worst-case to the heuristic's polynomial time. This speed difference is what enables the 2× more frequent rebalancing.

Key Tables #

Table 1: Latency Reduction Results (Conceptual) #

MethodMoE Exec LatencyRebalancing FrequencyData Movement Overhead
Naive assignmentbaselineN/AN/A
Prior dynamic rebalancingimprovedhigh
This work (heuristic)up to -12.5%minimized

Takeaway: The joint optimization achieves the best latency reduction while enabling more frequent rebalancing because the algorithm itself is fast and its decisions minimize data movement.

Limitations #

Infrastructure Impact #


Deep Analysis (framework) #

1. System Scope #

2. Architecture & Data Flow #

2a. End-to-End Data Flow #

The system inserts a load balancing layer between the MoE router and device-level execution:


[Token Batch] → [MoE Router (top-k)] → [Token-to-Expert Assignment]
     → [Workload Monitor: observe per-expert load]
     → [Load Balancer: ILP/Heuristic decides expert placement]
     → [Expert Migration Engine: move/replicate expert weights]
     → [Device Execution: each device processes its assigned tokens]
     → [All-to-All gather results] → [Output]
StageInput → OutputLocationLatencyData
Token routingtokens → per-expert token listsCPU/GPU~μsrouting decisions
Workload observationtoken counts → load profileCPU~μsE integers
Load balancing decisionload profile + current assignment → new assignmentCPU~ms (heuristic)assignment matrix E×D
Expert migrationexpert weights transferredGPU↔GPU via interconnect~msexpert param size (tens of MB each)
MoE computationtokens × expert weights → outputsGPU HBMmain costdepends on model

2b. Data Movement Hotspots #

  1. Expert weight migration (GPU→GPU): When the load balancer decides to move an expert from device A to device B, the full expert weight tensor must be transferred. For a typical MoE expert (e.g., DeepSeek-V3 has 256 experts, each ~hundreds of MB in FP16), this is the dominant data movement cost. Frequency: per rebalancing event (every N batches).
    1. All-to-all token dispatch (GPU↔GPU): Before MoE computation, tokens are dispatched to the device hosting their assigned expert. This happens every forward pass. The load balancer doesn't directly control this but its placement decisions affect the balance of this communication.
      1. All-to-all result gather (GPU↔GPU): After expert computation, results are gathered back. Same frequency as dispatch.
      2. The paper's core insight is that hotspot #1 (expert migration) was being ignored in the optimization objective of prior work. By including migration cost in the objective, the algorithm avoids excessive weight transfers.

        3. Key Innovations #

        InnovationMechanismBenefitCost/Tradeoff
        Joint ILP formulationObjective = $\alpha \times \text{max\_load} + \beta \times \text{migration\_cost}$Avoids rebalancing actions where migration cost exceeds balance benefitRequires tuning $\alpha/\beta$; ILP is NP-hard
        Polynomial-time heuristicGreedy descent: find straggler → evaluate best expert move → execute if net positiveRuntime-practical (ms-scale), enables 2× more frequent rebalancingMay miss global optimum; greedy can get stuck in local optima
        Expert replicationReplicate hot experts to multiple devices instead of just movingReduces straggler load without removing expert from sourceIncreases total memory usage; requires coherent handling
        Min-max load formulationMinimize maximum device load (not average or variance)Directly targets the straggler — the actual bottleneck in synchronous EPMay leave non-straggler devices suboptimally loaded

        4. Scheduling & Resource Management #

        • Batch formation: N/A — the paper operates at the expert placement layer, not request scheduling. It assumes tokens are already batched and routed.
        • Memory management: Expert replication must respect device memory capacity constraints (modeled in ILP). The replication budget limits total expert copies.
        • GPU utilization: The entire purpose is to improve GPU utilization by eliminating straggler imbalance — idle time on underloaded devices is reduced.
        • Multi-tenancy: Not addressed.
        • Priority / SLO-aware: Not addressed directly — the latency minimization is a proxy for SLO compliance.

        Core scheduling algorithm (heuristic):

        
        Input: current_assignment, workload_profile, device_set
        while improvement_possible:
            d_max = argmax_d load(d)
            e_hot = argmax_e tokens(e, d_max)
            best_target = None, best_gain = 0
            for d_cand in device_set \ {d_max}:
                if can_fit(e_hot, d_cand):
                    gain = balance_improvement(move e_hot → d_cand)
                    cost = migration_cost(e_hot, d_max → d_cand)
                    net = α * gain - β * cost
                    if net > best_gain:
                        best_target = d_cand; best_gain = net
            if best_target:
                migrate(e_hot, d_max → best_target)
            else:
                break
        

        Complexity: $O(E \times D \times K)$ per rebalancing — polynomial, practical for online use.

        5. Target Scenarios & Workload Characterization #

        ScenarioWorkload PatternSLO / GoalWhy existing systems fail
        MoE inference on scale-up clusterDynamic token routing creates load imbalance across EP devicesMinimize per-request latencyNaive assignment creates stragglers; dynamic rebalancing has excessive migration overhead
        High-frequency load shiftingExpert popularity changes across batchesResponsive rebalancingPrior optimization approaches too slow to run frequently

        Primary bottleneck: Communication-bound — the data movement cost of expert weight migration is the key bottleneck that prior approaches failed to optimize. After optimization, the remaining bottleneck shifts to compute (the actual expert computation, which is now better balanced).

        6. Performance Evaluation #

        6a. Metrics #

        MetricDefinitionUnitDirection
        MoE execution latencyTime for the MoE layer forward pass under EPmsLower is better
        Load imbalanceMax device load / average device loadratioLower is better
        Rebalancing frequencyHow often load balancing can be triggeredper N batchesHigher is better
        Data movement overheadTotal bytes transferred during expert migrationGBLower is better

        6b. Before-After Comparison #

        OptimizationMetricBaselineAfterImprovementConditions
        Joint load balance + migration costMoE exec latencynaive assignment baselineup to -12.5%12.5% reductionScale-up, EP setting
        Fast heuristic vs prior approachRebalancing frequency1× (prior)2× more frequentSame overhead budget
        ILP optimality boundHeuristic gapILP optimalnear-optimalsmall gapExperimental verification

        6c. Bottleneck Shift Analysis #

        
        Before: scheduling-bound (straggler from load imbalance)
        → After joint optimization: communication-bound → compute-bound
          (migration cost is minimized, remaining bottleneck is actual expert computation)
        

        6d. Baselines & Fairness #

        • Baseline: "Naive expert assignment" — static, round-robin expert-to-device mapping with no runtime adjustment. This is a weak baseline.
        • Missing comparison: No comparison against state-of-the-art dynamic approaches like Libra, ExFlow, or CRAFT. The workshop paper scope may explain this gap.
        • Conditions: Scale-up network (likely NVLink/xGMI), specific MoE configuration not detailed.
        • When baseline might win: If workload is already balanced (uniform token distribution), the overhead of running the optimizer is pure cost with no benefit.

        7. API & Usability #

        N/A — This is an algorithm/technique paper, not a full system. No API, deployment, or configuration details are provided. Integration into existing frameworks (vLLM, SGLang, TRT-LLM) would require adaptation.

        8. Infrastructure Impact #

        LayerImpact
        AlgorithmThe ILP formulation provides a principled optimization framework that could inform training-time auxiliary loss design for MoE routing
        KernelNo new kernels needed — operates above kernel level. Expert computation kernels unchanged
        LLMModel-agnostic; benefits any MoE architecture (DeepSeek-V3, Mixtral, etc.) without modification
        AgentIndirectly reduces latency for agent systems using MoE models
        OpsThe rebalancing frequency and α/β tradeoff are operationally relevant knobs for SLO tuning
        FeatureThis WorkExFlowLibraCRAFTFineMoE/LPLB
        ScopeInferenceInferenceInferenceInferenceTraining
        OptimizationILP + heuristicDynamic reallocationPrediction-basedCost-aware replicationLP-based scheduling
        Considers migration costYes (joint)NoNoYes (different formulation)N/A
        ScaleScale-upMulti-nodeMulti-nodeMulti-nodeMulti-node
        Rebalancing speedFast (polynomial)MediumFast (prediction)MediumMedium
        Latency reduction12.5%[varies]up to 19.2% throughput1.14× throughputup to 47.6% throughput

        10. Adoption & Maturity #

        • Open source? No public code release mentioned. Authors are from AMD — likely internal research.
        • Production deployment: Not mentioned. Workshop paper stage.
        • Adoption path: The ILP formulation is self-contained and implementable with standard solvers. The heuristic is described algorithmically. Integration into vLLM/SGLang EP paths would require: (1) adding a workload monitor, (2) implementing the heuristic, (3) building an expert migration engine with interconnect-aware cost model.
        • Maturity: Early-stage research (workshop paper, 7 pages). Needs full conference-level evaluation with real MoE models and end-to-end serving benchmarks.

        Open Questions #

        • How to handle correlated expert activation patterns (expert combinations that are always co-activated)?
        • What is the optimal rebalancing frequency as a function of workload volatility?
        • Can expert placement be co-optimized with KV cache placement in disaggregated serving?
        • How does this interact with auxiliary loss-based load balancing during training?
        • What is the heuristic's gap to ILP optimality in worst case?