UBEP: Re-architecting Expert Parallelism Communication Library for Production Superpods

Baochuan Yang; Chang Liu; Guanhua Li; Guihai Chen; Han Bao; Jiaqi Zheng; Junsong Wang; Mingfan Li; Qihang Duan; Si Shen

Reviewed by Pith at T0; open to challenge.

T0 means a machine referee read the full paper against a public rubric. The mark states how deep the mechanical check went, never who wrote it. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · glm-5.2

UBEP cuts MoE All-to-All latency 52% on production superpods

2026-07-08 13:25 UTC pith:BRM2KPJO

load-bearing objection Solid systems paper with real production-scale results; one gap in the end-to-end evaluation needs clarification but does not undermine the core contribution. the 3 major comments →

arxiv 2607.06202 v2 pith:BRM2KPJO submitted 2026-07-07 cs.DC cs.AIcs.NI

UBEP: Re-architecting Expert Parallelism Communication Library for Production Superpods

Yipeng Liu , Chang Liu , Si Shen , Jiaqi Zheng , Mingfan Li , Yuyang Yang , Guanhua Li , Yuquan Zhang

show 11 more authors

Yimeng Xu Zhongzhe Hu Zhiyuan Huang Qihang Duan Junsong Wang Wenkai Ling Baochuan Yang Xianzhi Yu Han Bao Yijie Chen Guihai Chen

This is my paper

classification cs.DC cs.AIcs.NI

keywords Mixture-of-ExpertsExpert ParallelismAll-to-All CommunicationSuperpodUnified BusSynchronizationLoad BalancingHierarchical Scheduling

verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that modern superpod architectures — integrated fabrics like Huawei's CloudMatrix384 with hundreds of NPUs sharing a unified address space — expose a previously hidden bottleneck: when interconnect bandwidth is high enough and link latency is low enough, the software synchronization overhead of traditional Bulk Synchronous Parallel (BSP) communication patterns dominates total execution time. The authors identify three specific problems: rigid phase-level serialization from global barriers, a 'synchronization tax' where flag and barrier costs scale worse than data transfer, and topology-agnostic scheduling that ignores the large latency gap between one-hop and two-hop memory accesses across switching tiers. UBEP addresses all three through kernel decomposition (splitting the monolithic All-to-All into fine-grained tasks assigned to distinct processing cores that can run in parallel), Data-as-Flag synchronization (embedding control signals directly into 512-byte atomic data writes so that receivers detect arrival by polling the data itself, eliminating separate barrier operations), and hierarchical token-level scheduling (a hardware-accelerated mapper that balances both token count and hop-distance distribution across cores, solved via a latency-homogenization heuristic in under one microsecond). Evaluated on 256 NPU dies from a production CM384 superpod, UBEP reduces All-to-All dispatch latency by up to 52.4% and end-to-end inference Time Per Output Token by up to 11.1% across models ranging from Qwen3-30B to DeepSeek-R1, compared to the baseline CANN EP library on identical hardware.

Core claim

The central mechanism is the combination of three synergistic techniques. Kernel decomposition exposes fine-grained, dependency-driven sub-tasks from what was previously a monolithic BSP kernel — for example, overlapping token-count computation with token transmission by assigning them to separate groups of vector cores (AIVs). Data-as-Flag replaces explicit global barriers with implicit synchronization: by leveraging the superpod's native 512-byte atomic write capability, the sender embeds a flag or sentinel value directly in the data payload, and the receiver polls the same memory location to detect arrival — no separate control message required. The paper presents three variants of this (

What carries the argument

The load-bearing object is the Data-as-Flag mechanism built on 512-byte atomic writes: it collapses the control plane into the data plane, making synchronization cost nearly zero on fabrics that support atomic load/store semantics across NPUs. The hierarchical scheduler is the second pillar, proving that topology-aware token assignment (equalizing hop-count distributions across cores) is necessary to avoid stragglers on multi-tier fabrics where two-hop access is 11.5x slower than local access.

Load-bearing premise

The Sentinel Polling variant of Data-as-Flag depends on reserving a 32-byte sentinel value that normal model computation can never produce; if any valid activation or weight pattern across all model configurations matches the sentinel, the synchronization protocol deadlocks. The paper states this is verified at model initialization and estimates collision probability at 2^{-256}, but does not detail the empirical validation scope across diverse architectures, precisions, andg

What would settle it

If a valid MoE activation pattern in some model configuration (e.g., a specific quantization scheme or gating function) produces the reserved sentinel value, the Sentinel Polling synchronization would deadlock, breaking the entire communication protocol. More broadly, if synchronization overhead does not dominate on a given fabric (e.g., on traditional clusters with lower bandwidth), the gains from kernel decomposition and Data-as-Flag would shrink toward zero.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

If synchronization overhead rather than raw bandwidth is the true bottleneck on next-generation superpods, then future interconnect designs should prioritize lower-latency atomic operations and receiver-side notification semantics over simply increasing bandwidth.
The kernel decomposition approach — splitting monolithic collective primitives into dependency-driven sub-tasks — could be applied to other collective communication operations (AllReduce, AllGather) beyond MoE All-to-All, potentially yielding similar gains wherever BSP barriers dominate on low-latency fabrics.
The finding that only half of available processing cores are needed to saturate dispatch bandwidth implies that the remaining cores are available for overlapping computation, suggesting a path toward tighter communication-computation fusion at the kernel level.
The topology-aware scheduling heuristic (per-hop capacity bounding) provides a general framework that extends to arbitrary numbers of switching tiers, making it applicable as superpods scale from hundreds to thousands of accelerators.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The 11.1% end-to-end TPOT improvement being much smaller than the 52.4% operator-level improvement suggests that the remaining MoE inference pipeline (FFN computation, attention, framework overhead) now becomes the dominant bottleneck, and applying the same fine-grained decomposition philosophy to those components could yield further gains.
The Sentinel Polling variant of Data-as-Flag, which achieves theoretical 100% bandwidth utilization but risks deadlock if payload matches the sentinel, could be made safe by reserving a small number of unused bit patterns in the floating-point representation — but this requires per-model validation that may not generalize to future architectures or quantization schemes.
The paper's cost model for optimal AIV allocation (proportional to expert count, inversely proportional to token load) provides a closed-form tuning rule that could be auto-calibrated at runtime, potentially enabling adaptive resource partitioning as batch sizes and routing patterns change during inference.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Desk Editor's Note

Solid systems paper with real production-scale results; one gap in the end-to-end evaluation needs clarification but does not undermine the core contribution.

read the letter

Bottom line: UBEP is a well-engineered communication library that delivers substantial, measured improvements on production hardware. The 52.4% All-to-All latency reduction and 11.1% TPOT improvement on a 256-die CM384 superpod are real systems results, validated with ablations and sensitivity analysis. This deserves a serious referee. There is one gap in the evaluation that I want to flag, but it does not break the paper. The stress-test concern about the Sentinel Polling (SP) variant is legitimate but narrower than it first appears. SP is one of three Data-as-Flag variants, and the paper is candid about its deadlock risk. The real issue is that §5.5 does not specify which variant (TFF, DC, or SP) is used for each model in the end-to-end TPOT evaluation. Two of the four models use W8A8 quantization, and the sentinel safety argument — which relies on unused BF16/FP16 bit patterns — does not directly apply to 8-bit activations where every value is producible. So if SP was used for the W8A8 models, the safety claim is unverified for those runs. If TFF or DC was used instead, the gains might differ from SP's ablation numbers. Either way, the missing variant specification creates a gap between the ablation study and the headline TPOT result. That said, all three variants improve over baseline, so the qualitative claim holds regardless of which was used. The magnitude of the 11.1% number for DeepSeek-R1 specifically is what cannot be fully pinned down. What is genuinely new here: the combination of kernel decomposition replacing BSP barriers with point-to-point data dependencies, topology-aware hop-distance scheduling for multi-tier fabrics, and the Data-as-Flag synchronization family leveraging 512B atomic writes. The cost model derivation (Appendix A) and NP-hardness proof (Appendix B) add formal grounding. The ablation in Figure 9 isolating scheduling effects and Figure 10 isolating sync variants are clean and informative. The portability discussion (Table 5) is honest about what is CM384-specific versus what transfers to other fabrics. No code is shipped, but the hardware-specific environment makes that largely impractical, and the design is described in enough detail for re-implementation. This paper is for distributed systems researchers and engineers working on MoE communication at superpod scale. It deserves a serious peer review. The referee should ask the authors to specify which Data-as-Flag variant was used in the end-to-end evaluation and to address SP safety for W8A8 activations explicitly.

Referee Report

3 major / 8 minor

Summary. This paper presents UBEP, a communication library for Mixture-of-Experts (MoE) inference on production superpods (specifically Huawei's CM384). UBEP addresses three bottlenecks in existing Expert Parallelism Communication Libraries (EPCLs): (1) BSP-style serialization, addressed via kernel decomposition into fine-grained, dependency-driven tasks; (2) synchronization overhead, addressed via a Data-as-Flag mechanism that embeds synchronization signals in data payloads using 512-byte atomic writes; and (3) topology-agnostic scheduling, addressed via a hierarchical token-level scheduler that balances load across AIVs while accounting for multi-tier fabric latency. The system is evaluated on a 256-die CM384 superpod, reporting up to 52.4% reduction in All-to-All latency and up to 11.1% improvement in end-to-end TPOT compared to the CANN EP baseline.

Significance. The paper tackles a timely and practically important problem: optimizing sparse MoE communication on unified-memory superpods where reduced link latency exposes software overheads previously hidden by slower interconnects. The three core mechanisms (kernel decomposition, Data-as-Flag, hierarchical scheduling) are well-motivated and the evaluation on production hardware at 256-die scale is a notable strength. The cost model for AIV allocation (Appendix A) and the NP-hardness proof for the scheduling problem (Appendix B) add analytical depth. The ablation studies (§5.4) isolate each component's contribution. The portability discussion (§6, Table 5) usefully separates CM384-specific assumptions from portable ideas. The Data-as-Flag mechanism, while relying on hardware-specific 512-byte atomicity, is a creative approach to eliminating explicit synchronization barriers.

major comments (3)

§5.5, Figure 11: The end-to-end TPOT evaluation does not specify which Data-as-Flag variant (TFF, DC, or SP) is used for each of the four models. This matters because Figure 10 shows variant-dependent latency differences (SP achieves lower latency across most settings), and Table 3 shows two models (DeepSeek-R1, DeepSeek-V3.2) use W8A8 quantization. The SP variant's sentinel safety argument (§3.4) is framed around BF16/FP16 unused bit patterns, but for W8A8 every 8-bit value is a valid activation, making the sentinel collision risk qualitatively different. If SP is used for the W8A8 models that achieve the headline 11.1% improvement, the safety of those results depends on an unverified invariant. If TFF or DC is used instead, the gains may differ from SP's potential. The paper should specify which variant is used per model and either confirm SP safety for W8A8 or clarify that TFF/DC is用于
§3.4, paragraph on SP correctness: The paper states the sentinel is 'an unused bit pattern in BF16/FP16' and that collision probability is 2^{-256} under uniform distribution. However, the argument that activations 'occupy a narrow subset of the value space' (making the bound 'far lower') is asserted without evidence. Neural network activations are not uniformly distributed — they exhibit structured, heavy-tailed distributions — so the 2^{-256} bound may be optimistic or pessimistic depending on the sentinel choice. More importantly, the paper does not describe what happens if a collision is detected at runtime (deadlock is mentioned but no fallback mechanism is specified). For a production-ready library, the absence of a runtime detection/fallback for SP collisions is a gap. The paper should either (a) describe a watchdog/fallback mechanism, or (b) recommend TFF/DC for configurations (e
§5.2, Table 4: DeepEP is evaluated on H800 while CANN EP and UBEP are on CM384. The paper notes DeepEP is included as a 'protocol-capability reference,' but the table structure invites direct cross-hardware comparison of latency numbers (e.g., DeepEP 16-rank at 118μs vs. UBEP at 73μs). While the text does note the hardware difference, the table caption or a row annotation should make this non-comparability more prominent to avoid misreading. This is a presentation issue that affects how the central performance claims are interpreted.

minor comments (8)

§5.3, Figure 8 caption and text: 'idle tome' should be 'idle time' in the sentence 'reducing the idle tome of AIVs.'
§3.3, Algorithm 1: The quaternary search algorithm is described as converging in 4-5 steps for typical expert counts, but the complexity is not stated explicitly (O(log_4 N_exp)). Adding this would help readers assess scalability.
§2.3, Table 2: The latency values for Intra-NPU (2181 ns) and One-Hop (9294 ns) appear to have formatting issues — the 'Normalized' column shows '1.0×' and '4.3×' but the main latency column appears to concatenate digits oddly (e.g., '2181.0×' could be '218' with normalized '1.0×'). Please verify.
§3.4, Figure 6: The figure labels for subfigures (a), (b), (c) use different naming conventions in the text vs. the figure. The text refers to 'Token-Flag Fusion (TFF),' 'Data-for-Checksum (DC),' and 'Sentinel Polling (SP),' but Figure 6(b) is labeled 'Data for CheckSum' and the caption uses 'Data-for-Checksum.' Consistent naming would help.
Appendix A, Eqs. (2)-(9): The cost model uses F(·) and G(·) as 'linear scaling functions' but then assumes F(x)=αx and G(x)=βx only in the approximation step. The model would be clearer if linearity were stated upfront or if the approximation step explained why non-linear scaling is negligible.
§5.5: The paper states 'MoE communication accounts for roughly 50% of per-token latency... but only about 20% of actual hardware execution time,' suggesting 'substantial dependency stalls and runtime overhead.' This is an interesting finding that deserves more analysis — which specific stalls are responsible? This could strengthen the motivation for future work.
§1, Table 1: The 'Pipeline' column for CANN EP is listed as 'Intra-only' with a superscript '2' but the footnote marker placement is ambiguous — it could be read as 'Intra-only²' (squared) rather than a footnote reference.
References: Several arXiv preprints are cited with future dates (e.g., [53] dated 2026, [2] accessed June 2026). If this is a 2026 submission this is fine, but please verify all dates are accurate.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the careful reading and constructive feedback. The three major comments are all valid and will be addressed in the revision. Below we respond point by point.

read point-by-point responses

Referee: §5.5, Figure 11: The end-to-end TPOT evaluation does not specify which Data-as-Flag variant (TFF, DC, or SP) is used for each of the four models. This matters because Figure 10 shows variant-dependent latency differences, and Table 3 shows two models use W8A8 quantization. The SP variant's sentinel safety argument is framed around BF16/FP16 unused bit patterns, but for W8A8 every 8-bit value is a valid activation, making the sentinel collision risk qualitatively different.

Authors: The referee is correct on all counts. The current manuscript does not specify which Data-as-Flag variant is used per model in the end-to-end evaluation, and the SP safety argument as written applies to BF16/FP16 but not to W8A8. We will revise the manuscript to address both issues. First, we will add a column or annotation to Table 3 (or a note in §5.5) specifying the variant used for each model. In our actual deployment, the BF16 models (Qwen3-30B, GLM-4.7) use SP, while the W8A8 models (DeepSeek-R1, DeepSeek-V3.2) use DC. This is precisely because SP's sentinel mechanism cannot guarantee a collision-free sentinel for 8-bit quantized activations, as the referee correctly identifies. Second, we will make explicit in §3.4 that SP is restricted to BF16/FP16 configurations and that DC (or TFF) should be used for low-precision quantization where every bit pattern is a valid value. We will also note in §5.5 that the headline 11.1% TPOT improvement for DeepSeek-R1 is achieved with DC, not SP, so the result does not depend on SP's sentinel safety. We agree this information is essential for reproducibility and for readers to correctly interpret the results. revision: yes
Referee: §3.4, paragraph on SP correctness: The paper states the sentinel is 'an unused bit pattern in BF16/FP16' and that collision probability is 2^{-256} under uniform distribution. However, the argument that activations 'occupy a narrow subset of the value space' is asserted without evidence. More importantly, the paper does not describe what happens if a collision is detected at runtime (deadlock is mentioned but no fallback mechanism is specified). The paper should either (a) describe a watchdog/fallback mechanism, or (b) recommend TFF/DC for configurations where SP safety cannot be guaranteed.

Authors: The referee raises two valid points: (1) the claim that activations occupy a narrow subset of the value space is unsupported, and (2) there is no runtime detection/fallback for SP collisions. On the first point, we agree the assertion is informal and not backed by empirical distribution analysis. We will soften the language: rather than claiming the bound is 'far lower' in practice, we will state that the 2^{-256} figure is a worst-case bound under uniform distribution and that the actual collision probability depends on the sentinel choice and activation distribution, which we do not formally characterize. On the second point, we will add a description of the runtime safety mechanism used in our implementation. Specifically, UBEP includes a watchdog timer on the receiver side: if a sentinel check does not observe a change within a threshold interval (set conservatively based on the expected maximum transmission latency), the receiver falls back to an explicit flag-based verification (equivalent to TFF) for that DataBlock. This prevents indefinite deadlock while retaining SP's bandwidth advantage in the common case. We will also add the recommendation that TFF or DC should be used for configurations where sentinel safety cannot be statically verified (including W8A8), as noted in our response to the first comment. Both changes will be incorporated into §3.4. revision: yes
Referee: §5.2, Table 4: DeepEP is evaluated on H800 while CANN EP and UBEP are on CM384. The table structure invites direct cross-hardware comparison of latency numbers. While the text notes the hardware difference, the table caption or a row annotation should make this non-comparability more prominent to avoid misreading.

Authors: This is a fair presentation concern. We will revise Table 4 to make the hardware distinction more prominent. Specifically, we will add a horizontal rule between the DeepEP row and the CANN EP / UBEP rows, include '(reference only — different hardware)' in the DeepEP row label, and update the caption to explicitly state that DeepEP numbers are on H800 and are included solely as a protocol-capability reference, not for direct latency comparison. We agree that the current table format could lead to misreading and will make the non-comparability visually and textually clear. revision: yes

Circularity Check

0 steps flagged

No significant circularity found; the derivation is self-contained against external benchmarks.

full rationale

The paper's central claims—52.4% All-to-All latency reduction and 11.1% TPOT improvement—are measured against CANN EP (ref [57]) on identical CM384 hardware. While CANN EP is a prior system from overlapping authors (Huawei), it serves as an independent baseline: the improvements are empirically measured, not derived by definition from the baseline. The cost model (Appendix A, Eqs. 2-9) derives an AIV allocation ratio n_count ∝ N_exp/(K_top × B_sz) from stated assumptions (linear scaling, communication dominance, negligible constants), then validates it empirically (Appendix C.3, Figure 14). The NP-hardness proof (Appendix B) reduces from Subset Sum—a standard external reduction, not self-citation. The Data-as-Flag mechanism (§3.4) is a novel design with correctness argued from 512B atomicity assumptions, not circularly defined. The hierarchical scheduler (§3.3) formulates an optimization problem (Eq. 1), proves NP-hardness, then proposes a heuristic (latency homogenization) that is evaluated empirically (§5.4, Figure 9). No step reduces to its inputs by construction. The one minor concern is that CANN EP [57] shares authors with this paper, but it is a real deployed system used as a comparison point, not a self-citation that load-bears the theoretical derivation. This is normal self-citation, not circularity.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 2 invented entities

The axiom ledger captures the key assumptions underlying UBEP's design. The 512B atomicity and linear scaling assumptions are standard domain assumptions for the CM384 hardware. The sentinel-value assumption for SP is the most ad-hoc, as it requires a universal invariant across model configurations that is asserted but not rigorously proven. The free parameters (AIV allocation ratio, sentinel value) are either empirically tuned or hardware-constrained rather than theoretically derived with closed-form constants.

free parameters (3)

AIV allocation ratio (n_count vs n_token) = tuned empirically per configuration (Fig. 14)
The cost model (Appendix A, Eq. 8) gives n_count proportional to N_exp / (K_top * B_sz), but the proportionality constant beta/alpha is not specified. Actual allocation is tuned via grid search (Appendix C.3, Figure 14) across batch sizes and rank counts.
Sentinel value for SP variant = an unused bit pattern in BF16/FP16 (not specified exactly)
The Sentinel Polling mechanism (§3.4) requires a reserved sentinel encoding that cannot be produced by normal computation. The specific value is chosen at model initialization but the selection criteria and validation procedure are not detailed.
DataBlock size for TFF = 512 bytes (32B flag + 480B payload)
Set by the hardware's 512B atomic write granularity. Not a free parameter in the traditional sense but a design parameter constrained by hardware capability.

axioms (5)

domain assumption 512B atomic writes are guaranteed by the UB Fabric across scale-up and NoC domains on CM384.
Stated in §2.3 (Insight 2) and §3.4. The entire Data-as-Flag mechanism depends on this hardware guarantee. The paper notes degradation paths if this is absent (Table 5).
domain assumption Token transmission time per token is approximately uniform across tokens (tokens have uniform sizes much smaller than bandwidth).
Stated in §3.3 (Latency Homogenization). Justifies reducing the sum of l_i to a count proportional to x_ij, enabling the per-hop capacity bound heuristic.
domain assumption Transmission time for a single token is much shorter than network propagation latency on high-bandwidth superpods.
Stated in §3.3. Justifies focusing optimization on the RTT term rather than the transmission term in the objective function.
domain assumption F(x) = alpha*x and G(x) = beta*x are linear scaling functions for communication and computation latency.
Stated in Appendix A (Approximation and Solution). Enables the closed-form allocation ratio in Eq. 8. Validated empirically in Appendix C.3 but not proven from first principles.
ad hoc to paper A sentinel value exists that cannot be produced by normal MoE computation across all model configurations.
Stated in §3.4 (Correctness and safety assumptions). Required for the SP variant of Data-as-Flag. The paper claims verification at model initialization but does not prove this holds universally across all activation functions, precisions, and weight distributions.

invented entities (2)

Data-as-Flag synchronization protocol (TFF, DC, SP variants) independent evidence
purpose: Eliminates explicit software barriers by embedding synchronization signals into data payloads or using data itself as a completion signal.
The mechanism is validated empirically (Figure 10) with latency measurements across granularities and rank counts. The correctness argument is provided via happens-before reasoning under the 512B atomicity assumption. Falsifiable: if atomicity does not hold, the protocol is incorrect.
Hierarchical token-level scheduler with latency homogenization independent evidence
purpose: Balances token-to-core assignments while equalizing hop-count distributions to minimize straggler effects from multi-tier fabric latency.
Validated via ablation (Figure 9) showing reduced AIV-level latency variance compared to topology-agnostic baselines. The NP-hardness of the exact problem is proven (Appendix B), and the heuristic is shown to produce near-uniform latency in practice.

pith-pipeline@v1.1.0-glm · 35945 in / 3693 out tokens · 464810 ms · 2026-07-08T13:25:40.731569+00:00 · methodology

0 comments

read the original abstract

The deployment of Mixture-of-Experts (MoE) models on production high-bandwidth superpods, such as NVIDIA's NVL72/576 and Huawei's CloudMatrix384, introduces critical challenges beyond raw interconnect bandwidth. While these systems provide unified global address spaces and high-bandwidth fabrics, their full potential for sparse MoE communication is hindered by three fundamental bottlenecks: (1) Strict execution serialization imposed by coarse-grained Bulk Synchronous Parallel (BSP) orchestration of interdependent communication phases; (2) Prohibitive synchronization overhead that fails to scale alongside high interconnect bandwidth; and (3) Severe load imbalance resulting from distance-agnostic scheduling of irregular token traffic. To eliminate these bottlenecks, we introduce UBEP (Unified-Bus Expert Parallelism), a production-ready communication library that rethinks MoE's All-to-All primitives for modern superpod architectures. Through large scale experiments, UBEP reduces All-to-All latency by up to 52.4% and MoE inference Time Per Output Token (TPOT) by up to 11.1%.

Figures

Figures reproduced from arXiv: 2607.06202 by Baochuan Yang, Chang Liu, Guanhua Li, Guihai Chen, Han Bao, Jiaqi Zheng, Junsong Wang, Mingfan Li, Qihang Duan, Si Shen, Wenkai Ling, Xianzhi Yu, Yijie Chen, Yimeng Xu, Yipeng Liu, Yuquan Zhang, Yuyang Yang, Zhiyuan Huang, Zhongzhe Hu.