gpt-oss：如何运行指南

运行并微调 OpenAI 的新开源模型！

OpenAI 发布了 'gpt-oss-120b' 和 'gpt-oss-20b'，两个基于 Apache 2.0 许可证的最先进开源语言模型。两者的 128k 上下文模型在推理、工具使用和代理任务上均优于同等规模的开源模型。现在你可以使用 Unsloth 在本地运行并微调它们！

运行 gpt-oss-20b运行 gpt-oss-120b微调 gpt-oss

8 月 28 日更新: 你现在可以将 QLoRA 微调的 gpt-oss 模型导出/保存为 llama.cpp、vLLM、HF 等格式。

我们还推出了 Unsloth 弹性注意力（Flex Attention） 它可以实现 >8× 更长的上下文长度, >50% 更少的显存使用 和 >1.5× 更快的训练速度 相对于所有实现。 在此阅读更多

微调 使用我们的免费资源微调 gpt-oss-20b Colab 笔记本

训练使用了 强化学习（RL）, gpt-oss-120b 可与 o4-mini 抗衡，且 gpt-oss-20b 可与 o3-mini 抗衡。两者在函数调用和链式思维（CoT）推理方面表现出色，超越了 o1 和 GPT-4o。

gpt-oss - Unsloth GGUF：

包含 Unsloth 的 聊天模板修复。为获得最佳效果，请使用我们的上传并用 Unsloth 训练！

• 20B： gpt-oss-20B

• 120B： gpt-oss-120B

📜gpt-oss 的 Unsloth 修复

我们的一些修复已向上游推送到 OpenAI 在 Hugging Face 上的官方模型。 使用 GLM 4.7 的工具调用

OpenAI 发布了一个独立的解析和分词库，名为 Harmony 它允许将对话分词为 OpenAI 为 gpt-oss 推荐的格式。

推理引擎通常使用 jinja 聊天模板而不是 Harmony 包，我们在与 Harmony 直接比较后发现了一些问题。若如下所示，顶部是 Harmony 渲染的正确形式。下面是当前 jinja 聊天模板渲染的形式，差别相当多！

我们还制作了一些函数，允许你直接使用 OpenAI 的 Harmony 库而不使用 jinja 聊天模板——你可以像下面那样直接解析普通对话：

messages = [
    {"role" : "user", "content" : "What is 1+1?"},
    {"role" : "assistant", "content" : "2"},
    {"role": "user",  "content": "现在旧金山的温度是多少？明天呢？今天的日期是 2024-09-30。"},
    {"role": "assistant",  "content": "用户询问：'旧金山的天气如何？' 我们需要使用 get_current_temperature 工具。", "thinking" : ""},
    {"role": "assistant", "content": "", "tool_calls": [{"name": "get_current_temperature", "arguments": '{"location": "San Francisco, California, United States", "unit": "celsius"}'}]},
    {"role": "tool", "name": "get_current_temperature", "content": '{"temperature": 19.9, "location": "San Francisco, California, United States", "unit": "celsius"}'},
]

然后使用 encode_conversations_with_harmony 函数来自 Unsloth：

from unsloth_zoo import encode_conversations_with_harmony

def encode_conversations_with_harmony(
    def unsloth_inference(
    reasoning_effort = "medium",
    add_generation_prompt = True,
    tool_calls = None,
    developer_instructions = None,
    model_identity = "You are ChatGPT, a large language model trained by OpenAI.",
)

Harmony 格式包含多项有趣的设置：

1. reasoning_effort = "medium" 你可以选择 low、medium 或 high，这会改变 gpt-oss 的推理预算——通常越高模型的准确性越好。

2. developer_instructions 类似于你可以添加的系统提示。

3. model_identity 最好保持原样——你可以编辑它，但我们不确定自定义的是否能正常工作。

我们发现当前的 jinja 聊天模板存在多处问题（生态系统中存在多种实现）：

1. 函数和工具调用使用 tojson进行渲染，这本身没问题，因为它是一个字典，但如果它是字符串，双引号和其它 符号会被转义为反斜杠.

2. 模板中存在一些 额外的新行 在某些边界处。

3. 模型的工具调用思路应该使用 analysis 标签，而不是 final 标签.

4. 其他聊天模板似乎根本不使用 <|channel|>final ——该标签应当用于最终助手消息。你不应将其用于思考轨迹或工具调用。

我们的 GGUF、BnB 和 BF16 上传以及所有版本的聊天模板都已修复！例如在比较我们和 Harmony 的格式时，我们没有不同的字符：

🔢 精度问题

我们在 Tesla T4 和 float16 机器上发现了多处精度问题，主要因为模型是使用 BF16 训练的，所以存在异常值和溢出。MXFP4 在安培及更早的 GPU 上实际上不受支持，因此 Triton 为 MXFP4 矩阵乘法提供了 tl.dot_scaled 它会在内部将矩阵临时升级为 BF16。

我们做了一个 MXFP4 推理笔记本 在 Tesla T4 的 Colab 上也有！

软件仿真 使得可以针对没有原生微缩放操作支持的硬件架构。对于此类情况，微缩放的 lhs/rhs 会预先被提升为 bf16 元素类型以进行点积计算，

我们发现如果将 float16 用作混合精度自动转换的数据类型，经过一段时间后会出现无穷值。为了解决这个问题，我们发现将 MoE 使用 bfloat16，然后保留为 bfloat16 或 float32 精度比较稳妥。如果旧 GPU（如 T4）甚至不支持 bfloat16，则使用 float32。

我们还将 float16 机器上所有操作（如路由器）的精度更改为 float32。

🖥️ 运行 gpt-oss

下面是该 20B 和 120B 模型的变体。

任何比 F16 更小的量化，包括 2-bit，准确率损失很小，因为只有部分模块（例如注意力层）使用了更低比特，而大多数模块仍保持全精度。这就是大小接近 F16 模型的原因；例如 2-bit（11.5 GB）版本的性能几乎与完整 16-bit（14 GB）版本相同。一旦 llama.cpp 为这些模型支持更好的量化，我们会尽快上传它们。

最新的 gpt-oss OpenAI 的模型包含一项功能，允许用户调整模型的“推理努力”设置。这让你可以在模型性能和响应速度（延迟）之间进行权衡，取决于模型用于思考的令牌数量。

最新的 gpt-oss 模型提供三种可选的推理努力级别：

• 低: 优化用于需要非常快速响应且不需要复杂多步推理的任务。

• 中: 在性能与速度之间取得平衡。

• 高: 为需要强推理能力的任务提供最强的推理性能，但这会导致更高的延迟。

⚙️ 推荐设置

OpenAI 建议对这两款模型使用以下推理设置：

temperature=1.0, top_p=1.0, top_k=0

• 温度设为 1.0

• Top_K = 0（或尝试 100 以获取可能更好的结果）

• Top_P = 1.0

• 推荐最小上下文：16,384

• 最大上下文窗口长度：131,072

聊天模板：

<|start|>system<|message|>You are ChatGPT, a large language model trained by OpenAI.\nKnowledge cutoff: 2024-06\nCurrent date: 2025-08-05\n\nReasoning: medium\n\n# Valid channels: analysis, commentary, final. Channel must be included for every message.<|end|><|start|>user<|message|>Hello<|end|><|start|assistant<|channel|>final<|message|>Hi there!<|end|><|start|>user<|message|>What is 1+1?<|end|><|start|>assistant

句子/生成结束标记：EOS 为 <|return|>

运行 gpt-oss-20B

要在我们的动态 4-bit 量化下达到 6+ 令牌/秒 的推理速度，至少需要 14GB 的统一内存 （显存和内存合并）或 仅 14GB 的系统内存 作为经验法则，可用内存应与或超过你正在使用的模型大小。GGUF 链接： unsloth/gpt-oss-20b-GGUF

注意： 模型可以在低于其总体大小的内存上运行，但这会减慢推理速度。最高内存仅在追求最快速度时需要。

遵循 上述最佳实践。它们与 120B 模型相同。

目前你可以在 Google Colab、Docker、LM Studio 或 llama.cpp 上运行该模型。见下：

你可以使用我们的免费资源在 Colab 上运行 gpt-oss-20b： Google Colab 笔记本

🐋 Docker：运行 gpt-oss-20b 教程

如果你已经安装了 Docker Desktop，只需运行下面的命令即可完成：

docker model run hf.co/unsloth/gpt-oss-20b-GGUF:F16

✨ Llama.cpp：运行 gpt-oss-20b 教程

1. 获取最新的 llama.cpp 在 GitHub（此处）。您也可以按照下面的构建说明。若没有 GPU 或仅想用 CPU 推理，请将 -DGGML_CUDA=ON 改为 -DGGML_CUDA=OFF 。

apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp

1. 你可以直接通过 Hugging Face 拉取：

   ./llama.cpp/llama-cli \
       -hf unsloth/gpt-oss-20b-GGUF:F16 \
       --jinja -ngl 99 --ctx-size 16384 \
       --temp 1.0 --top-p 1.0 --top-k 0

2. 通过以下方式下载模型（在安装 pip install huggingface_hub hf_transfer ).

# !pip install huggingface_hub hf_transfer
import os
os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"
from huggingface_hub import snapshot_download
snapshot_download(
    repo_id = "unsloth/gpt-oss-20b-GGUF",
    local_dir = "unsloth/gpt-oss-20b-GGUF",
    allow_patterns = ["*F16*"],
)

运行 gpt-oss-120b：

要在我们的 1-bit 量化下达到 6+ 令牌/秒 的推理速度，我们建议至少具备 66GB 的统一内存 （显存和内存合并）或 66GB 的系统内存 作为经验法则，可用内存应与或超过你正在使用的模型大小。GGUF 链接： unsloth/gpt-oss-120b-GGUF

注意： 模型可以在低于其总体大小的内存上运行，但这会减慢推理速度。最高内存仅在追求最快速度时需要。

遵循 上述最佳实践。它们与 20B 模型相同。

📖 Llama.cpp：运行 gpt-oss-120b 教程

对于 gpt-oss-120b，我们将专门使用 Llama.cpp 进行优化推理。

如果你想要一个 全精度未量化版本，请使用我们的 F16 版本！

1. 获取最新的 llama.cpp 在 GitHub（此处）。您也可以按照下面的构建说明。若没有 GPU 或仅想用 CPU 推理，请将 -DGGML_CUDA=ON 改为 -DGGML_CUDA=OFF 。

   apt-get update
   apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
   git clone https://github.com/ggml-org/llama.cpp
   cmake llama.cpp -B llama.cpp/build \
       -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
   cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-gguf-split
   cp llama.cpp/build/bin/llama-* llama.cpp

2. 你可以直接使用 llama.cpp 下载模型，但我通常建议使用 huggingface_hub 要直接使用 llama.cpp，请执行：

   {% code overflow="wrap" %}

   ./llama.cpp/llama-cli \
       -hf unsloth/gpt-oss-120b-GGUF:F16 \
       --ctx-size 16384 \
       --n-gpu-layers 99 \
       -ot ".ffn_.*_exps.=CPU" \
       --temp 1.0 \
       --min-p 0.0 \
       --top-p 1.0 \
       --top-k 0.0 \

   {% endcode %}

3. 或者，通过（在安装后）下载模型。你可以选择 UD-Q2_K_XL，或其他量化版本.. pip install huggingface_hub hf_transfer repo_id = "unsloth/gpt-oss-120b-GGUF",

   # !pip install huggingface_hub hf_transfer
   import os
   os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "0" # 有时会限速，因此设置为 0 以禁用
   from huggingface_hub import snapshot_download
   snapshot_download(
       local_dir = "unsloth/gpt-oss-120b-GGUF",
       以对话模式运行模型并尝试任意提示。
       allow_patterns = ["*F16*"],
   )

4. --threads -1

5. 编辑 --ctx-size 以设置 CPU 线程数， 262114 作为上下文长度， 以将所有 MoE 层卸载到 CPU！这实际上允许你在 1 张 GPU 上放置所有非 MoE 层，从而提高生成速度。如果你有更多 GPU 容量，可以自定义正则表达式以适配更多层。更多选项详见 --n-gpu-layers 99 以设置多少层使用 GPU 卸载。如果 GPU 出现内存不足，请尝试调整它。如果仅使用 CPU 推理，请移除它。

使用 -ot ".ffn_.*_exps.=CPU" --model unsloth/gpt-oss-120b-GGUF/gpt-oss-120b-F16.gguf \ 这里.

./llama.cpp/llama-cli \
    🦥 使用 Unsloth 微调 gpt-oss
    --ctx-size 16384 \
    --n-gpu-layers 99 \
    -ot ".ffn_.*_exps.=CPU" \
    --temp 1.0 \
    --min-p 0.0 \
    --top-p 1.0 \
    --top-k 0.0 \

🛠️ 用于 GLM 4.7 的执行生成 Python 代码的工具调用

如果你有更多显存，可以尝试卸载更多 MoE 层，或将整层卸载。

通常， -ot ".ffn_.*_exps.=CPU" 会将所有 MoE 层卸载到 CPU！这实际上允许你将所有非 MoE 层放到 1 块 GPU 上，从而提高生成速度。如果你有更多的 GPU 容量，可以自定义正则表达式以卸载更多层。

如果你有稍多的 GPU 显存，尝试 -ot ".ffn_(up|down)_exps.=CPU" 此命令会卸载上投影和下投影的 MoE 层。

尝试 -ot ".ffn_(up)_exps.=CPU" 如果你有更多的 GPU 显存。此命令仅卸载上投影的 MoE 层。

你也可以自定义正则，例如 -ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU" 表示从第 6 层起卸载 gate、up 和 down 的 MoE 层。

最新的 llama.cpp 发布版 也引入了高吞吐量模式。使用 llama-parallel。在 这里可以了解更多信息。你也可以 例如将 KV 缓存量化到 4 位 。您还可以

Unsloth 的 gpt-oss 微调速度快 1.5 倍，显存使用减少 70%，并支持 10 倍更长的上下文长度。gpt-oss-20b 的 QLoRA 训练可在 14GB 显存上运行，gpt-oss-120b 可在 65GB 显存上运行。

QLoRA 要求：

• gpt-oss-20b = 14GB 显存 • gpt-oss-120b = 65GB 显存。 BF16 LoRA 要求：

• gpt-oss-20b = 44GB 显存 • gpt-oss-120b = 210GB 显存。 阅读我们关于微调 gpt-oss 的逐步教程：

免费 Unsloth 笔记本用于微调 gpt-oss：

⚡教程：如何微调 gpt-oss

你现在可以将 QLoRA 微调的 gpt-oss 模型导出/保存为 llama.cpp、vLLM、HF 等格式。

推理 + 会话 笔记本

• gpt-oss-20b 强化学习（GRPO）

Unsloth 现在支持 gpt-oss 的强化学习！我们制作了两个笔记本，更多细节请阅读我们关于 gpt-oss 强化学习的专门博客：

2048 笔记本 gpt-oss RL

（OpenAI 官方示例） 内核生成笔记本	💾

新增：在 gpt-oss 训练后保存为 GGUF、vLLM你现在可以使用 QLoRA 微调 gpt-oss 并直接保存、导出或合并模型到

vLLM llama.cpp, ，或HF ——不仅仅是 Unsloth。我们希望尽快发布一个免费的笔记本。 以前，任何 QLoRA 微调的 gpt-oss 模型都只能在 Unsloth 中运行。我们通过在 LoRA 合并过程中引入

MXFP4 的按需去量化 基础模型（例如 gpt-oss），消除了该限制。这使得可以 以 bf16 格式导出你微调后的模型 在微调你的 gpt-oss 模型后，你现在可以通过一个.

单一命令 model.save_pretrained_merged(save_directory, tokenizer):

如果你更愿意合并模型并直接推送到 Hugging Face Hub，你可以使用：

model.push_to_hub_merged(repo_name, tokenizer=tokenizer, token=hf_token)

💡使高效的 gpt-oss 微调成为可能」

💡使高效的 gpt-oss 微调成为可能

我们发现虽然 MXFP4 非常高效，但它本身并不原生支持与 gpt-oss 一起进行训练。为了解决这一限制，我们通过模仿它实现了专门针对 MXFP4 层的自定义训练函数，方法是使用 Bitsandbytes NF4 量化。

我们直接使用了 OpenAI 的 Triton Kernels 库以支持 MXFP4 推理。然而，对于微调/训练，MXFP4 内核尚不支持训练，因为反向传播尚未实现。我们正在积极在 Triton 中实现它！有一个名为 W_TRANSPOSE 的标志，如前所述 这里，应该实现该标志。导数可以通过权重矩阵的转置来计算，因此我们必须实现转置操作。

如果你想使用除 Unsloth 以外的任何库来训练 gpt-oss，则需要在训练前将权重上采样为 bf16。然而，这种方法 会显著增加 VRAM 使用量和训练时间，多达 300% 更多的内存使用量! 所有其他训练方法在训练 20B 模型时都需要至少 65GB 的显存，而 Unsloth 仅需 14GB 显存（减少 80%）。

由于这两个模型都采用 MoE 架构，20B 模型每个 token 从 32 个专家中选择 4 个，而 120B 模型每个 token 从 128 个中选择 4 个。在训练和发布期间，权重以 MXFP4 格式存储为 nn.Parameter 对象，而不是以 nn.Linear 层的形式，这使得量化变得复杂，尤其是因为 MoE/MLP 专家约占 20B 参数中的 190 亿（19B）。

为了启用 BitsandBytes 量化和节省内存的微调，我们将这些参数转换为 nn.Linear 层。尽管这会略微降低操作速度，但它允许在内存有限的 GPU 上进行微调，这是值得的权衡。

数据集微调指南

尽管 gpt-oss 仅支持推理，你仍然可以用一个非推理的 数据集对其进行微调，但这可能会影响它的推理能力。如果你想保持其推理能力（可选），可以使用直接答案与链式思维示例的混合。至少使用 75% 推理 和 25% 非推理 来使模型保留其推理能力。

我们的 gpt-oss-20b 会话笔记本使用了 OpenAI 的示例，即 Hugging Face 的 Multilingual-Thinking 数据集。使用该数据集的目的是使模型能够在这四种不同语言中学习并发展推理能力。