Expert Parallelism on PCIe: A Comprehensive Investigation into MoE Optimization for GLM-5-NVFP4 on Blackwell GPUs

Introduction

Deploying large Mixture-of-Experts (MoE) language models on multi-GPU systems presents one of the most challenging optimization problems in modern machine learning infrastructure. The choice between Tensor Parallelism (TP) and Expert Parallelism (EP) determines not only how computation is distributed across GPUs but also the communication patterns, memory footprints, and ultimately the throughput that the system can achieve. This article synthesizes a deep investigation into this trade-off for the GLM-5-NVFP4 model—a 744-billion-parameter MoE with 256 experts, 8 activated per token, quantized to FP4—running on eight NVIDIA RTX PRO 6000 Blackwell (SM120) GPUs connected exclusively via PCIe Gen5 with no NVLink interconnect.

The investigation, spanning dozens of research probes across the SGLang codebase, quantitative modeling exercises, and hardware topology analysis, reveals a nuanced picture. Expert Parallelism offers genuine theoretical advantages in GEMM efficiency through larger matrix dimensions, but its practical viability on PCIe-only hardware is severely constrained by backend compatibility issues. The journey from initial hypothesis to final assessment is a masterclass in systematic performance engineering, demonstrating how theoretical modeling, codebase reconnaissance, and hardware-aware analysis must be combined to make informed deployment decisions.

The Performance Problem: Why Expert Parallelism Was Considered

The investigation began with a stark observation: under the current Tensor Parallelism (TP8) configuration, the GLM-5-NVFP4 model's FP4 GEMM operations were achieving only 55 TFLOPS against a theoretical peak of 1,850 TFLOPS—a utilization rate of roughly 3%. The root cause was clear from the GEMM dimensions. With TP8, each GPU holds all 256 experts but each expert's weight matrices are sharded to 1/8th their full size. The per-expert W13 (gate+up projection) GEMM has shape (64, 6144, 512), while the W2 (down projection) GEMM has shape (64, 256, 6144). The N dimension of 512 and the K dimension of 256 are pathologically small for the Blackwell SM120 tensor cores, which operate on fixed-size tiles typically 128×128 or 256×128 elements.

The tile efficiency analysis in [8] revealed the severity of this problem. For the W13 GEMM under TP8, with a 256×256 FP4 tensor core tile, only 2 tiles are produced (1×2), achieving a mere 5.6% SM utilization on a GPU with 36 SMs. The W2 GEMM under TP8 has a K dimension of only 256, yielding just 2 K-tiles—far too few to properly pipeline through the tensor core array. Expert Parallelism offered a potential escape: with EP8, each GPU would hold 32 complete experts with full-size weights, producing W13 GEMMs of shape (64, 6144, 4096) with 16 tiles (44.4% SM utilization) and W2 GEMMs of shape (64, 2048, 6144) with 16 K-tiles. The 8× increase in matrix dimensions promised dramatically better hardware utilization—if the communication overhead could be managed.

Codebase Reconnaissance: Mapping the EP Landscape

The first phase of the investigation involved systematic exploration of the SGLang codebase to understand what Expert Parallelism infrastructure existed. The assistant began with broad grep searches across the server configuration and MoE layer files [7], discovering that SGLang supports an ep_size parameter, multiple all-to-all backends ("deepep", "mooncake", "mori", "ascend_fuseep", "flashinfer"), and a dedicated EP MoE layer at ep_moe/layer.py [11].

Deeper exploration of the token dispatcher implementations [4] revealed the critical communication infrastructure. The DeepEP dispatcher, considered the most mature EP backend, was found to have NVLink and RDMA buffer management, with separate tracking of num_nvl_bytes and num_rdma_bytes. The FlashInfer dispatcher, by contrast, used a simpler TorchDistributedCommBackend wrapping PyTorch's distributed primitives, making it potentially more suitable for PCIe-only systems. The standard dispatcher, examined in [13], contained a conditional if self.moe_ep_size > 1 check that confirmed EP support existed even in the baseline implementation.

The EP MoE layer itself was found to have explicit support for the W4AFP8 quantization format used by NVFP4 [12]. The layer imports W4AFp8Config and W4AFp8MoEMethod, checks isinstance(quant_config, W4AFp8Config) to set self.use_w4afp8 = True, and calls self.forward_cutlass_w4afp8(dispatch_output) in the forward pass. This confirmed that the FP4 quantization path and Expert Parallelism were wired together in the codebase—a critical prerequisite for any EP deployment.

However, the codebase reconnaissance also revealed significant limitations. The moe_dense_tp_size parameter, which would enable hybrid TP+EP configurations (e.g., TP2+EP4), was found to be forced to 1 in the current code [12], with a TODO comment acknowledging that moe_dense_tp_size != 1 is unsupported for non-DeepEP backends. This meant that pure EP8 was the only viable EP configuration—hybrid approaches were blocked by the current implementation.

The Hardware Reality: PCIe-Only, No NVLink

A critical turning point in the investigation came with the hardware topology discovery [17]. Running nvidia-smi topo -m revealed a dual-NUMA configuration: GPUs 0-3 were connected via "NODE" (within the same PCIe root complex on NUMA node 0), GPUs 4-7 similarly on NUMA node 1, but cross-NUMA connections (e.g., GPU 0 to GPU 4) were marked "SYS"—meaning they traversed the system interconnect through the CPU. This topology had profound implications for any communication-intensive parallelism strategy.

The assistant also discovered that neither FlashInfer nor DeepEP was installed on the system [19]. The pip list grep returned empty for both packages, and a direct Python import test for sgl_kernel (which provides the cutlass_w4a8_moe_mm kernel) also failed with ModuleNotFoundError. This meant that the most sophisticated EP backends were unavailable without additional installation steps.

The GPU compute capability was confirmed as SM 12.0 [15], verifying that the RTX PRO 6000 Blackwell GPUs were indeed SM120 architecture with native FP4 tensor core support. This was reassuring—the hardware could execute the FP4 kernels—but the absence of NVLink meant that any EP communication would have to traverse the PCIe fabric.

The Quantitative Analysis: Memory Traffic and GEMM Efficiency

The assistant built a comprehensive quantitative model comparing TP8 and EP8 across multiple dimensions [20]. The analysis computed exact memory traffic per MoE layer, weight load sizes, GEMM dimensions, and communication overhead for both strategies.

The most surprising finding was that TP8 and EP8 load the same total weight data per GPU. Under TP8, each GPU loads 1/8th of each of 256 experts, totaling 32 full expert equivalents (256/8 = 32). Under EP8, each GPU loads full weights of 32 experts—also 32 full expert equivalents. The total weight bytes are identical: 576 MB per MoE layer per GPU. This counterintuitive result reframed the entire comparison. The advantage of EP was not reduced memory traffic but improved GEMM efficiency—the same data arranged into larger, more compute-intensive matrix multiplications.

The detailed memory traffic breakdown revealed that TP8 requires approximately 1,210 MB of total memory traffic per MoE layer (including 42 MB of all-reduce overhead), while EP8 requires only about 592 MB of compute memory traffic plus additional all-to-all communication. The compute time at 1,500 GB/s memory bandwidth was estimated at 846 μs for TP8 versus 395 μs for EP8—a potential 2.1× improvement in compute-bound time.

The communication analysis was more sobering. EP8's all-to-all dispatch and combine operations were estimated at approximately 244 μs on PCIe (at 54 GB/s effective bandwidth), compared to TP8's all-reduce at only 28 μs. With communication-computation overlap (as supported by DeepEP's async mode), the effective EP8 time could be as low as max(395, 244) = 395 μs, still significantly better than TP8's 846 μs. But without overlap, EP8's total time of 639 μs was only marginally better.

The Tile Efficiency Deep Dive

The arithmetic intensity analysis [9] initially suggested that TP8 and EP8 were equivalent, both achieving approximately 170 FLOPS/byte for the W13 GEMM. But this conventional metric proved misleading. The assistant recognized that arithmetic intensity measures the ratio of computation to data movement for an idealized GEMM, but it doesn't account for how the GPU actually executes the operation.

The tile efficiency analysis [8] revealed the true differentiator. Under TP8, the W13 GEMM produces only 2 tiles (1×2) with a 256×256 FP4 tile, achieving 5.6% SM utilization. Under EP8, the same GEMM produces 16 tiles (1×16), achieving 44.4% SM utilization—an 8× improvement. The W2 GEMM was even more dramatic: TP8's K=256 yields only 2 K-tiles, while EP8's K=2048 yields 16 K-tiles. The small K dimension under TP8 is "pathologically small for FP4," as the assistant noted, because the tensor cores cannot pipeline effectively with so few tiles.

The assistant also considered the grouped GEMM across all experts. While total tile counts were identical (1,024 tiles in both configurations), the distribution differed critically: TP8 produced 256 expert GEMMs with 4 tiles each, while EP8 produced 32 expert GEMMs with 32 tiles each. The EP8 approach provides better "wave quantization"—each expert's computation produces enough tiles to fully occupy the GPU's SM array, whereas TP8's tiny per-expert GEMMs leave most SMs idle.

Backend Compatibility: What Actually Works on PCIe

The most practically important analysis was the backend compatibility assessment [18]. The assistant systematically evaluated each EP backend against the hardware constraints of a PCIe-only system without NVLink:

The GLM-Specific Configuration Constraints

The investigation also uncovered model-specific configuration logic in SGLang's server arguments [6]. The Glm4MoeForCausalLM architecture has a dedicated code block that automatically selects flashinfer_trtllm as the MoE runner backend on SM100/SM120 hardware. This auto-selection could override manual backend choices, creating a potential conflict if the assistant attempted to configure EP with a different backend.

The modelopt_fp4 quantization format used by GLM-5-NVFP4 was found to be explicitly handled in multiple validation paths within server_args.py [3]. The code checks is_blackwell_supported() and is_mxfp4_quant_format at line 1370, confirming that the Blackwell-MXFP4 combination receives special handling. This was reassuring—the model's quantization format was recognized—but it also meant that any EP configuration would need to pass through these validation paths without triggering assertion errors.

The critical constraint discovered in [15] was the assertion that Flashinfer MoE A2A is only supported with flashinfer_cutlass moe runner backend. This hard enforcement meant that enabling EP via the FlashInfer A2A backend would force the MoE runner backend to flashinfer_cutlass, which may not support the W4AFP8 quantization format. This created a potential dead end: the EP path required a runner backend that might be incompatible with the model's quantization.

The DeepEP Checkpoint and Installation Barriers

The assistant attempted to install DeepEP via pip [14], but encountered a PEP 668 error—the system refused to install packages outside a virtual environment. This was a deliberate safety mechanism in modern Ubuntu/Python distributions, but it meant that even if DeepEP were the right backend, additional environment setup work would be required.

The listing of available token dispatchers [14] revealed the full set of EP implementations in SGLang's codebase: base.py, deepep.py, flashinfer.py, flashinfer_utils.py, fuseep.py, mooncake.py, moriep.py, and standard.py. The presence of deepep.py was noteworthy given the failed installation—the code existed but the library dependency was missing. The standard dispatcher's NCCL usage was minimal, relying primarily on pynccl_allocator rather than direct NCCL all-to-all collectives.

Synthesis: The EP Decision Framework

The investigation produced a clear analytical framework for the EP vs. TP decision. The key findings can be summarized as follows:

Theoretical advantage: EP8 offers significantly better GEMM efficiency through larger matrix dimensions (8× larger N dimension for W13, 8× larger K dimension for W2). The tile efficiency analysis shows 8× more tiles per expert, enabling much better SM utilization and wave quantization.

Memory traffic: Both TP8 and EP8 load the same total weight data per GPU (576 MB per MoE layer). The difference lies not in data volume but in how that data is arranged in GEMM operations.

Communication overhead: EP8's all-to-all communication on PCIe is estimated at ~244 μs, compared to TP8's all-reduce at ~28 μs. With communication-computation overlap, EP8's effective time could be as low as 395 μs, versus TP8's 846 μs. Without overlap, EP8's 639 μs is only marginally better.

Backend compatibility: The most sophisticated EP backends (DeepEP, MORI) require NVLink or RDMA hardware that doesn't exist on this PCIe-only system. Only FlashInfer A2A and the Standard dispatcher with ep_size > 1 are viable, and FlashInfer is not installed.

Implementation constraints: Hybrid TP+EP configurations (e.g., TP2+EP4) are not supported by the current codebase. Pure EP8 is the only EP option, and it requires the flashinfer_cutlass runner backend, which may conflict with the W4AFP8 quantization path.

Conclusion

The investigation into Expert Parallelism for GLM-5-NVFP4 on Blackwell GPUs reveals a classic tension in systems optimization: theoretical promise versus practical feasibility. The quantitative analysis demonstrates that EP8 offers genuine advantages in GEMM efficiency, with the potential to reduce per-layer compute time from 846 μs to 395 μs. The tile efficiency analysis shows that EP8's larger matrix dimensions provide 8× more tiles per expert, enabling dramatically better SM utilization.

However, the practical path to realizing these gains is narrow. The PCIe-only interconnect without NVLink eliminates the most sophisticated EP backends (DeepEP, MORI), leaving only FlashInfer A2A and the Standard dispatcher as viable options. FlashInfer is not installed, and the Standard dispatcher's EP path may be less performant. The flashinfer_cutlass runner backend required by FlashInfer A2A may conflict with the W4AFP8 quantization format. And hybrid TP+EP configurations that could balance communication and computation are blocked by current codebase limitations.

The investigation demonstrates that effective optimization requires more than theoretical modeling—it demands systematic codebase reconnaissance, hardware topology verification, dependency checking, and constraint analysis. The assistant's methodical approach—from broad grep searches to targeted code reading, from quantitative modeling to backend compatibility assessment—provides a template for anyone facing similar optimization challenges in large-scale ML deployment.

The final assessment is that Expert Parallelism on this PCIe-only Blackwell system is theoretically promising but practically constrained. The recommended path forward would involve installing FlashInfer, verifying the flashinfer_cutlass runner's compatibility with W4AFP8 quantization, and benchmarking EP8 against the optimized TP8 baseline to determine whether the theoretical advantages translate into real-world throughput improvements. Whether EP ultimately wins or not, the analytical framework established in this investigation provides a solid foundation for making that determination.