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

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

私たちは、新しいMoE Tritonカーネルと新しい数学的最適化により、約12倍高速なMixture of Experts（MoE）LLMトレーニングを導入します。 VRAMを35％以上削減 と コンテキストが約6倍長く 精度を損なうことなく実現します。

• 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を使用します。

• 当社のカーネルはデータセンター（B200、H100）でも動作し、 コンシューマー および古いGPU（例：RTX 3090）でも動作し、FFT、LoRA、QLoRAにも対応します。

🤗Hugging Faceとの協力により、すべてのMoEトレーニング実行をPyTorchの新しい標準である torch._grouped_mm 関数で標準化しました。Transformers v5は最近v4より約6倍高速なMoEに最適化されており、UnslothはカスタムTriton grouped‑GEMM + LoRAカーネルによってさらにこれを推し進めています。 追加の 約2倍の速度向上、VRAMを35％以上削減、コンテキストを6倍以上延長（v4比で総合的に12〜30倍の高速化）。

高速なMoEトレーニングにはUnslothノートブックをお試しください：

gpt-oss（20b） （無料）	Qwen3-30B-A3B （A100）	GLM-4.7-Flash （A100）
gpt-oss-120b （A100）	gpt-oss（500Kコンテキスト）	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％高速化でき、長時間の実行では十分に価値があります。 _grouped_mm、長いランでは価値があります。

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

🧭 自動バックエンド選択

当社の主な革新は Split LoRAアプローチ で、効率的なMoEのために約35％少ないメモリを使用し、Transformers v5 + と比較してトレーニングが2倍高速です。 torch._grouped_mmカスタム torch._grouped_mm ＋当社のTritonカーネルはTransformers v4より約12〜30倍高速です。

トレーニングMoEモデルを 4ビット QLoRAで行うことは現時点では推奨されません。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 として保持されていました。順伝播を実行する実用的な方法はエキスパートごとの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以降、エキスパート重みは 単一の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向けに導入しており、これらの最適化によってさらに効率が向上するはずです。

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

以下はシーケンス長にわたるトレーニング速度とメモリ使用量の比較で、Transformers v5（すでにMoEに torch._grouped_mm を使用）と比較したものです。gpt-oss BF16 MoEトレーニングでは、NVIDIA B200上でトレーニングが7倍高速化しVRAMが36％削減されるのを確認しています。 gpt-oss BF16 MoEトレーニングでは、B200上で7倍の高速化と36％のVRAM削減を確認しています。 Qwen3-30B-A3Bでは1.8倍の高速化が見られ、 GLM 4.7 FlashはRTX PRO 6000上で2.1倍高速です。すべてのベンチマークはLoRAランク=64およびMoEレイヤー上のすべてのLoRAモジュール（gate、up、down）で実施しています。

gpt-ossベンチマーク

私たちは以下を微調整してベンチマークを行いました： unsloth/gpt-oss-20b-BF16 ベンチマークではUnslothは7倍高速で、16Kコンテキスト時に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.4倍	6.76%
2048	292.88	696.57	41.83	44.93	2.4倍	6.89%
4096	370.30	1785.89	43.68	49.86	4.8倍	12.39%
8192	712.33	5226.86	47.43	73.80	7.3倍	35.73%
16384	1775.80	OOM（メモリ不足）	55.13	OOM（メモリ不足）	該当なし	該当なし

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.7倍	2.06%
2048	467.0	745.3	80.88	104.81	1.6倍	2.57%
4096	711.6	975.5	80.89	104.80	1.4倍	5.08%
8192	1376.6	1633.5	80.90	104.81	1.2倍	9.17%
16384	3182.2	3407.9	85.53	116.61	1.1倍	15.26%

GLM 4.7 ベンチマーク

Unslothは 全てのバッチサイズにおいてスループットが2.6倍速く、かつVRAMを15％以上削減します 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 ノートブック A100 80GB

コンテキスト長	Unsloth（ms）	TF v5（ms）	Unsloth メモリ（GB）	TF v5 メモリ（GB）	速度向上	VRAM節約
512	1145.0	2992.1	57.81	60.89	2.6倍	6.51%
1024	1298.9	3323.3	58.76	62.55	2.6倍	6.22%
2048	1831.9	4119.3	60.09	67.32	2.3倍	9.46%
4096	2883.9	5646.1	63.34	76.78	2倍	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ビット QLoRAで行うことは現時点では推奨されません。BitsandBytesがそれをサポートしていないためで、これはUnsloth固有の問題ではありません。現状ではLoRAにbf16または完全なフルファインチューニングを使用してください。

これらの最適化は デフォルトで有効化されています （特にQwen-3 MoE、gpt-oss、上記のモデルで）UnslothでMoEモデルをトレーニングする際に。実装は 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であり、それは概ね 約100万のLoRAパラメータ対約4800万のフルパラメータに相当します - おおよそ ~2%, 精度の損失がほとんどまたはまったくないことが多いです。

MoEではLoRAの状況が変わります

MoEレイヤーは異なり、並列にE個のエキスパートMLPがあるため、エキスパートごとの変更（LoRAを追加するなど）はすべてのエキスパートに拡張されます。 E個のエキスパートMLPが並列に存在しますので、エキスパートごとの変化は全体にスケールします。

例として 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ランク 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 と up_proj として融合されるため、 gate_up_projを通常は一緒に具現化し、オーバーヘッド／ピークメモリをほぼ2倍にします。

メモリに関して言えば、シーケンス長 s、Eエキスパート、 k が選ばれた場合、両方のアプローチで共通する以下の値があります

# これらの値はすべてエキスパートあたり
最終出力： (s, n)
入力活性化： (s, m)
最終出力： (s, n)

ここから両者は分岐し始めます。peftのアプローチでは次のようになります：

delta = loraA@loraB = （エキスパートごと）(m,n) = E*m*n パラメータ

UnslothのSplit LoRAアプローチでは、次の演算を行います：

Y = X @ loraA : (s,m) @ (m, r)       # しかしkエキスパートに対しては疎で k*s*r パラメータ
Y @ loraB: (s, r) @ (r, n)           # しかし再び疎で k*s*n パラメータ

ここで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の場合、次のようになります： 分析的観点からSplit LoRAの方が有利になる限界は次のときです： s > Emn / (k (m+n)) これはおおよそ Qwen3-30B-A3Bスタイルのモデルで16Kトークン程度です。

最後に、いくつかの速度向上は メモリトラフィックの削減によるものです：現代の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.37倍
2048	292.88	696.57	2626.80	2.38倍
4096	370.30	1785.89	4027.93	4.82倍
8192	712.33	5226.86	8513.52	7.34倍
16384	1775.80	OOM（メモリ不足）	OOM（メモリ不足）	該当なし

メモリ（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（メモリ不足）	該当なし

🎉 重要なUnslothアップデート

1. MoEリリースの一環として、次も行いました： Gemma-3はデフォルトでFlex-Attentionを使用するようになり、これはfloat16設定でも動作します（以前あった無限大問題は既に解決済みです）。 Gemma-3は現在O(N)メモリを使用し、O(N^2)メモリではなく、トレーニングが3倍以上速くなります （コンテキスト長が長くなるほどさらにスケールします）。以前のUnslothバージョンはOOMになっていました。 以前の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％）
これはおおよそ	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との後方互換性を得るために協力してくれたことに心から感謝します。