💎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ビット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では全体の実行を35%高速化できるため長時間の実行では十分に価値があります（vs _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 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から動作し始め、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はメモリ不足（OOM）になりますが、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つの共有エキスパート）を採用しています。私たちは新しく最適化されたTransformers v5と比較してUnsloth MoEトレーニングをベンチマークしました。

以下の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	2x	14.83%

⚡より高速なLoRA MoEトレーニング

Transformers/PEFTでは、通常のアプローチは LoRAアダプターをベースの重みにマージすること そしてその後MoEの計算を実行することです（特にMoEはしばしば 両モデルはMoEアーキテクチャを使用しており、20Bモデルはトークンごとに32中4人のエキスパートを選択し、120Bモデルは128中4人を選択します。訓練とリリース時には重みはMXFP4形式で の代わりに オブジェクトとして保存され、を使うため）。問題は、このマージが実質的に 全エキスパート分のLoRA差分を具現化してしまうことです。 lora_B @ lora_A.t、これは 非常にメモリを消費します.

Unslothはそれを回避します。以前私たちは同じアイデアを使って一般的なLoRAのトレーニングと推論を最適化しており、現在それを MoE + LoRA にも適用しました。数学的には同一であるため、損失、勾配、出力は同じままです。唯一の変更は 演算の順序で、行列乗算の結合法則によって可能になっています。この順序変更により大幅な高速化とメモリ削減が得られます。

でMoEモデルをトレーニングする場合、 4ビット QLoRAは現時点ではBitsandBytesがサポートしていないため推奨されません。これはUnsloth固有の問題ではありません。現状ではLoRAにはbf16、またはフルファインチューニングを使用してください。

これらの最適化は デフォルトで有効になっています （特にQwen-3 MoE、gpt-oss、および上で言及したモデルの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追加）はすべてのエキスパートに対してスケールします。

例として 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 を すべての Qwen 3 デンスモデル（ の類似サイズの場合。

これをすべての 専門家に実体化すると、メモリは急速に積み上がります。そして、 はしばしば gate_proj および up_proj として融合されるため、 gate_up_proj、通常は両方を一緒に実体化するため、オーバーヘッド/ピークメモリが概ね倍になります。

メモリの観点では、シーケンス長を s、E を専門家数、 k が選ばれた場合、両アプローチで共通する次のような値が得られます

# これらの値はすべて専門家ごとです
最終出力: (s, n)
入力アクティベーション: (s, m)
最終出力: (s, n)

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

delta = loraA@loraB  = (m,n) 専門家ごと = Emn パラメータ

Unsloth の分割 LoRA アプローチでは、次の操作を行います

Y = X @ loraA : (s,m) @ (m, r)       # ただし k 個の専門家に対してはスパースで = ksr パラメータ
Y @ loraB: (s, r) @ (r, n)           # ただし再び k 個の専門家に対してはスパースで = ksn パラメータ

ここで 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}$$

先に述べた Unsloth の分割 LoRA の場合、次のようになります

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

解析的観点から分割 LoRA が有利になる点は次のとおりです: s > Emn/k(m+n) これはおおよそ次のオーダーです 16K Qwen3-30B-A3B スタイルのモデルではトークン。

最後に、いくつかの高速化は次から来ます メモリ転送量の削減：現代のGPUはしばしば 帯域幅制約にあるため、転送データを減らすことは FLOP より重要になる場合があります。おおまかな速度向上の推定は Emn / [k·s·(m+n)]、したがってこれは強く依存します s、E、k、および行列の形状。

🔮 モデルサポート

Unsloth は Qwen、gpt-oss、DeepSeek、および GLM モデルのより高速な MoE トレーニングをサポートします：

• Qwen3 （Thinking and Instruct）：VL • 2507 • Coder

• gpt-oss：20B • 120B • セーフガード

• 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 と比較したトレーニング速度

: SigLIP2 NaFlex 形状最適化 400M	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	該当なし

メモリ VRAM 使用量

: SigLIP2 NaFlex 形状最適化 400M	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) ではなく、トレーニングは >3x 速くなりました （コンテキスト長とともにさらに良くスケールします）。以前の 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. ビジョンのファインチューニングは、画像のみとテキストのみの混合データを受け付けるようになりました！

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

h-small —

コミュニティのための MoE トレーニング改善で協力してくれた Hugging Face チームに感謝します。

また、torchao チーム、特に Vasily Kuznetsov (vkuzo) に、float16 の grouped_mm サポートを有効にして T4 で動作させ、A100 との下位互換性を得るために協力してくれたことを心より感謝します。