gpt-oss-120b 与 gpt-oss-20b 硬件要求：显存与 GPU

gpt-oss-120b 的权重约占 61 GiB（65 GB）显存，OpenAI 表示该模型可在单块 80 GB GPU（如 H100）上运行；gpt-oss-20b 在 16 GB 以内即可运行。在 BF16 下，120b 的上下文每个 token 约占 37 KB，因此一张 96 GB 的显卡可以同时容纳多个长对话。

简要结论

从硬件角度认识 gpt-oss

gpt-oss-120b 和 gpt-oss-20b 是 OpenAI 于 2025 年 8 月以 Apache 2.0 许可证发布的开放权重推理模型；其仓库另附一份简短的使用政策，要求用户遵守适用法律。它们的硬件需求由以下三项设计决定。

• 混合专家。120b 的每个 MoE 块包含 128 个专家，20b 为 32 个，路由器为每个 token 选出其中 4 个。在 120b 的 116.8B 参数中，每个 token 只激活 5.1B，但所有参数都必须驻留在显存中。
• MXFP4 权重。OpenAI 在后训练时将 MoE 权重量化为 MXFP4，每个参数约 4.25 位。这部分权重占全部参数的 90% 以上，正是这一点让 120b 能装进单块 80 GB GPU。注意力、路由器和嵌入层均未量化，而 OpenAI 的所有评估都使用同样的 MXFP4 权重。
• 精简的注意力机制。各层交替使用稠密注意力和 128 个 token 的带状窗口注意力，并采用分组查询注意力，包含 64 个查询头和 8 个键值头，头维度为 64。通过在稠密层上使用 YaRN，上下文长度可达 131,072 个 token。

两个模型都要求使用 OpenAI 的 harmony 响应格式；据 OpenAI 称，不使用该格式时模型将无法正常工作。Transformers 的聊天模板会自动应用该格式，vLLM 的 Responses 端点则借助 openai-harmony 库渲染和解析该格式。推理强度可设为低、中或高，在系统提示词中设置，例如“Reasoning: high”。

gpt-oss-120b 需要多少显存？

先看权重。OpenAI 的模型卡给出的 120b 检查点大小为 60.8 GiB；Hugging Face 上的 safetensors 文件合计 65.25 GB，这是用十进制单位表示的同一数值；vLLM 的发布博文给出的是 63 GB。用单块 GPU 部署该模型时，在处理第一个上下文 token 之前，就需要这么多显存。

显卡的其余显存用于 KV 缓存、激活值和运行时。正因如此，80 GB 是实际可用的下限，而且相当紧张。OpenAI 的 vLLM 指南称，120b“在 ≥60GB 显存下效果最佳”，并且“可以装进单块 H100 或多 GPU 配置”。vLLM 的 recipe（部署指南）称它可以装进单块 80 GB A100，但提醒在单块 H100 上使用默认设置可能会显存不足；其建议的命令将 --gpu-memory-utilization 提高到 0.95，并将 --max-num-batched-tokens 降低到 1024。

有两种捷径行不通：

• 未量化的权重。OpenAI 的 PyTorch 参考实现会把所有权重提升为 BF16 精度，至少需要四块 H100 GPU。请使用 MXFP4 检查点。
• 48 GB 显卡。仅权重就超过了 L40S 的显存容量，因此模型的一部分必须放在系统内存中，详见下文。

磁盘空间也要提前规划。Hugging Face 仓库中的权重有两份：一份是 vLLM 和 Transformers 加载的格式，另一份位于供 OpenAI 参考代码使用的 original 文件夹中；如果全部下载，总计约 130 GB。

gpt-oss-20b 的要求

gpt-oss-20b 有 20.9B 参数，每个 token 激活其中 3.6B，共 24 层、32 个专家。其检查点为 12.8 GiB，即 Hugging Face 上 13.8 GB 的文件。OpenAI 称它可以在 16 GB 内存以内运行；其 Cookbook 称，使用 vLLM 时它“只需要约 16GB 显存”，使用 Ollama 时“最好有 ≥16GB 显存或统一内存”。

在 16 GB 的 GPU 上，留给上下文和运行时的只有约 2 GB，因此只能进行短对话。按 vLLM 的默认显存预算，24 GB 的显卡（如 RTX PRO 4000）可剩余约 8 GB，48 GB 的 L40S 可剩余约 30 GB。据 OpenAI 称，20b 甚至可以在消费级硬件上微调，而 120b 可以在单个 H100 节点上微调。

KV 缓存：上下文占用多少显存

在生成过程中，每个注意力层都会为上下文中的每个 token 存储一个键向量和一个值向量。共有 8 个键值头，每个头的维度为 64，因此在 BF16 下，每个 token 每层需要 2,048 字节。gpt-oss 省下了其中一半：只有稠密层保留所有 token，带状窗口层只保留最近的 128 个。vLLM 的混合 KV 缓存管理器会释放落在窗口之外的缓存块，该管理器的文档也将 gpt-oss 列为混合使用这两类层的模型之一。

• gpt-oss-120b：18 个稠密层 × 2,048 字节 = 36,864 字节，即每个 token 约 37 KB。
• gpt-oss-20b：12 个稠密层 × 2,048 字节 = 24,576 字节，即每个 token 约 25 KB。
• 窗口层：无论对话多长，120b 每个对话固定占用 4.7 MB，20b 为 3.1 MB。
• FP8 KV 缓存：每个值占一个字节而不是两个，因此是上述数字的一半。vLLM 为 gpt-oss 提供的 Blackwell 配置通过 kv-cache-dtype: fp8 启用它。

再乘以同时服务的对话数量即可。vLLM 会根据其预算内剩余的显存自动确定缓存大小，该预算由 --gpu-memory-utilization 设置（默认为 0.92），除非您用 --kv-cache-memory-bytes 直接指定缓存大小。--max-model-len 用于限制每个请求的上下文长度；vLLM 的 recipe 还指出，可运行的最大批次受限于加载权重后留给 KV 缓存的显存。

能在单块 GPU 上运行 gpt-oss-120b 吗？

可以，只要 GPU 显存不低于 80 GB。vLLM 同样推荐使用单块 GPU 以获得最佳的单卡吞吐量；若要降低每个用户的延迟，则推荐使用 2、4 或 8 块 GPU。下表估算了单卡上可留给 KV 缓存的空间，计算时采用标称显存容量、十进制 GB 以及 vLLM 默认的 92% 预算。

这些都是上限：激活值和 CUDA Graph 也从同一预算中分配，因此实际的缓存会更小。H100 一行中微薄的余量，与 vLLM recipe 中显存不足的警告相符。在 96 GB 的 RTX PRO 6000 上，同样的权重留下的空间接近三倍：在扣除运行时开销之前，BF16 下约可容纳四个满长度对话，FP8 下约九个，或者数十个 8,192 token 的对话。

在 48 GB 的 L40S 上，120b 只有把部分权重放到系统内存中才能运行。vLLM 的 --cpu-offload-gb 选项会把 CPU 内存当作额外的 GPU 显存使用，但其文档提醒，这需要快速的 CPU-GPU 互连，因为每次前向传播时，被卸载的权重都要传输到 GPU。Ollama 会自行在 CPU 和 GPU 之间拆分模型。OpenAI 的 Cookbook 总结得很清楚：显存不够时可以卸载到 CPU，“但预计运行速度会变慢”。

GPU 支持：文档怎么说

MXFP4 是一种较新的格式，能否用上高效内核，既取决于推理引擎，也取决于 GPU 的架构代际。以下是 2026 年 10 月时各文档的说法：

• vLLM 的发布博文（2025 年 8 月 5 日）宣布支持 NVIDIA Blackwell 和 Hopper GPU 以及 AMD MI300X 和 MI355X，并提供利用 Blackwell 原生 MXFP4 Tensor Core 的 FlashInfer MoE 内核，以及针对 Hopper 优化的 Triton 内核。
• vLLM 的 gpt-oss recipe 列出了 NVIDIA H100、H200 和 B200，AMD MI300X、MI325X 和 MI355X，以及 Radeon AI PRO R9700，并表示正在推进让该模型在 Ampere、Ada Lovelace 和 RTX 5090 上运行的工作。它为 A100 记录了一条 Ampere 路径，使用 Triton 注意力和 Marlin MXFP4 MoE 内核。其示例启动脚本仅在 GPU 报告的计算能力为 10.0 时（如 B200）才会应用 Blackwell 设置，即 FlashInfer MXFP4+MXFP8 MoE 和 FP8 KV 缓存；其他所有 GPU 都使用 Hopper 配置。
• 计算能力。NVIDIA 列出 RTX PRO 6000 Blackwell、RTX PRO 4000 Blackwell 和 GeForce RTX 5090 的计算能力为 12.0，而 Ada Lovelace 架构的 L40S 为 8.9。
• vLLM 的量化支持表将 Marlin 内核（GPTQ、AWQ、FP8 和 FP4）标为支持 Ampere、Ada 和 Hopper。该表没有 Blackwell 一栏。
• NVIDIA NIM 使用 vLLM 部署这两个模型，它将 L40S、RTX PRO 4500 Blackwell 服务器版和 RTX PRO 6000 Blackwell 服务器版列为两个模型的已验证 GPU，并将 RTX PRO 6000 Blackwell 服务器版纳入其针对 gpt-oss-120b 优化的单 GPU MXFP4 配置文件（profile）。
• Ollama 原生运行 MXFP4，使用为其新引擎编写的内核，并宣布与 NVIDIA 合作优化 GeForce RTX 和 RTX PRO GPU 上的性能。

从实际角度看：在 RTX PRO 6000 Blackwell 服务器版上单卡运行 gpt-oss-120b 有 NVIDIA NIM 的配置文件作为依据，而 vLLM 自己调优的 Blackwell 路径面向的是 B200。在 L40S 上，尽管 gpt-oss recipe 仍将 Ada 列为进行中的工作，vLLM 的量化支持表已通过 Marlin 覆盖了 Ada。无论选择哪种引擎，在规划容量之前，都要在确切的显卡上测试确切的版本，不要依赖在其他 GPU 上测得的公开速度数据。

使用 vLLM 部署 gpt-oss

vLLM 提供兼容 OpenAI 的 API。以下命令遵循其 gpt-oss recipe：

# Python environment and the official vLLM release
uv venv
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# gpt-oss-120b on one GPU, API on port 8000
vllm serve openai/gpt-oss-120b

# Shorter context limit, plus function calling
vllm serve openai/gpt-oss-120b --max-model-len 32768 --tool-call-parser openai --enable-auto-tool-choice

# gpt-oss-20b in the official container
docker run --gpus all -p 8000:8000 --ipc=host vllm/vllm-openai --model openai/gpt-oss-20b

• 端点。/v1/responses 支持在推理步骤之间调用工具，是 OpenAI 为该模型推荐的接口；/v1/chat/completions 返回推理内容和最终文本，但不带内置工具。
• 显存相关参数。--max-model-len 限制每个请求的上下文长度，recipe 指出，在输入和输出较短时，调低该值可以提升性能；--max-num-seqs 限制批次大小；--kv-cache-dtype fp8 将每个 token 的缓存减半。
• 已知不足。recipe 列出的问题包括：用量统计返回零、Responses API 仅支持基础的流式输出，以及函数调用仅限于 tool_choice="auto"。

使用 Ollama 运行 gpt-oss

Ollama 会负责下载，并在显存不足时在 GPU 和 CPU 之间拆分模型：

ollama pull gpt-oss:120b
ollama run gpt-oss:120b

# Larger default context for the models this server loads
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Check where the model is loaded, GPU or CPU
ollama ps

Ollama 会根据 GPU 显存选择默认上下文长度：低于 24 GiB 时为 4k token，24 至 48 GiB 时为 32k，48 GiB 及以上为 256k。对于智能体、编程工具和网页搜索，它建议至少使用 64,000 个 token，并提醒上下文越长，需要的显存越多。在 24 GB 的显卡上，请显式设置上下文长度，而不要依赖默认值，并用 ollama ps 确认没有任何部分溢出到 CPU。

哪款 PowerDedi 服务器适合哪个模型

对于 gpt-oss-120b，RTX PRO 6000 是能在单卡上运行且留有余量的那一款，其 384 GB 主机内存和 Gen5 NVMe 也为权重和模型缓存留出了充足空间。对于 gpt-oss-20b，RTX PRO 4000 足以支撑上下文适中的单个应用，而 L40S 能同时服务多得多的并行对话。每台服务器都配备独享的 10 Gbps 不限流量端口、IPMI/KVM 访问以及一键安装的 Ubuntu 或 Debian；我们的入门指南介绍了服务器交付后的最初几步。另请参阅我们的 AI 与 GPU 计算概览。

以下情况我们并不是合适的选择：

• 微调 gpt-oss-120b。OpenAI 给出的方案是单个 H100 节点。我们每台服务器只配一块 GPU，不提供 NVLink，也不提供多 GPU 集群。
• 每用户最低延迟。vLLM 通过在 2、4 或 8 块 GPU 上进行张量并行来实现这一点，这需要多 GPU 机器。
• 只测试几个小时。短期使用时，按小时计费的云平台更便宜；我们的 RTX PRO 6000 租用对比说明了盈亏平衡点在哪里。

参考资料

• gpt-oss-120b & gpt-oss-20b 模型卡 — OpenAI，arXiv:2508.10925，2025 年 8 月
• openai/gpt-oss-120b — OpenAI，Hugging Face
• openai/gpt-oss — OpenAI，GitHub
• 如何使用 vLLM 运行 gpt-oss — OpenAI Cookbook
• 如何使用 Ollama 在本地运行 gpt-oss — OpenAI Cookbook
• GPT OSS — vLLM Recipes
• vLLM 现已支持 gpt-oss — vLLM 博客，2025 年 8 月 5 日
• 混合 KV 缓存管理器 — vLLM 文档
• 引擎参数 — vLLM 文档
• 量化 — vLLM 文档
• OpenAI gpt-oss — Ollama 博客，2025 年 8 月 5 日
• 上下文长度 — Ollama 文档
• NIM 支持矩阵 — NVIDIA NIM for LLM and VLM
• CUDA GPU 计算能力 — NVIDIA Developer