# UnslothでMoEモデルを12倍高速にファインチューニング

約12倍高速なMixture of Experts（MoE）LLM学習を **VRAMを35%以上削減し** さらに **約6倍長いコンテキストで** 新しいMoE Tritonカーネルと新しい数理最適化により、精度を損なうことなく実現します。

* Unslothは現在、以下を含むMoEアーキテクチャの高速学習をサポートしています [gpt-oss](/docs/jp/moderu/gpt-oss-how-to-run-and-fine-tune.md), [Qwen3](/docs/jp/moderu/tutorials/qwen3-how-to-run-and-fine-tune.md) （30B、235B、VL、Coder）、DeepSeek [R1](/docs/jp/moderu/tutorials/deepseek-r1-0528-how-to-run-locally.md), [V3](/docs/jp/moderu/tutorials/deepseek-v3.1-how-to-run-locally.md) およびGLM（[4.6](https://unsloth.ai/docs/jp/ji-ben/pages/15da73ffae68627da854f843c0328406ea1ae99b#glm-4.6v-flash), [4.7](/docs/jp/moderu/tutorials/glm-4.7.md), [Flash](/docs/jp/moderu/tutorials/glm-4.7-flash.md)).
* gpt-oss-20bのファインチューニングは **12.8 GBのVRAM**で可能です。Qwen3-30B-A3B（16-bit LoRA）では63GBを使用します。
* 私たちのカーネルは、データセンター向けGPU（B200、H100）と **コンシューマー向け** および旧世代GPU（例: RTX 3090）で動作し、FFT、LoRA、QLoRAにも対応しています。

🤗Hugging Faceとの協力により、PyTorchの新しい `torch._grouped_mm` 関数を用いて、すべてのMoE学習ランを標準化しました。Transformers v5は最近、v4より約6倍高速なMoEに最適化されましたが、UnslothはカスタムTriton grouped-GEMM + LoRAカーネルにより、さらに **追加で** 約2倍の高速化、VRAMを35%以上削減、コンテキストを6倍以上長くできるようにしました（v4比で全体として12〜30倍高速化）。

高速なMoE学習には、Unsloth Notebooksをお試しください:

| [**gpt-oss (20b)**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-\(20B\)-Fine-tuning.ipynb) **（無料）** | [Qwen3-30B-A3B](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_MoE.ipynb) （A100）                                   | [GLM-4.7-Flash](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/GLM_Flash_A100\(80GB\).ipynb) （A100） |
| ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| [gpt-oss-120b](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-\(120B\)_A100-Fine-tuning.ipynb) （A100）  | [gpt-oss（50万トークンのコンテキスト）](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt_oss_\(20B\)_500K_Context_Fine_tuning.ipynb) | [TinyQwen3 MoE](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/TinyQwen3_MoE.ipynb) （テストのみ）         |

<figure><img src="/files/f86af8b5dc835a7cdedda995dd379f58d1140c12" alt="" width="563"><figcaption></figcaption></figure>

### 🦥 Unsloth MoE Tritonカーネル

と並んで `torch._grouped_mm` （参照 [#what-is-torch.\_grouped\_mm](#what-is-torch._grouped_mm "mention")）、場合によってはさらに高速に動作するカスタムTriton MoEカーネルを作成しました。これらはまた **下位互換性があり** A100のような旧世代ハードウェアや、古いPyTorchバージョンでも動作します。

{% columns %}
{% column width="50%" %}
A100では、私たちの **Tritonカーネルは約2.5倍高速です** より `torch._grouped_mm`。カーネルには最適な設定を選ぶための一度だけの自動チューニング手順もあります。

自動チューニングは学習開始時に一度だけ約2分かかりますが、A100では `_grouped_mm`より全体の実行時間を35%短縮できるため、長いランでは十分に価値があります。
{% endcolumn %}

{% column width="50%" %}

<figure><img src="/files/2cbfc5a3989f9e828a54f90d600572832d186d96" alt="" width="295"><figcaption></figcaption></figure>
{% endcolumn %}
{% endcolumns %}

{% hint style="success" %}
モデルが大きく、使うコンテキストが長いほど、 **Unslothカーネルによるメモリ節約効果はより顕著になります** （効率は指数関数的にスケールします）。
{% endhint %}

### :compass: バックエンドの自動選択

私たちの主な革新は、効率的なMoEのための **Split LoRAアプローチ** で、Transformers v5 + `torch._grouped_mm`と比較して、約35%少ないメモリで、学習は2倍高速です。カスタム `torch._grouped_mm` +私たちのTritonカーネルは、Transformers v4より約12〜30倍高速です。

<figure><img src="/files/f07fc78e7b4897988ef2d83ac45cd2b913a75738" alt="" width="563"><figcaption></figcaption></figure>

{% hint style="warning" %}
MoEモデルを **4ビット** で学習することは、BitsandBytesがまだ対応していないため、現時点では推奨されません。これはUnsloth固有の問題ではありません。今のところ、LoRAまたはフルファインチューニングにはbf16を使ってください。
{% endhint %}

Unslothは、ハードウェアに応じて以下のバックエンドのいずれかを自動選択します:

<table><thead><tr><th width="144.95001220703125">バックエンド</th><th>最適化</th></tr></thead><tbody><tr><td>grouped_mm</td><td><code>torch._grouped_mm</code> - T4からB200まで利用可能ですが、H100以降向けに最適化されています。</td></tr><tr><td>unsloth_triton</td><td>Unsloth Tritonカーネル - A100や古いPyTorchバージョンでは自動的に有効になります。</td></tr><tr><td>native_torch</td><td>標準のPyTorchです。12倍遅いですが、VRAM削減の恩恵はそのままあります！</td></tr></tbody></table>

自分で切り替えることもできます:

```python
os.environ["UNSLOTH_MOE_BACKEND"] = "grouped_mm"
os.environ["UNSLOTH_MOE_BACKEND"] = "unsloth_triton"
os.environ["UNSLOTH_MOE_BACKEND"] = "native_torch"
```

{% hint style="success" %}
より高速なMoE学習を有効にするには、Unslothを以下で更新してください `pip install --upgrade unsloth unsloth_zoo`
{% endhint %}

### ❓torch.\_grouped\_mmとは何ですか？

以前は、Mixture-of-Experts（MoE）の重みは `ModuleList` として各エキスパートごとの線形層で保存されていました。forwardパスを実行する現実的な方法は、エキスパートをforループで回すことだけでしたが、これは高コストで最適ではありませんでした。

```python
for expert_idx in expert_hit:
    expert_idx = expert_idx[0]
    if expert_idx == num_experts: continue
    _, token_idx = torch.where(expert_mask[expert_idx])
    current_state = hidden_states[token_idx]
    gate, up = nn.functional.linear(current_state, self.gate_up_proj[expert_idx]).chunk(2, dim=-1)
```

PyTorchは最近 [`grouped_mm`](https://docs.pytorch.org/docs/main/generated/torch.nn.functional.grouped_mm.html) まさにこのボトルネックに対処するために導入しました。並行して、私たちは独自のMoE最適化Tritonカーネルも提供しています。これはTransformersの重要な変更とも一致しています。Transformers v5以降では、エキスパートの重みは [`1つのnn.Parameter`](https://github.com/huggingface/transformers/blob/v5.0.0/src/transformers/models/qwen3_moe/modeling_qwen3_moe.py#L226)として保存されるため、 `grouped_mm` より高速なMoE学習と推論に自然に適しています。

つまり [transformers 4.57.6](https://github.com/huggingface/transformers/blob/v4.57.6/src/transformers/models/qwen3_moe/modeling_qwen3_moe.py#L222) では次のように変更されました:

{% code overflow="wrap" %}

```python
self.experts = nn.ModuleList(
    [Qwen3MoeMLP(config, intermediate_size) for _ in range(self.num_experts)]
)
```

{% endcode %}

から [transformers 5.0.0](https://github.com/huggingface/transformers/blob/v5.0.0/src/transformers/models/qwen3_moe/modeling_qwen3_moe.py#L226) 形式へ:

{% code overflow="wrap" %}

```python
self.gate_up_proj = nn.Parameter(torch.empty(num_experts, 2 * intermediate_dim, hidden_dim))
```

{% endcode %}

`torch._grouped_mm` NVIDIA T4以降のGPUで動作し、H100、A100、B200、RTX 6000 Proでも確認済みなので、幅広くサポートされています。

私たちは以前にもUnsloth [Flex Attention](/docs/jp/moderu/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) をgpt-oss向けに導入しましたが、これらの最適化によりさらに効率化されるはずです。

## 📊 カーネル結果 + ベンチマーク

以下は、学習速度とメモリ使用量を、すでに `torch._grouped_mm` を使っているTransformers v5に対して、シーケンス長ごとに比較したものです。MoE用の **gpt-ossのBF16 MoE学習では、NVIDIA B200で7倍高速化と36%のVRAM削減** が見られました。Qwen3-30B-A3Bでは1.8倍高速で、 **GLM 4.7 FlashはRTX PRO 6000で2.1倍高速**です。すべてのベンチマークはLoRA rank = 64、かつMoE層（gate、up、down）のすべてのLoRAモジュールで実施しています。

### gpt-oss ベンチマーク

私たちは [unsloth/gpt-oss-20b-BF16](https://huggingface.co/unsloth/gpt-oss-20b-BF16) をベンチマーク用にファインチューニングしました。Unslothは16Kコンテキスト長で7倍高速、VRAMを36%少なく使用します。Transformers v5 + TRLはメモリ不足になりますが、Unslothはなりません。また、この場合は私たちの [Long Context gpt-oss](/docs/jp/moderu/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md#unsloths-flex-attention-implementation)とMoEカーネルのおかげで、シーケンス長が長くなるほど高速化が増します。

<div><figure><img src="/files/afeff841a3261ca1445ae86fa8f58e1186e2014f" alt="" width="563"><figcaption></figcaption></figure> <figure><img src="/files/9457134dc832cf40f25010f6dad6d13d777d55af" alt="" width="188"><figcaption><p>transformers v4との比較</p></figcaption></figure></div>

<table data-full-width="true"><thead><tr><th>コンテキスト長</th><th>Unsloth (ms)</th><th>TF v5 (ms)</th><th>Unslothメモリ (GB)</th><th>TF v5メモリ (GB)</th><th>高速化</th><th>VRAM節約</th><th data-hidden>Rank</th><th data-hidden>Unslothウォームアップ (ms)</th><th data-hidden>TRLウォームアップ (ms)</th></tr></thead><tbody><tr><td>1024</td><td>275.35</td><td>376.99</td><td>40.91</td><td>43.88</td><td>1.4x</td><td>6.76%</td><td>8</td><td>2601.17</td><td>615.62</td></tr><tr><td>2048</td><td>292.88</td><td>696.57</td><td>41.83</td><td>44.93</td><td>2.4x</td><td>6.89%</td><td>8</td><td>4996.62</td><td>928.42</td></tr><tr><td>4096</td><td>370.30</td><td>1785.89</td><td>43.68</td><td>49.86</td><td>4.8x</td><td>12.39%</td><td>8</td><td>6648.94</td><td>2130.33</td></tr><tr><td>8192</td><td>712.33</td><td>5226.86</td><td>47.43</td><td>73.80</td><td>7.3x</td><td>35.73%</td><td>8</td><td>9632.44</td><td>5472.66</td></tr><tr><td>16384</td><td>1775.80</td><td><strong>OOM</strong></td><td>55.13</td><td><strong>OOM</strong></td><td>N/A</td><td>N/A</td><td>8</td><td>12696.26</td><td>N/A</td></tr></tbody></table>

### Qwen3 ベンチマーク

ある **NVIDIA B200**では、 **Qwen3-30B-A3B LoRAで約1.7倍の高速化と約35%良いメモリ効率**が見られ、長いシーケンス長ではさらにメモリ節約が改善します。

Qwen3-NextとCoderは、bf16 LoRAで単一のB200 GPUに意外にも収まります。

<figure><img src="/files/e252e2915206fbb94b029c6c8eea331ca755c174" alt="" width="563"><figcaption></figcaption></figure>

H100 GPUでは、ベースラインより大幅に良好で、 **1.77倍の高速化** を達成しつつ、4Kコンテキスト長でのファインチューニング時に約5.3GB節約します。8192のコンテキスト長までシームレスに拡張できますが、Transformers v5 + TRLは8KでOOMになります。8K時のメモリ使用量が、ベースラインの4K時より少ないことに注目してください。つまり、さらに長いコンテキスト長へ押し進めることができます。

<table data-full-width="true"><thead><tr><th>コンテキスト長</th><th>Unsloth (ms)</th><th>TF v5 (ms)</th><th>Unslothメモリ (GB)</th><th>TF v5メモリ (GB)</th><th>高速化</th><th>VRAM節約</th><th data-hidden>Rank</th></tr></thead><tbody><tr><td>1024</td><td>366.3</td><td>628.3</td><td>80.88</td><td>104.80</td><td>1.7x</td><td>2.06%</td><td>8</td></tr><tr><td>2048</td><td>467.0</td><td>745.3</td><td>80.88</td><td>104.81</td><td>1.6x</td><td>2.57%</td><td>8</td></tr><tr><td>4096</td><td>711.6</td><td>975.5</td><td>80.89</td><td>104.80</td><td>1.4x</td><td>5.08%</td><td>8</td></tr><tr><td>8192</td><td>1376.6</td><td>1633.5</td><td>80.90</td><td>104.81</td><td>1.2x</td><td>9.17%</td><td>8</td></tr><tr><td>16384</td><td>3182.2</td><td>3407.9</td><td>85.53</td><td>116.61</td><td>1.1x</td><td>15.26%</td><td>8</td></tr></tbody></table>

### GLM 4.7 ベンチマーク

Unslothは **2.6倍高速なスループットと15%以上少ないVRAM** を、GLM 4.7 Flashのすべてのバッチサイズで達成します。GLM 4.7 Flashは30B MoE（アクティブパラメータ3B）のエージェント／コーディングモデルで、DeepSeekのMoEスタイルに似た構成を採用し、64のルーティングされたエキスパートと1つの共有エキスパートを備えています。私たちはUnslothのMoE学習と新しく最適化されたTransformers v5をベンチマークしました。

下のGLM 4.7 Flash用の新しいColabノートブックを使ってください:

{% embed url="<https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/GLM_Flash_A100(80GB).ipynb>" %}
GLM 4.7 Flash MoE Notebook A100 80GB
{% endembed %}

<figure><img src="/files/000112fd357d6eab97e8e5b49421457d7b6774d3" alt="" width="563"><figcaption></figcaption></figure>

<table data-full-width="true"><thead><tr><th>コンテキスト長</th><th>Unsloth (ms)</th><th>TF v5 (ms)</th><th>Unslothメモリ (GB)</th><th>TF v5メモリ (GB)</th><th>高速化</th><th>VRAM節約</th><th data-hidden>Rank</th><th data-hidden>Unslothウォームアップ (ms)</th><th data-hidden>TRLウォームアップ (ms)</th></tr></thead><tbody><tr><td><p></p><p>512</p></td><td>1145.0</td><td>2992.1</td><td>57.81</td><td>60.89</td><td>2.6x</td><td>6.51%</td><td>8</td><td>13317.46</td><td>893.04</td></tr><tr><td>1024</td><td>1298.9</td><td>3323.3</td><td>58.76</td><td>62.55</td><td>2.6x</td><td>6.22%</td><td>8</td><td>12895.28</td><td>937.37</td></tr><tr><td>2048</td><td>1831.9</td><td>4119.3</td><td>60.09</td><td>67.32</td><td>2.3x</td><td>9.46%</td><td>8</td><td>12531.37</td><td>1039.45</td></tr><tr><td>4096</td><td>2883.9</td><td>5646.1</td><td>63.34</td><td>76.78</td><td>2x</td><td>14.83%</td><td>8</td><td>7671.60</td><td>1643.26</td></tr></tbody></table>

### ⚡より高速なLoRA MoE学習

Transformers/PEFTでは、通常のアプローチは **LoRAアダプタをベース重みに統合し** その後MoE計算を実行することです（特にMoEではしばしば `nn.Parameter` を `nn.Linear`の代わりに使うためです）。問題は、この統合によって実質的に **LoRAデルタ（すべてのエキスパート分）を実体化してしまう** `lora_B @ lora_A.t`ため、 **非常にメモリを消費する**.

ことです。Unslothはそれを回避します。私たちは以前、一般的なLoRA学習と推論を最適化するために同じ考え方を使っており、今回それを **MoE + LoRA** にも適用しました。数式は同じなので、損失、勾配、出力は変わりません。変わるのは **演算の順序**だけで、行列積の結合律によって可能になります。この並べ替えにより、大幅な高速化とメモリ削減が得られます。

{% hint style="warning" %}
MoEモデルを **4ビット** で学習することは、BitsandBytesがまだ対応していないため、現時点では推奨されません。これはUnsloth固有の問題ではありません。今のところ、LoRAまたはフルファインチューニングにはbf16を使ってください。
{% endhint %}

これらの最適化は **デフォルトで有効** です。UnslothでMoEモデルを学習する際（特にQwen-3 MoE、gpt-oss、上で述べたモデル）に有効になります。実装は `UNSLOTH_MOE_BACKEND` 環境変数で切り替えられ、互換性と好みに応じて `torch._grouped_mm` **Tritonカーネル** または **基本的なPyTorchのforループ**を選べます。最高の性能と幅広いサポートのため、既定では `grouped_mm` を使います。

```python
import os
# 別のバックエンドを選びたい場合（既定はgrouped_mm）以下の変数を設定してください:
# os.environ['UNSLOTH_MOE_BACKEND'] = 'unsloth_triton' # または grouped_mm あるいは native_torch
lora_rank = 16
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "Qwen/Qwen3-30B-A3B-Instruct-2507", # MoEモデル
    max_seq_length = max_seq_length,
    load_in_4bit = False, # MoEのnn.Parameterはまだbnb 4bitをサポートしていません
)
model = FastLanguageModel.get_peft_model(
    model,
    r = lora_rank,
    target_modules = [
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_up_proj", "down_proj", # MoE層にLoRA!
    ],
    lora_alpha = lora_rank*2, # *2で学習を高速化
    use_gradient_checkpointing = "unsloth", # メモリ使用量を削減
    random_state = 3407,
)
```

## 📚 実装の詳細

LoRAはパラメータ効率の良いファインチューニング手法です。フルの重み行列を更新する代わりに、はるかに少ないパラメータの低ランク「アダプタ」を学習するため、オプティマイザのメモリを大幅に削減できます。

元の重みの形状が **(m, n)**&#x306A;ら、LoRAは2つの学習可能な行列を追加し、その形状は **(m, r)** さらに **(r, n)**&#x3067;す。その積は **(m, n)**&#x306B;なりますが、オプティマイザ状態と勾配を追跡するのは次だけです:

* `m*r + r*n` 個のパラメータ（LoRA）であり、
* `m*n` 個のパラメータ（フルファインチューニング）ではありません。

{% hint style="info" %}
MoEのファインチューニングでは、ルータ層を微調整するのは良い考えではないため、デフォルトで無効化しています。
{% endhint %}

典型的なMLP層では、 `m ≈ 4096、n ≈ 12k、r ≈ 64`なので、だいたい **LoRAパラメータ約100万個 vs フルパラメータ約4800万個 -** およそ **\~2%,** 多くの場合、精度低下はほとんどなく、あるいは全くありません。

<figure><img src="/files/81a38bb3446c563493738110c18b94f54a9c4868" alt="" width="255"><figcaption></figcaption></figure>

#### MoE LoRAは事情を変えます

MoE層は異なります。なぜなら **E個のエキスパートMLPが並列**で存在するため、各エキスパートごとの変更（LoRAの追加など）はすべてのエキスパートにまたがってスケールするからです。

例として **Qwen3‑30B‑A3B**を取ると、隠れ次元 **m=2048**、中間次元 **n=768**, **、** E=128 **個のエキスパートがあり、トークンごとに** k=8

* `個が有効化されます。各エキスパートごとに:` さらに `gate_proj`: `up_proj`
* `(m, n) = (2048, 768)`: `down_proj`

(n, m) = (768, 2048) **LoRA rank r=64**では、各射影に追加されるのは `r*(m+n)=64*(2048+768)=180,224` 個のパラメータ/エキスパート（約 `11%` に相当します `2048×768` 行列の）。核心的な問題は `r/n = 64/768` が一般的なMLP設定と比べて大きいことです。例えば、 `r/n = 64/25600` の [Qwen3-32B](https://huggingface.co/Qwen/Qwen3-32B/blob/main/config.json#L13) のように同程度のサイズのモデルではそうです。

これを *すべての* エキスパートに対して実体化すると、メモリはすぐに膨らみます。さらに `個が有効化されます。各エキスパートごとに:` さらに `gate_proj` はしばしば `gate_up_proj`として融合されるため、通常は両方を一緒に実体化し、オーバーヘッド/ピークメモリがほぼ2倍になります。

**メモリの観点では、シーケンス長s、E個のエキスパート、そして `k` 個が選ばれる場合、両方式で共通して以下になります**

```
# これらの値はすべてエキスパートごとです
最終出力: (s, n)
入力活性化: (s, m)
最終出力: (s, n)
```

ここから違いが出始めます。peftの方式では

```
delta = loraA@loraB  = (m,n) per expert = Emn parameters
```

UnslothのSplit LoRA方式では、次の操作を行います

```
Y = X @ loraA : (s,m) @ (m, r)       # ただしk個のエキスパートに対しては疎 = ksr parameters
Y @ loraB: (s, r) @ (r, n)           # ただし再びk個のエキスパートに対しては疎 = ksn parameters
```

ではQwen3-30B-A3Bの場合を見てみましょう。

`E = 128, k = 8, m = 2048, n = 768.` これらをすべて代入すると `s < 32K.`&#x20;

$$
\begin{aligned}
\text{PEFT params}                       &:\quad Emn \\
\text{Unsloth Split LoRA params}         &:\quad ks(r+n) \\
\text{In typical LoRA we have}           &:\quad r \ll n \\
\text{Split LoRA is better when}         &:\quad Emn > ksn ;=; Em > ks \\
\\
\text{For Qwen3-30B-A3B, we have} \\
E &= 128, \quad k = 8, \quad m = 2048, \quad n = 768 \\
\\
\text{So, Split LoRA is mathematically better when} \\
s &< \frac{Emn}{kn} = 32K
\end{aligned}
$$

**計算量の観点では、シーケンス長 `s`, `、` E `k` 個のエキスパートと上位**

$$
\begin{aligned}
\Delta = AB,
A \in \mathbb{R}^{m \times r}, ;
B \in \mathbb{R}^{r \times n}
&\quad \Rightarrow \quad 2mnr \text{ flops per expert lora} \\
\\
W' = W + \Delta
\quad &\Rightarrow \quad mn \text{ flops} \\
\\
XW'  \quad | \quad
X \in \mathbb{R}^{s \times m}, ;
W' \in \mathbb{R}^{m \times n}
\quad &\Rightarrow \quad 2smn \text{ flops} \\
\\
\text{MoE peft lora flops}
&= E\big(2mnr + mn\big)

* 2k,smn
  \end{aligned}
  $$

個を選ぶ場合、次を行っています:

$$
\begin{aligned}
XW &= 2smn  \text{  flops} \\
Y = XA, &= 2smr
\quad \text{(applied only to routed token--expert pairs)} \\
\
Z = YB &= 2srn \\
\text{MoE split lora flops}
&= 2k\big(smn + smr + srn\big) \\
\text{Crossover condition}
&:\quad 2ksr(m+n) > 2Emn(r+1/2)
\Rightarrow
s > \frac{Emn}{k(m+n)} \times (1+ \frac{1}{2r}) \\
\\
\text{For Qwen3-30B-A3B with}
&:
E = 128,;
m = 2048,;
n = 768,;
k = 8 \\
\\
\Rightarrow \quad
s
& ;\approx; 16\text{K tokens}
\end{aligned}
$$

先ほど述べたUnslothのsplit loraの場合は、 `s > Emn/k(m+n)` のときまでSplit LoRAの解析的な観点が有利であり、これは `16K` トークン程度でQwen3-30B-A3Bスタイルのモデルに相当します。

最後に、いくつかの高速化は **メモリトラフィックの削減**から来ています。現代のGPUはしばしば **帯域幅制約**を受けるため、転送するデータを減らすことがFLOPs以上に重要になることがあります。おおまかな高速化の見積もりは `Emn / [k·s·(m+n)]`で、したがって **s, E, k**と行列形状に強く依存します。

### 🔮 モデル対応

Unslothは、Qwen、gpt-oss、DeepSeek、GLMモデルの高速MoE学習をサポートしています:

* **Qwen3** （ThinkingとInstruct）: VL • 2507 • Coder&#x20;
* **gpt-oss**: 20B • 120B • safeguard
* **GLM**: 4.5 • 4.6 • 4.6-Air • 4.7 • 4.7-Flash
* **DeepSeek**: V3 • R1 • V3.1 • V3.2

いくつかのMoEモデルはまだアップロードしていない可能性がありますが、Unslothは引き続きそれらをサポートすべきです。

### 📈 さらにベンチマーク

#### gpt-oss BF16 ベンチマーク

Transformers v4に対する学習速度を含む

<table data-full-width="false"><thead><tr><th align="right">コンテキスト長</th><th align="right">Unsloth (ms)</th><th align="right">TF v5 (ms)</th><th align="right">TF v4 (ms)</th><th align="right">高速化</th></tr></thead><tbody><tr><td align="right">1024</td><td align="right">275.35</td><td align="right">376.99</td><td align="right">2111.18</td><td align="right">1.37x</td></tr><tr><td align="right">2048</td><td align="right">292.88</td><td align="right">696.57</td><td align="right">2626.80</td><td align="right">2.38x</td></tr><tr><td align="right">4096</td><td align="right">370.30</td><td align="right">1785.89</td><td align="right">4027.93</td><td align="right">4.82x</td></tr><tr><td align="right">8192</td><td align="right">712.33</td><td align="right">5226.86</td><td align="right">8513.52</td><td align="right">7.34x</td></tr><tr><td align="right">16384</td><td align="right">1775.80</td><td align="right">OOM</td><td align="right">OOM</td><td align="right">N/A</td></tr></tbody></table>

**メモリVRAM使用量**

<table data-full-width="false"><thead><tr><th align="right">コンテキスト長</th><th align="right">Unslothメモリ (GB)</th><th align="right">TF v5メモリ (GB)</th><th align="right">TF v4メモリ (GB)</th><th align="right">VRAM節約</th></tr></thead><tbody><tr><td align="right">1024</td><td align="right">40.91</td><td align="right">43.88</td><td align="right">89.75</td><td align="right">6.76%</td></tr><tr><td align="right">2048</td><td align="right">41.83</td><td align="right">44.93</td><td align="right">90.47</td><td align="right">6.89%</td></tr><tr><td align="right">4096</td><td align="right">43.68</td><td align="right">49.86</td><td align="right">92.72</td><td align="right">12.39%</td></tr><tr><td align="right">8192</td><td align="right">47.43</td><td align="right">73.80</td><td align="right">100.3</td><td align="right">35.73%</td></tr><tr><td align="right">16384</td><td align="right">55.13</td><td align="right">OOM</td><td align="right">OOM</td><td align="right">N/A</td></tr></tbody></table>

## :tada: 重要なUnslothアップデート

1. MoEリリースの一環として、私たちはまた **Gemma-3がデフォルトでFlex-Attentionを使用するようにしました** 。これはfloat16設定でも動作します（以前は無限大が発生していましたが、しばらく前に解決済みです）。 **Gemma-3は現在、O(N^2)メモリではなくO(N)メモリを使用し、3倍以上高速に学習します** （コンテキスト長が長いほどさらに良くスケールします）。以前のUnslothバージョンではOOMになっていました。

<figure><img src="/files/cab840469bc1104b2703099935bde2d109346a14" alt="" width="375"><figcaption></figcaption></figure>

| コンテキスト | 旧ピークVRAM | 新ピークVRAM | VRAM節約       |
| ------ | -------- | -------- | ------------ |
| 1K     | 20.1 GB  | 20.1 GB  | 0 GB（0%）     |
| 2K     | 21.5 GB  | 21.1 GB  | 0.3 GB（2%）   |
| 4K     | 27.7 GB  | 23.3 GB  | 4.5 GB（16%）  |
| 8K     | 52.3 GB  | 27.5 GB  | 24.8 GB（47%） |
| 16K    | OOM      | 36.0 GB  | --           |
| 24K    | OOM      | 44.6 GB  | --           |
| 32K    | OOM      | 53.1 GB  | --           |
| 48K    | OOM      | 38.4 GB  | --           |
| 64K    | OOM      | 44.7 GB  | --           |

2. Visionのファインチューニングで、画像のみとテキストデータの混在データが利用できるようになりました！
3. [WindowsがWSL不要で正式にサポートされるようになりました](/docs/jp/meru/install/windows-installation.md).
4. `trl==0.27.1` さらに `transformers==5.1.0` がよくサポートされています。以前は120個のノートブック全体の30%しか対応していませんでしたが、今では80%以上をカバーしており、今後数日で100%にする予定です。
5. 多くのバグ修正とその他の更新があります - 参照 <https://github.com/unslothai/unsloth/releases/tag/February-2026>

{% hint style="success" %}
より高速なMoE学習を有効にするには、Unslothを以下で更新してください `pip install --upgrade unsloth unsloth_zoo`
{% endhint %}

### 謝辞

コミュニティのMoE学習改善に協力してくださったHugging Faceチームに感謝します。

また、torchaoチーム、特にVasily Kuznetsov（vkuzo）には、float16向けのgrouped\_mmサポートを有効にしてT4で動作させ、A100との後方互換性を実現するのを手伝ってくださったことに心より感謝します。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://unsloth.ai/docs/jp/ji-ben/faster-moe.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.