OpenAI发布的GPT-OSS模型是其自六年前GPT-2以来最重要的开源大语言模型。在此期间，LLM的能力取得了显著进步。虽然与DeepSeek、Qwen、Kimi等现有开源模型相比，该模型在能力上未必有飞跃性提升，但它为我们重新审视LLM这些年的演变提供了良好契机。

与以往开源GPT模型的差异

GPT-OSS与早期模型类似，都是一个自回归的Transformer模型，一次生成一个标记。

2025年中期的LLM主要差异在于，其生成的标记能通过以下方式解决更复杂的问题：

• 使用工具
• 逻辑推理
• 更强的解题与编程能力

下图展示了其主要架构特征，这些特征与当前主流开源模型并无显著区别。与GPT-2的核心架构差异在于GPT-OSS采用了专家混合模型设计。

若想深入了解架构细节，我们的免费课程《Transformer LLM工作原理》通过大量可视化内容（含独家动画）进行了详细解析。

沿用课程中引入的注意力机制可视化语言，GPT-OSS的Transformer模块结构如下图所示。

需注意这些架构细节大多并非创新设计，与最新开源MoE模型的主流方案基本一致。

消息格式化

对多数用户而言，模型推理与工具调用的行为细节及格式化方式比架构本身更为重要。

下图清晰展示了模型的输入输出结构。

消息与输出通道

让我们通过三类开源LLM主要用户群体来解析这一机制：

• LLM应用终端用户

• 示例：ChatGPT应用使用者

• 这类用户主要接触自己发送的消息和最终答案，某些应用可能会展示部分中间推理过程

• LLM应用构建者

• 示例：Cursor或Manus开发者

• 输入消息：可自定义系统消息和开发者消息——定义模型预期行为、安全选项、推理层级及可用工具。还需对用户消息进行大量提示工程和上下文管理

• 输出消息：可选择是否向用户展示推理痕迹，同时还需定义工具，并设置推理的详细程度（例如，允许生成多少推理标记）

• LLM后训练者

• 进行模型微调的高级用户需要处理所有消息类型，并以正确格式组织推理、工具调用及响应数据

后两类用户（应用构建者与模型调优者）可通过理解助手消息的通道概念获益，该功能实现在OpenAI Harmony代码库中。

消息通道

模型输出均为助手消息，并通过"通道"类别标识消息类型：

• 分析通道：用于推理（及部分工具调用）
• 注释通道：用于函数调用（及多数工具调用）
• 最终通道：包含最终回复的消息

假设我们给模型一个需要推理并使用多个工具调用的提示，下图展示了使用全部三种消息类型的对话流程。

图中标注为第1、3、5轮是因为第2、4轮对应工具调用的响应。最终答案将是终端用户可见的内容。

推理机制

推理功能需要高级用户在权衡中做出选择。一方面，更深入的推理能让模型获得更多计算资源来解决复杂问题；另一方面，这会增加延迟和计算成本。这种权衡体现在：强推理LLM与非推理LLM各自擅长处理不同类型的问题。

折中方案是采用支持特定"推理预算"的推理模型，GPT-OSS正属于此类。它允许在系统消息中设置推理模式（低/中/高）。模型卡片中的图3展示了不同模式对基准测试得分及推理痕迹（即思维链）标记数量的影响。

这与Qwen3的二元推理模式（思考/非思考）形成对比。在思考模式下，Qwen3展示了在达到特定标记阈值时停止思考的方法，并报告了这对各类推理基准测试得分的影响。

推理模式详解（低/中/高）

为展示不同推理模式的差异，我们选取AIME25数据集中的难题对120B模型进行测试：

该题正确答案为104。中、高推理模式均答对，但高模式耗时翻倍。这印证了前文关于根据场景选择推理模式的观点：

• 智能体任务：若操作链涉及多步骤，高/中模式可能耗时过长

• 实时vs离线场景：考虑哪些任务可离线执行（用户无需主动等待）

• 以搜索引擎为例：通过预先处理与设计，查询时能快速返回结果

分词器特性

分词器与GPT-4相似但效率略优——尤其对非英语标记。例如，表情符号和汉字现在都被分词为两个标记（而非之前的三个），阿拉伯文字更多以完整标记而非字母形式分组。

不过，尽管分词器在这方面有所改进，但该模型主要还是基于英语数据进行训练的。代码（及Python缩进用的制表符）处理方式基本不变。数字分词规则也保持一致：三位数以内为独立标记，更大数字则拆分。

延伸阅读

推荐以下几篇深度解析：

• Sebastian Raschka博士的《从GPT-2到GPT-OSS：架构演进分析》
• Nathan Lambert的《GPT-OSS：OpenAI终于拥抱开源生态》
• 《GPT-OSS-120B（高模式）：API服务商基准测试与分析》