---
title: "模型变笨还是换了供应商：推理供应商与 fp8、fp4 模型量化"
description: "同一模型时好时坏，常和推理供应商的模型量化精度有关。本文用 cdnping 采集的 OpenRouter 快照统计 137 个端点的 fp8、fp4、int4 分布，并给出锁定精度和排查变笨的步骤。"
url: https://cdnping.org/blog/llm-quantization-fp8-fp4-providers
language: zh-CN
published: 2026-10-17
category: "模型观察"
tags: ["模型量化","推理供应商","OpenRouter","模型监测","fp8"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# 模型变笨还是换了供应商：推理供应商与 fp8、fp4 模型量化

同一个模型 id 时好时坏，一个常见原因是请求每次落到了不同的推理供应商，而各家采用的模型量化精度不一样：有的是 fp8，有的是 fp4 或 int4，还有不少没有标注。cdnping 在 2026-10-17 采集的 OpenRouter 快照里，137 个供应商端点中只有 50 个标注了量化精度，没有一个标注 bf16。判断模型是不是真的“变笨”之前，先确认这次请求由谁服务、用的什么精度。

## 量化是什么，为什么会影响输出

大模型的权重是一大堆浮点数，训练时通常用 bf16（16 位）保存，每个参数占 2 字节。量化就是把这些数换成更少的位数来存储和计算：

| 精度 | 每个参数位数 | 显存相对 bf16 | 常见做法 |
|---|---|---|---|
| bf16 | 16 | 100% | 训练和发布时常用的精度 |
| fp8 | 8 | 约 50% | E4M3 / E5M2 格式，按张量或按通道缩放 |
| int4 | 4 | 约 25% | 多为只量化权重，按组共享缩放系数（如 AWQ、GPTQ 一类方法） |
| fp4 | 4 | 约 25% | E2M1 格式，依赖新一代 GPU 的原生支持 |
| mxfp4 | 4 | 约 25% | 微缩放格式，每 32 个元素共享一个 8 位指数 |

位数减半，显存和带宽压力大致减半，同一张卡能跑更大的批次，吞吐上去，单价就能降下来。这是推理供应商愿意量化的直接原因。

代价是精度损失。4 位只能表示 16 个不同的值，模型里的离群值（少数绝对值特别大的权重或激活）很难照顾到。单次前向计算里的误差很小，但在下面几类场景里会被放大：

- 长上下文：误差随层数和序列长度累积，几万 token 之后的检索和引用更容易出错。
- 多步推理和数学：一步偏了，后面跟着偏。
- 严格格式输出：工具调用的 JSON、函数参数名、代码缩进，对低概率 token 很敏感。
- 低频语言和专有名词：这类 token 本来概率就低，量化后更容易被挤掉。

另外有两点要分清。一是量化不等于降级：不少开源模型官方发布的权重本身就是 fp8，或者是经过量化感知训练（QAT）的 int4，这时低精度就是原版。二是同样标 fp8，校准数据、缩放粒度、推理引擎和 KV cache 精度不同，效果也会有差别。精度标签只是线索，不能直接当结论。

## OpenRouter 上各供应商标的是什么精度

以下数据来自 cdnping 的 /models 页面，源头是 OpenRouter 公开 API，采集时间 2026-10-17（UTC），是单次快照。cdnping 从这一天才开始采集，还没有趋势数据，数字只代表当时的状态。

快照覆盖 16 个模型 id、137 个供应商端点（同一家供应商的不同区域或档位算不同端点）。quant 字段的分布：

| quant 字段 | 端点数 | 占比 |
|---|---|---|
| 未标注（unknown） | 87 | 63.5% |
| fp8 | 23 | 16.8% |
| fp4 | 13 | 9.5% |
| mxfp4 | 8 | 5.8% |
| int4 | 6 | 4.4% |
| bf16 | 0 | 0% |

### 闭源模型为什么看不到精度

快照里 Anthropic、OpenAI、Google、xAI 四家共 8 个模型 id、57 个端点，quant 字段全部是 unknown。闭源模型由原厂或其授权的云厂商部署，精度不对外公开。对这类模型，“时好时坏”要从别的方向找原因，后文会讲。

### 开源模型的精度差异有多大

标注了精度的 50 个端点里，49 个来自三个开源模型（为避免绑定具体版本，下表用代号）：

| 模型 | 端点数 | fp8 | fp4 | mxfp4 | int4 | 未标注 |
|---|---|---|---|---|---|---|
| DeepSeek 开源模型 A | 36 | 17 | 3 | 1 | 0 | 15 |
| Moonshot 开源模型 B | 26 | 2 | 9 | 7 | 0 | 8 |
| Moonshot 开源模型 C | 13 | 3 | 1 | 0 | 6 | 3 |

也就是说，在 OpenRouter 上调用同一个开源模型 id，背后可能有十几到三十几个端点，精度从 fp8 到 4 位都有。不指定供应商时，路由会按价格、可用率和延迟自动选择，连续两次请求落到不同精度的端点很正常。

快照里还有几处细节：

- 原厂端点也可能是 4 位。模型 B 在 Moonshot AI 自营端点上标的是 mxfp4，模型 C 的原厂端点标的是 int4。第三方用同样精度部署，不能直接认定为“缩水”。
- 同一家供应商也会分档。例如 DeepInfra 在模型 A 上同时有 `fp8`、`fp8/flex`、`fp8/priority` 三个端点，精度相同，服务等级不同。
- 可用率和精度看不出对应关系。模型 A 近 1 天可用率最低的四个端点依次是 fp8、未标注、fp8、fp4，数值都在 88% 到 90% 之间。可用率要单独看。

## 除了量化，还有什么会让模型“变笨”

同一个模型 id 在不同端点上表现不一样，还可能来自：

1. 上下文长度被截断：有的端点支持的最大上下文比模型标称的小，长对话前半段会被丢掉。
2. 对话模板和工具调用解析：chat template 或 tool call 解析器实现不一致，表现为格式乱、参数名错、该调工具时不调。
3. 默认采样参数：各家 temperature、top_p 的默认值不同，没有显式传参时会体现在输出里。
4. 推理加速：投机解码、KV cache 量化、`fast` 一类加速档位，可能带来细微差别。
5. 原厂自身的变化：闭源模型的版本更新、系统提示调整、高峰期的策略变化。这类变化外部看不到精度字段，只能从行为上观察。

## 怎样锁定精度并排查“变笨”

### 第 1 步：查一个模型有哪些端点、各是什么精度

OpenRouter 提供公开的端点列表接口，不需要密钥：

```bash
# 把 <author>/<slug> 换成你要查的模型 id
curl -s https://openrouter.ai/api/v1/models/<author>/<slug>/endpoints \
  | jq -r '.data.endpoints[] | [.provider_name, .tag, .quantization] | @tsv'
```

每行输出一个端点：供应商名、端点标签、量化精度。字段名以 OpenRouter 官方文档为准。不想自己跑命令，可以打开 cdnping 的 [模型监测页](/models)，同一份数据按模型分组，附带各端点的可用率、延迟和吞吐。

### 第 2 步：在请求里限定精度或供应商

OpenRouter 的请求体支持 `provider` 路由参数。下面的写法只接受标为 bf16 或 fp8 的端点，并且不回退到其他端点：

```json
{
  "model": "<author>/<slug>",
  "messages": [{"role": "user", "content": "..."}],
  "provider": {
    "quantizations": ["bf16", "fp8"],
    "allow_fallbacks": false
  }
}
```

对某个供应商的输出已经验证过的话，也可以用 `order` 指定优先顺序。两点提醒：按精度筛选时，未标注精度的端点可能被排除，可选端点会明显变少；关掉回退后，可用率完全取决于选中的那几个端点，选之前最好对照 /models 上的近 1 天可用率。

### 第 3 步：记录每次请求实际由谁服务

遇到“这次回答明显变差”，先拿到这次请求的 generation id，再查询是哪个供应商服务的：

```bash
curl -s "https://openrouter.ai/api/v1/generation?id=<generation_id>" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  | jq '.data | {provider_name, model, tokens_prompt, tokens_completion}'
```

最好在自己的日志里固定记下供应商名，事后对比才有依据。

### 第 4 步：用固定样例做 A/B

挑 5 到 10 条能代表你业务的提示（至少包括一条长上下文、一条工具调用、一条严格 JSON 输出），temperature 设为 0，分别锁定两个不同精度的端点，各跑几遍再对比。单次结果受随机性影响大，不要只看一条。

### 排查检查表

| 现象 | 优先怀疑 | 检查方法 |
|---|---|---|
| 长文档后半段引用出错 | 上下文截断、4 位量化 | 看端点的最大上下文；锁定 fp8 端点重跑 |
| 工具调用 JSON 不合法 | 模板或解析器差异、量化 | 换供应商对比；在请求里限定精度 |
| 同一提示两次结果差很多 | 路由到了不同端点 | 查 generation 的 provider_name |
| 闭源模型整体变差 | 原厂侧变化或故障 | 看 /changes 有无更新公告，看 /down 和 /status |
| 突然变慢、超时增多 | 端点负载或故障 | 看 /models 的端点可用率和 /status/openrouter |

## 在哪里持续跟踪精度和状态变化

- [/models](/models)：各家最新模型在每个推理供应商上的可用率、延迟、吞吐和量化精度，自动记录上架、下架、调价和量化变化。供应商把某个端点从 fp8 换成 fp4，这里会留下记录。页面另附几个第三方“模型变笨”评测项目的导航，cdnping 不转载它们的数据。
- [/down/openrouter](/down/openrouter)：综合官方状态页、每 5 分钟的 API 探测和用户一键报告，报告选项里有“变笨了”。
- [/changes](/changes)：监控多家官方更新日志、价格页和新闻页，逐行记录增删。闭源模型的行为变化，可以先到这里找有没有对应公告。
- [/status/openrouter](/status/openrouter)：从 Cloudflare 边缘每 5 分钟探测 OpenRouter 的 API 入口，用来区分“模型答得差”和“接口本身不稳”。

如果你不直接调用 OpenRouter，而是通过聚合网关使用模型，例如 [AGI Plan](https://agiplan.dev)（AGI Plan 是 cdnping 的商业合作方），同样建议用固定样例定期对比。AGI Plan 的按能力组可用率可以在 [/status/agiplan](/status/agiplan) 查看，具体模型和能力组以 [agiplan.dev/models](https://agiplan.dev/models) 为准。

cdnping 的量化变化记录从 2026-10-17 才开始积累，等数据窗口变长，再回头看各供应商调整精度的频率会更有参考价值。