Mixtral of Experts：スパースMoEによるオープンウェイト言語モデルの新基準

モデル全体を大きくすると知識を持つ余地は増えますが、一語を処理するたびに全体を動かす計算も重くなります。持てる量と一回の計算量を分けられるかが課題です。

Mixtralは各層に8つの専門部分を置き、単語ごとに受付役が2つを選びます。全体では467億個の調整値を持ちますが、一つの単語を処理するときに使うのは129億個分です。

著者らはMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%を報告し、これらではLlama 2 70Bを上回りました。32,000トークンまでの長文評価も行っています。

使わない専門部分を含む全重みをメモリに置く必要があります。入力が一部の専門部分へ偏ると待ち時間が生じ、複数の計算機に分ける場合は通信も増えます。

論文では、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。この結果が対象に近い条件でも確かめられるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。ただし、計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

モデル全体を大きくすると知識を持つ余地は増えますが、一語を処理するたびに全体を動かす計算も重くなります。持てる量と一回の計算量を分けられるかが課題です。

著者らは提案手法と比較手法を同じデータと指標で比べ、この問いを検証しました。

通常の密なモデルは一語ごとに層の全部分を動かします。専門部分だけを選ぶ考え方は以前からありましたが、選択の偏りや複数機器に分けたときの通信が課題になります。

Mixtralは各層に8つの専門部分を置き、単語ごとに受付役が2つを選びます。全体では467億個の調整値を持ちますが、一つの単語を処理するときに使うのは129億個分です。

この中心アイデアを、先行法との差と評価結果を分けて確認する。

文章の各単語が層へ入ると、受付役が8つの専門部分へ点数をつけ、上位2つだけを動かします。二つの出力を点数に応じて混ぜ、次の層へ渡します。注意機構は全単語で共有し、計算を分けるのは主に層内の変換部分です。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

著者らはMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%を報告し、これらではLlama 2 70Bを上回りました。32,000トークンまでの長文評価も行っています。

これらは原論文の著者報告であり、比較対象、データ、指標をそろえた範囲で解釈する。

この論文が直接確かめた範囲は、記載されたデータセット、比較対象、指標、計算条件に限られる。別の用途へ広げる場合は、同じ効果が保たれるかを改めて測る必要がある。

確認すべき限界は次の通り。

1. 推論の計算量は小さくても、470億個の全パラメータをグラフィックボードのメモリに載せる必要があるため、高価なVRAMが必要
2. 2人の専門家に均等に仕事が分散されるよう学習させるのが難しく、訓練の難易度が高い。 評価対象と異なるデータ、規模、計算条件へ結論を広げるには追加検証が必要になる。

論文では、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。同じ制約がある場面で再現できるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。採用を決める際は、論文と同じ指標だけでなく、対象データと計算条件でも比較したいところです。計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

モデル全体を大きくすると知識を持つ余地は増えますが、一語を処理するたびに全体を動かす計算も重くなります。持てる量と一回の計算量を分けられるかが課題です。

ここでの結論は、原論文が使ったデータ、モデル規模、比較条件を前提とします。条件が変われば、性能と計算量の関係も測り直す必要があります。

通常の密なモデルは一語ごとに層の全部分を動かします。専門部分だけを選ぶ考え方は以前からありましたが、選択の偏りや複数機器に分けたときの通信が課題になります。

この違いを踏まえ、何を共有・圧縮・追加したのかと、どの条件で結果を比べたのかを分けて読みます。

Mixtralは各層に8つの専門部分を置き、単語ごとに受付役が2つを選びます。全体では467億個の調整値を持ちますが、一つの単語を処理するときに使うのは129億個分です。

次節では、入力から出力までに何を更新し、どの部分の計算や学習を変えたのかを整理する。

文章の各単語が層へ入ると、受付役が8つの専門部分へ点数をつけ、上位2つだけを動かします。二つの出力を点数に応じて混ぜ、次の層へ渡します。注意機構は全単語で共有し、計算を分けるのは主に層内の変換部分です。

この流れの各段階を分けて考えると、どこで情報を減らし、どこで結果を確かめる必要があるかが見える。論文に記録されていない細かな設定は推測せず、評価条件と合わせて読む。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

論文に明記されていない条件は補わず、追試時の確認事項とする。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

指標が測る性能と、実運用で必要な性質が一致するかは別に検討する。

著者らが報告した主な結果は次の通り。

1. MMLU（大学レベル知識測定）で70.6%を達成し、パラメータ数が1.5倍大きいLlama 2 70B（69.8%）を上回った
2. GSM8K（小学生の算数文章題）で58.4%を記録し、Llama 2 70Bの34.1%を24ポイント以上突き放す大きなな数学的推論力を報告
3. HumanEval（Pythonコード生成）で40.2%を達成し、コーディング支援モデルとしても優秀であることを立証。 これらは原論文の著者報告であり、後続研究による独立検証とは区別する。

確認すべき限界は次の通り。

1. メモリ容量問題：推論計算自体はRTX 4090などの家庭用GPUでも動く軽さですが、モデル全体の重みを展開するために90GB前後のVRAMまたは量子化技術（4bit圧縮など）が必須
2. ルーティングの偏りリスク：学習中に一部のエキスパートばかりが選ばれる『エキスパート崩壊（Expert Collapse）』を防ぐための複雑な損失調整が必要。 正典データに独立したアブレーション結果が記録されていない要素については、各構成要素の寄与を数値で分離できない。失敗条件の範囲も、記録された限界を超えて推測しない。

報告された改善は提案全体を支持するが、評価条件が限定される場合、特定の構成要素、データ、計算量の寄与を完全には切り分けられない。別の比較条件でも差が残るかが、より強い解釈に必要になる。 この論文が直接確かめた範囲は、記載されたデータセット、比較対象、指標、計算条件に限られる。別の用途へ広げる場合は、同じ効果が保たれるかを改めて測る必要がある。

確認すべき限界は次の通り。

1. メモリ容量問題：推論計算自体はRTX 4090などの家庭用GPUでも動く軽さですが、モデル全体の重みを展開するために90GB前後のVRAMまたは量子化技術（4bit圧縮など）が必須
2. ルーティングの偏りリスク：学習中に一部のエキスパートばかりが選ばれる『エキスパート崩壊（Expert Collapse）』を防ぐための複雑な損失調整が必要。 特定ハードウェアや分散構成に対する依存性。 極限スケールにおけるハイパーパラメータチューニングの難しさ。 性能値だけでは、評価外の分布、規模、資源条件での頑健性までは示せない。

残る問いは、特定ハードウェアや分散構成に対する依存性をどの条件まで解消できるかである。 同一条件での追試、異なる規模やデータでの比較、構成要素ごとの切り分けが、結論の適用範囲を明確にする。

論文では、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。同じ制約がある場面で再現できるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。採用を決める際は、論文と同じ指標だけでなく、対象データと計算条件でも比較したいところです。計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

さらに、改善が中心機構によるものか、データ・規模・計算条件にも依存するのかを構成要素別の比較で確かめる必要があります。異なる条件での追試が、結論をどこまで広げられるかを判断する材料になります。

Dense Transformerではparameter容量を増やすとtoken当たりのFFN計算量も増える。総parameter数とactive computeを疎なroutingで分離できるかが問いである。

Mixtral 8x7Bは各層に8個のSwiGLU expertを置き、routerがtokenごとにTop-2を選んで出力を合成する。総46.7Bのうちtoken当たり12.9B parameterがactiveになる。

著者らが報告した主な結果は次の通り。

1. MMLUで70.6%を達成し、Llama 2 70B（69.8%）およびGPT-3.5（70.0%）と同等以上を記録
2. GSM8Kにおいて58.4%を達成し、Llama 2 70B（34.1%）を大幅に上回った
3. CodeforcesやHumanEval（40.2%）で高いプログラミング適性を実証。

数値は原論文における著者報告である。

確認すべき限界は次の通り。

1. 全46.7BのウェイトをVRAM上に保持する必要があり、推論時メモリフットプリント（FP16で約90GB）がハードウェア制約となる
2. 分散並列環境においてExpert Parallelism（EP）を適用する際、All-to-All通信オーバーヘッドがボトルネック化しやすい。

評価条件の外で同じ結果が得られるとは限らない。

著者らは、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。この結果が対象に近い条件でも確かめられるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。ただし、計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

Dense Transformerは容量を増やすと各tokenの計算量も増える。総parameter数を増やしながら、token当たりにactiveな計算を一部へ限定できるかが研究課題である。

この問いに対し、提案手法と比較手法を同じ評価条件で比べる。

Dense modelは各tokenで全FFN parameterを使う。従来のMixture-of-Expertsは疎な活性化を可能にする一方、routingの偏りや分散実行時の通信を考慮する必要がある。

Mixtral 8x7Bは、各Transformer blockのFFNを8 expertへ置き換え、routerがtokenごとにTop-2を選ぶSparse MoEです。総46.7B parameterに対してtoken当たり12.9Bを使用し、原論文はLlama 2 70Bなどと各種benchmarkで比較しました。

この中心アイデアを、先行法との差と評価結果を分けて確認する。

中心となる流れは次の通り。

1. 1. 数理的・アルゴリズム的アプローチの再設計による効率化
2. 2. 入出力および内部状態の表現空間の最適化
3. 3. 実装レベルでのメモリ階層や並列化パイプラインの緊密な協調。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

著者らが報告した主な結果は次の通り。

1. MMLUで70.6%を達成し、Llama 2 70B（69.8%）およびGPT-3.5（70.0%）と同等以上を記録
2. GSM8Kにおいて58.4%を達成し、Llama 2 70B（34.1%）を大幅に上回った
3. CodeforcesやHumanEval（40.2%）で高いプログラミング適性を実証。

これらは原論文の著者報告であり、比較対象、データ、指標をそろえた範囲で解釈する。

この論文が直接確かめた範囲は、記載されたデータセット、比較対象、指標、計算条件に限られる。別の用途へ広げる場合は、同じ効果が保たれるかを改めて測る必要がある。

確認すべき限界は次の通り。

1. Expert Parallelism（EP）展開時、各GPUへのトークン分散と集約に伴うネットワーク帯域（All-to-All通信）への依存度が高い
2. 小バッチ推論ではアクティブパラメータの小ささが活きるが、大バッチ時には全エキスパートが活性化しキャッシュヒット率が低下する。

評価対象と異なるデータ、規模、計算条件へ結論を広げるには追加検証が必要になる。

著者らは、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。同じ制約がある場面で再現できるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。採用を決める際は、論文と同じ指標だけでなく、対象データと計算条件でも比較したいところです。計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

Dense Transformerは容量を増やすと各tokenの計算量も増える。総parameter数を増やしながら、token当たりにactiveな計算を一部へ限定できるかが研究課題である。

結論は原論文に記載されたモデル、データ、計算環境を前提とし、条件外へはそのまま外挿しない。

Dense modelは各tokenで全FFN parameterを使う。従来のMixture-of-Expertsは疎な活性化を可能にする一方、routingの偏りや分散実行時の通信を考慮する必要がある。

提案の位置づけは、先行法から変えた要素と、比較実験で固定した条件を分けて読む必要がある。

Mixtral 8x7Bは、各Transformer blockのFFNを8 expertへ置き換え、routerがtokenごとにTop-2を選ぶSparse MoEです。総46.7B parameterに対してtoken当たり12.9Bを使用し、原論文はLlama 2 70Bなどと各種benchmarkで比較しました。

次節では、入力から出力までに何を更新し、どの部分の計算や学習を変えたのかを整理する。

token表現 $x$ に対しrouterは8個のexpert scoreを計算し、上位2個の集合 $T$ を選ぶ。層の出力は、選ばれたexpertだけを使う次の形で表せる。

ここで $E_i$ は各SwiGLU expert、$g_i(x)$ は選択された二つの間で正規化したrouter weightである。attention部分は全tokenで共有され、疎になるのは各blockのFFN部分である。したがって演算量はactive expert数で抑えられる一方、全expertのweightを保持するメモリは必要になる。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

論文に明記されていない条件は補わず、追試時の確認事項とする。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

指標が測る性能と、実運用で必要な性質が一致するかは別に検討する。

著者らが報告した主な結果は次の通り。

1. MMLU 70.6%, GSM8K 58.4%, HumanEval 40.2%, MATH 28.4%と、オープンモデルとして当時の最高水準を樹立
2. Passkey Retrievalテストにおいて、32kトークンの全範囲にわたって挿入深度に関わらず100%の精度でトークンを抽出
3. Llama 2 70Bに対して、推論時の消費トークンあたりエネルギー効率が3倍以上向上。

これらは原論文の著者報告であり、後続研究による独立検証とは区別する。

確認すべき限界は次の通り。

1. VRAM要求とオフローディング：FP16で約90GB、INT4量子化でも約25〜30GBのメモリが必要であり、単一コンシューマGPU（24GB）での非量子化実行は不可能
2. バッチ並列時の負荷不均等（Load Imbalance）：特定トークンが同一エキスパートに偏った場合、当該GPUの実行待ちが発生しバブルが拡大する。

正典データに独立したアブレーション結果が記録されていない要素については、各構成要素の寄与を数値で分離できない。失敗条件の範囲も、記録された限界を超えて推測しない。

報告された改善は提案全体を支持するが、評価条件が限定される場合、特定の構成要素、データ、計算量の寄与を完全には切り分けられない。別の比較条件でも差が残るかが、より強い解釈に必要になる。

この論文が直接確かめた範囲は、記載されたデータセット、比較対象、指標、計算条件に限られる。別の用途へ広げる場合は、同じ効果が保たれるかを改めて測る必要がある。

確認すべき限界は次の通り。

1. VRAM要求とオフローディング：FP16で約90GB、INT4量子化でも約25〜30GBのメモリが必要であり、単一コンシューマGPU（24GB）での非量子化実行は不可能
2. バッチ並列時の負荷不均等（Load Imbalance）：特定トークンが同一エキスパートに偏った場合、当該GPUの実行待ちが発生しバブルが拡大する。

特定ハードウェアや分散構成に対する依存性。

極限スケールにおけるハイパーパラメータチューニングの難しさ。

性能値だけでは、評価外の分布、規模、資源条件での頑健性までは示せない。

残る問いは、特定ハードウェアや分散構成に対する依存性をどの条件まで解消できるかである。

同一条件での追試、異なる規模やデータでの比較、構成要素ごとの切り分けが、結論の適用範囲を明確にする。

著者らは、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。同じ制約がある場面で再現できるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。採用を決める際は、論文と同じ指標だけでなく、対象データと計算条件でも比較したいところです。計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

さらに、改善が中心機構によるものか、データ・規模・計算条件にも依存するのかを構成要素別の比較で確かめる必要があります。異なる条件での追試が、結論をどこまで広げられるかを判断する材料になります。

Dense Transformerではparameter容量を増やすとtoken当たりのFFN計算量も増える。総parameter数とactive computeを疎なroutingで分離できるかが問いである。

Mixtral 8x7Bは各層に8個のSwiGLU expertを置き、routerがtokenごとにTop-2を選んで出力を合成する。総46.7Bのうちtoken当たり12.9B parameterがactiveになる。

著者らが報告した主な結果は次の通り。

1. MMLU 70.6%（Llama 2 70B: 69.8%, GPT-3.5: 70.0%）
2. GSM8K 58.4%（Llama 2 70B: 34.1%から24.3ポイント向上）
3. HumanEval 40.2%（Llama 2 70B: 29.3%から10.9ポイント向上）。

結果は原論文の著者報告として扱う。

確認すべき限界は次の通り。

1. 推論時のメモリフットプリントは総パラメータ数（46.7B）に拘束され、ハードウェアVRAM要件が緩和されない点
2. Expert Parallelism展開時のAll-to-All通信オーバヘッドとトークンディスパッチのレイテンシ。

外的妥当性は評価条件の範囲に限定される。

著者らは、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。この結果が対象に近い条件でも確かめられるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。ただし、計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

Dense Transformerは容量を増やすと各tokenの計算量も増える。総parameter数を増やしながら、token当たりにactiveな計算を一部へ限定できるかが研究課題である。

この問いに対し、提案手法と比較手法を同じ評価条件で比べる。

Dense modelは各tokenで全FFN parameterを使う。従来のMixture-of-Expertsは疎な活性化を可能にする一方、routingの偏りや分散実行時の通信を考慮する必要がある。

Mixtral 8x7Bは8個のSwiGLU expertとTop-2 routingを持つdecoder-only SMoEです。各tokenでは二つのexpert出力をrouter weightで合成し、総46.7Bに対して12.9B parameterをactiveにします。

この中心アイデアを、先行法との差と評価結果を分けて確認する。

各レイヤーの出力は $y = \sum_{i=0}^{N-1} g_i(x) E_i(x)$。ここで $g(x) = \text{Softmax}(\text{KeepTopK}(H(x), 2))$、$H(x)_i = (x \cdot W_g)_i$。$\text{KeepTopK}$ は上位2要素以外を $-\infty$ に設定。補助損失 $\mathcal{L}_{aux} = \alpha \cdot N \sum_{i=1}^N f_i P_i$ により、トークン配分比率 $f_i$ とルーター確率平均 $P_i$ の積を最小化して負荷均等化を達成します。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

著者らが報告した主な結果は次の通り。

1. MMLU 70.6%（Llama 2 70B: 69.8%, GPT-3.5: 70.0%）
2. GSM8K 58.4%（Llama 2 70B: 34.1%から24.3ポイント向上）
3. HumanEval 40.2%（Llama 2 70B: 29.3%から10.9ポイント向上）。

これらは原論文の著者報告であり、比較対象、データ、指標をそろえた範囲で解釈する。

この論文が直接確かめた範囲は、記載されたデータセット、比較対象、指標、計算条件に限られる。別の用途へ広げる場合は、同じ効果が保たれるかを改めて測る必要がある。

確認すべき限界は次の通り。

1. バッチサイズ増大時におけるGPU間All-to-All通信のインターコネクト帯域ボトルネック
2. メモリ帯域幅に依存する推論レイテンシ特性と、単一ノード内でのKVキャッシュ＋モデル重みの共存制約。

評価対象と異なるデータ、規模、計算条件へ結論を広げるには追加検証が必要になる。

著者らは、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。同じ制約がある場面で再現できるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。採用を決める際は、論文と同じ指標だけでなく、対象データと計算条件でも比較したいところです。計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

Dense Transformerは容量を増やすと各tokenの計算量も増える。総parameter数を増やしながら、token当たりにactiveな計算を一部へ限定できるかが研究課題である。

結論は原論文に記載されたモデル、データ、計算環境を前提とし、条件外へはそのまま外挿しない。

Dense modelは各tokenで全FFN parameterを使う。従来のMixture-of-Expertsは疎な活性化を可能にする一方、routingの偏りや分散実行時の通信を考慮する必要がある。

提案の位置づけは、先行法から変えた要素と、比較実験で固定した条件を分けて読む必要がある。

Mixtral 8x7Bは8個のSwiGLU expertとTop-2 routingを持つdecoder-only SMoEです。各tokenでは二つのexpert出力をrouter weightで合成し、総46.7Bに対して12.9B parameterをactiveにします。

次節では、入力から出力までに何を更新し、どの部分の計算や学習を変えたのかを整理する。

token表現 $x$ に対しrouterは8個のexpert scoreを計算し、上位2個の集合 $T$ を選ぶ。層の出力は、選ばれたexpertだけを使う次の形で表せる。

ここで $E_i$ は各SwiGLU expert、$g_i(x)$ は選択された二つの間で正規化したrouter weightである。attention部分は全tokenで共有され、疎になるのは各blockのFFN部分である。したがって演算量はactive expert数で抑えられる一方、全expertのweightを保持するメモリは必要になる。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

論文に明記されていない条件は補わず、追試時の確認事項とする。

著者らはLlama 2 70Bなどを比較対象に、知識、推論、コード、多言語、長文検索を評価した。Mixtralの報告値はMMLU 70.6%、GSM8K 58.4%、HumanEval 40.2%で、32K文脈のpasskey retrievalも調べている。

指標が測る性能と、実運用で必要な性質が一致するかは別に検討する。

著者らが報告した主な結果は次の通り。

1. MMLU 70.6%（Llama 2 70B: 69.8%, Llama 2 13B: 54.8%）
2. GSM8K 5-shot 58.4%（Llama 2 70B: 34.1%）、MATH 4-shot 28.4%（Llama 2 70B: 13.5%）
3. HumanEval pass@1 40.2%（Llama 2 70B: 29.3%）、MBPP pass@1 60.7%（Llama 2 70B: 49.8%）
4. Passkey Retrievalにおいて、32kトークンの全シーケンス長、全相対位置（0%〜100%）で完全一致100%を達成。

これらは原論文の著者報告であり、後続研究による独立検証とは区別する。

確認すべき限界は次の通り。

1. 原論文のrouting分析では、expertは明確な話題別に分かれるのではなく、構文やtoken位置に応じた選択も見られる。個々のexpertの役割を単純な専門分野として解釈することはできない。
2. 分散All-to-Allの通信ボトルネック：Expert Parallelismにおけるトークンディスパッチ・コンバインのレイテンシ隠蔽（Communication Overlap）が不十分な環境でのスループット低下。

正典データに独立したアブレーション結果が記録されていない要素については、各構成要素の寄与を数値で分離できない。失敗条件の範囲も、記録された限界を超えて推測しない。

報告された改善は提案全体を支持するが、評価条件が限定される場合、特定の構成要素、データ、計算量の寄与を完全には切り分けられない。別の比較条件でも差が残るかが、より強い解釈に必要になる。

この論文が直接確かめた範囲は、記載されたデータセット、比較対象、指標、計算条件に限られる。別の用途へ広げる場合は、同じ効果が保たれるかを改めて測る必要がある。

確認すべき限界は次の通り。

1. 全46.7B parameterをメモリへ保持する必要があり、active parameter数だけから必要メモリを見積もれない。
2. 分散All-to-Allの通信ボトルネック：Expert Parallelismにおけるトークンディスパッチ・コンバインのレイテンシ隠蔽（Communication Overlap）が不十分な環境でのスループット低下。

特定ハードウェアや分散構成に対する依存性。

極限スケールにおけるハイパーパラメータチューニングの難しさ。

性能値だけでは、評価外の分布、規模、資源条件での頑健性までは示せない。

残る問いは、特定ハードウェアや分散構成に対する依存性をどの条件まで解消できるかである。

同一条件での追試、異なる規模やデータでの比較、構成要素ごとの切り分けが、結論の適用範囲を明確にする。

著者らは、総46.7Bパラメータのうち各トークンで12.9Bを使い、複数の評価でLlama 2 70Bを上回る結果を報告しています。同じ制約がある場面で再現できるなら、モデル容量と一回の演算量を分けたい場合、疎な専門家選択は比較対象になりえます。採用を決める際は、論文と同じ指標だけでなく、対象データと計算条件でも比較したいところです。計算しない専門家の重みもメモリへ置く必要があり、ルーティングの偏りや分散時の通信も制約になります。

さらに、改善が中心機構によるものか、データ・規模・計算条件にも依存するのかを構成要素別の比較で確かめる必要があります。異なる条件での追試が、結論をどこまで広げられるかを判断する材料になります。