博客 / 模型观察

模型变笨还是换了供应商：推理供应商与 fp8、fp4 模型量化

2026-10-17cdnping 编辑部约 6 分钟读完

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

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

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

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

代价是精度损失。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 字段的分布：

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

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

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

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

也就是说，在 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 提供公开的端点列表接口，不需要密钥：

# 把 <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 的 模型监测页，同一份数据按模型分组，附带各端点的可用率、延迟和吞吐。

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

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

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

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

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

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

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，分别锁定两个不同精度的端点，各跑几遍再对比。单次结果受随机性影响大，不要只看一条。

#排查检查表

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

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

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

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