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

Unsloth ガイドを使って MoE LLM をローカルで学習しましょう。

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

• Unslothは現在、以下を含むMoEアーキテクチャの高速学習をサポートしています gpt-oss, Qwen3 （30B、235B、VL、Coder）、DeepSeek R1, V3 およびGLM（4.6, 4.7, Flash).

• 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) （無料）	Qwen3-30B-A3B （A100）	GLM-4.7-Flash （A100）
gpt-oss-120b （A100）	gpt-oss（50万トークンのコンテキスト）	TinyQwen3 MoE （テストのみ）

🦥 Unsloth MoE Tritonカーネル

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

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

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

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

🧭 バックエンドの自動選択

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

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

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

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

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

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

より高速なMoE学習を有効にするには、Unslothを以下で更新してください pip install --upgrade unsloth unsloth_zoo

❓torch._grouped_mmとは何ですか？

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

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 まさにこのボトルネックに対処するために導入しました。並行して、私たちは独自のMoE最適化Tritonカーネルも提供しています。これはTransformersの重要な変更とも一致しています。Transformers v5以降では、エキスパートの重みは 1つのnn.Parameterとして保存されるため、 grouped_mm より高速なMoE学習と推論に自然に適しています。

つまり transformers 4.57.6 では次のように変更されました:

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

から transformers 5.0.0 形式へ:

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

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

私たちは以前にもUnsloth Flex Attention を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 をベンチマーク用にファインチューニングしました。Unslothは16Kコンテキスト長で7倍高速、VRAMを36%少なく使用します。Transformers v5 + TRLはメモリ不足になりますが、Unslothはなりません。また、この場合は私たちの Long Context gpt-ossとMoEカーネルのおかげで、シーケンス長が長くなるほど高速化が増します。

transformers v4との比較

コンテキスト長	Unsloth (ms)	TF v5 (ms)	Unslothメモリ (GB)	TF v5メモリ (GB)	高速化	VRAM節約
1024	275.35	376.99	40.91	43.88	1.4x	6.76%
2048	292.88	696.57	41.83	44.93	2.4x	6.89%
4096	370.30	1785.89	43.68	49.86	4.8x	12.39%
8192	712.33	5226.86	47.43	73.80	7.3x	35.73%
16384	1775.80	OOM	55.13	OOM	N/A	N/A

Qwen3 ベンチマーク

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

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

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

コンテキスト長	Unsloth (ms)	TF v5 (ms)	Unslothメモリ (GB)	TF v5メモリ (GB)	高速化	VRAM節約
1024	366.3	628.3	80.88	104.80	1.7x	2.06%
2048	467.0	745.3	80.88	104.81	1.6x	2.57%
4096	711.6	975.5	80.89	104.80	1.4x	5.08%
8192	1376.6	1633.5	80.90	104.81	1.2x	9.17%
16384	3182.2	3407.9	85.53	116.61	1.1x	15.26%

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ノートブックを使ってください:

Google Colabcolab.research.google.com

GLM 4.7 Flash MoE Notebook A100 80GB

コンテキスト長	Unsloth (ms)	TF v5 (ms)	Unslothメモリ (GB)	TF v5メモリ (GB)	高速化	VRAM節約
512	1145.0	2992.1	57.81	60.89	2.6x	6.51%
1024	1298.9	3323.3	58.76	62.55	2.6x	6.22%
2048	1831.9	4119.3	60.09	67.32	2.3x	9.46%
4096	2883.9	5646.1	63.34	76.78	2x	14.83%

⚡より高速なLoRA MoE学習

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

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

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

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

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)なら、LoRAは2つの学習可能な行列を追加し、その形状は (m, r) さらに (r, n)です。その積は (m, n)になりますが、オプティマイザ状態と勾配を追跡するのは次だけです:

• m*r + r*n 個のパラメータ（LoRA）であり、

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

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

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

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 のように同程度のサイズのモデルではそうです。

これを すべての エキスパートに対して実体化すると、メモリはすぐに膨らみます。さらに 個が有効化されます。各エキスパートごとに: さらに 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.

$$\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

• 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に対する学習速度を含む

コンテキスト長	Unsloth (ms)	TF v5 (ms)	TF v4 (ms)	高速化
1024	275.35	376.99	2111.18	1.37x
2048	292.88	696.57	2626.80	2.38x
4096	370.30	1785.89	4027.93	4.82x
8192	712.33	5226.86	8513.52	7.34x
16384	1775.80	OOM	OOM	N/A

メモリVRAM使用量

コンテキスト長	Unslothメモリ (GB)	TF v5メモリ (GB)	TF v4メモリ (GB)	VRAM節約
1024	40.91	43.88	89.75	6.76%
2048	41.83	44.93	90.47	6.89%
4096	43.68	49.86	92.72	12.39%
8192	47.43	73.80	100.3	35.73%
16384	55.13	OOM	OOM	N/A

🎉 重要なUnslothアップデート

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

コンテキスト	旧ピーク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	--

1. Visionのファインチューニングで、画像のみとテキストデータの混在データが利用できるようになりました！

2. WindowsがWSL不要で正式にサポートされるようになりました.

3. trl==0.27.1 さらに transformers==5.1.0 がよくサポートされています。以前は120個のノートブック全体の30%しか対応していませんでしたが、今では80%以上をカバーしており、今後数日で100%にする予定です。

4. 多くのバグ修正とその他の更新があります - 参照 https://github.com/unslothai/unsloth/releases/tag/February-2026

より高速なMoE学習を有効にするには、Unslothを以下で更新してください pip install --upgrade unsloth unsloth_zoo

謝辞

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

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