gpt-oss：如何运行指南

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

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

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

微调 使用我们的免费 Colab 笔记本

使用以下方法训练 强化学习 (RL), gpt-oss-120b 可与 o4-mini 竞争，以及 gpt-oss-20b 可与 o3-mini 竞争。两者在函数调用和链式思考（CoT）推理方面表现出色，超过了 o1 和 GPT-4o。

为获得最佳性能，请确保你的总可用内存（统一内存 + 显存 + 系统内存）超过你正在下载的量化模型文件大小。如果不够，llama.cpp 仍然可以通过 SSD/HDD 卸载运行，但推理会更慢。

gpt-oss - Unsloth GGUF：

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

• 20B： gpt-oss-20B

• 120B： gpt-oss-120B

📜Unsloth 对 gpt-oss 的修复

我们的一些修复已被推送到 OpenAI 在 Hugging Face 上的官方模型中。 参见

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

推理引擎通常使用 jinja 聊天模板而不是 Harmony 包，我们在与 Harmony 直接比较后发现了一些问题。如果你看下面，顶部是来自 Harmony 的正确渲染形式。下面是当前 jinja 聊天模板渲染的形式。两者有不少差异！

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

messages = [
    {"role" : "user", "content" : "What is 1+1?"},
    {"role" : "assistant", "content" : "2"},
    {"role": "user",  "content": "What's the temperature in San Francisco now? How about tomorrow? Today's date is 2024-09-30."},
    {"role": "assistant",  "content": "User asks: 'What is the weather in San Francisco?' We need to use get_current_temperature tool.", "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(
    messages,
    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. 在 jinja 模板的一些边界处存在一些 额外的换行 。

3. 模型用于工具调用的思考内容应该有 analysis 标签，而不是 final 标签.

4. 其他聊天模板似乎根本没有利用 <|channel|>final ——应当将其用于最终的助手消息。你不应将其用于思考痕迹或工具调用。

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

🔢 精度问题

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

我们制作了一个 MXFP4 推理笔记本 ，也在 Tesla T4 的 Colab 上！

软件模拟 使得在没有本地微缩算子支持的硬件架构上成为可能。现在在这种情况下，微缩的 lhs/rhs 会预先上采样为 bf16 元素类型来进行点乘计算，

我们发现如果你使用 float16 作为混合精度自动铸型的数据类型，经过一段时间会出现无穷大。为了解决这个问题，我们发现将 MoE 在 bfloat16 中计算，然后保持在 bfloat16 或 float32 精度下，可以避免该问题。如果旧 GPU 甚至不支持 bfloat16（例如 T4），则使用 float32。

我们还将所有运算（如路由器）的精度改为 float32，以适应 float16 机器。

🖥️ 运行 gpt-oss

下面是关于该模型的 20B 和 120B 变体的指南。

任何低于 F16 的量化（包括 2 位）对精度的影响都很小，因为只有部分（例如注意力层）是更低位，其他大部分仍为全精度。因此大小接近 F16 模型；例如 2 位（11.5 GB）版本的性能几乎与完整 16 位（14 GB）版本相同。一旦 llama.cpp 对这些模型支持更好的量化，我们会尽快上传它们。

这些 gpt-oss 来自 OpenAI 的模型包含一个功能，允许用户调整模型的“推理努力（reasoning effort）”。这让你可以在模型性能与响应速度（延迟）之间进行权衡，具体表现为模型用于“思考”的 token 数量。

这些 gpt-oss 模型提供三种不同级别的推理努力供你选择：

• 低：针对需要非常快速响应且不需要复杂多步推理的任务进行优化。

• 中：性能与速度之间的平衡。

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

⚙️ 推荐设置

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

temperature=1.0, top_p=1.0, top_k=0

• 温度（Temperature）为 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 位量化达到每秒 6+ token 的推理速度，至少需要 14GB 的统一内存 （显存和内存合并）或 仅 14GB 的系统内存 作为经验法则，你的可用内存应当与所使用模型的大小相匹配或更大。GGUF 链接： unsloth/gpt-oss-20b-GGUF

注意： 模型可以在低于其总大小的内存下运行，但这会使推理变慢。最大内存仅在需要最快速度时才需要。

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

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

你可以使用我们的免费在 Google 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 之后）。如果下载卡住，请参见 Hugging Face Hub、XET 调试

# !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 位量化达到每秒 6+ token 的推理速度，建议至少有 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. 或者，通过以下方式下载模型（在安装 pip install huggingface_hub hf_transfer 之后）。你可以选择 UD-Q2_K_XL 或其他量化版本。

   # !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(
       repo_id = "unsloth/gpt-oss-120b-GGUF",
       local_dir = "unsloth/gpt-oss-120b-GGUF",
       allow_patterns = ["*F16*"],
   )

4. 以对话模式运行模型并尝试任意提示。

5. 编辑 --threads -1 为 CPU 线程数， --ctx-size 262114 为上下文长度， --n-gpu-layers 99 用于指定多少层进行 GPU 卸载。如果你的 GPU 内存不足，请尝试调整它。如果仅使用 CPU 推理，则移除该选项。

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

./llama.cpp/llama-cli \
    --model unsloth/gpt-oss-120b-GGUF/gpt-oss-120b-F16.gguf \
    --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 \

🛠️ 提高生成速度

如果你有更多显存，可以尝试卸载更多 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

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

我们还引入了 Unsloth 弹性注意力（Flex Attention） ，它能够实现 >8× 更长的上下文长度, >50% 更少的显存使用 和 >1.5× 更快的训练 相比所有实现。 在此处阅读更多

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 的分步教程：

教程：如何微调 gpt-oss

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

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

• gpt-oss-20b 推理 + 会话 笔记本

强化学习（GRPO）

Unsloth 现在支持 gpt-oss 的 RL！我们制作了两个笔记本，详情请阅读我们关于 gpt-oss RL 的专门博客： gpt-oss RL

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

💾新增：在 gpt-oss 训练后保存为 GGUF、vLLM

你现在可以使用 QLoRA 微调 gpt-oss 并直接保存、导出或合并模型到 llama.cpp, vLLM，或 HF ——不仅限于 Unsloth。我们希望尽快发布一个免费笔记本。

之前，任何 QLoRA 微调的 gpt-oss 模型仅限在 Unsloth 中运行。我们通过引入 MXFP4 的按需反量化 基模型（如 gpt-oss）在 LoRA 合并过程中，取消了该限制。这使得可以 以 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 微调可行

我们发现虽然 MXFP4 高效，但它并不原生支持与 gpt-oss 一起训练。为克服此限制，我们通过模拟 Bitsandbytes 的 NF4 量化，实施了针对 MXFP4 层的自定义训练函数。

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

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

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

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

数据集微调指南

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

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