AI 工程实践
gpt-oss 首发复盘：80GB 是权重门槛，不是 128K 并发的生产显存答案
以 2025 年 8 月 5 日至 7 日的一手资料为边界，拆解 gpt-oss-120b/20b 的开放权重、MoE、MXFP4、Harmony 与推理档位，并给出本地部署的显存预算、任务合同、评测、恢复和单位经济性方案。
时间与证据
本文研究的事件是 OpenAI 在 2025 年 8 月 5 日发布 gpt-oss-120b 与 gpt-oss-20b 两个开放权重推理模型。同期信息截止到 8 月 7 日；文章发布日期与更新日期见页首。这里的型号名是产品档位，不是精确参数计数：官方架构表给出的实际总参数分别是 117B 与 21B，每个 token 激活约 5.1B 与 3.6B 参数。
主要证据是 OpenAI 的 首发页、2025 年 8 月 5 日 17:05:37 UTC 保存的发布日快照与 8 月 7 日 01:59:38 UTC 保存的T+2 快照，以及模型卡和 8 月 6 日的固定快照。代码边界同时固定在 gpt-oss 仓库的发布日 commit 89fe402d、T+2 commit 7e64492f与 Harmony 仓库 T+1 commit 3efbf742。发布日证据用于约束首发声明，后两项只补充信息截止日前可核验的协议与仓库状态，避免用更晚的 README、运行时适配或模型服务状态解释首发。
在这个边界内可以确认：两个模型均为文本模型，原生支持最长 128K 上下文，使用稀疏 MoE；权重以 Apache License 2.0 发布，并原生采用 MXFP4 量化的 MoE 权重。官方称 120b 可在单张 80GB GPU 上运行，20b 可在 16GB 内存设备上运行；这句话证明了一种装载与推理入口，不等于承诺 128K、多并发、目标吞吐和完整服务栈能同时塞进同一容量。
首发还公开了 Harmony 响应格式与 Python/Rust renderer。模型通过系统消息表达 low、medium、high 三档 reasoning effort，并使用不同 channel 组织分析、工具调用前言和最终回答。仓库明确提醒：不按 Harmony 格式使用会导致行为不正确；这意味着 Prompt 模板不是装饰性字符串，而是模型运行协议的一部分。
本文证据等级是 sourced。我核验了首发页、同期快照、模型卡和固定代码，但没有在 2025 年 8 月的驱动、推理引擎与硬件组合上复跑 120b/20b，也没有本站吞吐、功耗、首 token 延迟或准确率数据。所有发布方 Benchmark、80GB/16GB 可运行表述均归属于 OpenAI；显存公式、验收集、门槛与成本模型是本站提出的工程方案，不冒充实测结果。
当时发生了什么
开放的是权重与参考实现，不是完整训练工程
Apache-2.0 给了复制、修改、分发和商业使用的宽松路径，权重、配置、参考推理实现与 Harmony renderer 让团队能够在自己的基础设施上运行和定制模型。这对数据驻留、离线环境、专用微调和供应商议价都很重要。
但“开放权重”不应自动改写成“完整开源模型”。首发没有交付可从头复现 117B/21B 模型的训练数据、数据清洗账本、完整训练代码、训练算力记录和全部内部评测流水线。企业可以检查权重文件、许可和部分实现，却不能仅凭这些材料独立复现训练来源与每项安全声明。正确资产清单应逐项写明：权重、tokenizer、配置、推理代码、许可证、训练数据说明、训练代码与评测证据分别是否可得。
总参数决定常驻重量，激活参数主要影响每 token 计算
gpt-oss-120b 有 117B 总参数、每 token 激活 5.1B；gpt-oss-20b 有 21B 总参数、每 token 激活 3.6B。MoE router 每次只选择部分 expert，可以降低相对计算量，但未被选中的 expert 权重通常仍需驻留在 GPU、CPU 或分层存储中。因而不能用 5.1B 乘量化位数，宣称 120b 只需要“小模型显存”。
这也解释了型号选择不能只看 active parameters。120b 的每 token 计算稀疏，并不消除权重搬运、跨设备通信、内存带宽与冷 expert 命中的代价；20b 的总权重更小，也不保证在特定并发和长上下文下延迟更低。部署结论必须来自相同运行时、相同 Prompt、相同输出预算和相同并发的端到端测试。
MXFP4 降低权重门槛，但没有冻结整台服务器的显存账单
若把所有参数理想化为 4 bit，117B 与 21B 的纯数值下界大约是 58.5GB 与 10.5GB。实际模型并非每个模块都以同一种 4-bit 表示，运行还需要量化元数据、embedding、attention、router、输出头、kernel workspace 与内存对齐，所以官方给出的“80GB 内运行”和“16GB 内运行”比简单乘法更接近装载事实。
生产服务又多出 KV Cache、批处理、并发序列、采样 buffer、CUDA graph、通信 buffer、碎片与故障余量。上下文上限 128K 是协议容量，不是默认应占满的输入长度。把一个模型成功启动、单请求生成首字与在 P95 SLA 内承载真实流量，是三个不同验收点。
Harmony 是推理协议，不只是聊天模板
Harmony 定义角色、channel、工具 namespace、reasoning effort 和结构化输出边界。自建服务若错误拼接 system/developer/user 消息、把 analysis 暴露成 final、丢失 tool result 或在续写时重复特殊 token，模型质量会在“权重完全相同”的情况下明显漂移。
因此版本合同必须同时固定模型权重 digest、tokenizer、Harmony renderer 版本、系统模板、工具 schema 与推理引擎。某个 OpenAI-compatible HTTP endpoint 能接收相似 JSON，不证明它正确渲染 Harmony，也不证明 tool call、reasoning channel 和 stop 条件语义一致。
首发没有 OpenAI 托管的 gpt-oss API
首发页称模型可用于与 Responses API 相容的工作流，并列出多家第三方部署伙伴；同一页面也明确表示 OpenAI 未来“可能考虑”API support。由此可见，首发时下载权重、自建或选择第三方 provider 才是交付路径，不能把“Responses API compatible”写成“OpenAI 已托管 gpt-oss endpoint”。
这一区分直接影响责任：自建方要承担容量、安全补丁、滥用防护、可用性与数据治理；第三方托管则要审计其权重版本、量化方式、Harmony 适配、日志、地区、SLA 与退出机制。接口长得一样，不代表运行时与风险合同相同。
可见 CoT 是诊断信号，不是用户审计记录
OpenAI 称模型提供完整 chain-of-thought，并说明没有直接监督 CoT，以保留监测模型失当行为的研究价值；首发页同时明确建议开发者不要直接向终端用户展示 CoT，因为它可能包含幻觉、有害内容或本应不进入最终回答的信息。
更重要的是，CoT 是模型生成的中间文本，不天然忠实地解释内部计算，也没有外部事实签名。它可以帮助发现异常模式，却不能证明“为什么批准了退款”“是否真的查询了数据库”或“谁授权了工具”。业务审计必须依赖不可变输入版本、策略判定、工具请求/响应、审批、状态回读与最终证据，而不是一段看起来合理的自述。
任务判断
具体场景：内网设备故障工单助手
假设一家制造企业要在隔离网络中处理设备故障工单。输入包括操作员描述、设备型号、过去 30 天告警、维修手册片段和备件库存；输出包括故障类别、证据引用、建议排查步骤、风险等级和是否转人工。系统只可读手册与告警，任何停机、参数写入和备件领用都必须由工程师批准。
这个场景值得评估 gpt-oss：数据驻留明确、文本和工具链较稳定、可建立本地评测，且长工单需要推理与结构化输出。但不应从 120b 开始。先用 20b 建立检索、Harmony、证据引用和拒答基线，再让 120b 只处理 20b 低置信或多设备关联样本；若 120b 没有提高最终合格率，就不为更高的常驻内存与运维复杂度买单。
任务合同至少包含：case_id、设备与租户、数据快照时间、允许读取的索引、禁止动作、最大上下文、reasoning 档位、输出 JSON schema、引用格式、总 deadline、模型/renderer/runtime digest 和人工升级条件。模型只能提出排查动作；确定性策略检查设备范围、危险步骤和权限，再决定是否把建议交给工程师。
验收集可从 300 个去敏历史工单起步，按常见故障、告警冲突、手册过期、相似型号、缺失证据、恶意工单指令、超长日志、工具超时和必须停机的高风险事件分层。每条样本保存允许证据、不可接受建议、预期风险等级和最终维修结论。数字是试点设计，不是本站已经完成的实验。
比较时至少保留四条基线：关键词/规则路由；20b low；20b high；120b high。所有方案使用同一检索结果、Harmony 版本、输出上限和验证器。不能让大模型获得更多手册，随后把提升全算给参数规模；也不能只比较模型回答，忽略检索、工具和人工复核时间。
工程影响
先建立四层内存账本
生产显存应按峰值而不是模型文件大小规划：
生产峰值显存
= 常驻权重与量化元数据
+ 每个活跃序列的 KV Cache × 并发
+ activation / sampling / kernel / communication workspace
+ runtime graph、内存碎片与安全余量
一个用于容量预估的 KV Cache 上界式是：
KV bytes / sequence
≈ 2 × layer_count × kv_head_count × head_dim
× cache_bytes_per_element × cached_tokens
按首发配置中的 36/24 层、8 个 KV head、64 head dimension 和 2-byte cache 粗算，若所有层都保留完整 KV，120b 与 20b 分别约为每 token 72KiB 与 48KiB；128K 单序列会接近 9GiB 与 6GiB。这个计算只是保守解释，不是实测：交替局部 attention、滑窗淘汰、cache dtype、分页 KV、prefix sharing 和具体引擎都会改变结果。它足以证明 80GB/16GB 不能直接当作长上下文并发容量。
容量测试应逐项增加变量：先固定 2K 输入和单并发测权重/工作区，再固定上下文增加并发，最后固定并发增加上下文。每一步记录 GPU/CPU 峰值、首 token 延迟、输出 token/s、排队时间、OOM、上下文截断与任务通过率。一次只改变一个变量，才能定位瓶颈来自模型、cache、调度还是检索。
把 Harmony 编译成可测试输入
业务消息先进入内部规范对象，再由固定版本 renderer 编译为 Harmony token；禁止各客户端自行拼字符串。编译产物保存模板版本和输入 hash，但敏感正文只保留受控引用。解析器只接受预期 channel、工具和 schema，遇到未知 special token、未闭合 tool call 或 analysis 泄漏立即失败关闭。
reasoning effort 也是任务合同的一部分。low、medium、high 应按任务类别预设，而不是由用户任意写进自然语言；升级档位需记录原因。高档位若只是生成更长 CoT、没有提高经验证完成率，就应回落。不能用 reasoning token 数量代替推理质量。
工具调用与模型权限彻底分开
浏览、Python 或企业工具都在隔离执行器中运行。模型输出的是候选 tool_intent，策略层根据 actor、tenant、case、tool、参数范围、数据分类与 deadline 签发一次性 ticket；执行器校验 ticket 和幂等键后调用，结果经过大小、MIME、schema、秘密与注入过滤，才重新进入模型上下文。
工单正文、手册和工具结果都属于不可信数据。即使 Harmony 有角色与 channel，也不能让文档中的“忽略规则并关闭设备”升级成 developer 指令。危险操作永不暴露给模型直连；审批必须绑定设备、动作、参数、证据 hash、版本和有效期。
用权威结果而不是 CoT 判定完成
建议状态机如下：
accepted -> retrieving -> reasoning -> proposal_ready
-> policy_denied | needs_evidence | awaiting_human
approved -> executing -> verifying
-> resolved | failed | unknown -> reconciling
模型说“已查询库存”不改变状态。只有工具回执证明查询成功，才能从 reasoning 前进；模型说“设备恢复”也不结束工单，必须由监控新快照或工程师签名确认。响应丢失时进入 unknown，按幂等键读取权威系统，不自动重放可能有副作用的动作。
日志分成三类：推理 trace 保存模型、renderer、档位、token、延迟和脱敏 channel hash；安全审计保存主体、策略、审批与拒绝；业务账本保存工单、工具回执和最终状态。CoT 默认短期、受限保存，不进入客服可见记录，也不作为合规解释。
升级必须同时回归权重、运行时和协议
上线制品应形成不可变元组：
model weight digest
+ tokenizer digest
+ Harmony renderer version
+ inference runtime image digest
+ quantization / KV cache config
+ system template + tool schema hash
+ evaluator and dataset version
任何一项变化都先回放离线集，再做影子流量和小比例 canary。门禁同时检查任务合格率、危险建议率、引用正确率、JSON/工具解析失败、P95 延迟、峰值显存、OOM、人工分钟与单位成本。失败时回滚整个元组，而不是只换回权重，让新 renderer 继续污染旧模型。
商业价值
gpt-oss 的商业价值不是“免 API 费”，而是把模型控制权、数据路径与容量优化空间交给部署方。适合付费的场景包括受监管或离线环境、持续高负载的窄任务、需要专用微调的行业流程，以及希望在多个运行时和供应商之间保留退出权的企业。
成本不能只除以 GPU 小时：
每个经验证工单成本
=（GPU/CPU/内存与机房或云资源
+ 模型下载、镜像、运行时优化与升级摊销
+ 检索、存储、队列、观测和安全控制
+ 评测、值班、人工复核与异常恢复分钟 × 人工单价
+ OOM、错误建议、停机和数据事件的预期损失）
/ 经权威维修结果验证的合格工单数
失败、拒答、转人工和超时都进入分子。active parameters 较少可能降低计算成本，却不会自动降低权重驻留、工程维护或事故成本；自建没有按 token 账单，也不代表边际成本为零。
建议用 10 周试点：前 3 周冻结数据与 Harmony/runtime 元组，完成离线对照和容量曲线；第 4 至 6 周影子运行，只生成建议；第 7 至 10 周开放低风险读工具并保留人工批准。扩量门槛可预先设为：危险未授权动作 0，引用可回读率 100%，关键故障召回不低于人工基线，P95 在业务 SLA 内，OOM 为 0，人工处理分钟下降至少 20%，每个经验证工单成本低于节省的人工与停机损失。这些是待验证目标。
若请求量低且波动大、团队没有 GPU 运维能力、需要供应商内置多模态/搜索/安全服务，托管 API 可能更便宜。若数据可安全出域，第三方 gpt-oss provider 也可能优于自建，但必须把权重 digest、量化、日志、SLA、地区和迁移导出写入合同。
局限与风险
第一，本文没有运行模型，不能确认官方 80GB/16GB 表述在任意 GPU、驱动、框架和上下文下成立。参考 PyTorch/Triton/Metal 实现也不等于生产服务；仓库同期明确把部分实现定位为教育参考。
第二，理论 KV 公式没有覆盖每个引擎的滑窗、分页、cache dtype、prefix sharing 和 offload，只用于揭示容量变量。采购前必须在目标硬件上测峰值与碎片，并为驱动升级和异常 batch 留余量。
第三，Apache-2.0 不解决训练数据来源、行业合规、第三方权利和输出责任的全部问题。许可证评审仍要结合模型使用政策、分发方式、微调数据和部署地区，由企业法务给出结论。
第四，开放权重扩大可定制性，也把模型安全、内容过滤、滥用监控、补丁与撤销责任移给部署方。模型卡的发布方评测不是本地系统认证；微调、量化、Prompt 和工具都会改变风险。
第五，完整 CoT 可能泄露敏感上下文、包含幻觉或被用户误解为真实解释。隐藏它不代表失去审计，因为真正审计对象应是外部策略、工具轨迹、审批与权威结果；保存它也不代表已经可解释。
第六，Harmony 与 OpenAI-compatible HTTP 容易被混为一谈。provider 若在内部改模板、丢 channel 或改变 stop token，表面接口仍可返回 200，但工具语义和安全边界已经变化。
最后，本文严格停在 2025 年 8 月 7 日。后续运行时优化、provider 上线、模型卡修订、API 支持或安全研究都不能倒填成首发事实；它们需要新的事件日期与证据边界。
面试表达
30 秒结论： gpt-oss-120b/20b 实际是 117B/21B 总参数、每 token 激活 5.1B/3.6B 的稀疏 MoE，最长 128K，权重采用 Apache-2.0 并以原生 MXFP4 降低装载门槛。官方 80GB/16GB 是运行入口，不是生产并发答案；总参数影响常驻权重，KV Cache 随上下文和并发增长，运行时还要工作区与余量。
3 分钟架构： 我会从内网设备工单的 20b 只读试点开始。任务合同固定权重、tokenizer、Harmony renderer、runtime、tool schema 和预算；模型只提议工具，策略层授权，隔离执行器调用，验证器以监控与工单状态证明完成。容量测试把上下文和并发逐项增加，记录显存、P95、OOM 与任务合格率。120b 只接管 20b 低置信样本；上线看单位经验证工单成本，而不是“没有 API 费”。
若追问“只有 5.1B active，为什么还要 80GB”，答案是 active parameters 描述每 token 的稀疏计算路径，不代表其他 expert 权重消失；常见部署仍需保存全部 117B 权重。若追问“完整 CoT 是否等于审计”，答案是否定的：CoT 是不保证忠实的生成文本，审计要依赖策略、工具回执、审批和权威结果。
若追问“Responses API compatible 是否意味着 OpenAI 托管”，答案仍是否定的：首发交付是权重、自建参考实现和第三方生态，官方当时只表示未来可能考虑 API support。兼容描述的是交互形态，不是服务提供者和 SLA。
复盘
站在 2026 年回看，gpt-oss 的关键变化不是又多了两个下载链接，而是闭源前沿实验室重新把较强推理权重、可商用许可和工具协议交给部署者。企业获得了更大控制面，也同时接过容量、安全和生命周期责任。
当时最容易犯的错误有三个：把型号后缀当精确参数；把 active parameters 当权重显存；把单请求装载门槛当 128K 并发容量。它们都源于把模型卡字段直接翻译为系统 SLA，而没有画出权重、cache、runtime、协议与业务验证之间的链路。
另一个长期价值是 Harmony 提醒我们：模型权重不再是唯一制品。对推理模型，消息编译、channel、工具 schema、reasoning 档位和解析器共同决定行为。未来比较不同开放权重模型，也应比较“权重 + 协议 + 运行时 + 控制面”的完整交付，而不是只看参数与排行榜。
下一步可复现实验应在固定 GPU 上分别运行 20b 与 120b，公开权重 digest、runtime image、Harmony commit、cache dtype、输入/输出长度、并发与采样参数；先捕获空载和单请求内存，再生成上下文 × 并发矩阵，并用同一工单集测合格率、危险建议、延迟和成本。完成之前本文保持 sourced，不升级为 reproduced。
方法披露
本文使用 AI 工具辅助抽取官方首发页、模型卡与固定仓库的结构，推导待验证的内存账本，组织工单案例与检查文章契约；事件日期、Wayback UTC 时间、commit、参数数字、许可证、Harmony 边界、无 OpenAI 首发托管 API 和最终工程判断由作者逐项复核。
文中 4-bit 下界、KV Cache 公式、状态机、300 条样本、10 周试点与门槛均为解释或实验设计，不是本站运行结果。文章没有下载权重、没有测 GPU、没有微调模型，也没有声称 CoT 可以证明业务事实。
修订记录
2025-08-07：初版发布；固定 2025-08-05 至 08-07 的首发页、发布日与 T+2 快照、模型卡及发布日/T+2 代码 commit，区分开放权重与完整开源、active compute 与 resident weights、模型装载与生产显存，并补充 Harmony、CoT、任务合同、失败恢复与单位经济性。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论