部落格 / 模型觀察

大模型 API 價格變了怎麼第一時間知道：更新日誌、模型目錄與賬單三路追蹤

2026-10-17cdnping 編輯部約 6 分鐘讀完

想及時知道大模型 API 價格調整、上新或下架，比較省事的辦法是同時盯三類資訊源：廠商的官方更新日誌和價格頁、OpenRouter 這類聚合平臺的公開模型目錄、你自己賬單和請求日誌裡的異常。前兩類可以交給工具自動比對，cdnping 的 官網動態 /changes 和 模型監測 /models 分別覆蓋這兩塊；第三類只能你自己接入。下面說明每類資訊源能告訴你什麼，怎麼訂閱，以及想自己寫指令碼時該怎麼搭。

#廠商會通知調價，為什麼還要自己追蹤

廠商調價或下線舊模型時可能會發郵件，但郵件一般發到賬號繫結的郵箱，團隊裡實際寫程式碼、配路由的人未必收得到。還有幾種變化不一定有單獨通知：

• 價格頁上某一行悄悄改了，或者快取命中價、長上下文分檔價單獨調整；
• 第三方推理供應商對同一個模型換了量化精度，例如從 fp8 換成 fp4；
• 某個模型 ID 從聚合平臺的目錄裡消失，或者多了一個帶日期字尾的新 ID。

這些變化會影響成本或輸出質量。靠人每週翻一遍網頁容易漏，適合做成自動比對。

#該盯哪三類資訊源，各自能回答什麼

幾點需要注意：

1. 官方頁面是準繩。聚合平臺上的標價是它自己的售價，和官方直連價格不一定相同，調價結論以廠商價格頁為準。
2. 更新日誌和價格頁要分開盯。兩者不一定同時更新，只盯一個可能晚幾天才發現。
3. 結構化資料要先清洗。OpenRouter 目錄裡有特殊值，直接拿來算最小值會得出錯誤結論，下面有例項。

#用 cdnping 的 /changes 和 /models 能看到哪些變化

#官網動態 /changes：盯官方網頁的逐行增刪

cdnping 是面向開發者的免費網路觀測站。/changes 監控 DeepSeek、OpenAI、Codex、Claude、Gemini、xAI、Kimi、阿里雲百鍊等 11 個官方更新日誌、價格頁和新聞頁。它的做法是定期抓取頁面正文，與上一次快照逐行比較，把新增和刪除的行記錄下來。你看到的是原文哪一行被加上或刪掉，影響由你自己判斷。

這個頁面帶 RSS，訂閱 RSS 比每天開啟網頁更不容易漏。

#模型監測 /models：盯 OpenRouter 目錄和推理供應商

/models 讀取 OpenRouter 的公開 API，展示各家最新模型在每個推理供應商上的可用率、延遲、吞吐和量化精度，並自動記錄四類事件：上架、下架、調價、量化變化。

下面是 cdnping 在 2026 年 10 月 17 日對 OpenRouter 公開模型目錄做的單日快照：

• 目錄中共有 376 個模型條目；
• 輸入價格欄位的最大值是 150；
• 輸入價格欄位的最小值是 -1000000。這顯然不是真實價格，而是特殊條目使用的佔位值。

最後一條是自己寫指令碼時容易踩的坑：不先過濾負數和佔位值，“目錄最低價”會算成負數，調價告警也會誤報。cdnping 從 2026-10-17 才開始採集，這只是單日快照，不代表長期趨勢。

同一天的供應商資料裡還能看到量化精度的差別：同一個模型在不同推理供應商上，有的標註 fp8，有的標註 fp4、mxfp4 或 int4，也有不少未標註。如果你透過聚合平臺呼叫，輸出質量的波動可能來自供應商切換，而不是模型本身變了。/models 會把量化變化記成事件，排查時可以先對一下時間點。

/models 頁面還附有幾個第三方“模型變笨”評測專案的導航（Livenerf、AI Stupid Level、Is It Nerfed?、BridgeBench Nerf Bench），cdnping 不轉載它們的資料，需要時去原站看。

#怎樣把調價和上新提醒推到團隊群

下面的步驟按先個人、後團隊的順序排列。

#第 1 步：訂閱 /changes 的 RSS

開啟 /changes，複製頁面上的 RSS 地址，加到你常用的閱讀器裡。只關心部分廠商的話，可以在閱讀器裡按標題關鍵詞過濾，例如只保留含“DeepSeek”“價格”的條目。

#第 2 步：把 RSS 接進團隊群

常見做法有兩種：

• 飛書、釘釘、企業微信的群機器人都支援 Webhook。用一個定時任務讀取 RSS，把新條目推到 Webhook 即可，具體引數以各平臺的官方文件為準。
• 如果團隊已經在用支援 RSS 訂閱的協作工具，直接在頻道里新增訂閱。

建議單獨建一個“模型變更”頻道，不要和告警頻道混在一起。調價和上新屬於需要閱讀的資訊，不是需要馬上處理的故障。

#第 3 步：把 /models 加入每週例行檢查

/models 的事件更適合定期翻看。可以把它放進每週的例行檢查清單，和 穩定性週報 /reports 一起看，週報每週一自動生成，也可以訂閱。

#第 4 步：約定誰來判斷影響

提醒只解決“知道”的問題。團隊裡最好明確一個人每週過一遍變更，按下面的清單判斷：

• 我們在用的模型 ID 是否出現在下架或停用條目裡？停用日期是哪天？
• 價格變化涉及輸入、輸出還是快取命中？對月度預算的影響按自己的用量估算。
• 新模型是否值得試？先在測試環境用小流量對比，再改生產配置。
• 透過聚合平臺呼叫的模型，供應商的量化精度有沒有變化？
• 程式碼裡寫死的模型 ID、單價常量是否需要同步修改？

#自己寫追蹤指令碼該怎麼搭

如果你需要盯 cdnping 沒覆蓋的頁面，或者想把資料存進自己的系統，可以按下面的思路寫。這裡用虛擬碼，語言和排程方式按你的環境選，例如 cron、CI 的定時任務或雲函式。

#思路一：比對 OpenRouter 目錄

OpenRouter 的模型列表介面是公開的（GET https://openrouter.ai/api/v1/models），返回每個模型的 ID、上下文長度和標價。欄位含義和價格單位以 OpenRouter 官方文件為準。

每 6 小時執行一次（頻率僅為示例）：
  current = 請求 OpenRouter 模型列表，取 data 陣列
  previous = 讀取上一次儲存的快照（沒有則儲存後退出）

  清洗：
    對每個模型，把 prompt / completion 價格轉成數字
    價格 < 0 或無法解析的，標記為“特殊條目”，不參與調價比較
    統一換算成“每百萬 token 的美元價格”，方便人讀

  比較：
    新增 = current 裡有、previous 裡沒有的模型 ID      -> 記為“上架”
    消失 = previous 裡有、current 裡沒有的模型 ID      -> 記為“下架”
    對兩邊都有的 ID：
      若價格變化超過閾值（例如 0.5%，避免浮點誤差誤報） -> 記為“調價”，寫明舊價和新價
      若上下文長度變化                               -> 記為“規格變化”

  輸出：
    把事件列表推送到群機器人 Webhook
    儲存 current 作為新的 previous

幾個細節：

• 只推自己在用的模型。目錄有幾百個條目，全量推送很快就沒人看了。維護一個關注列表，其餘變化只寫日誌。
• 連續兩次確認再告警。介面可能返回不完整的資料，某個 ID 臨時缺失不一定是下架，可以要求連續兩次快照都缺失才發“下架”通知。
• 儲存原始響應。出現爭議時，原始 JSON 比你的摘要更有說服力。

#思路二：比對官方更新日誌和價格頁

每天執行一次，對每個關注的 URL：
  html = 抓取頁面（帶合理的 User-Agent，頻率放低，遵守站點的 robots 規則）
  text = 提取正文：去掉導航、頁尾、指令碼，保留表格文字，每行一條
  previous_text = 讀取上次儲存的正文

  diff = 按行比較 previous_text 和 text
  若 diff 為空：退出
  過濾噪音：忽略只包含日期、訪問量、隨機 ID 的行
  若過濾後仍有新增或刪除：
    推送“頁面 + 新增行 + 刪除行 + 原頁連結”
  儲存 text

這類指令碼的維護成本主要在提取正文這一步。頁面改版、改用前端渲染，都會讓提取結果整頁變化，觸發一次誤報。遇到這種情況，人工確認後更新提取規則即可。如果你只關心 cdnping 已覆蓋的那 11 個頁面，直接訂閱 /changes 的 RSS 更省事。

#思路三：從自己的賬單反推

廠商調價最終會體現在賬單上。可以每天用請求日誌裡的 token 數乘以你記錄的單價，算出預估費用，再和廠商控制檯的實際扣費對比。兩者偏差持續超過某個比例（比如 5%，按你的容忍度定），就說明單價可能變了，或者計費規則有調整，需要回頭查價格頁。

#透過聚合閘道器呼叫時，價格以誰為準

如果你透過多供應商閘道器呼叫模型，價格和可用模型取決於閘道器自己的定價和模型清單，官方調價不一定同步傳導。以 AGI Plan 為例（AGI Plan 是 cdnping 的商業合作方），它按月訂閱、人民幣結算、按 CU 計量，可用模型以 agiplan.dev/models 為準，套餐價格見 agiplan.dev/pricing。這種情況下，除了盯上游廠商，還要關注閘道器自己的模型頁和公告。

#今天就能做的四件事

1. 現在就訂閱 /changes 的 RSS，並推到團隊的“模型變更”頻道。
2. 把程式碼裡寫死的模型 ID 和單價整理成一份配置檔案，下次調價只改一處。
3. 開啟 /models，找到你在用的模型，看一下各推理供應商的量化精度和近 1 天可用率，記下現狀作為基線。
4. 想了解各官方 API 入口的連通情況，可以順帶看 API 狀態 /status；資料口徑見 資料方法 /methodology。