在 LM Studio 中本地运行 OpenAI 的 gpt-oss
我们很高兴能与 OpenAI 合作，在发布当天为您带来 LM Studio 中对 gpt-oss 的支持🎉
编辑于 2025 年 8 月 8 日：查阅 OpenAI 关于在 LM Studio 中运行 gpt-oss 的食谱。
作为这项工作的一部分，我们为 MLX 贡献了以下实现 (PR)。预计今天将更新并改进。
请参阅下文，了解对实现某些方面的微型技术深入探讨。
请更新到 LM Studio 0.3.21 以在本地运行模型。
模型详情
该模型有两种尺寸：20B 和 120B。
较小的模型大约需要 ~13GB 的 RAM。
- gpt-oss-20b — 用于低延迟、本地或专用用例（210 亿参数，36 亿活动参数）
- gpt-oss-120b — 用于生产、通用、高推理用例，可放入单个 H100 GPU（1170 亿参数，51 亿活动参数）
微型技术深入探讨
滑动窗口注意力
您可能以前见过注意力方程，它通常被认为是使 Transformer 如此强大的“秘密武器”
注意力(Q, K, V) = softmax(QK^T/sqrt(d))V
我们称之为*全注意力*，因为模型可以关注整个输入：由于 Q、K 和 V 是整个输入的函数，模型可以访问序列中的所有标记。这使得注意力极其强大，但它有一个不幸的副作用，即随着您的聊天变长，Q、K 和 V 也会变大。这意味着一旦您的聊天达到数千个标记，计算注意力就需要更多的计算量，这表现为内存使用量增加和响应速度变慢。事实上，这种增加是二次方的，这意味着您的聊天长度加倍会使模型响应时间增加大约四倍！
这对于设备上的 AI 来说并不理想，因为没有人愿意等待半小时才能得到响应。*滑动窗口注意力*通过仅使用最后 W 个标记的*滑动窗口*的输入嵌入（其中 W 取决于模型）来解决此问题，这意味着 Q、K 和 V 被限制在固定大小，因此内存使用量和计算要求也固定。这样，无论聊天有多长，模型都不会花费荒谬的时间响应或耗尽您计算机的所有内存。
听起来不错，对吧？一个问题：如果整个模型都使用滑动窗口注意力，它就不会看到其小滑动窗口之外的任何内容，因此它会忘记您早期的聊天！一个有记忆力损失的模型没有乐趣，因此 OpenAI 在这个模型中使用了全注意力与滑动窗口注意力 50/50 的比例，以两全其美：了解整个输入，但也比其他模型更高效地处理。
注意力汇集
让我们看看注意力操作的这一部分
softmax(QK^T/sqrt(d))
矩阵 QK^T 包含*注意力分数*：量化每个标记希望关注其他每个标记的程度。模型可能会在像主语或动词这样的承重词上给出高分，而在像“the”这样的助词上给出低分。为了确定流向模型下一部分的信息，模型希望使用这些注意力分数提取 V 中存储的值的某种组合。为了在确保数字不会失控的情况下做到这一点，模型应用 softmax 操作，这使得标记的所有出站分数总和为 1。
但是如果模型不想特别关注任何标记呢？softmax 仍然强制分数总和为 1，这迫使模型对不重要的标记给予过多的关注！这些过多的注意力分数通常汇集在序列中最早的标记中，称为*注意力汇集*。这给滑动窗口注意力带来了问题：当这些标记离开滑动窗口时，所有过多的注意力都会分配给其他标记，导致模型根本不会额外关注任何内容！已经发现这种现象会导致 LLM 响应质量在长时间对话或长输入提示中显着下降。
Xiao 等人通过使用注意力汇集的自定义标记解决了这个问题，这些标记附加到注意力分数，但在从 V 中提取信息时未使用。这使得过多的注意力可以汇集在汇集标记中，而不会影响注意力输出，从而防止质量下降。OpenAI 在其 GPT OSS 模型中采用了这种方法，这使得模型能够准确响应数百万个标记长的查询或持续数小时的对话！
请继续关注更新
我们当前的实现是初步的，我们将在未来几天内提供改进的引擎更新。
社区
加入我们的 Discord 服务器！ https://discord.gg/lmstudio