7 月 29 日凌晨，OpenAI 把两枚模型权重扔到了 Hugging Face 上：gpt-oss-120b 和 gpt-oss-20b。Apache 2.0 协议，可商用、可改、可再分发。这是 OpenAI 时隔四年再一次把自家模型权重放出来。
很多人第一反应是：「闭源之王怎么突然开源了？」其实回头看过去半年的牌面，DeepSeek V3/V4、Kimi K3、Llama 4 系列的下载量已经把闭源 API 围得水泄不通。OpenAI 这步不像是良心发现，更像是被市场逼到墙角之后的反击——既然挡不住开源大军，那就自己也下场分一杯羹。
昨天下午我刚写过 Kimi K3 权重开源那篇，讲的是国产 2.8T MoE 怎么下载怎么跑。今天这篇主角是 OpenAI 系，定位和路径不太一样——gpt-oss 不是单一旗舰，而是一大一小两条线，分别瞄准企业推理和本地尝鲜。
这次开源的到底是什么
先把两个模型放桌上对比一下，免得后面选错。
| 维度 | gpt-oss-120b | gpt-oss-20b |
|---|---|---|
| 总参数 | 117B | 21B |
| 单次激活 | 5.1B | 3.6B |
| 架构 | MoE（128 专家，每次激活 4 个） | MoE（32 专家，每次激活 4 个） |
| 上下文 | 128k | 128k |
| 训练后量化 | MXFP4 | MXFP4 |
| 硬件门槛 | 80GB 显存单卡（H100 / MI300X） | 16GB 内存（消费级显卡或 Mac） |
| 定位 | 生产级复杂推理 | 低延迟、本地实验、端侧 |
两个模型都是 MoE 架构，这意味着虽然总参数量看起来吓人，但实际跑起来只激活一小部分专家——5.1B 激活参数的单卡推理，和一个稠密 5B 模型差不多。这点和 Kimi K3 的 1040 亿激活参数是同一个思路。
两个模型都原生用 MXFP4 量化，意思是 OpenAI 在训练完之后就把权重压成了 MXFP4 格式，不是用户自己再压缩。所以你拿到的就是官方推荐的部署形态，所有 benchmark 都是基于这个量化版本测出来的。
性能到底什么水平
OpenAI 自己在文档里给的对照表是这样的：
- gpt-oss-120b：在竞赛编程（Codeforces）、通用问题（MMLU、HLE）、工具调用（TauBench）这几项上，整体接近 o4-mini，部分项目能打平甚至超过。
- gpt-oss-20b：在同类基准上和 o3-mini 相当，但数学和健康类任务上反而比 o3-mini 强。
最值得看的几个数字：
- AIME 2024 数学竞赛：gpt-oss-120b 96.6%，gpt-oss-20b 96.0%（o3-mini 95.2%）。
- AIME 2025：gpt-oss-120b 97.9%，gpt-oss-20b 98.7%（o3-mini 98.4%）。
- HealthBench：两个版本都超过了 o1 和 GPT-4o。
注意一个细节——这两个模型不通过 OpenAI API 提供，也不在 ChatGPT 里出现。也就是说，OpenAI 这次是把”模型层”和”产品层”做了一次切割：模型是开源的，但 GPT-5.6、ChatGPT Work 这些产品线仍然是付费闭源。如果你想直接用 gpt-oss 跑产品，得自己接，或者用第三方托管。
三种上手路径，按你的硬件选
路径一：什么都不装，浏览器里直接玩
OpenAI 自己搭了一个 Playground，地址在 openai.com/open-models，进去就能在网页上问问题。两个模型都接了简单的 chain-of-thought 可视化，能看到模型在思考过程中走过的路径。
这条路适合：先确认这个模型适不适合你的业务再下载。
路径二：本地跑 gpt-oss-20b（16GB 内存就够）
这是大多数个人开发者会走的一条路。Ollama 和 LM Studio 都已经 Day0 适配，开箱即用。
Ollama 路线：
# 拉模型
ollama pull gpt-oss:20b
# 启动对话
ollama run gpt-oss:20bLM Studio 路线：在 UI 里搜 openai/gpt-oss-20b，下载模型权重，左侧选 Harmony 聊天模板，右侧问就行。
要注意的是，这两个模型必须用 OpenAI 自研的 harmony 格式才能正常输出。如果你在 LM Studio 里没选对应模板，模型会输出乱码或者干脆拒绝响应。Hugging Face 上的 openai-harmony 包提供了 Python 和 Rust 两种实现，可以直接嵌入自己的推理链路。
20B 版本能在 16GB 内存上跑，意味着 Mac M2/M3/M4 用户和大多数配了 16GB 显存的 Windows 笔记本都能用。速度上，Mac 上大概 30-50 token/s，够日常对话和代码补全。
对 Ollama 还不熟的朋友，可以回看 本地部署大模型完全指南，里面把 Ollama 和 LM Studio 的安装、模型管理、API 暴露都讲过一遍。
路径三：企业级部署 gpt-oss-120b（80GB 显存单卡）
这条是给有 H100 或 MI300X 的团队准备的。推荐用 vLLM，OpenAI 给了一键启动命令：
uv pip install --pre vllm==0.10.1+gptoss \
--extra-index-url https://wheels.vllm.ai/gpt-oss/ \
--extra-index-url https://download.pytorch.org/whl/nightly/cu128 \
--index-strategy unsafe-best-match
vllm serve openai/gpt-oss-120b启动后，vLLM 会暴露一个 OpenAI 兼容的 API（/v1/chat/completions）。也就是说，你原来写给 GPT 的客户端代码、Agent 框架、LangChain 工具链，几乎不改一行就能直接对接 gpt-oss-120b。这是这次开源最值得琢磨的地方——OpenAI 把模型层拆开卖的同时，没让集成成本变高。
硬件层面，OpenAI 已经和 NVIDIA、AMD、Cerebras、Groq 都做了适配。Microsoft 通过 ONNX Runtime 在 Windows 端提供了 Foundry Local 和 AI Toolkit for VS Code 集成，Windows 开发者可以在 VS Code 里直接调用 20B 版本的本地推理。
怎么调教这个模型的”思考深度”
这是 gpt-oss 最有意思的设计之一。它和 o 系列一样支持三档推理力度：low / medium / high，只需要在系统提示词里写一句就行：
Reasoning: high不同档位对应不同的延迟和能力：
- low：默认，响应快，适合闲聊、简单问答、代码补全。
- medium：思考得稍微深一点，适合中等复杂度的逻辑题。
- high：拉满推理时长，适合数学证明、多步规划、复杂代码生成。
值得注意的是，gpt-oss 的 chain-of-thought 是完整暴露给开发者的，你可以通过 Responses API 或者 Harmony 格式拿到模型的完整思考过程。OpenAI 明确说不要把 CoT 直接展示给终端用户（里面可能包含模型被训练去隐藏的内容），但开发者可以用它来调试模型行为、做安全监控。
这个模型能干什么、不能干什么
把文档翻完一遍，gpt-oss 适合的场景大致是：
- 本地代码助手：配合 VS Code 扩展或 Claude Code fork，做离线代码补全和重构。
- 企业内部问答：把公司文档塞进 RAG，再用 gpt-oss 跑推理，数据不出公司。
- Agent 工作流的本地节点：配合 vLLM 暴露的 OpenAI 兼容 API，可以塞进 LangChain、AutoGen、OpenClaw 这些 Agent 框架。
- 微调出行业专属模型：Apache 2.0 协议允许商用，你可以基于 gpt-oss 微调后卖。
- 消费级硬件的端侧推理：gpt-oss-20b 在 16GB 内存的设备上就能跑，适合做手机、嵌入式设备的本地大脑。
不适合的场景：
- 多模态：这两个模型是纯文本的，图片、音频、视频都不支持。
- 联网搜索：模型本身不带搜索能力，但有 function calling 框架，你可以自己接。
- 极致中文能力：训练语料以英文为主，STEM 和通用知识上中文表现不错，但如果是中文创意写作、文学类任务，建议优先看国产模型。
和昨天那篇 Kimi K3 怎么选
可能有人会问：gpt-oss 和 Kimi K3 都是开源 MoE，怎么选？
我的判断是分场景看：
- 如果你的硬件是消费级显卡或 Mac：直接选 gpt-oss-20b。16GB 内存门槛、单卡能跑，Ollama/LM Studio 现成支持。
- 如果你有 8 卡 A100/H100 集群：两个都能跑。K3 是 2.8T 总参数、104B 激活，能力天花板更高；gpt-oss-120b 是 117B 总参数、5.1B 激活，更省算力。
- 如果你想用中文：优先 K3 或 DeepSeek V4。gpt-oss 的英文 benchmark 很强，但中文创作和本土知识上还是国产模型更稳。
- 如果要做企业 API 集成：gpt-oss 走 vLLM 暴露 OpenAI 兼容 API，几乎零迁移成本；K3 在国内走千问 AI 平台和阿里云百炼，海外走 Nebius/Fireworks 等。
- 如果需要多模态：两个都帮不上忙，得看 Qwen-Image-3.0 这种专门做图像的。
类似的横向对比逻辑也适用于 GPT-5.6 三档模型 和 Claude Opus 5——闭源旗舰在多模态、长上下文、企业级支持上仍然领先，但开源模型的边际成本已经低到值得每个团队都搭一个本地推理节点。
几个容易踩的坑
最后写几个实测中容易遇到的问题，省得大家走弯路：
- 一定要用 Harmony 格式：用 Transformers 直接调
model.generate之前，必须先用openai-harmony包把对话渲染成 harmony 格式，否则模型会输出乱码。直接用 chat template 可以自动处理。 - MXFP4 量化不要自己改：模型已经原生 MXFP4 量化，不要再用 bitsandbytes 二次量化到 4bit，那样 benchmark 会掉。
- CoT 不要给用户看：OpenAI 官方建议不要把 chain-of-thought 直接展示给终端用户，可能包含模型本来该隐藏的思考过程。
- 20B 不是不能做大任务：很多人觉得 20B 干不了正事，其实配 vLLM + 8 比特 KV 缓存，20B 也能跑 128k 上下文的复杂推理，只是慢一些。
- vLLM 版本要选对：必须是
vllm==0.10.1+gptoss这个特殊版本，普通 vLLM 0.10 装上会报错。
写在最后
gpt-oss 这次开源对国内开发者最大的意义，不在于模型本身有多强（实际上 o3/o4-mini 在很多任务上仍然领先），而在于它把 OpenAI 兼容 API 的生态彻底开放了。你之前写的所有调用 OpenAI 的代码、框架、Agent 工作流，几乎可以零成本切换到 gpt-oss 上跑。
下一步可能发生的事情：基于 gpt-oss 微调的垂直模型会大量出现；vLLM 生态对 harmony 格式的原生支持会越来越完善；端侧设备（手机、笔记本、嵌入式）会开始用 20B 版本做本地推理。
如果你是个人开发者，今天就能在 Mac 上用 LM Studio 跑起来试试；如果是企业用户，先用 vLLM 部署一个 120B 的测试节点，验证一下效果，再考虑是不是要全量替换某个 API 调用。
想看更详细的开源模型部署对比，可以再翻翻 AI 编程工程化那篇，里面讲的 Skill、MCP、Agent 编排思路，搭配 gpt-oss 的 function calling 能力，能拼出很多本地化的工作流。
发表回复