Layerwise Recurrent Router for Mixture-of-Experts

## Abstract

Abstract The scaling of large language models (LLMs) has revolutionized their capabilities in various tasks, yet this growth must be matched with efficient computational strategies.
The Mixture-of-Experts (MoE) architecture stands out for its ability to scale model size without significantly increasing training costs.
Despite their advantages, current MoE models often display parameter inefficiency.
For instance, a pre-trained MoE-based LLM with 52 billion parameters might perform comparably to a standard model with 6.7 billion parameters (Rajbhandari et al., 2022 ) .
Being a crucial part of MoE,
current routers in different layers independently assign tokens without leveraging historical routing information, potentially leading to suboptimal token-expert combinations and the parameter inefficiency problem.
To alleviate this issue, we introduce the Layerwise Recurrent Router for Mixture-of-Experts (RMoE).
RMoE leverages a Gated Recurrent Unit (GRU) to establish dependencies between routing decisions across consecutive layers.
Such layerwise recurrence can be efficiently parallelly computed for input tokens and introduces negotiable costs.
Our extensive empirical evaluations demonstrate that RMoE-based language models consistently outperform a spectrum of baseline models.
Furthermore, RMoE integrates a novel computation stage orthogonal to existing methods, allowing seamless compatibility with other MoE architectures.
Our analyses attribute RMoE’s gains to its effective cross-layer information sharing, which also improves expert selection and diversity.
Our code is at https://github.com/qiuzh20/RMoE

## 1 Introduction

In the era of large language models (LLMs), scaling the model parameters and training data up has unlocked remarkable model capabilities, such as in-context learning (Brown et al., ; Dong et al., ), nuanced conversations (Ouyang et al., ), and even complex code (Guo et al., ) and math (Imani et al., ) tasks.
These advancements showcase the profound impact of increasing model size.
The quest to enhance neural networks’ capacity while ensuring training and inference efficiency spurred the development of computation-efficient transformer architectures.
The Mixture-of-Experts (MoE) framework is one of such efficient architectural recipes (Shazeer et al., ; Lepikhin et al., ; Fedus et al., ; Zhang et al., ; Dai et al., ).
Most MoE modules comprise one router and a group of expert networks.
The router, usually parametrized as one linear layer, conditionally and sparsely assigns each input token to its corresponding experts, i.e., the FeedForward Network (FFN) in the transformer layer.
Therefore, MoE can significantly scale the model size and keep computational costs nearly unchanged (Smith et al., ).

Despite efficiently increasing the model size, most current pre-trained MoE models are not on par with standard models of the same size, demonstrating their parameter inefficiency.
For example, Rajbhandari et al. () shows that with the same training data, an MoE with 52B parameters and 1.3B activated ones for each token performs similarly to a 6.7B standard model.
Komatsuzaki et al. () demonstrates that upcycling a standard T5-base (248M) into its MoE counterpart (2B) by copying existing FFN can bring some improvements, but it still lags behind the T5-large with 783M parameters.
Similarly, Dai et al. () use fine-grained and shared experts to improve the effectiveness, but the 16B MoE performs comparably with the 7B standard model (Bi et al., ).

One potential bottleneck for the current MoE could be the router.
Typically, the router is parameterized as one lightweight linear layers, which may limit its capacity to explore the optimal token-expert combination.
Previous works also reveal such limitations.
For instance,  Xue et al. () finds the routing results converge to the token-id-based routing very quickly during the early phase of pre-training, which means the token-expert combination is far from well-explored.
Some works even show hash functions (Roller et al., ), stochastic routing policy (Zuo et al., ), and fixed-random router (Chen et al., ) achieves competitive performance with the learnable router, illustrating that the learnable router component in MoE needs further enhancement.

Figure: Figure 1: Recurrent router for Mixture-of-Experts. In the $i$-th layer, the hidden state $\mathbf{x}_{i}$ is I. projected to $\mathbf{x}^{\prime}$ with alower hidden dimension (Eq. 4), II. combined with previous layer’s GRU output $\mathbf{h}_{i-1}$, and processed through the cross-layer-shared GRU to produce the current layer’s GRU output, $\mathbf{h}_{i}$ (Eq. 5). III. layer $i$’s router uses this output to select experts and executes standard MoE computation (Eq. 6). Such operation doesn’t introduce sequence-level recurrence and can be efficiently implemented, as shown in Tab. 1 and Tab. 3.
Refer to caption: x1.png

Despite some enhancements for router (Chi et al., ; Shen et al., ; Do et al., ; Chen et al., ), current routers in different MoE layers still operate independently without comprehensive investigations into the decisions of other layers.
This isolation may lead to suboptimal expert utilization, as each layer manages its routing based solely on local information, potentially leading to inefficiency of model parameters.
Though vanilla MoE models could technically share the routing information via hidden states residual, this information may be overshadowed by the language modelling loss, requiring routing-relevant information to ”compete” for its representation.

To this end, we introduce a dedicated component to capture and pass routing information for each layer.
The proposed architecture, Recurrent Router for Mixture-of-Experts (RMoE), is shown in the Fig. 1.
Concretely, we regard routing decisions in consecutive layers as a sequence in which the routing results of the $i$-th layer should be conditioned on previous layers’ decisions.
We thus introduce a lightweight Gated Recurrent Unit (GRU) (Dey & Salem, ) to capture this dependence and simulate the information flow between routers across layers.
Intuitively, GRU has a reset and an update gate to control the information flow across time steps.
Hence, such layerwise recurrence will inform the router to which experts the current token was assigned in previous layers, potentially supporting cross-layer collaborations.
Furthermore, the introduced GRU is especially for routing. It thus helps to disentangle the states relevant to model prediction and routing decisions.

We validate RMoE’s performance with various model sizes, architectures, datasets, and training settings (per-training and supervised fine-tuning), demonstrating that RMoE outperforms a range of baselines.
Moreover, RMoE’s introduction of a novel computation stage during routing makes it orthogonal to and compatible with most existing methods.
We further analyze RMoE and elucidate the primary contributors to its improvement.
Our findings indicate that while the relatively complex GRU in RMoE shares essential cross-layer information, it also enables additional gradient propagation for the router.
Our analysis shows that layerwise recurrence provides cross-layer information, fostering router exploration and optimizing expert utilization.
Consequently, the selected experts are leveraged more effectively, leading to increased diversity of experts.
We believe that our innovative router design and massive analysis can offer insights into the development of future MoE models.

## 2 Related Works: Various Routers for MoE

In this section, we review previous approaches to improve router design in SMoE.
For example, XMoE (Chi et al., ) first projects hidden states into a lower-dimension space and computes their cosine-similarity to low-dimension expert embeddings, which can prevent the hidden states from collapsing to a linear combination of expert embeddings.
Moduleformer (Shen et al., ) uses an MLP router with ReLU activation to increase router capacity.
SMoE-dropout (Chen et al., ) utilizes a fixed random-initialized linear router and gradually increases $\operatorname{Top-k}$ during training.
HyperMoE (Do et al., ) introduces a fixed random-initialized hypernet (Ha et al., ) at each layer to generate router weights condition on input and one learnable router embedding.
One concurrent work (Gong et al., ) also introduces GRU in sequential routing stages.
However, it does not view such a recurrent mechanism as a general and composable method with broad MoE fields or provide relative ablation or analysis.
Extra discussion of related work to improve MoE from routing and training strategies, and utilize recurrent controllers can be found in App. A.1.

## 3 Methodology

### 3.1 Preliminaries

##### Mixture-of-Experts

MoEs are typically implemented by replacing transformer models’ original feed-forward networks (FFNs) with a group of parallel FFNs and incorporating a router.
Suppose there are $N$ experts, denoted as $E_{n},n\in[1,N]$. The router $g(\cdot;\mathbf{G},k)$, defined by its parameters $\mathbf{G}\in\mathbb{R}^{(h,N)}$ and an integer $k$, maps the input $\mathbf{x}$ to a score distribution over the experts, $g(\mathbf{x};\mathbf{G},k)\in\mathbb{R}^{N}$.
Given $\mathbf{x}\in\mathbb{R}^{h}$, the output $\mathbf{y}\in\mathbb{R}^{h}$ is the weighted sum of the outputs from all experts:

$$ $\mathbf{y}=\sum_{n\in N}g_{n}(\mathbf{x};\mathbf{G},k)E_{n}(\mathbf{x})$ (1) $$

Typically, $g$ is a simple linear layer followed by a $\operatorname{softmax}$ and a $\operatorname{Top-k}$ function.
The $n$ th element of $\textbf{x}\times\mathbf{G}\in R^{N}$ represents the gating score of expert $E_{n}$, and the $n$ th column of $\mathbf{G}$ can be regarded as the expert embedding for expert $E_{n}$.
When $k$ for $\operatorname{Top-k}$ is smaller than $N$, only a subset of experts is involved in the computation, which is known as Sparse Mixture-of-Experts (SMoE) (Shazeer et al., ; Fedus et al., ).

##### Recurrent Neural Networks

RNNs (Medsker et al., ) are designed to handle sequential data by maintaining a hidden state $\mathbf{h}$ that holds the information from previous time steps.
This hidden state is updated at each time step $i$ based on the current input $\mathbf{x}^{\prime}_{i}$ and the hidden state at the last time step $\mathbf{h}_{i-1}$, formulated as $\mathbf{h}_{i}=f(\mathbf{h}_{i-1},\mathbf{x}^{\prime}_{i})$.

The Gated Recurrent Units Dey & Salem () module is an advanced variant of RNNs that addresses some of the traditional RNNs’ limitations, such as difficulty capturing long-term dependencies and gradient vanishing issues.
Given an input $\mathbf{x}^{\prime}_{i}$ at time step $i$, GRU first calculates the reset gate $\mathbf{s}_{i}$ and the update gate $\mathbf{z}_{i}$ to determine how much of the previous memory to keep and to forget,

$$ $\displaystyle\mathbf{s}_{i}$ $\displaystyle=\sigma(\mathbf{W}_{s}\mathbf{x}^{\prime}_{i}+\mathbf{U}_{s} \mathbf{h}_{i-1})$ (2) $\displaystyle\mathbf{z}_{i}$ $\displaystyle=\sigma(\mathbf{W}_{z}\mathbf{x}^{\prime}_{i}+\mathbf{U}_{z} \mathbf{h}_{i-1})$ $$

where $\sigma$ represented the sigmoid activation function and all $\mathbf{W}$ and $\mathbf{U}$ are tranable parameters. And then, the hidden state $h_{t}$ is updated by

$$ $\displaystyle\mathbf{\tilde{h}}_{i}$ $\displaystyle=\tanh(\mathbf{W}_{h}\mathbf{x}^{\prime}_{i}+\mathbf{s}_{i}\odot( \mathbf{W}_{h}\mathbf{h}_{i-1}))$ (3) $\displaystyle\mathbf{h}_{i}$ $\displaystyle=(1-\mathbf{z}_{i})\odot\mathbf{\tilde{h}}_{i}+\mathbf{z}_{i} \odot\mathbf{h}_{i-1}$ $$

### 3.2 Layerwise Recurrent Router

Existing routers work independently,
this lack of global information may prevent routers from discovering more effective token-expert combinations.
Therefore, we integrate a GRU into the routing process, explicitly incorporating historical routing information into the current expert selection for each token.
Formally, at the $i$ th layer, we first project the hidden state $\mathbf{x}_{i}$ to the dimension of the GRU state $\mathbf{x}^{\prime}_{i}\in\mathbb{R}^{p}$ (usually smaller than the dimension $h$ of $\mathbf{x}_{i}$.
We choose 128 for most of the settings to save computational cost and provide further analysis in Tab. 6 and Tab. 7):

$$ $\mathbf{x}^{\prime}_{i}=\operatorname{Proj}_{i}(\mathbf{x}_{i})$ (4) $$

Importantly, we use separate projectors for each layer since the hidden states $\mathbf{x}$ of different layers vary greatly (more discussion in Sec. 5). This projection output $\mathbf{x}^{\prime}$, along with the GRU result from the previous layer, $\mathbf{h}_{i-1}$, is then fed into a GRU unit to obtain the current GRU output $\mathbf{h}_{i}$.

$$ $\mathbf{h}_{i}=\operatorname{GRU}(\mathbf{x}^{\prime}_{i},\mathbf{h}_{i-1}).$ (5) $$

Next, $\mathbf{h}_{i}$ is input into the router to make router decisions and then to aggregate different experts based on that decision:

$$ $\mathbf{y_{i}}=\sum_{n\in N}g_{n}(\mathbf{h}_{i};\mathbf{G}_{i},k)E_{n}( \mathbf{x}_{i}).$ (6) $$

Here, $\mathbf{y}_{i}$ represents the output of the $i$-th layer, $\mathbf{h}_{i}$ is the GRU output, $g_{n}(\mathbf{h}_{i};\mathbf{G_{i}},k)$ is the router output computed with routing parameter $\mathbf{G_{i}}$ in layer $i$.
Notice that, unlike traditional RNNs, which use a shared projector together for sequential inputs when the input dimension isn’t equal to the RNN’s hidden dimension, we use different projectors $\operatorname{Proj}_{i}$ in Eq. 4 for different layers since hidden states and model weights in different layers usually various a lot (Fig. 13 and Tab. 6).

Despite capturing inter-layer dependencies between routers in different layers, RMoE potentially has other advantages:
(1) Prevent representation collapse: Chi et al. ()
identified that the single linear layer routers encourage token embeddings clustering around
expert embedding, implying a trend toward representation collapse issue.
And they propose XMoE to first project hidden states into a low-dimension and then calculate the gating score.
Similarly, the projector (Eq. 4) and GRU (Eq. 6) in RMoE also separate hidden states from expert embeddings and can reduce this issue.
(2) Additional Gradient Flow:
Before the inclusion of GRU, the router’s gradient mainly derive from the expert weight score $g_{n}$ in Eq. 1.
The introduction of GRU not only provides enriched information about historical routing
but also an extra gradient propagation through GRU hidden states.
We denote this extra gradient flow as Recurrent Gradient, and we empirically demonstrated that this Recurrent Gradient is important to RMoE.
(3) Applicable with other MoE design: the proposed method introduces an additional computation stage into SMoE, it is orthogonal to most existing attempts to improve MoE and is seamlessly compatible with them.

## 4 Experiments

### 4.1 Experimental settings

##### Langauge Modeling Tasks and Metrics

Following (Pham et al., ),
we first test on two common language modeling tasks: enwiki8 (character-level language modeling, with Bits-Per-Character (BPC) as the evaluation metrics) and WikiText-103 (word-level language modeling, with Perplexity (PPL) as the evaluation metrics).
We employ default train-validation-test splits for each dataset.
We report test performances of the best validation checkpoints.
More details can be found in App. A.2.

##### Configurations and Baselines

We mainly compare RMoE with other existing router designs.
All methods are based on the decoder-only standard switch-transformer architecture.
Following Pham et al. (), all routers adopt the same MoE configuration: selecting top-2 experts from 16 experts. Each task is trained on 2 NVIDIA A100 GPUs for about 20 hours.
More training configurations can be found in App. A.2.
Our baselines include
(1) SMoE: standard switch-transformers with a standard linear router.
(2) HyperMoE (Do et al., ):
the method employs a fixed, randomly initialized hypernetwork (Ha et al., ) to produce the weights for the linear router, subsequently allowing the generated linear layer to perform the routing.
(3) SMoE-MLP (Shen et al., ): it replaces the linear router with a two-layer MLP using the GELU activation function.
(4) RandomMoE: inspired by SMoE-Dropout (Chen et al., ) and HyperMoE, we propose to compare with a fixed randomly initialized linear router; this could be a naive baseline for all learnable routers.
(5) XMoE (Chi et al., ): it first down-projects the token embeddings to a lower dimension (default 16) and computes its cosine-similarity with the low-dimension expert embeddings. It also uses a learnable temperature in softmax operation.
(5) CosineSMoE, similar to XMoE except without down-projection.

##### Pre-Training and SFT paradigm

As pre-training-then-supervised-fine-tuning has become the standard paradigm, we also evaluate the RMoE in this setting.
Our pre-training corpus is a multilingual data collection that spans common and specialized domains, including Wikipedia, finance, and legal texts.
We follow the filtering guidelines in Redpajama V2 (Computer, ) and subsequently perform a de-duplication process on the filtered data, yielding approximately 126.5 billion high-quality tokens.
Our model architecture is modified based on Llama family (Touvron et al., ).
Specifically, we use a 24-layer model and top-4 gating from 16 experts per layer following (Dai et al., ).
This yields a model with approximately 0.53B activated / 0.91B total parameters.
All different routers use the same training configurations.
To ensure expert load balance, we employ balance loss with weights $0.01$ during training.
These experiments are conducted using the Megablocks (Gale et al., ) on 8 NVIDIA A100 GPUs for about 5 days. More details can be found in App. A.2.
After pertaining, we perform supervised fine-tuning (sft).
All models are trained on Alpaca (Taori et al., ) with the same configuration.
We use lm-evaluation-harness(^1^11https://github.com/EleutherAI/lm-evaluation-harness) to evaluate the fine-tuned model.
To simulate the real LLMs application scenario, we don’t perform task-specific fine-tuning and evaluation.
Since the models are largely under-trained due to computation resource limitation, they give almost random-guessing results on challenging tasks like MMLU (Hendrycks et al., ).
Therefore, we only test on tasks (ARC-easy, Hellaswag, PIQA, SciQ, LAMBADA) in lm-evaluation-harness, where the results largely surpass random guessing. More details about sft configurations and tasks can be found in App. A.2.

### 4.2 Main Results

**Table 1: Performance of RMoE and baselines on two language modeling tasks, Enwiki8 and WikiText-103. Params means the non-embedding model parameters and (router parameters). Notice we don’t separate unlearnable parameters in HyperMoE and RandomSMoE. Mem means the peak GPU memory usage with the same batch-size configurations. Speed is the average time for 1k training steps. Results demonstrate that the RMoE outperforms baseline models and achieves comparable memory usage and speed as the standard SMoE.**
| Algorithm | Enwiki8 (BPC)$\downarrow$ | WikiText (PPL)$\downarrow$ | Params | Mem | Speed |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- |
| val | test | val | test | (M) | (GB) | (s/1k steps) |  |
| SMoE | 1.152 | 1.128 | 31.279 | 33.061 | 36.08 (0.04) | 47.92 | 960.2 |
| HyperMoE | 1.162 | 1.139 | 31.918 | 33.374 | 48.41 (12.4) | 49.69 | 962.0 |
| SMoE-MLP | 1.164 | 1.137 | 31.430 | 33.142 | 36.79 (0.75) | 48.70 | 964.1 |
| RandomSMoE | 1.163 | 1.135 | 31.938 | 33.410 | 36.08 (0.04) | 47.72 | 961.4 |
| CosineMoE | 1.148 | 1.122 | 31.367 | 33.047 | 36.08 (0.04) | 48.68 | 962.4 |
| XMoE | 1.150 | 1.125 | 31.265 | 32.926 | 36.13 (0.09) | 48.70 | 967.5 |
| RMoE | 1.141 | 1.116 | 30.939 | 32.867 | 36.51 (0.47) | 49.46 | 972.9 |

**Table 2: Performance of combining layer-wise recurrent routing mechanism with XMoE.**
| Algorithm | Enwiki8 (BPC)$\downarrow$ | WikiText (PPL)$\downarrow$ |  |  |
| --- | --- | --- | --- | --- |
| Val | test | val | test |  |
| XMoE (8) | 1.160 | 1.132 | 31.74 | 33.55 |
| + GRU router | 1.150 | 1.124 | 31.34 | 32.99 |
| XMoE (16) | 1.150 | 1.125 | 31.27 | 32.93 |
| + GRU router | 1.144 | 1.119 | 31.15 | 32.47 |
| XMoE (32) | 1.140 | 1.114 | 31.30 | 32.71 |
| + GRU router | 1.136 | 1.112 | 31.25 | 32.55 |

Tab. 1 shows the performance of RMoE and selected baselines on two language modelling tasks.
Our observations are as follows:
(1) RMoE performs best on validation and test sets of two tasks, and the recurrent routing mechanism and the introduction of extra GRU block do not severely impact the training speed and memory usage, making RMoE more practical.
(2) Comparing SMoE-MLP and SMoE, we find that replacing the original simple linear layer with a more capable MLP does not improve performance. It even underperforms the fixed random routing (RandomMoE) on Enwikik8, suggesting that naively increasing model capacity can’t result in a more powerful router.
Furthermore, since RMoE introduces novel computation stages in routing and is orthogonal to most existing router designs, it can easily be combined with them.
Tab. 2 showcases the performance of the original XMoE and XMoE with GRU router in different XMoE lower dimensions (8, 16, and 32). We observe that the GRU router benefits all of the 3 configurations of XMoE.

**Table 3: SMoE and RMoE’s pre-training costs and evaluation results in selected informative lm-evaluation-harness tasks. ‘sft’ means supervised fine-tuning on the Alpaca dataset. The task names and metrics for short names in the table are: ‘ARC-e’ for ARC-Easy, acc; ‘Hella’ is for Hellaswag, acc-norm; ‘Piqa’ for PIQA, acc-norm; ‘Lamb’ for LAMBADA, acc. Each model has approximately 0.53B activated parameters out-of 0.91B parameters. RMoE introduces about 3.5M additional parameters relative to SMoE.**
| Algorithm | Training | ARC-e | Hella | Piqa | Sciq | Lamb | Avg$\uparrow$ |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SMoE<br>Speed: 48.87 s/step<br>Mem: 48.00 GB | pre-train 20B tokens | 47.14 | 35.51 | 64.69 | 76.2 | 14.61 | 47.63 |
| +sft | 50.93 | 35.82 | 65.61 | 74.7 | 17.81 | 48.97 |  |
| +sft (freeze router) | 50.59 | 35.78 | 66.32 | 74.7 | 18.18 | 49.11 |  |
| pre-train 40B tokens | 52.57 | 40.85 | 67.74 | 83.4 | 26.74 | 54.26 |  |
| +sft | 53.70 | 42.07 | 68.61 | 83.5 | 32.80 | 56.13 |  |
| +sft (freeze router) | 53.45 | 41.94 | 68.88 | 83.1 | 32.06 | 55.88 |  |
| RMoE<br>Speed: 49.07 s/step<br>Mem: 48.69 GB | pre-train 20B tokens | 47.01 | 35.91 | 65.23 | 78.7 | 19.13 | 49.20 |
| +sft | 48.53 | 36.90 | 66.21 | 79.6 | 24.74 | 51.20 |  |
| +sft (freeze router) | 49.24 | 36.79 | 66.16 | 79.7 | 24.32 | 51.24 |  |
| pre-train 40B tokens | 51.18 | 41.38 | 67.79 | 83.6 | 32.58 | 55.31 |  |
| +sft | 53.20 | 43.05 | 68.55 | 83.8 | 37.16 | 57.15 |  |
| +sft (freeze router) | 53.11 | 43.16 | 68.77 | 82.8 | 37.57 | 57.08 |  |

While previous work on improving routers has not mostly been evaluated on large-scale pre-training (Dai et al., ; Chi et al., ; Do et al., ), we scale up RMoE to billion-level parameters and training tokens.
We report SMoE and RMoE’s evaluation results (both directly evaluated and evaluated after supervised fine-tuning (sft)) in Tab. 3.
Existing works suggest freezing the router during SMoE tuning Zoph et al. (); we report SMoE’s results under freeze and unfreeze settings.
Correspondingly, for RMoE, we freeze the GRU and the linear layer under the freeze setting.
From Tab. 3, we can observe that (1) Even in large-scale pre-training that requires more complex parallel training strategies, RMoE brings negligible wall time and memory cost compared with vanilla SMoE.
(2) In comparable settings (e.g., the same number of tokens and with/without sft), RMoE outperforms SMoE, and even the best results of SMoE are lower than those of RMoE.

## 5 Ablation Studies

**Table 4: Enwiki8 validation and test BPC for different routing designs. ‘NP’ stands for not passing recurrent states cross-layer. ‘RMoE+NP’ has the same parameters and FLOPs as ‘RMoE’.**
| Algorithm | Val$\downarrow$ | Test$\downarrow$ | Paras (M) | Val$\downarrow$ | Test$\downarrow$ | Paras (M) |
| --- | --- | --- | --- | --- | --- | --- |
| Small | Medium |  |  |  |  |  |
| SMoE | 1.214 | 1.184 | 15.32 | 1.152 | 1.128 | 36.08 |
| SMoE + MLP | 1.214 | 1.183 | 15.73 | 1.164 | 1.137 | 36.79 |
| RMoE + NP | 1.227 | 1.196 | 15.61 | 1.150 | 1.123 | 36.51 |
| RMoE | 1.213 | 1.183 | 15.61 | 1.141 | 1.116 | 36.51 |

##### Which contributes more?       More Router parameters or layerwise recurrence.

A straightforward reason for RMoE improvement could be that RMoE introduces additional computation and parameters.
To disentangle the effect of introducing more router parameters and layerwise recurrence, we consider the following two extra settings: (1) SMoE+MLP: we naively increase the router parameters by replacing the original linear layer with a larger MLP layer; (2) RMoE + NP: we change Eq. 5 to $\operatorname{GRU}(\mathbf{r}_{i},\mathbf{h}_{0})$ to cancel the layerwise recurrence of RMoE, rendering a stateless GRU.
The setting has the same parameters and computation as RMoE.
From Tab. 4, we can observe that (1) in our setting, introducing larger routers in SMoE doesn’t bring improvement (SMoE v.s. SMoE + MLP).
(2) When ablated on the layerwise recurrence in RMoE, the performance largely drops, even worse than SMoE.
Both results suggest that the layerwise recurrence is the main contributor.

**Table 5: Enwiki8 validation and test BPC. ‘detach $h_{i-1}$’ means detaching the recurrent hidden states before passing it to the next block. ‘r-0.5$/$1.0’ means passing the routing logits of the previous block to the current block. ‘detach-r’ means detaching the gradient computation of passed logits.**
| Algorithm | Val | Test |
| --- | --- | --- |
| SMoE | 1.152 | 1.128 |
| RMoE | 1.141 | 1.116 |
| + NP | 1.150 | 1.123 |
| + detach $h_{i-1}$ | 1.159 | 1.133 |
| + NP + r-0.5 | 1.149 | 1.124 |
| + NP + r-1.0 | 1.150 | 1.124 |
| + NP + r-0.5 + detach-r | 1.157 | 1.133 |
| + NP + r-1.0 + detach-r | 1.152 | 1.126 |

##### Recurrent Gradient is important to RMoE

Following the aforementioned analysis, we try to further disentangle the effect of the layerwise recurrence.
When removing the layerwise recurrence as in the RMoE + NP setting, we remove two information flows across layers:
(1) the forward information about previous routers’ decisions and
(2) the backward gradient propagation through GRU hidden states in different layers.
To compare the two information flows, we investigate the following settings:
(1) RMoE + detach $h_{i-1}$: in intermediate stage between RMoE and RMoE-NP. By detaching $h_{i-1}$ to stop its gradient computation in Eq. 5, each GRU cell can only use previous information during feed-forward.
(2) RMoE + NP + r-$\alpha$: inspired by Realformer (He et al., ) that introduces residual attention score to facilitate attention gradient back-propagation, we investigate an intermediate stage between RMoE and RMoE-NP by adding gating logits residual for the RMoE + NP settings.
Concretely, the gating score of $i$-th layer for expert $n$ is $g_{n}(\mathbf{h}_{i};\mathbf{G}_{i},k)+\alpha g_{n}(\mathbf{h}_{i-1};\mathbf{G
}_{i-1},k)$.
It is a straightforward way to supplement router information across layers based on the NP setting.
In our experiments, we set $\alpha$ as 0.5 and 1.0.
(3) Moreover, we also test detaching the gradient computation of passed logits ($\textbf{h}_{i-1}\times\textbf{G}_{i-1}$), denoted as ‘detach-r’.
From Tab. 5, RMoE + detach $h_{i-1}$ performs even worse than RMoE-NP,
showing that the Recurrent Gradient is important.
Similarly, ‘NP+r0.5’ and ‘NP+r1.0’ are comparable with ‘NP’, demonstrating that the naive gating score residual cannot provide effective cross-layer information.
The performance of their detached version largely drops, further demonstrating the importance of extra backward gradient passing.

Figure: Figure 2: Test BPC on Enwiki8 with different model sizes (6, 12, 18, 24, 32). Similar validation results are in App. A.3 Fig. 6
Refer to caption: x2.png

To further validate the gradient passing hypothesis, we test ‘NP‘ and ‘NP-r0.5$/$1.0‘ on deeper models. The results are summarized in Fig. 2.
As the layer increases, we can observe that
(1) RMoE consistently outperforms other settings, and RMoE-NP even lags behind SMoE.
The possible reason is, without passing recurrent states, RMoE-NP is similar to SMoE-MLP which simply increases router complexity but doesn’t refine the router training.
(2) RMoE-NP-r0.5 surpasses RMoE-NP, further emphasizing that SMoE’s optimization benefits from the added additional gradient flow for routers. The spirit echoes the principles behind residual network, where residual connection are used to create direct paths for gradient propagation, thereby mitigating gradient vanishing as lerys deepen. Similarly, the GRU and the direct logits passing help for gradient flow of routers in deep layers. Ad shown in the Fig. 2, as the layer increases. the performance gaps between them may becomes more significant
(3) While providing additional gradient across layers, RMoE-NP-r0.5 underperforms RMoE.
This may because the indexes of experts in layer $i$ are not aligned with those in other layers, directly adding logits can lead to improper constraints and hurt the model performance, further highlighting that RMoE adds flexible while informative pathways in the SMoE framework.

**Table 6: Ablation of RMoE design. ‘L-proj‘ means the layerwise projector in Equ 4, ‘S-proj‘ is the standard RNN projector. ‘SMoE + L-proj + GRU router‘ is our proposed used RMoE method.**
| Algorithm | Enwiki8 (BPC)$\downarrow$ | WikiText (PPL)$\downarrow$ | Params |  |  |
| --- | --- | --- | --- | --- | --- |
| Val | test | val | test |  |  |
| SMoE | 1.152 | 1.128 | 31.28 | 33.06 | 36.08 |
| SMoE + L-proj + GRU router | 1.141 | 1.116 | 30.93 | 32.86 | 36.50 |
| SMoE + S-proj + GRU router | 1.148 | 1.123 | 31.15 | 33.02 | 36.23 |
| SMoE + L-proj + RNN router | 1.145 | 1.119 | 31.18 | 32.72 | 36.44 |
| SMoE + L-proj + LSTM router | 1.148 | 1.122 | 31.19 | 33.04 | 36.54 |

**Table 7: Ablation of the recurrent design on large scale per-training setting. $p$ is the dimension of the recurrent state $\textbf{r}_{i}$ in Eq. 4. We report averaged tasks (the same as Tab. 3) results for pre-trained and stf models. All models are trained with 20B tokens.**
| Algorithm | Pretrain | +sft |
| --- | --- | --- |
| SMoE | 47.63 | 49.11 |
| RMoE (GRU, $p=128$) | 49.20 | 51.32 |
| RMoE (GRU, $p=256$) | 49.08 | 50.04 |
| RMoE (GRU, $p=512$) | 49.19 | 50.02 |
| RMoE (RNN, $p=256$) | 47.92 | 50.44 |

##### Layerwise projector and suitable recurrent net bring the best results.

This part tests the other components in RMoE, such as recurrent hidden state dimension, layerwise projector, and GRU cell.
As shown in Tab. 6:
(1) All methods with recurrent routers outperform SMoE, further validating the effectiveness of RMoE.
(2) Layerwise projector in Eq. 5 performs better than standard RNNs using a single shared projector. One possible reason is that the weights and hidden states norm in different layers vary greatly (as shown in App. A.4.4 Fig. 13), and it would be hard for a single shared projector to process them.
(3) The GRU router performs better than the RNN and LSTM routers.
Moreover, we further compare RMoE variants in the larger scale settings. We compare pre-trained models with different structures and recurrent hidden dimensions in Tab. 7 (Averaged results, full results in App. A.3 Tab. 9). We can find similar results: (1) All RMoE variants outperform SMoE; (2) Simple router (RNN) and complex routers (GRU with $p=256,512$) perform worse than GRU with $p=128$. In short, layerwise projector and moderate recurrent cell (e.g. GRU with $p=128$) effectively introduce layerwise recurrent.

Figure: Figure 3: Heat maps of cross-layer mutual information (MI) for different methods. The (i-th row, j-th column) value represents MI between layers i and j. The First Row ((a) SMoE, (b) XMoE, (c) HyperMoE): All three methods have low cross-layer MI. Second Row((d) RMoE, (e) RMoE-NP, (f) RMoE-NP-r1.0): While RMoE has high cross-layer MI when disabled layerwise recurrent states passing, MI largely drops.
Refer to caption: x3.png

## 6 Observations

##### Layerwise recurrence increases cross-layer mutual information.

The intuition of the proposed RMoE is that current routers in different layers are isolated, and the layerwise GRU is incorporated to provide routers with some global information for coordination.
Therefore, we measure the Mutual Information (MI) between routing distributions in different layers for each router.
The code implementation can be found in App. A.4.1.
We can observe:
(1) Besides RMoE, all existing methods show low cross-layer MI, indicating that the routers of different layers work relatively independently.
(2) RMoE shows higher MI than three baselines (d v.s. a, b, and c) and RMoE-NP (d v.s. e), showing the recurrent router can facilitate cross-layer information sharing.
(3) While RMoE-NP’s MI is largely smaller than RMoE, it still surpasses the three baseline methods. The reason can be the shared GRU in Eq. 5.
(4) Intuitively, passing routing logits can directly improve MI (f v.s. e). However, directly passing logits can’t ensure long-range information sharing, as the values in the right part of (f), which indicate the MI between non-neighbor layers, are smaller than those in (d).

##### RMoE enables moderate flat gating scores.

The router’s gating score is a noteworthy feature for MoE-based models. It showcases the models’ training dynamics and how they ultimately exploit their experts.
Ideally, the training paradigm of MoE models may have two stages: exploration and then exploitation. i.e., the router should actively explore more new expert combinations at the early stage of learning. But if the gating score converges to a sharp distribution too early, the router will learn very shallow routing mechanisms and fail to find optimal routing decisions.
So We record gate entropy for each token($-(\sum_{n}g_{n}\ln{g_{n}})$, $g_{n}$ is the gating score for expert $n$) and plot the entropy distribution in Fig. 4 (left).
Generally, the higher the entropy, the more evenly the router activates different experts rather than allowing one expert to dominate the layer. Thus, large density in high-entropy parts means many recorded tokens have flat gating score distributions.
We can observe that
(1) RandomMoE, with a fixed random-initialized router, shows the largest gate entropy. Moreover, most tokens have high entropy, as there is only one peak in the large entropy location.
This indicates while RandomRMoE can highly encourage exploration, the router may be under-trained and lack exploitation.
(2) SMoE and HyperMoE show low routing entropy, with many tokens having nearly zero entropy.
Such low entropy means the softmax operation gives nearly one-hot results, which means the $\operatorname{Top-k}$ experts degrade to $\operatorname{Top-1}$ and the router’s gradient are very sparse. This can hurt the exploration of expert selection and lead to inefficient $\operatorname{Top-k}$ experts usage.
(3) XMoE and CosineMoE, using cosine similarity, which normalized the input and weights $G$ before computing logits, show relatively high entropy.
They also perform better than SMoE in Tab. 1, indicating the benefits of suitable exploration.
(4) RMoE, with unique cross-layer information sharing, has high entropy for many tokens while low entropy for a few tokens.
These moderate gating scores can achieve a better balance between exploration and exploitation.

One may argue that such high entropy may come from the under-trained recurrent router in RMoE instead of capturing the dependency across layers, as the unlearnable RandomMoE also gives high entropy.
Therefore, we further visualize the scores of ‘RMoE-NP’ and ‘RMoE-NP-r0.5/1.0‘ in Fig. 4 (right).
The observations are: (1) RMoE-NP’s entropy is slightly larger than SMoE’s but largely smaller than RMoE’s.
, indicating that the larger entropy in RMoE is not from under-training but from cross-layer information sharing.
(2) While ‘RMoE-NP-r0.5‘ is larger than SMoE and smaller than RMoE, ‘RMoE-NP-r1.0‘ is the largest.
From Tab. 5 and Fig. 2, the small and large one both under-perform RMoE,
These further demonstrate that the recurrent network can achieve a moderate flat gating score distribution, leading to a better trade-off between exploration and exploitation.

Figure: Figure 4: Gate score entropy distribution over Enwiki8 test set for different router configurations. More similar results can be found in App. A.4.2 Fig. 9 and Fig. 10.
Refer to caption: x9.png

**Table 8: Expert scores balance on Enwiki8. Inner Balance (IB) represents the (top-1 score / top-2 score) ratio, and Outer Balance (OB) represents summed selected gate scores.**
| Algorithm | IB | OB |
| --- | --- | --- |
| SMoE | 34.68 | 0.915 |
| HyperMoE | 34.60 | 0.920 |
| CosineMoE | 7.611 | 0.794 |
| XMoE | 19.93 | 0.861 |
| RandomMoE | 2.000 | 0.414 |
| RMoE | 2.021 | 0.573 |
| + NP | 16.58 | 0.842 |
| + NP + r-0.5 | 2.792 | 0.661 |
| + NP + r-1.0 | 1.147 | 0.212 |

We also look into the statistics of selected experts’ scores.
Here we calculate the (1) Inner Balance (IB): defined as the ratio $\operatorname{Top-1}$ score / $\operatorname{Top-k}$ score, large IB means the first expert dominates all selected experts; and (2) Outer Balance (OB), defined as $\sum_{k\in\operatorname{Top-k}}g_{k}$, indicating the selected scores’ ratio in the score distribution, large OB means selected expert scores dominate the gate score distribution.
Because such a ratio could have some extreme values, we report the median number for all tokens in Tab. 8.
We can observe:
(1) RandomMoE, with a fixed router, shows the lowest IB and OB.
(2) Low-entropy models in the previous section (Sec. 6) have high IB and OB.
(3) RMoE gives suitable IB and OB. While simply using a complex router (‘RMoE-NP’) shows relatively low IB and OB, RMoE is even lower. Moreover, passing logits can reduce IB and OB (‘RMoE-NP-r0.5/1.0’).
All these experiments show sharing cross-layer router information can lead to more balanced routing decision and thus facilitate expert usage.

##### Layerwise recurrence encourages expert diversity

One intriguing feature of MoE
is that experts could modularly specialize on different inputs.
Therefore, following recent works that analyze the FFNs (Geva et al., ; Qiu et al., ; ) and expert weights similarity (Wu et al., ; Lo et al., ), we use the cosine-similarity of expert’s parameters to measure the expert diversity .
We calculate for SMoE and RMoE in the large-scale pre-training settings, and
the results are shown inFig. 5.
To better understand the scale of similarity score, we also plot one dash line showing the similarity of random initialized experts.
More details about similarity calculation and explanation can be found in App. A.4.3. We can observe that: (1) At the beginning of the training, the lowest expert similarities are similar to the random initialized one.
(2) The expert similarity increases in the early training stages, then decreases later.
This may be due to the randomly initialized router in the early stages, which essentially assigns tokens randomly to different experts, leading to increased expert similarity.
As the router continues to learn, it gradually assigns specific tokens to the corresponding experts, resulting in decreased expert similarity as training progresses.
(3) During the entire training stages, the average similarity score between experts in RMoE is lower than those in SMoE, indicating that RMoE encourages more diverse experts.
This expert diversity also reasonably corresponds to the moderate flat gate scores in Sec 6.

Figure: Figure 5: Experts similarity distribution across layers during large-scale pre-training. We plot box plots of expert similarity from checkpoints taken every 1k training steps (approximately 4B tokens), showing the expert similarity across the 24 layers of the model (with maximum, minimum, first quartile, median, and mean).
Refer to caption: x11.png

## 7 Conclusion

This work introduces a layer-wise recurrent router for existing MoE-based language models.
We validate the effectiveness of this layer-wise recurrence across various settings, tasks, and model sizes.
By adding a new yet efficient computation stage in the routing, RMoE stands orthogonal to most existing methods and can be flexibly integrated with them.
Ablation studies reveal that this recurrent mechanism offers additional Recurrent Gradients, aiding router optimization.
Further analysis validates our intuition that GRU facilitates inter-layer information sharing.
We also systematically compare RMoE’s model behavior with various baseline models, demonstrating that RMoE can enhance existing SMoE methods and providing insights for future research.

## 8 Limitations

Our pre-trained language model is still under-trained and not tested on popular challenging tasks like MMLU (Hendrycks et al., ) and GSM8K (Cobbe et al., ).
Introducing moderate z-loss (Zoph et al., ) (penalizes large router logits) and changing temperature in softmax operation (leads to more flat score distributions) to achieve moderate flat gating scores. We will investigate these modifications and combine them with RMoE in future works.
The supplement gradient pathways hypothesis is only investigated by indirect observations like performance (Sec 5).
More direct gradient analysis for MoE’s router might bring more insights.

## Appendix A Appendix

### A.1 More Related Works

##### Routing Strategies

While most MoE works follow the original success and use token choice routing, some works explore different routing approaches.
In Expert-Choice Routing (Zhou et al., ), each expert selects tokens to process across the whole batch input.
This method avoids expert imbalance issues and allows different tokens to be processed by a flexible number of experts.
Soft Mixture-of-Experts (Puigcerver et al., ) further assigns token weights for input tokens, weighted-averages them, and passes these merged tokens to different experts.
This method moves one step behind the Expert-Choice Routing to allow more precise control.
However, their token-selecting operations are non-causal and thus can’t be directly used in the decoder models.
Recent works (Huang et al., ; Yang et al., ) introduce dynamic top-k for each input token.
While the FLOPs can be reduced, since this dynamic assignment can hurt the parallel computation of experts, more system-level implementation must be optimized to achieve wall-time efficiency.
Some works also analyze issues in the routing of standard MoE like uncertain tokens (Wu et al., ) and lack of expert knowledge transfer (Zhao et al., ).

##### Training Strategies

Due to the unstable nature of MoE (Zoph et al., ), some works investigate special training strategies for MoE.
EvoMoE (Nie et al., ) uses a large top-$k$ (even equal to the expert number) at the beginning of training, gradually decreasing $k$.
StableMoE (Dai et al., ) proposes to freeze the router after training some tokens to avoid token assignment conflicts.
Residual Mixture of Experts (Wu et al., ) initializes MoE from dense training checkpoints and finds it is an efficient method to train MoE models.
Later, sparse-upcycling (Komatsuzaki et al., ) further trains large-scale language models from dense checkpoints, and many works follow this paradigm to efficiently utilize the power of MoE in fine tuning (Li et al., ), instruction tuning (Lin et al., ), and visual instruction tuning (Ding et al., ).
Different from directly training MoE models, some works continue training the same pre-trained model on several different datasets to encourage specialization and combine them, either merging them into an MoE-style model (Gururangan et al., ; Sukhbaatar et al., ) or keeping a group of models and introducing a model-level router (Li et al., ; Gururangan et al., ).

##### Recurrence Controller

A series of works introduce recurrent networks for Neural Architecture Search (NAS) (Zoph & Le, ; Ramachandran et al., ; Pham et al., ; Liu et al., ).
They introduce a recurrent controller network that predicts the current layer-$i$’s architecture (like CNN filters’ number, size, and stride) based on layer-$i$’s input hidden states and previous recurrent states (Zoph & Le, ).
While these works use RNN to predict model architecture configurations of each layer for all inputs, RMoE utilizes RNN to help the router select expert combinations for each token, which can be viewed as a dynamic version of NAS.

### A.2 Experiment Setup

##### Enwiki8 and WikiText-103

We follow the default configurations in CompeteSMoE (Pham et al., ). Each model is trained for 80,000 steps with Adam optimizer. The learning rate is 0.0007 with 4000 warmup steps, and the batch size is 48. The main used model is a decoder-only transformer-based architecture with 8 layers and a hidden size of 352. It includes 16 experts, where the top 2 are selected during computation, each with an expert size of 352. The model uses 8 attention heads and handles sequences up to 512 tokens in length, with an attention span of 2048 tokens. It incorporates a dropout rate of 0.1 and a load balancing factor of 0.01 to ensure an even distribution of expert utilization. Computation Cost Each 8-layer model is trained on one NVIDIA-A100 GPU for approximately 21 hours.

##### Large Scale Pre-training

For model architecture, our 24-layer model employs Rotary Embedding for positional encoding, SwiGLU for activation functions, and RMSNorm to enhance the model’s efficiency and performance. Other model configuration includes a hidden size of 1280, 20 attention heads, an initialization method standard deviation of 0.02, a sequence length of 4096, and a maximum positional embedding length of 4096. All dropout rates are set to 0. For the MoE part, we use 16 experts, with each expert having a feedforward network hidden size of 448, following the fine-grained MoE settings, and each token activating 4 experts.
We use a tokenizer with a 96512 vocabulary size, which adds approximately 123M embedding parameters and 123M vocabulary projection head parameters.
Under this configuration, each model has approximately 664M non-embedding parameters, and every token activates 334M non-embedding parameters.
The total parameter is around 910M.
For pre-training configurations, we use a global batch size of 1120, a warmup period of 2000 iterations, a learning rate of 4.2e-4, a minimum learning rate of 4.2e-5, cosine learning rate decay, Adam optimizer with $\beta_{1}=0.9$ and $\beta_{2}=0.95$, a weight decay of 0.1, and gradient clipping at 1.0. Computation Cost Each 24-layer model is trained on 8 NVIDIA-A100 GPUs for approximately 5 days.

##### Instruction Tuning Data

The Alpaca (Taori et al., ) dataset is an open-source instruction-following dataset created by Stanford researchers, inspired by OpenAI’s ChatGPT. The dataset consists of 52,000 instruction-response pairs generated using the text-davinci-003 model by providing diverse and comprehensive instructions and recording the corresponding responses. It is designed to facilitate the training and evaluation of models in understanding and generating human-like text responses to various instructions.

##### Instruction Tuning Setting

We use the codebase(^2^22https://github.com/tatsu-lab/stanford$_$alpaca) and corresponding default configurations. More concretely, we use bfloat16 (bf16) precision to accelerate training while maintaining numerical stability. The model is trained for 3 epochs using AdamW optimizer with a global batch size 128.
We set the learning rate to 2e-5 and do not apply weight decay.
A warmup ratio of 0.03 is used to gradually increase the learning rate at the beginning of training, and we utilize a cosine learning rate scheduler to adjust it throughout the training process, promoting smoother convergence.
Computation Cost Each is trained on 8 NVIDIA-A100 GPUs for approximately 2 hours.

##### Evaluation Tasks

Here we shortly describe our used evaluation datasets:

ARC-Easy is a subset of the AI2 Reasoning Challenge (ARC) dataset (Clark et al., ). It consists of multiple-choice questions from elementary and middle school science exams that are relatively easier than the ARC-Challenge set. These questions require basic reasoning and knowledge application.

Hellaswag (Zellers et al., ) is a dataset designed for commonsense reasoning and narrative prediction. It involves choosing the most plausible continuation of a given scenario from multiple options. The task is challenging because it requires understanding and applying common sense knowledge.

PIQA (Bisk et al., ) dataset tests a model’s ability to understand and reason about physical interactions and affordances. The task involves selecting the correct answer to questions about everyday physical activities.

SciQ (Welbl et al., ) is a dataset of science questions that includes multiple-choice and direct-answer formats. It aims to test a model’s ability to understand and reason with scientific concepts typically taught at the school level.

LAMBADA (Paperno et al., ) is a dataset designed for language modeling and comprehension. The task involves predicting the last word of a given passage, which requires a deep understanding of the context provided by the preceding text.

### A.3 Additional Results

**Table 9: More SMoE and RMoE variants pre-training costs and evaluation results in selected informative lm-evaluation-harness tasks. ‘sft’ means supervised fine-tuning on the Alpaca dataset. The task names and metrics for short names in the table are: ‘ARC-e’ for ARC-Easy, acc; ‘Hella’ is for Hellaswag, acc-norm; ‘Piqa’ for PIQA, acc-norm; ‘Lamb’ for LAMBADA, acc.**
| Algorithm | Training | ARC-e | Hella | Piqa | Sciq | Lamb | Avg$\uparrow$ |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SMoE | 20B (5k steps) | 47.14 | 35.51 | 64.69 | 76.2 | 14.61 | 47.63 |
| +sft | 50.93 | 35.82 | 65.61 | 74.7 | 17.81 | 48.97 |  |
| +sft (freeze gate) | 50.59 | 35.78 | 66.32 | 74.7 | 18.18 | 49.11 |  |
| 40B (10k steps) | 52.57 | 40.85 | 67.74 | 83.4 | 26.74 | 54.26 |  |
| +sft | 53.7 | 42.07 | 68.61 | 83.5 | 32.8 | 56.13 |  |
| +sft (freeze gate) | 53.45 | 41.94 | 68.88 | 83.1 | 32.06 | 55.89 |  |
| RMoE<br>GRU<br>$p=128$ | 20B | 47.01 | 35.91 | 65.23 | 78.7 | 19.13 | 49.20 |
| +sft | 48.53 | 36.9 | 66.21 | 79.6 | 24.74 | 51.20 |  |
| +sft (freeze router) | 48.65 | 36.88 | 66.43 | 80.1 | 24.55 | 51.32 |  |
| +sft (freeze router and GRU) | 49.24 | 36.79 | 66.16 | 79.7 | 24.32 | 51.24 |  |
| 40B | 51.18 | 41.38 | 67.79 | 83.6 | 32.58 | 55.31 |  |
| +sft | 53.20 | 43.05 | 68.55 | 83.8 | 37.16 | 57.15 |  |
| +sft (freeze router) | 53.03 | 42.96 | 68.34 | 83.6 | 36.68 | 56.92 |  |
| +sft (freeze router and GRU) | 53.11 | 43.16 | 68.77 | 82.8 | 37.57 | 57.08 |  |
| RMoE<br>GRU<br>$p=256$ | 20B | 47.47 | 35.91 | 65.78 | 76.2 | 20.03 | 49.08 |
| +sft | 48.36 | 36.49 | 65.07 | 77.4 | 22.86 | 50.04 |  |
| +sft (freeze router) | 48.27 | 36.42 | 65.23 | 76.9 | 22.88 | 49.94 |  |
| +sft (freeze router and GRU) | 48.23 | 36.46 | 64.94 | 77.3 | 22.61 | 49.91 |  |
| 40B | 53.07 | 41.15 | 68.52 | 84.0 | 19.17 | 53.18 |  |
| +sft | 54.46 | 43.06 | 67.46 | 84.9 | 24.57 | 54.89 |  |
| +sft (freeze router) | 54.45 | 43.10 | 67.19 | 84.1 | 23.93 | 54.55 |  |
| +sft (freeze router and GRU) | 54.50 | 43.13 | 67.36 | 83.8 | 23.62 | 54.48 |  |
| RMoE<br>GRU<br>$p=512$ | 20B | 47.77 | 35.39 | 64.80 | 79.5 | 25.00 | 50.49 |
| +sft | 48.27 | 36.47 | 65.51 | 76.6 | 22.18 | 49.81 |  |
| +sft (freeze router) | 47.73 | 36.41 | 65.78 | 76.6 | 22.88 | 49.88 |  |
| +sft (freeze router and GRU) | 48.19 | 36.22 | 65.29 | 76.8 | 23.5 | 50.00 |  |
| 40B | 51.64 | 41.37 | 66.81 | 86.0 | 22.76 | 53.72 |  |
| +sft | 52.82 | 42.68 | 68.55 | 86.0 | 26.88 | 55.39 |  |
| +sft (freeze router) | 52.48 | 42.61 | 68.44 | 86.0 | 27.23 | 55.35 |  |
| +sft (freeze router and GRU) | 52.74 | 42.44 | 68.77 | 86.3 | 27.13 | 55.48 |  |
| RMoE<br>RNN<br>$p=256$ | 20B | 46.63 | 35.7 | 64.91 | 76.1 | 16.24 | 47.92 |
| +sft | 48.40 | 36.45 | 65.51 | 77.3 | 22.65 | 50.06 |  |
| +sft (freeze router) | 48.70 | 36.29 | 65.45 | 77.3 | 22.60 | 50.07 |  |
| +sft (freeze router and RNN) | 49.24 | 36.48 | 65.56 | 77.7 | 23.20 | 50.44 |  |

Figure: Figure 6: Validation BPC on Enwiki8 with different model sizes (6, 12, 18, 24, 32 layers).
Refer to caption: x12.png

### A.4 Additional Observations

#### A.4.1 Mutual Information

Figure: Figure 7: Mutual information of RMoE-NP-r0.5 and CosineMoE settings
Refer to caption: x13.png

Figure: Figure 8: Mutual information of SMoE, RMoE, RMoE-NP, and RMoE-NP-r0.5 in 24-layer models.
Refer to caption: x15.png

#### A.4.2 More Router Entropy Distributions

Figure: Figure 9: Gate score entropy distribution over Enwiki test set for different routers in 8-layer models.
Refer to caption: x19.png

Figure: Figure 10: Gate score entropy distribution over Enwiki test set for different information passing settings in 8-layer models.
Refer to caption: x25.png

Figure: Figure 11: Gate score entropy distribution over Enwiki test set for different routers. RMoE can be combined with XMoE to encourage the exploration of XMoE.
Refer to caption: x31.png

#### A.4.3 Expert Similarities

Figure: Figure 12: Expert similarity in Enwiki8 training experiments. RandomMoE shows the highest expert similarity. XMoE, which introduces down-projected cosine routing to resolve representation collapse in SMoE, shows the lowest expert similarity. While RMoE doesn’t significantly diversify experts as in the large-scale training settings (left), it can be further combined with XMoE, which largely increases expert diversity and brings improvement (right).
Refer to caption: x39.png

#### A.4.4 Router Weights Information

Figure: Figure 13: Different layers’ router weight statistics (left column: norm and right column: standard deviation) in Enwiki8 setting. (1) different layers have different norms and STDs, which inspires us to introduce layerwise projector in Equ 4 and explains using the shared projector can hurt RMoE’s performance (Tab. 6). (2) While SMoE routers show larger weight norms than RMoE settings, their standard deviations are not the highest. The large router norms can potentially explain the larger IB and OB in Tab. 8.
Refer to caption: x41.png

#### A.4.5 Expert Selection Frequency

Figure: Figure 14: Different methods’ expert selection frequency on medium size models in Enwiki8. (1) RMoE slightly increases expert imbalance than SMoE. (2) Methods using a frozen-random-initialize router (HyperMoE and RandomMoE) show more imbalance problems.
Refer to caption: x49.png

## Peer Reviews

confidence: 4
contribution: 3
initial_rating: 6
presentation: 3
questions: The paper emphasizes the importance of gradient flow through the GRU-based recurrence in RMoE but does not mention whether Truncated Backpropagation Through Time (BPTT) or any specific method was used to manage gradients across layers. Did the authors consider using truncated BPTT for controlling gradient flow through the recurrent router? Including details on gradient management would help clarify if additional methods, like truncation, could further optimize training.

 Would it be possible to conduct a more direct analysis, such as by visualizing or measuring gradient norms through layers, to further validate the specific impact of recurrent gradients? 

 Could the authors provide insights or quantitative analysis on how the recurrence depth impacts the RMoE’s routing decisions?

The current evaluation omits challenging benchmarks like MMLU and GSM8K, mentioning that the models are still under-trained. Can the authors comment on whether they plan to scale the training or incorporate task-specific fine-tuning to gauge RMoE’s performance on these harder tasks? Additional results on these benchmarks could help better gauge RMoE’s robustness and adaptability in real-world scenarios.
soundness: 3
strengths: The paper offers a simple but new enhancement to MoE architectures by introducing a layerwise recurrent mechanism, distinguishing it from other MoE router designs that operate independently across layers. The methodology is sound, with a well-motivated design backed by extensive experimental validation and ablation studies. The work is valuable to the research community, as it not only provides a means to improve existing MoE designs but also contributes insights into the impact of cross-layer recurrence on expert diversity and selection.
summary: This paper proposes the Layerwise Recurrent Router for Mixture-of-Experts, a novel approach to enhance efficiency in MoE architectures within LLM. The authors highlight limitations in traditional MoE routers that operate independently across layers, potentially resulting in suboptimal parameter utilization. To address this, Recurrent-Router MoE introduces a GRU-based mechanism that enables dependencies between routing decisions across layers, which improves the diversity and effectiveness of expert utilization. The proposed method integrates seamlessly with other MoE architectures and demonstrates substantial improvements in performance on various language modeling tasks. Through comprehensive experiments, the authors show that RR-MoE achieves superior performance over several baseline router designs with only marginal computational overhead.
weaknesses: The authors mention that their model is under-trained and does not yet perform well on challenging tasks like MMLU and GSM8K. A more complete evaluation on these benchmarks, perhaps by including more training tokens or longer training duration, would provide a fuller picture of the model's real-world applicability.

Also the paper presents extensive performance metrics and ablation studies, a more direct analysis of gradient propagation through the recurrent router could strengthen the argument for the importance of recurrent gradients in optimizing routing decisions. Also, do we need truncated backpropagation similar to BPTT?

The paper could benefit from a deeper comparative analysis with recent MoE models that also use recurrence or other advanced routing strategies (such as XMoE, HyperMoE etc). This would help clarify how RRMoE’s benefits compare to similar innovations in this rapidly evolving field.

---

confidence: 4
contribution: 2
initial_rating: 3
presentation: 2
questions: Suggestions for improvement are to show results on a larger MoE model. Not all models need to be 100s of billions of parameters, but a 36M parameter MoE model is quite small these days, and it is hard to be convinced that small gains on this model would translate to a more realistic sized model.
soundness: 2
strengths: Paper clearly expresses main idea, that routing decisions in MoE should have some dependency on previous routing decisions, and how they achieve this and test the results.
summary: Paper introduces a gated recurrent connection for routing decisions in MoEs such that routing decision in a layer depend on shared GRU so that routing decisions between layers are no longer independent. The intuition expressed by authors is that this should help improve model because routing decisions in current layer should be able to leverage routing info from previous layers.
weaknesses: The results are relatively minor improvements (1-2% relative), the models are very small (on the order of 36M parameters for an MoE model) and the benchmarks are small (enwiki8 & wikitext).

---

confidence: 3
contribution: 2
initial_rating: 5
presentation: 3
questions: - Clarify the architecture of the layer-specific projectors used in Eq. 4; are there structural variations across layers, or have alternative projector architectures been tested for potential performance improvements?
- In Table 1, improvement over baselines is minor, yet gains are more noticeable in Table 2 (billion-level settings). Could the authors explain the differing results, specifically regarding training sizes and conditions?
- Column names in Table 8 appear inconsistent with descriptions in the text; could these be corrected or clarified?
soundness: 3
strengths: - The use of a GRU to incorporate layerwise information into MoE is a novel and well-motivated approach to address parameter inefficiencies in SMoE.
- Extensive ablation studies demonstrate the importance of recurrent gradient flow, validating the primary contributor to RMoE’s improvements.
- Interesting analysis on the increase in cross-layer mutual information and gating score entropy with RMoE, providing insights into how cross-layer information sharing improves expert selection and model robustness.
summary: The paper presents the Layerwise Recurrent Router for Mixture-of-Experts (RMoE), designed to address inefficiencies where routers at each layer operate independently, leading to suboptimal token-expert assignments. RMoE integrates a GRU to enable cross-layer communication, establishing dependencies between routing decisions across layers. The authors validate RMoE through experiments across various model sizes and tasks, demonstrating consistent improvements over baseline MoE models. Analysis shows that RMoE’s gains are primarily due to effective cross-layer information sharing, resulting in better expert utilization and diversity.
weaknesses: - Current performance improvement appears marginal; val and test losses alone do not demonstrate statistically significant gains over baselines. Benchmarking on standard language modeling tasks would provide more practical context for the model's effectiveness.
- Analysis of gradient flow could be more rigorous; while recurrent gradient flow is highlighted as crucial in Section 5, more sophisticated gradient tracking techniques would strengthen this claim.
- The additional computation stage introduced by the GRU increases complexity, yet the impact on training efficiency is not thoroughly analyzed across different model sizes.

---

confidence: 5
contribution: 3
initial_rating: 6
presentation: 3
questions: NA
soundness: 2
strengths: 1) Elegant design. Using previous routing representation to improve the routing decision is a smart idea.
2) Some experimental results in Section 6 (Observation) are interesting, such as Layer-wise recurrence encourages expert diversity.
3) Comprehensive ablation studies in Section, which shows the effectiveness of RNN router under this scale.
4) Unshare part of trainable parameters in RNN also makes sense. I suggest to cite this work (https://arxiv.org/abs/2107.11817), which unshare the layernorm when sharing MoE Transformer blocks.
summary: This paper proposes to use RNN to replace the linear projection layer to route the tokens in MoE models. The proposed model achieves better results than vanilla router across scales (after revision).
weaknesses: I have only one important concern, i.e. the scale of the experiments. I agree the paper is promising in many aspects, but the experiments are too toy for a model architecture paper in 2024. We need at least 3B/7B activated parameters and 1T tokens to justify the scalability of the proposed method. 

However, I understand it might be difficult to acquire enough computation resources for some reasons, so I decided to give a positive rating to this paper.

Meta-review: The authors propose changing the standard MoE architecture to allow for direct dependencies between routing decisions across layers. It is a simple idea that is well-executed, giving rise to modest but consistent improvements across a variety of tasks and model scales. Reviewers initially questioned the authors on only running experiments on small model scales as well as on some ablations, but the authors responded with additional experiments (in particular on larger models) that convinced most of the reviewers. Overall, I think this is a useful addition to the growing MoE literature and will be helpful guidance for practitioners seeking to train their own MoEs, and I am happy to recommend acceptance.

I encourage the authors to take the reviewer feedback into account and in particular to move the experiments on larger models (currently in the appendix) to the main text.

Decision: Accept (Poster)