> For the complete documentation index, see [llms.txt](https://unsloth.ai/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unsloth.ai/docs/zh/ji-chu-zhi-shi/faster-moe.md). # 使用 Unsloth 将 MoE 模型微调速度提升 12 倍使用 Unsloth 指南在本地训练 MoE LLM。我们推出了约快 12 倍的专家混合（MoE）LLM 训练，采用 **显存减少超过 35%** 和 **上下文长度约延长 6 倍** 借助我们新的 MoE Triton 内核和新的数学优化，且精度完全不损失。 * Unsloth 现在支持以下 MoE 架构的快速训练，包括 [gpt-oss](/docs/zh/mo-xing/gpt-oss-how-to-run-and-fine-tune.md), [Qwen3](/docs/zh/mo-xing/tutorials/qwen3-how-to-run-and-fine-tune.md) (30B、235B、VL、Coder），DeepSeek [R1](/docs/zh/mo-xing/tutorials/deepseek-r1-0528-how-to-run-locally.md), [V3](/docs/zh/mo-xing/tutorials/deepseek-v3.1-how-to-run-locally.md) 以及 GLM（[4.6](https://unsloth.ai/docs/zh/ji-chu-zhi-shi/pages/c95883ea2c2bc5222ff12a80cc8e663fcb28cbdd#glm-4.6v-flash), [4.7](/docs/zh/mo-xing/tutorials/glm-4.7.md), [Flash](/docs/zh/mo-xing/tutorials/glm-4.7-flash.md)). * gpt-oss-20b 微调可在 **12.8 GB 显存**。Qwen3-30B-A3B（16 位 LoRA）使用 63GB。 * 我们的内核可同时用于数据中心（B200、H100）， **消费级** 以及较老的 GPU（例如 RTX 3090），并支持 FFT、LoRA 和 QLoRA。与 🤗Hugging Face 合作，我们用 PyTorch 新的 `torch._grouped_mm` 函数。Transformers v5 最近已针对 MoE 优化到比 v4 快约 6 倍，而 Unsloth 通过自定义 Triton grouped-GEMM + LoRA 内核进一步将其提升，带来 **额外的** 约 2 倍提速、显存减少超过 35%，以及上下文长度延长超过 6 倍（相较 v4 总体提速 12-30 倍）。试试我们用于 MoE 快速训练的 Unsloth Notebook： | [**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) (仅测试) |

### 🦥 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%" %}

{% endcolumn %} {% endcolumns %} {% hint style="success" %} 模型越大、使用的上下文越长， **我们的 Unsloth 内核带来的显存节省就越明显** （效率会指数级提升）。 {% endhint %} ### :compass: 自动后端选择我们的主要创新是 **Split LoRA 方法** ，用于高效 MoE；与 Transformers v5 + 相比可减少约 35% 的内存，并使训练快 2 倍 `torch._grouped_mm`。自定义 `torch._grouped_mm` + 我们的 Triton 内核比 Transformers v4 快约 12-30 倍。

{% hint style="warning" %} 在以下环境中训练 MoE 模型： **4 位** 目前不建议使用 QLoRA，因为 BitsandBytes 还不支持它。这并非 Unsloth 特有的问题。暂时请使用 bf16 进行 LoRA 或全量微调。 {% endhint %} Unsloth 会根据你的硬件自动选择以下任一后端：

后端	优化
grouped_mm	`torch._grouped_mm` - 从 T4 一直到 B200 都可用，但针对 H100 及以上进行了优化。
unsloth_triton	Unsloth Triton 内核——会在 A100 以及较旧的 PyTorch 版本上自动启用。
native_torch	原生 PyTorch。它慢 12 倍，但我们的显存节省依然保留！

你也可以自行切换： ```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` ，由每个专家对应的线性层组成。执行前向传播的唯一实际方法是对专家进行 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 起，专家权重被存储为一个 [`单个 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/zh/mo-xing/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) 用于 gpt-oss，而这些优化应该会让它更高效。 ## 📊 内核结果 + 基准测试以下是在不同序列长度下，与 Transformers v5 在训练速度和内存占用方面的对比（其已使用 `torch._grouped_mm` 用于 MoE）。对于 **gpt-oss BF16 MoE 训练，我们看到训练快 7 倍，显存减少 36%** 在 NVIDIA B200 上。对于 Qwen3-30B-A3B，则快 1.8 倍，而 **GLM 4.7 Flash 在 RTX PRO 6000 上快 2.1 倍**。所有基准测试都使用 LoRA rank = 64，并将所有 LoRA 模块放在 MoE 层（gate、up、down）上。 ### gpt-oss 基准测试我们微调了 [unsloth/gpt-oss-20b-BF16](https://huggingface.co/unsloth/gpt-oss-20b-BF16) 用于基准测试。Unsloth 快 7 倍，并且在 16K 上下文长度下显存减少 36%。Transformers v5 + TRL 会发生内存溢出，而 Unsloth 不会。此外，在这种情况下，得益于我们的 [Long Context gpt-oss](/docs/zh/mo-xing/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md#unsloths-flex-attention-implementation)以及我们的 MoE 内核，速度提升会随着序列长度增加而提升。

上下文长度	Unsloth（ms）	TF v5（ms）	Unsloth 内存（GB）	TF v5 内存（GB）	加速倍数	显存节省	Rank	Unsloth 预热（ms）	TRL 预热（ms）
1024	275.35	376.99	40.91	43.88	1.4x	6.76%	8	2601.17	615.62
2048	292.88	696.57	41.83	44.93	2.4x	6.89%	8	4996.62	928.42
4096	370.30	1785.89	43.68	49.86	4.8x	12.39%	8	6648.94	2130.33
8192	712.33	5226.86	47.43	73.80	7.3x	35.73%	8	9632.44	5472.66
16384	1775.80	OOM	55.13	OOM	不适用	不适用	8	12696.26	不适用

### Qwen3 基准测试在 **NVIDIA B200**上，我们看到 **使用 Qwen3-30B-A3B LoRA 时，速度提升约 1.7 倍，内存效率提升约 35%**，并且在更长序列长度下，显存节省还会进一步提升。 Qwen3-Next 和 Coder 令人惊讶地可以在单张 B200 GPU 上以 bf16 LoRA 运行。

在 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）	加速倍数	显存节省	Rank
1024	366.3	628.3	80.88	104.80	1.7x	2.06%	8
2048	467.0	745.3	80.88	104.81	1.6x	2.57%	8
4096	711.6	975.5	80.89	104.80	1.4x	5.08%	8
8192	1376.6	1633.5	80.90	104.81	1.2x	9.17%	8
16384	3182.2	3407.9	85.53	116.61	1.1x	15.26%	8

### GLM 4.7 基准测试 Unsloth 实现 **吞吐量快 2.6 倍，显存减少超过 15%** 在 GLM 4.7 Flash 的所有批大小下均如此。GLM 4.7 Flash 是一个 30B 的 MoE（30 亿活跃参数）智能体与代码模型，采用类似 DeepSeek MoE 风格的配置，包含 64 个路由专家和 1 个共享专家。我们将 Unsloth 的 MoE 训练与新版优化后的 Transformers v5 进行了基准测试。请使用下面我们为 GLM 4.7 Flash 新推出的 Colab 笔记本： {% embed url="" %} GLM 4.7 Flash MoE 笔记本 A100 80GB {% endembed %}

上下文长度	Unsloth（ms）	TF v5（ms）	Unsloth 内存（GB）	TF v5 内存（GB）	加速倍数	显存节省	Rank	Unsloth 预热（ms）	TRL 预热（ms）
512	1145.0	2992.1	57.81	60.89	2.6x	6.51%	8	13317.46	893.04
1024	1298.9	3323.3	58.76	62.55	2.6x	6.22%	8	12895.28	937.37
2048	1831.9	4119.3	60.09	67.32	2.3x	9.46%	8	12531.37	1039.45
4096	2883.9	5646.1	63.34	76.78	2倍	14.83%	8	7671.60	1643.26

### ⚡更快的 LoRA MoE 训练在 Transformers/PEFT 中，通常的做法是 **将 LoRA adapter 合并到基础权重中** 然后再运行 MoE 计算（尤其是因为 MoE 通常使用 `nn.Parameter` 而不是 `nn.Linear`）。问题在于，这种合并实际上会 **把 LoRA 增量（针对所有专家）实体化** `lora_B @ lora_A.t`，这会 **非常吃内存**. Unsloth 避免了这一点。我们之前曾用同样的思路优化通用 LoRA 训练和推理，现在也将其应用到了 **MoE + LoRA** 。数学上完全相同，因此损失、梯度和输出都保持不变。唯一改变的是 **操作顺序**，这得益于矩阵乘法的结合律。通过这种重排，我们获得了显著的加速和内存减少。 {% hint style="warning" %} 在以下环境中训练 MoE 模型： **4 位** 目前不建议使用 QLoRA，因为 BitsandBytes 还不支持它。这并非 Unsloth 特有的问题。暂时请使用 bf16 进行 LoRA 或全量微调。 {% 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)**，LoRA 会添加两个可训练矩阵，形状分别为 **(m, r)** 和 **(r, n)**。它们的乘积是 **(m, n)**，但你只需要跟踪以下内容的优化器状态和梯度： * `m*r + r*n` 个参数（LoRA），而不是 * `m*n` 个参数（全量微调） {% hint style="info" %} 在微调 MoE 时——不建议微调路由层，因此我们默认将其禁用。 {% endhint %} 对于典型的 MLP 层， `m ≈ 4096，n ≈ 12k，且 r ≈ 64`，大致相当于 **约 100 万个 LoRA 参数 vs 约 4800 万个完整参数——** 大约 **\~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 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` 和 `up_proj` 通常会被融合为 `gate_up_proj`，你通常会把两者一起实体化，从而使开销/峰值显存大致翻倍。 **从显存角度看，对于序列长度 s、E 个专家以及 `k` 个被选中的专家，两种方法共有如下部分** ``` # 这些数值都按每个专家计算最终输出：(s, n) 输入激活：(s, m) 最终输出：(s, n) ``` 从这里开始，两者开始分化。对于 peft 的方法，我们有 ``` delta = loraA@loraB = 每个专家 (m,n) = Emn 个参数 ``` 对于 Unsloth 的 Split 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` 个专家以及 top `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 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} $$ 从分析角度来看，Split LoRA 更优的临界点是当 `s > Emn/k(m+n)` 其数量级约为 `16K` Qwen3-30B-A3B 风格模型的 token 数。最后，一些加速来自 **减少内存流量**：现代 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	不适用

**显存使用量**

上下文长度	Unsloth 内存（GB）	TF v5 内存（GB）	TF v4 内存（GB）	显存节省
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	不适用

## :tada: Unsloth 重要更新 1. 作为我们 MoE 发布的一部分，我们还让 **Gemma-3 现在默认使用 Flex-Attention** ，并且这在 float16 设置下也同样有效（之前存在的无穷大问题我们已经在一段时间前解决了）。 **Gemma-3 现在使用 O(N) 内存，而不是 O(N^2) 内存，并且训练快 3 倍以上** （随着上下文长度扩展得甚至更好）。之前的 Unsloth 版本会 OOM。

| 上下文 | 旧峰值显存 | 新峰值显存 | 显存节省 | | --- | ------- | ------- | ------------- | | 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. 视觉微调现在接受仅包含图像和文本数据的混合数据！ 3. [Windows 现在已正式支持，无需 WSL](/docs/zh/kuai-su-kai-shi/install/windows-installation.md). 4. `trl==0.27.1` 和 `transformers==5.1.0` 得到了良好支持——之前我们的 120 个笔记本中覆盖率只有 30%，但现在覆盖率已超过 80%——我们计划在接下来的几天内将其提高到 100%。 5. 许多错误修复和其他更新——见 {% hint style="success" %} 要启用更快的 MoE 训练，请通过以下方式更新 Unsloth： `pip install --upgrade unsloth unsloth_zoo` {% endhint %} ### 致谢我们感谢 Hugging Face 团队与我们合作，为社区改进 MoE 训练。我们也衷心感谢 torchao 团队，尤其是 Vasily Kuznetsov（vkuzo），感谢他协助我们为 float16 启用 grouped\_mm 支持，使其能在 T4 上运行，并与 A100 保持向后兼容。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://unsloth.ai/docs/zh/ji-chu-zhi-shi/faster-moe.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.