进阶端侧 / 本地 6 分钟阅读发布于 2026-08-08 · 更新于 2026-10-03

本地运行 GPT-OSS 20B（及 120B）——不要重新量化

GPT-OSS 原生就是 MXFP4，习惯性去下 Q4_K_M 反而更大更差。本文讲清显存怎么算、该用哪些参数，以及如何用 MoE 专家卸载在 24GB 卡上跑 120B。

GPT-OSSMXFP4MoEllama.cppOllamaGGUF

最关键的一点：MXFP4 就是原版

本站几乎所有其他模型都是 BF16 发布、社区事后量化，所以"找 Q4_K_M"是对的直觉。GPT-OSS 打破了这个直觉：OpenAI 在后训练阶段就把 MoE 权重做成了 MXFP4（约 4.25 bit），而 MoE 权重占参数量 90% 以上。这份 MXFP4 权重不是某个更好版本的有损副本——它本身就是模型。把它转成 Q8_0 或平移到 Q4_K_M，只会得到一个更大但并不更准的文件，因为你补回去的精度从来就不存在。

text

gpt-oss-20b   MXFP4 (native)  11.3 GiB file   ← use this
gpt-oss-120b  MXFP4 (native)  59.0 GiB file   ← use this

(file sizes from llama.cpp's own gpt-oss guide)

Rule: for GPT-OSS, "bigger quant" buys you nothing.
Spend the VRAM on context length instead.

按你的显卡估算

20B 在 16GB 卡上可跑，且还剩下够用的上下文空间。注意 GPT-OSS 的 head dim 是 64 而非常见的 128，同层数下 KV cache 直接减半——而且一半的层使用 128 token 的滑动窗口，只有另一半会随上下文增长缓存。长上下文在这个模型上便宜得反常。用显存计算器时记得选 MXFP4 档。MXFP4 约 4.25 bit 只针对专家权重 —— 注意力和嵌入层存得更宽 —— 所以 20B 整个文件折合约每权重 4.6 bit，计算器用的就是这个比率。llama.cpp 自己的 gpt-oss 指南给出的总量比本计算器高（20B 在 8K 上下文下是 14.9 GB，这里约 12.9 GB），因为它把运行时的计算缓冲区完整算了进去；请把计算器的数字当作下限，留出余量。

text

gpt-oss-20b @ MXFP4, batch=1 (this site's calculator)
  weights                    ~11.5 GB
  KV cache @  8K ctx          ~0.2 GB
  KV cache @ 32K ctx          ~0.8 GB
  KV cache @ 131K ctx         ~3.0 GB
  total @ 8K / 32K / 131K     12.9 / 13.5 / 16.0 GB

llama.cpp's own guide, same model: 14.9 / 15.5 / 17.9 GB

16GB card  → comfortable to ~32K ctx; the full 131K window does not fit
24GB card  → full 131K ctx with headroom

最省事：Ollama

Ollama 默认拉取的就是 MXFP4 构建，没有量化档位可选，也就不会误拿到重新量化的版本。除非你需要自定义参数，否则从这里开始最合适。

bash

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

# 120B — needs ~61GB of combined VRAM+RAM
ollama pull gpt-oss:120b

# OpenAI-compatible endpoint stays on :11434
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-oss:20b","messages":[{"role":"user","content":"hi"}]}'

llama.cpp：必须加 --jinja，否则输出会很怪

GPT-OSS 使用 OpenAI 的 "harmony" 响应格式训练，该格式把推理通道与最终回答分开。这个结构写在模型的 chat template 里，所以 llama.cpp 需要 --jinja 才会套用。不加这个参数，你会看到通道标记直接漏进回复里，或者模型停不下来——这个现象很像量化坏了，其实纯粹是模板问题。

bash

# 20B, all layers on a 16GB+ GPU
llama-server \
  -hf ggml-org/gpt-oss-20b-GGUF \
  --jinja \
  -ngl 99 \
  --ctx-size 32768 \
  --host 127.0.0.1 --port 8080

# --jinja       applies the harmony chat template  (do not omit)
# -ngl 99       offload every layer to the GPU
# --ctx-size    32K is ~13.5 GB by this site's estimate, 15.5 GB by
#               llama.cpp's own table — fine on 16GB with nothing else
#               on the card. llama.cpp's guide uses --ctx-size 0 (the
#               full 131K) and -ub 2048 -b 2048, which needs ~18 GB.

在 24GB 消费级显卡上跑 120B

这正是 MoE 架构的价值所在。每个 token 只激活 5.1B 参数，专家权重是稀疏读取的——因此它们最适合留在系统内存里。llama.cpp 官方的做法是把整个模型都放到 GPU 上，再用 --n-cpu-moe 把需要的若干层专家留在 CPU；留在 CPU 上的部分占用的是系统内存，所以要为这 59 GiB 的文件留出大部分内存。同一个参数也能让 20B 跑在更小的卡上：llama.cpp 的指南就用 --n-cpu-moe 16 在 8GB 的 RTX 2060 上运行它。这两种配置本站都没有实测，所以不给速度数字。

bash

# 120B on 24GB: keep the experts of N layers on the CPU
llama-server \
  -hf ggml-org/gpt-oss-120b-GGUF \
  --jinja \
  -ngl 99 \
  --n-cpu-moe 28 \
  --ctx-size 16384 \
  --host 127.0.0.1 --port 8080

# 20B on an 8GB card (llama.cpp's own RTX 2060 example)
llama-server -hf ggml-org/gpt-oss-20b-GGUF --jinja \
  --ctx-size 32768 --n-cpu-moe 16 --host 127.0.0.1

# Lower N = more experts on the GPU = faster. Lower it until
# loading fails for lack of VRAM, then step back up.

推理强度是可调的，不是固定开销

GPT-OSS 支持 low / medium / high 三档推理强度。high 会在回答前消耗多得多的 token 思考，在本地硬件上这就是"响应利落的助手"和"卡一分钟"的区别。日常对话和补全用 low，只在真正需要思维链的问题上开 high。

text

llama.cpp (from its gpt-oss guide):

  llama-server ... --chat-template-kwargs '{"reasoning_effort": "low"}'

Any client that can only set the system message:

  System: Reasoning: low

Rough local cost on a 16GB card (20B):
  low     fast, chat-grade latency
  medium  noticeably more thinking tokens
  high    can multiply time-to-first-answer several times over

Start at low. Raise it per-task, not globally.

常见故障对照

本地跑 GPT-OSS 报的问题绝大多数是以下五种之一，且没有一种是量化的锅。换构建之前先对照检查。

text

Channel markers in the output, or it never stops
  → missing --jinja (harmony template not applied)

"unknown model architecture" on load
  → llama.cpp / Ollama predates gpt-oss support; update

Slower than expected on the 120B
  → --n-cpu-moe too high; lower it until GPU VRAM is nearly full

Repetitive or oddly degraded answers
  → check sampling: OpenAI recommends temperature 1.0 and
    top_p 1.0, and llama.cpp's guide says not to use a
    repetition penalty

File much bigger than ~11.3 GiB (20B)
  → you downloaded an upcast build; get the MXFP4 one

常见问题

GPT-OSS 20B 能在 8GB 或 12GB 显卡上跑吗？

没法完整放在显卡上 —— 本站按 4K 上下文估算约 12.8GB，llama.cpp 自己的表格还更高。把一部分专家留在系统内存就能跑：llama.cpp 的 gpt-oss 指南用 --n-cpu-moe 16 在 8GB 的 RTX 2060 上运行它，并报告 12GB 的 RTX 3060 在卸载状态下生成初期约每秒 67 个 token。由于每个 token 只激活约 3.6B 参数，卸载带来的减速远小于同体量的稠密模型。

GPT-OSS 20B 在 RTX 4090 上有多快？

llama.cpp 在其 gpt-oss 指南里给出的基准测试：RTX 4090 上生成约每秒 222 个 token，提示词处理约每秒 8,000 个 token。这是 llama.cpp 开发者测的，不是本站测的；本站对同一张卡的数字列在模型页上，并标明了来源。

GPT-OSS 应该用什么采样参数？

OpenAI 推荐 temperature 1.0、top_p 1.0，llama.cpp 的 gpt-oss 指南还补充了一条：不要用重复惩罚。很多前端会套用自己的默认值，通常是更低的 temperature 加上重复惩罚，所以如果回答重复或者莫名被截断，请显式设置这几个参数。

这篇指南用到了什么

硬件: RTX 409024GB RTX 3090
模型: GPT-OSS 20B21B MoE GPT-OSS 120B117B MoE
格式: GGUF
对应推荐: 24GB 能跑的最好的本地大模型
接着读: DGX Spark 64GB 与 128GB：各自能跑什么 AMD 显卡 + llama.cpp ROCm 快速入门 RTX 4060 Ti 16G 能跑什么模型？

接下来

看看 🟢 RTX 4090 还能跑哪些模型反向查询 —— 24GB、32768 上下文，按质量排序

本文涉及的模型

它真的跑起来了吗？

复制命令并不等于它能用，所以站内只在这里问一次。除了你的这个回答之外，不收集任何东西。

本地运行 GPT-OSS 20B（及 120B）——不要重新量化

最关键的一点：MXFP4 就是原版

按你的显卡估算

最省事：Ollama

llama.cpp：必须加 --jinja，否则输出会很怪

在 24GB 消费级显卡上跑 120B

推理强度是可调的，不是固定开销

常见故障对照

常见问题

GPT-OSS 20B 能在 8GB 或 12GB 显卡上跑吗？

GPT-OSS 20B 在 RTX 4090 上有多快？

GPT-OSS 应该用什么采样参数？

这篇指南用到了什么

接下来

它真的跑起来了吗？

相关指南

Intel Arc 显卡：llama.cpp（SYCL）或 Ollama（Vulkan）

RTX 5090：32GB 显存在本地大模型上到底多出什么

DGX Spark 64GB 与 128GB：各自能跑什么