OpenAI 本周刚刚发布了他们的新开源权重 LLM：gpt-oss-120b 和 gpt-oss-20b，这是自 2019 年 GPT-2 以来他们首次发布开源权重模型。没错，得益于一些巧妙的优化，它们可以在本地运行（但稍后会详细介绍）。
这是自 GPT-2 以来，OpenAI 首次分享一个大型、完全开源权重的模型。早期的 GPT 模型展示了 Transformer 架构的扩展能力。2022 年发布的 ChatGPT 则通过展示其在写作、知识（以及后来的编码）任务中的实际用途，使这些模型成为主流。现在，他们分享了一些期待已久的权重模型，其架构包含一些有趣的细节。
过去几天，我阅读了代码和技术报告，总结了最有趣的细节。（就在几天后，OpenAI 还宣布了 GPT-5，我将在本文末尾结合 gpt-oss 模型简要讨论一下。）
以下是本文内容的快速预览。为了方便导航，我建议使用文章左侧的目录。
- 与 GPT-2 的模型架构对比
- 用于将 gpt-oss 模型适配到单张 GPU 的 MXFP4 优化
- 宽度与深度的权衡（gpt-oss 对比 Qwen3）
- 注意力偏置与注意力汇点
- 基准测试及与 GPT-5 的对比
希望你觉得这篇文章有收获！
在更详细地讨论架构之前，我们先从两个模型 gpt-oss-20b 和 gpt-oss-120b 的概览开始，如下方图 1 所示。
如果你之前看过最近的 LLM 架构图，或者读过我之前的 大型架构对比 文章，你可能会注意到，乍看之下并没有什么新颖或不同寻常之处。
[
](https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison)
这并不奇怪，因为领先的 LLM 开发者倾向于使用相同的基础架构，然后进行小幅调整。这纯粹是我的猜测，但我认为这是因为：
- 这些实验室之间的员工流动率很高。
- 我们仍然没有找到比 Transformer 架构更好的方案。尽管存在状态空间模型和文本扩散模型，但据我所知，还没有人证明它们在这个规模上能像 Transformer 一样表现出色。（我发现的大多数比较只关注基准测试性能。这些模型在处理现实世界、多轮写作和编码任务方面的表现仍不清楚。在撰写本文时，LM Arena 上排名最高的非纯 Transformer 模型是 Jamba，它是一个 Transformer-状态空间混合模型，排名第 96。编辑注：有人友好地指出 有一个排名更高的混合模型：Hunyuan-TurboS，排名第 22。）
- 大部分改进可能来自数据和算法调整，而不是重大的架构变更。
话虽如此，他们的设计选择中仍有许多有趣的方面。其中一些在上图中有所展示（另一些则没有，但我们稍后也会讨论）。在本文的剩余部分，我将逐一重点介绍这些特性，并将其与其他架构进行比较。
我还需要说明的是，我与OpenAI没有任何关联。我的信息来源于审查已发布的模型代码以及阅读他们的技术报告。如果你想了解如何在本地使用这些模型，最好的起点是OpenAI的官方模型中心页面：
20B模型可以在配备高达16 GB显存的消费级GPU上运行。120B模型则可以在配备80 GB显存的单张H100或更新的硬件上运行。我稍后会再回到这个话题，因为其中有一些重要的注意事项。
在我们开始比较gpt-oss与更新架构之前，让我们先乘上时光机，并排看看GPT-2（图2），看看事情已经取得了多大的进展。
gpt-oss和GPT-2都是基于《Attention Is All You Need (2017)》论文中介绍的Transformer架构构建的仅解码器LLM。多年来，许多细节已经发生了变化。
然而，这些变化并非gpt-oss所独有。正如我们稍后将看到的，它们也出现在许多其他LLM中。由于我在之前的《大型架构比较》文章中已经讨论过其中许多方面，我将尽量使每个小节保持简洁和重点突出。
Dropout (2012)是一种传统的防止过拟合的技术，通过在训练过程中随机“丢弃”（即设置为零）一部分层激活或注意力分数（图3）来实现。然而，在现代LLM中很少使用Dropout，GPT-2之后的大多数模型都放弃了它（无意双关）。
我猜测Dropout最初在GPT-2中使用是因为它继承自原始的Transformer架构。研究人员可能注意到它并不能真正提高LLM的性能（我在自己小规模的GPT-2复现运行中也观察到了同样的情况）。这可能是因为LLM通常只在海量数据集上训练一个epoch，这与最初引入Dropout时所需的数百个epoch的训练方案形成对比。因此，由于LLM在训练期间每个token只被看到一次，过拟合的风险很小。
有趣的是，虽然Dropout在LLM架构设计中已被忽视多年，但我发现一篇2025年的研究论文通过小规模LLM实验（Pythia 1.4B）证实，在单周期训练模式下，Dropout会导致下游性能下降。
在基于Transformer的LLM中，由于注意力机制的存在，位置编码是必不可少的。默认情况下，注意力机制将输入token视为无序的。在原始GPT架构中，绝对位置嵌入通过为序列中的每个位置添加一个可学习的嵌入向量（图4）来解决这一问题，该向量随后被添加到token嵌入中。
RoPE（旋转位置编码）引入了一种不同的方法：它不是将位置信息作为单独的嵌入添加，而是通过根据每个token的位置旋转查询和键向量来编码位置。（RoPE是一个优雅的想法，但解释起来也有点棘手。我计划将来单独详细讨论。）
虽然RoPE在2021年首次提出，但随着2023年原始Llama模型的发布，它被广泛采用，并从此成为现代LLM的标准配置。
早期的GPT架构使用GELU。为什么现在用Swish代替GELU？Swish（也称为Sigmoid线性单元或SiLU）被认为计算成本略低，在我看来，这就是全部原因。根据你查阅的论文不同，你会发现其中一种在建模性能上略优于另一种。在我看来，这些微小差异可能都在标准误差范围内，实际效果会因超参数敏感性而异。
激活函数曾经是争论的热点话题，直到十多年前深度学习社区基本确定了ReLU。从那时起，研究人员提出并尝试了许多具有更平滑曲线的类ReLU变体，而GELU和Swish（图5）是最终被保留的。
早期的GPT架构使用GELU，其定义为 0.5x * [1 + erf(x / sqrt(2))]。这里的 erf（误差函数的简称）是高斯函数的积分，通过高斯积分的多项式近似计算，这使得它比Swish中使用的sigmoid等更简单的函数计算成本更高，而Swish就是简单的 x * sigmoid(x)。
实际上，Swish 在计算上比 GELU 略为高效，这可能是它在大多数新模型中取代 GELU 的主要原因。根据具体参考的论文，两者在建模性能上可能各有优劣。但我认为这些差异通常处于标准误差范围内，最终胜出者很大程度上取决于超参数调优。
如今，大多数架构都使用 Swish。不过，GELU 并未被完全遗忘；例如，Google 的 Gemma 模型仍然使用 GELU。
但更值得注意的是，前馈模块（一个小型多层感知机）被替换为带门控的 “GLU” 变体，其中 GLU 代表门控线性单元，由一篇 2020 年的论文 提出。具体来说，原来的 2 个全连接层被替换为 3 个全连接层，其使用方式如下方图 6 所示。
乍一看，GEGLU/SwiGLU 变体可能比常规前馈层更好，因为多了一层参数。但这具有欺骗性，因为在实践中，SwiGLU/GEGLU 中的 W 和 V 权重层通常被设置为传统前馈层中 W_1 层大小的一半。
为了更好地说明这一点，请考虑常规前馈层和 GLU 变体的具体代码实现：
那么，假设我们的嵌入维度为 1024。在常规前馈的情况下，参数为：
- fc1: 1024 × 4096 = 4,194,304
- fc2: 1024 × 4096 = 4,194,304
即 fc1 + fc2 = 8,388,608 个参数。
对于 GLU 变体，我们有：
- fc1: 1024 × 1024 = 1,048,576
- fc2: 1024 × 1024 = 1,048,576
- fc3: 1024 × 1024 = 1,048,576
即 3 × 1,048,576 = 3,145,728 个权重参数。
因此，总体而言，使用 GLU 变体不仅参数更少，而且性能也更好。性能提升的原因在于这些 GLU 变体提供了额外的乘法交互，从而增强了表达能力（这与深度且窄的神经网络在训练良好的情况下优于浅层且宽的神经网络是同样的道理）。
除了如前所述将前馈模块升级为 SwiGLU 之外，gpt-oss 还将单个前馈模块替换为多个前馈模块，每次生成 token 时仅使用其中一部分。这种方法被称为混合专家模型（MoE），如下图 8 所示。
因此，将单个前馈模块替换为多个前馈模块（如MoE设置中所做的那样）会大幅增加模型的总参数量。然而，关键技巧在于我们并非对每个token都使用（“激活”）所有专家。相反，路由器仅为每个token选择一小部分专家。
由于每次只有少数专家处于活跃状态，MoE模块通常被称为稀疏模块，这与始终使用全部参数集的密集模块形成对比。然而，通过MoE实现的大量总参数提升了LLM的容量，这意味着它能在训练过程中吸收更多知识。不过，稀疏性保证了推理效率，因为我们不会同时使用所有参数。
（有趣的事实：在大多数MoE模型中，专家权重占总模型参数的90%以上。）
正如我之前的文章所提到的，分组查询注意力（GQA）近年来已成为多头注意力（MHA）的一种更高效的计算和参数替代方案。
在MHA中，每个头都有自己独立的键和值集合。GQA通过将多个头分组共享相同的键和值投影来减少内存使用。
例如，如图9所示，如果有2个键值组和4个注意力头，头1和头2可能共享一组键和值，而头3和头4共享另一组。这种分组减少了键和值计算的总量，从而降低内存使用并提高效率，且根据消融研究，不会显著影响建模性能。
因此，GQA的核心思想是通过在多个查询头之间共享键和值头来减少其数量。这（1）降低了模型的参数量，并且（2）减少了推理过程中键和值张量的内存带宽使用，因为需要从KV缓存中存储和检索的键和值更少了。
（如果你好奇GQA在代码中如何实现，可以查看我的GPT-2到Llama 3转换指南中不含KV缓存的版本，以及此处我的KV缓存变体。）
虽然GQA主要是一种针对MHA的计算效率优化方案，但消融研究（例如原始GQA论文和Llama 2论文中的研究）表明，在LLM建模性能方面，其表现与标准MHA相当。
滑动窗口注意力（下图10）最早在LongFormer论文（2020年）中提出，后来由Mistral推广。有趣的是，gpt-oss在每隔一层应用了这种机制。你可以将其视为多头注意力的一种变体，或者在此场景下是分组查询注意力（GQA），其注意力上下文被限制在一个更小的窗口内，从而减少了内存使用和计算成本。
具体来说，gpt-oss在关注完整上下文的GQA层与滑动窗口限制为128个token的GQA层之间交替使用。
正如我在上一篇文章中讨论的，Gemma 2（2024年）采用了类似的1:1比例。今年早些时候的Gemma 3则更进一步，将比例调整为5:1，这意味着每五个滑动窗口（局部）注意力层中只有一个全注意力层。
根据Gemma的消融研究，滑动窗口注意力对建模性能的影响微乎其微，如下图所示。请注意，Gemma 2中的窗口大小为4096个token，而Gemma 3将其减少到1024个。在gpt-oss中，窗口仅为128个token，这非常小。
有趣的是，官方公告文章指出，滑动窗口注意力显然已经在GPT-3中使用过：
这些模型使用了交替的密集和局部带状稀疏注意力模式，类似于GPT-3
谁知道呢！我回头查阅了原始的GPT-3论文，确实在其中提到了：
我们使用了与GPT-2 [RWC+19]相同的模型和架构，包括其中描述的修改后的初始化、预归一化和可逆分词，唯一的区别是我们在Transformer的层中使用了交替的密集和局部带状稀疏注意力模式，类似于Sparse Transformer [CGRS19]。
最后，来自GPT-2的一个小调整是将LayerNorm（2016年）替换为RMSNorm（2019年），这已成为近年来的常见趋势。
类似于用Swish和SwiGLU替换GELU，RMSNorm是这些较小但明智的效率改进之一。RMSNorm在归一化层激活的目的上与LayerNorm类似，如下图11所示。
你可能还记得，不久前BatchNorm还是这项任务的首选。但它后来失宠了，主要是因为难以高效并行化（由于均值和方差的批次统计），并且在批次较小时表现不佳。
如上图11所示，LayerNorm和RMSNorm都将层输出缩放到一个合理的范围内。
LayerNorm 会减去均值并除以标准差，使得层输出具有零均值和单位方差（方差为 1，标准差为 1）。
RMSNorm 则将输入除以均方根。这会将激活值缩放到可比较的量级，而不强制要求零均值或单位方差。在图 11 所示的这个具体示例中，均值为 0.77，方差为 0.41。
LayerNorm 和 RMSNorm 都能稳定激活值的尺度并改善优化效果，但 RMSNorm 在大规模 LLM 中通常更受青睐，因为它的计算成本更低。与 LayerNorm 不同，RMSNorm 没有偏置（平移）项，并将昂贵的均值和方差计算简化为单一的均方根运算。这将跨特征规约操作从两次减少到一次，从而降低了 GPU 上的通信开销，并提高了训练效率。
图 12 展示了这在代码中的实现方式：
我仍然认为，在学习 LLM 时，GPT-2 是一个极好的入门架构。它足够简单，不会让你迷失在层层优化技巧中，但又足够复杂，能让你扎实地理解现代 Transformer 模型的工作原理。
从 GPT-2 入手，你可以专注于基础知识（注意力机制、位置嵌入、归一化以及整体训练流程），而不会被新架构中那些额外的特性和调整所淹没。
事实上，我认为在尝试叠加更新的改动之前，花时间学习甚至实现 GPT-2 是值得的。你不仅能更轻松地理解那些改动，而且很可能也会更欣赏它们，因为你会更清楚地了解它们试图解决哪些限制或问题。
例如，以我的 GPT-2 代码为基础，我最近从头实现了 Qwen3 架构，它与 gpt-oss 非常相似，这便引出了下一个话题：比较 gpt-oss 与一个更新的架构。
既然我们已经走过了从 GPT-2 到 GPT OSS 的演进历程，接下来我们可以更进一步，将 GPT OSS 与一个更新的架构——Qwen3 进行比较，后者于 2025 年 5 月发布，比 GPT OSS 早三个月。
我在这里选择 Qwen3 的原因是，截至撰写本文时，它是顶级的开放权重模型之一。此外，其中一个 Qwen3 MoE 模型在可训练参数的整体规模上与 GPT OSS 相对接近，因此可以直接进行比较。
下面的图 13 将 gpt-oss-20b 与一个规模相当的 Qwen3 模型进行了对比。
我们可以看到，gpt-oss 20B 和 Qwen3 30B-A3B 在架构组件上非常相似。除了维度之外，主要区别在于 gpt-oss 采用了滑动窗口注意力（如前文第 1.6 节所述，本图中未展示），而 Qwen3 则没有。
接下来，我们将在以下小节中逐一探讨值得关注的细节。
如果仔细观察这两个模型，我们会发现 Qwen3 的架构要深得多，它拥有 48 个 Transformer 块，而不是 24 个（图 14）。
另一方面，gpt-oss 的架构则要宽得多：
- 嵌入维度为 2880，而不是 2048
- 中间专家（前馈）投影维度同样为 2880，而不是 768
同样值得注意的是，gpt-oss 使用的注意力头数量是后者的两倍，但这并不会直接增加模型的宽度。宽度是由嵌入维度决定的。
在参数数量固定的情况下，一种方法是否比另一种更有优势？根据经验法则，更深的模型具有更大的灵活性，但由于梯度爆炸和消失问题（RMSNorm 和快捷连接旨在缓解这些问题），训练起来可能更困难，稳定性也更差。
更宽的架构在推理时具有优势（每秒 token 吞吐量更高），因为其并行化更好，但内存成本也更高。
在建模性能方面，不幸的是，据我所知，没有很好的同类对比（参数大小和数据集保持不变），除了 Gemma 2 论文（表 9）中的一项消融研究，该研究发现，对于 9B 参数的架构，更宽的设置略优于更深的设置。在 4 个基准测试中，更宽的模型平均得分为 52.0，更深的模型平均得分为 50.8。
如上图 14 所示，同样值得注意的是，gpt-oss 的专家数量少得惊人（32 个，而不是 128 个），并且每个 token 仅使用 4 个活跃专家，而不是 8 个。然而，每个专家都比 Qwen3 中的专家大得多。
这很有趣，因为最近的趋势和发展表明，使用更多、更小的模型是有益的。在总参数大小不变的情况下，这种变化在下面 DeepSeekMoE 论文的图 15 中得到了很好的说明。
值得注意的是，与 DeepSeek 的模型不同，gpt-oss 和 Qwen3 都没有使用共享专家。
平心而论，gpt-oss 中专家数量较少可能是 20B 参数规模的副作用。观察下面的 120B 模型，他们确实增加了专家数量（以及 Transformer 模块数量），同时保持其他所有参数不变，如下方图 16 所示。
对于 20B 和 120B 模型如此相似这一事实，一个平淡无奇的解释可能是：120B 模型才是主要关注点。而创建较小模型最简单的方法就是让它更短一些（减少 Transformer 模块数量）并减少专家数量，因为大部分参数都集中在这里。不过，我们也可以推测，他们是否先开始训练 120B 模型，然后裁剪掉部分 Transformer 模块和专家，用于继续预训练（而不是从随机权重开始）。
无论如何，只扩展这两个方面（Transformer 模块数量和专家数量）确实相当不寻常。例如，观察多种规模的 Qwen3 MoE 模型（下方图 17），它们在更多维度上的缩放比例更为均衡。
gpt-oss 和 Qwen3 都使用了分组查询注意力。主要区别在于，如前所述，gpt-oss 通过每隔一层的滑动窗口注意力来限制上下文大小。
不过，有一个有趣的细节引起了我的注意。如下方图所示，gpt-oss 似乎在注意力权重中使用了偏置单元。
自从 GPT-2 时代以来，我就没再见过使用这些偏置单元的情况，它们通常被认为是多余的。事实上，我找到了一篇近期论文，该论文从数学上证明，至少对于键变换（k_proj）来说确实如此。此外，实证结果表明，使用和不使用偏置单元之间几乎没有差异（参见下方图 19）。
你可能注意到的另一个细节是图18代码截图中对sinks的定义。在通用模型中，注意力汇聚点（attention sinks）是放置在序列开头的特殊“始终被关注”的标记，用于稳定注意力机制，这在长上下文场景中尤其有用。也就是说，如果上下文变得非常长，开头这个特殊标记仍然会被关注，并且它可以学习存储关于整个序列的一些通用有用信息。（我认为这最初是在《具有注意力汇聚点的高效流式语言模型》论文中提出的。）
在gpt-oss实现中，注意力汇聚点并不是输入序列中的实际标记。相反，它们是每个注意力头学习到的偏置logits，被附加到注意力分数上（图20）。其目标与上述注意力汇聚点相同，但无需修改分词后的输入。
最后，与Qwen3类似，gpt-oss模型采用Apache 2.0开源许可证，这非常棒（这也是我个人开源项目偏好的许可证）。这意味着这些模型可以无限制地被蒸馏到其他模型，或用于商业产品。
开放权重 vs. 开源大语言模型。 这一区别多年来一直存在争议，但有必要澄清，以避免对本发布及其相关成果产生混淆。一些模型开发者仅发布模型权重和推理代码（例如Llama、Gemma、gpt-oss），而另一些（例如OLMo）则发布包括训练代码、数据集和权重在内的所有内容，作为真正的开源。
按照这个更严格的定义，gpt-oss是一个开放权重模型（就像Qwen3一样），因为它包含权重和推理代码，但不包含训练代码或数据集。然而，行业内对这一术语的使用并不一致。
我猜测“gpt-oss”中的“oss”代表开源软件；不过，令我惊喜的是，OpenAI本身在其官方公告文章中明确将gpt-oss描述为一个开放权重模型。
虽然前几节描述了自GPT-2以来架构的演变，并讨论了其与Qwen3（以及大多数其他近期模型）的相似之处，但仍有一些额外但值得注意的细节我尚未提及。这些点不太适合归入前面的章节，但仍然值得一提。
遗憾的是，关于训练集大小和算法的可用信息不多。我将来自模型卡报告（1）和公告文章（2）中最有趣的零散信息补充如下：
gpt-oss 模型是使用我们最先进的预训练和后训练技术训练的 […] (1)
[…] 需要 210 万 H100 小时完成，而 gpt-oss-20b 所需的计算量几乎少了 10 倍。(1)
[…] 包括一个监督微调阶段和一个高计算量的 RL 阶段 […] (2)
我们在一个以英语为主的纯文本数据集上训练了这些模型，重点关注 STEM、编程和通用知识。(2)
因此，我们知道 gpt-oss 模型是推理模型。210 万 H100 GPU 小时的训练计算量大致与约 5.6 倍大的 DeepSeek V3 模型训练的 278.8 万 H800 GPU 小时相当。不幸的是，目前还没有关于 Qwen3 训练时间的信息。
有趣的是，GPT-oss 的训练时间估算包括了用于指令遵循的监督学习和用于推理的强化学习，而 DeepSeek V3 只是一个预训练的基础模型，DeepSeek R1 是在其基础上单独训练的。
如前所述，gpt-oss 模型是推理模型。然而，特别有趣的是，它们的训练方式使得用户可以通过推理时间缩放轻松控制推理程度。
具体来说，gpt-oss 模型可以在系统提示中接收“推理努力：低/中/高”指令，这直接影响响应长度和准确性，如图 21 所示。
这种可调节性很有用，因为它让我们能够平衡成本、计算量和准确性。例如，如果任务很简单，比如回答一个直接的知识问题或修正一个小错字，我们可以跳过扩展推理。这节省了时间和资源，同时避免了不必要的长响应和冗长的推理痕迹。
有点遗憾的是，OpenAI 没有像 Qwen3 或 OLMo 那样，在基于强化学习的推理训练之前发布基础模型。基础模型对于研究推理方法的研究人员来说是特别有价值的起点（这也是我目前喜欢使用 Qwen3 Base 的原因之一）。我的猜测是，OpenAI 的决定更多是出于行业和生产用例的考虑，而非研究考量。
请注意，原始的 Qwen3 模型也有一个用于启用/禁用思考（推理）模式的开关（通过分词器中的 enable_thinking=True/False 设置，只需添加
原因是混合模式相比单独的模型性能较低：
在与社区讨论并反思此事后，我们决定放弃混合思考模式。我们现在将分别训练 Instruct 和 Thinking 模型，以达到最佳质量。来源
一个有趣的惊喜是，OpenAI 发布了采用 MXFP4 量化方案的 gpt-oss 模型，专门针对 MoE 专家层进行了优化。
量化格式过去通常是一个小众话题，主要与移动端或嵌入式 AI 相关，但随着模型规模的不断增大，这一情况已经改变。在这种情况下，MXFP4 优化使得模型能够在单 GPU 设备上运行。
以下是实际效果：
-
大模型（比如 120B 参数）可以适配到单块 80GB 的 H100 或更新的 GPU 上。虽然不是消费级硬件，但租用一台单 H100 的机器比租用多 H100 的机器要便宜得多。此外，我们无需担心跨 GPU 分布模型以及增加通信开销的问题。而且，AMD MI300X 显卡从第一天起就获得支持，这真的很棒！
-
较小的 20B 模型甚至可以装入 16 GB 的显存；但前提是需要 RTX 50 系列或更新的 GPU 来支持 MXFP4。（编辑：最近通过一个补丁 增加了对旧款显卡（如 RTX 4090）的支持。）
请注意，这些模型也可以在旧硬件上运行，但如果没有 MXFP4 支持，它们会消耗更多内存。在没有 MXFP4 优化的情况下，使用 bfloat16 格式的模型大约会消耗 48 GB（gpt-oss-20b）和 240 GB（gpt-oss-120b）的内存。
顺便提一下，我可以在我的 Mac Mini 上使用 ollama 流畅地运行 gpt-oss-20b 模型。它大约占用 13.5 GB 的内存，这非常合理。
这些模型还太新，尚未有独立的基准测试。查看 LM Arena 排行榜，我发现 gpt-oss 目前还没有被收录。因此，根据 LM Arena 用户的反馈，Qwen3-Instruct 目前仍然是排名最高的开放权重模型（图 22）。
从 gpt-oss 发布公告中提供的推理基准测试来看，我们可以看到 gpt-oss 模型与 OpenAI 的专有模型以及 Qwen3 不相上下（图 23）。
然而，需要注意的是，gpt-oss-120b 的规模几乎是 Qwen3 A235B-A22B-Thinking-2507 模型的一半，并且可以在单 GPU 上运行。
不过，基准测试性能并不总能反映实际可用性。根据我过去几天的有限使用体验，我发现 gpt-oss 相当有能力。话虽如此，正如其他人所观察到的，它似乎有相对较高的幻觉倾向（这一点在其模型卡中也有提及）。
这可能源于其训练重点高度集中在推理任务上，例如数学、谜题和代码，这可能导致了一些“通用知识遗忘”。尽管如此，由于 gpt-oss 的设计初衷是用于工具调用，随着时间的推移，这一限制可能会变得不那么重要。开源大语言模型中的工具集成仍处于早期阶段，但随着其成熟，我预计我们会越来越多地让模型在回答事实性或知识性查询时咨询外部来源（如搜索引擎）。
如果这种情况发生，那么优先考虑推理能力而非记忆能力可能是合理的。这很像人类在学校（或一般生活中）的学习方式，解决问题的能力往往比记忆事实更重要。
OpenAI度过了忙碌的一周，在发布gpt-oss后不久，便推出了备受期待的GPT-5模型。GPT-5的发布很有意思。如果非要我说点什么，那就是我真的很惊讶，他们的开源模型在基准测试性能方面竟然能与他们最好的产品相媲美（图24）。
总而言之，尽管有些人认为这次发布被过度炒作，但我很高兴我们拥有了一套新的、强大的开源权重模型，它们与最好的专有模型差距并不大。当然，基准测试往往不能准确反映实际使用情况，基于有限的使用经验下结论还为时过早。但我认为，对于喜欢使用开源权重和本地（或私有托管）模型的人来说，这是个好时代。
本杂志是个人热情之作，您的支持有助于它持续发展。如果您愿意贡献一份力量，这里有几个很好的方式：
-
购买我的书。《从零开始构建大型语言模型》将引导您一步步构建LLM，从分词器到训练。
-
查看视频课程。现在有一门基于该书的17小时视频课程，由Manning提供。它紧密跟随原书，逐节讲解，既可以作为独立课程，也可以作为代码实操的配套资源。该视频课程无广告（与YouTube版本不同），格式更清晰、更有条理。它还包含由Abhinav Kimothi创建的额外5小时预备视频材料。
-
订阅。付费订阅有助于我的写作可持续发展，并让您能访问更多内容。
感谢阅读，感谢您支持独立研究！
