💎使用 Unsloth 将 MoE 模型微调加速 12 倍

使用 Unsloth 在本地训练 MoE LLM 的指南。

我们引入了约12倍更快的专家混合（MoE）大语言模型训练，具有 >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 显存。Qwen3-30B-A3B（16 位 LoRA）使用 63GB。
我们的内核可在数据中心 GPU（B200、H100）、 消费级 以及较旧的 GPU（例如 RTX 3090）上运行，并支持 FFT、LoRA 和 QLoRA。

我们与 🤗Hugging Face 合作，使所有 MoE 训练运行与 PyTorch 的新功能标准化， torch._grouped_mm 函数。Transformers v5 最近在 MoE 上比 v4 优化了约6倍，而 Unsloth 通过自定义 Triton 分组‑GEMM + LoRA 内核进一步提升，带来 额外的 约2倍的加速，>35% 的显存降低以及>6倍更长的上下文（相较于 v4 总体加速 12-30 倍）。

试用我们的 Unsloth 笔记本以进行快速 MoE 训练：

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 分钟，但相较于 _grouped_mm，在 A100 上可使整个运行加速 35%，对较长的训练非常值得。

模型越大、上下文越长， 我们的 Unsloth 内核带来的内存节省就越明显 （效率将呈指数级扩展）。

🧭 自动后端选择

我们的主要创新是我们的 Split LoRA 方法 用于高效 MoE，相比 Transformers v5 + torch._grouped_mm，它使用约 ~35% 更少的内存并且训练速度快 2 倍。 torch._grouped_mm 自定义的

加上我们的 Triton 内核比 Transformers v4 快约 12-30 倍。

Unsloth 将根据你的硬件自动选择以下后端之一：

后端

优化项

torch._grouped_mm grouped_mm

- 在 T4 到 B200 上可用，但针对 H100 及以上进行了优化。

unsloth_triton

Unsloth Triton 内核 - 在 A100 上会自动启用，并适用于较旧的 PyTorch 版本。

native_torch

原生 PyTorch。它慢 12 倍，但我们的显存减少仍然有效！

你也可以自行切换：
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？ 以前，专家混合（MoE）的权重被存储为一个 ModuleList

的每个专家的线性层。运行前向传递的唯一可行方式是对专家进行循环（for‑loop），这既昂贵又次优。
    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 最近引入了 以解决这个确切的瓶颈。与此同时，我们提供了自己的 MoE 优化 Triton 内核。这也与 Transformers 的一个关键变化一致：从 Transformers v5 起，专家权重被存储为一个单个 nn.Parameter 优化项 ，这使得

成为更自然的快速 MoE 训练和推理的匹配。所以， transformers 4.57.6

更改为：
    self.experts = nn.ModuleList(
)

为 [Qwen3MoeMLP(config, intermediate_size) for _ in range(self.num_experts)] transformers 5.0.0

风格：

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

在从 NVIDIA T4 开始的 GPU 上可运行，我们已在 H100、A100、B200 和 RTX 6000 Pro 上验证，因此支持范围广泛。我们之前还为 gpt-oss 引入了 Unsloth Flex Attention

，这些优化应使其更高效。

📊 内核结果与基准测试 torch._grouped_mm 下面是与 Transformers v5（已为 MoE 使用 进行对比）在不同序列长度下的训练速度和内存使用比较。对于 gpt-oss BF16 MoE 训练，我们在 NVIDIA B200 上看到 7 倍训练加速和 36% 的显存减少。对于 Qwen3-30B-A3B，则为 1.8 倍加速，且 GLM 4.7 Flash 在 RTX PRO 6000 上速度提高 2.1 倍。。所有基准测试均在 LoRA 秩 = 64 且所有 MoE 层（gate、up、down）上启用 LoRA 模块的情况下进行。

gpt-oss 基准

我们对以下模型进行了微调： unsloth/gpt-oss-20b-BF16 用于基准测试。Unsloth 在 16K 上下文长度下快 7 倍并使用 36% 更少的显存。Transformers v5 + TRL 在该情况下会内存不足，而 Unsloth 不会。此外，由于我们的 Long Context gpt-oss以及我们的 MoE 内核，随着序列长度增加速度提升也会增加。

上下文长度

Unsloth（毫秒）

TF v5（毫秒）

Unsloth 内存（GB）

TF v5 内存（GB）

加速比

显存节省

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）

不适用

Qwen3 基准

在一块 NVIDIA B200上，我们看到 Qwen3-30B-A3B LoRA 大约 1.7 倍的加速和约 35% 更好的内存效率，并且在更长序列长度下内存节省会进一步提升。

在 H100 GPU 上，我们相比基线表现显著更好，在 4K 上下文长度微调时最高可达 1.77 倍加速 训练的同时还节省了约 5.3GB 的内存。尽管我们可无缝扩展到 8192 上下文长度，Transformers v5 + TRL 在 8K 时会 OOM。注意我们在 8K 时使用的内存比基线在 4K 时还少，因此我们可以继续推动更长的上下文长度。

上下文长度

Unsloth（毫秒）

TF v5（毫秒）

Unsloth 内存（GB）

TF v5 内存（GB）

加速比

显存节省

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% 在所有批次大小下的 GLM 4.7 Flash 上。GLM 4.7 Flash 是一个 30B 的 MoE（3B 活跃参数）代理与代码模型，采用类似 DeepSeek MoE 风格的配置，具有 64 个路由专家和 1 个共享专家。我们将 Unsloth MoE 训练与新优化的 Transformers v5 进行了基准对比。

在下面使用我们的新 Colab 笔记本来运行 GLM 4.7 Flash：

上下文长度

Unsloth（毫秒）

TF v5（毫秒）

Unsloth 内存（GB）

TF v5 内存（GB）

加速比

显存节省

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

14.83%

⚡更快的 LoRA、QLoRA MoE 训练

在 Transformers/PEFT 中，通常的方法是先 将 LoRA 适配器合并到基础权重中， 然后再运行 MoE 计算（尤其是因为 MoE 通常使用 nn.Parameter 而不是 nn.Linear）。问题在于，这种合并实际上会 物化 LoRA 的增量（针对所有专家） lora_B @ lora_A.t，这会 非常耗内存.

Unsloth 避免了这一点。我们此前使用相同的思路去优化通用 LoRA 的训练与推理，现在我们已将其应用于 MoE + LoRA 。数学上是相同的，因此损失、梯度和输出保持不变。唯一的变化是 操作顺序，这是通过矩阵乘法的结合律实现的。通过这种重排，我们获得了显著的加速和内存减少。

这些优化在使用 Unsloth 训练 MoE 模型时默认启用（尤其是 Qwen-3 MoE、gpt-oss 以及上述提到的模型）。你可以通过环境变量切换实现： UNSLOTH_MOE_BACKEND ：选择 torch._grouped_mm Triton 内核 或 一个基本的 PyTorch for‑loop，取决于兼容性和偏好。我们默认使用 优化项 以获得最佳性能和广泛支持。

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 添加两个可训练矩阵，形状为 (m, r) 和 (r, n)。它们的乘积是 (m, n)，但你只跟踪优化器状态和梯度的：

m*r + r*n 参数（LoRA）而不是
m*n 参数（完整微调）

对于典型的 MLP 层， m ≈ 4096, n ≈ 12k, 且 r ≈ 64，大约是 ~1M 的 LoRA 参数对比 ~48M 的完整参数 - 大约 ~2%, 通常几乎不会或仅有极小的准确性损失。

MoE 中的 LoRA 会改变情况

MoE 层不同，因为你有 E 个专家 MLP 并行存在，因此任何每专家的变化（例如添加 LoRA）会在所有专家中放大。

以 Qwen3‑30B‑A3B为例：隐藏维度 m=2048，中间维度 n=768, E=128 专家，且 k=8 每个 token 激活。每个专家：

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_up_proj gate_proj 和 up_proj ，你通常会把两者一并物化，这大致会使额外开销/峰值内存翻倍。 就内存而言，对于序列长度 s、E 个专家以及被选择的k

，我们对两种方法都有以下常见项： # 所有这些值均为每个专家的数值 最终输出：（s, n）

输入激活：（s, m）
从这里开始情况开始分歧。对于 peft 的方法我们有：
delta = loraA@loraB  = (m,n) 每个专家 = E m n 参数
从这里开始情况开始分歧。对于 peft 的方法我们有：

对于 Unsloth 的 Split LoRA 方法，我们执行以下操作：

Y = X @ loraA : (s,m) @ (m, r)       # 但因为仅对 k 个专家稀疏，所以为 k s r 参数

Y @ loraB: (s, r) @ (r, n) # 但同样对 k 个专家稀疏，所以为 k s n 参数

现在以 Qwen3-30B-A3B 为例。
E = 128, k = 8, m = 2048, n = 768。

将这些值代入，我们得到

s < 32K。 在计算量方面，对于序列长度 s

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

、E 专家以及选择的前, k ，我们执行的是： # 所有这些值均为每个专家的数值 在我们提到的 Unsloth split lora 情况下，我们有：

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

从解析角度来看，Split 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}

s > Emn/k(m+n) 这大致在 16K 令牌对于 Qwen3-30B-A3B 风格的模型。 最后，一些加速来自于

减少的内存传输 ：现代 GPU 往往受限于带宽 ，因此传输更少的数据相比 FLOPs 更重要。一个粗略的加速估计为Emn / [k·s·(m+n)] ，因此它强烈依赖于s、E、k ，以及矩阵形状。🔮 模型支持

Unsloth 支持对 Qwen、gpt-oss、DeepSeek 和 GLM 模型进行更快的 MoE 训练：

（Thinking 与 Instruct）：VL • 2507 • Coder

Qwen3 ：20B • 120B • safeguard
gpt-ossGLM
：4.5 • 4.6 • 4.6-Air • 4.7 • 4.7-FlashDeepSeek
：V3 • R1 • V3.1 • V3.2我们可能尚未上传某些 MoE 模型，但 Unsloth 仍应支持它们。

📈 更多基准

gpt-oss BF16 基准

训练速度（包括与 Transformers v4 的对比）

上下文长度

TF v4（毫秒）

Unsloth（毫秒）

TF v5（毫秒）

1.37x

加速比

1024

275.35

376.99

2111.18

2.38x

2048

292.88

696.57

2626.80

4.82x

4096

370.30

1785.89

4027.93

7.34x

8192

712.33

5226.86

8513.52

显存使用情况

16384

1775.80

内存不足（OOM）

不适用

TF v4 内存（GB）

TF v4（毫秒）

Unsloth 内存（GB）

TF v5 内存（GB）

重要的 Unsloth 更新

显存节省

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）

不适用

🎉 作为我们 MoE 发布的一部分，我们还让

Gemma-3 现在默认使用 Flex-Attention ，并且这在 float16 设置下也能工作（之前存在的无穷问题我们已解决）。 Gemma-3 现在使用 O(N) 内存而不是 O(N^2) 内存，训练速度提高超过 3 倍 （随上下文长度扩展时表现更佳）。之前的 Unsloth 版本会 OOM。 上下文

旧的峰值显存

新的峰值显存

显存节省

20.1 GB

0 GB（0%）

21.5 GB

21.1 GB

0.3 GB（2%）

27.7 GB

23.3 GB

4.5 GB（16%）

52.3 GB

27.5 GB

24.8 GB（47%）

36.0 GB

令牌对于 Qwen3-30B-A3B 风格的模型。

内存不足（OOM）

24K

44.6 GB

内存不足（OOM）

32K

53.1 GB

内存不足（OOM）

48K

38.4 GB

内存不足（OOM）

64K

44.7 GB

内存不足（OOM）

视觉微调现在接受仅图片与文本混合的数据！

Windows 现已正式支持，无需 WSL
trl==0.27.1.
transformers==5.1.0 和 得到良好支持 - 之前覆盖了我们 120 个笔记本的 30%，现在我们已有 >80% 的覆盖率 - 我们计划在接下来的几天内将其提升至 100%。 许多错误修复和其他更新 - 参见
https://github.com/unslothai/unsloth/releases/tag/February-2026 鸣谢

os.environ["UNSLOTH_MOE_BACKEND"] = "native_torch" 要启用更快的 MoE 训练，通过以下命令更新 Unsloth：

我们感谢 Hugging Face 团队与我们合作，共同改进社区的 MoE 训练。

我们也衷心感谢 torchao 团队，特别是 Vasily Kuznetsov（vkuzo）帮助我们使 grouped_mm 支持 float16，在 T4 上运行并与 A100 保持向后兼容。

上一页DPO, ORPO, KTO 下一页Embedding Fine-tuning

最后更新于23小时前

这有帮助吗？

hashtag🦥 Unsloth MoE Triton 内核

hashtag🧭 自动后端选择

hashtagpip install --upgrade unsloth unsloth_zoo

hashtag，这些优化应使其更高效。

hashtaggpt-oss 基准

hashtagQwen3 基准

hashtagGLM 4.7 基准

hashtag⚡更快的 LoRA、QLoRA MoE 训练

hashtag📚 实现细节

hashtagMoE 中的 LoRA 会改变情况

hashtagUnsloth 支持对 Qwen、gpt-oss、DeepSeek 和 GLM 模型进行更快的 MoE 训练：

hashtaggpt-oss BF16 基准

hashtag训练速度（包括与 Transformers v4 的对比）

hashtag🎉 作为我们 MoE 发布的一部分，我们还让

hashtag我们感谢 Hugging Face 团队与我们合作，共同改进社区的 MoE 训练。

🦥 Unsloth MoE Triton 内核

🧭 自动后端选择

pip install --upgrade unsloth unsloth_zoo

，这些优化应使其更高效。

gpt-oss 基准

Qwen3 基准

GLM 4.7 基准

⚡更快的 LoRA、QLoRA MoE 训练

📚 实现细节

MoE 中的 LoRA 会改变情况

Unsloth 支持对 Qwen、gpt-oss、DeepSeek 和 GLM 模型进行更快的 MoE 训练：

gpt-oss BF16 基准

训练速度（包括与 Transformers v4 的对比）

🎉 作为我们 MoE 发布的一部分，我们还让

我们感谢 Hugging Face 团队与我们合作，共同改进社区的 MoE 训练。