部落格 / 模型觀察

模型變笨還是換了供應商：推理供應商與 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 才開始積累，等資料視窗變長，再回頭看各供應商調整精度的頻率會更有參考價值。