【2026 最新】模型身分查核怎麼做？第三方 LLM API 收據、對照題與判定門檻

你在第三方 API 選了某款模型，收到的答案卻自稱是另一款。第三方 LLM Provider 模型身分查核怎麼做？這時最容易做錯的事，是把模型說出的名字當成鑑定報告，或直接指控供應商換了權重。

這篇寫給第一次替應用程式接 LLM API、也願意複製幾行指令的讀者。你會學到一張可保存的「交付收據」、一組配對題目，以及把結果分成契約違反、可疑與無法判定的方法。本文是依截至 2026 年 10 月 6 日的官方 API 文件與原始研究設計的查核流程；文中的案例是示意，不是 AlphaLab 對任何供應商的實測。

先說結論：模型身分查核先查交付，再查行為

一句話記住：模型身分查核＝請求契約＋交付收據＋配對行為；前三者能查服務是否符合宣稱，單靠黑箱輸出仍不足以確證底層權重。就像網購：商品頁是宣稱、出貨單是交付紀錄、試用是功能驗收；只看包裝上的字，無法知道工廠裡用了哪一台機器。

• 先查「你要求了什麼」：model ID、provider 限制、fallback、參數和時間。
• 再查「平台記了什麼」：response model、request/generation ID、provider、token、成本與延遲。
• 最後查「它做得到什麼」：固定題集對照原廠端點，保留重複試跑與完整設定。

為什麼「你是哪款模型？」只能算線索？

模型回答的是文字，不是硬體序號。提示詞、系統訊息、先前對話與訓練材料都可能影響它如何自稱；第三方路由也可能調整訊息模板。一位開發者提出的身分不一致案例，本人也明說自我辨識不足以證明替換。這個案例提供查核題目，不能當作對該供應商的裁決。

連一整套輸出指紋也有界線。2026 年 6 月一篇原始研究研究了有限查詢預算下的指紋偽裝：經特定微調的弱模型，可能通過研究所測的若干辨識方法。它證明的是那些方法在該攻擊設定下的脆弱性，並非所有供應商都曾這樣做。對讀者最實用的結論是：輸出相似可以增加信心，不能升格成權重來源證書。

模型身分查核的五步流程

① 保存「下單單據」：凍結完整請求

先把每次請求的 UTC 時間、端點 URL、請求中的 model、messages、temperature、輸出上限、工具 schema、串流選項和供應商路由設定存成 JSON。金鑰只留環境變數，不要放進可分享的紀錄。若使用 OpenRouter，先到Models API確認當天的模型 ID，再到該模型的endpoints 清單確認可選的 endpoint；不要憑文章裡的舊型號輸入。

同時記錄 provider.only 或 provider.order、allow_fallbacks 等路由設定。OpenRouter 路由文件說明兩者用途不同：順序是偏好，限制可用 provider 才是控制範圍。若用了 models 陣列，還得記錄候補模型；官方 fallback 文件說明回應的 model 會反映最後使用的模型。這些欄位若沒存，事後常連「原本允許換去哪裡」都說不清。

② 保存「出貨單」：抓回應與計費收據

對 OpenRouter 的非串流 Chat Completions，可把請求加入 X-OpenRouter-Metadata: enabled，保存完整回應的 id、model、usage，以及若回傳的 openrouter_metadata。用回應 ID 查 GET /api/v1/generation，範例資料包含 model、provider_name、request_id、total_cost 與延遲。欄位可能為空或隨 API 變化，保存原始 JSON 比只截取幾個值可靠。

可以先用這兩行建立一張最小收據；將 MODEL_ID 換成當天 Models API 列出的值，再於自己的 shell 設好金鑰。curl -sS https://openrouter.ai/api/v1/chat/completions -H "Authorization: Bearer $OPENROUTER_API_KEY" -H "Content-Type: application/json" -H "X-OpenRouter-Metadata: enabled" -d '{"model":"MODEL_ID","messages":[{"role":"user","content":"請用一句話說明 HTTP 200"}]}' > response.json；接著 jq '{id,model,usage,openrouter_metadata}' response.json。這只採集平台自報資料，不是權重驗證。

③ 設「對照組」：同題、同設定、交錯試跑

在第三方端點與模型開發者的原廠端點，各用同一份可公開分享的無敏感資料題集。至少涵蓋你實際用到的三類工作：固定格式、工具呼叫、長上下文或多輪接續。每題保留完整 prompt、工具 schema、回應、錯誤、耗時與版本日期；兩邊交錯執行，避免一邊全在尖峰時段。原廠端點本身也是一個服務實作，因此差異只能指出值得追查，不能直接推回權重不同。

答案不要逐字比對。OpenAI 的重現性文件指出生成預設有隨機性，固定 seed 也只是提高可重現性，後端設定仍可能變。每個條件做數次重複，報告通過／失敗分布與原始樣本；評分規則先寫好，不能看完答案再改。若題目涉及 OpenAI 產品的 system_fingerprint，它表示後端設定訊號，不是跨供應商的權重證明。

④ 驗「能力契約」：看會不會做，而非像不像誰

若產品一定要呼叫工具，就要求回傳符合 schema 的工具名稱與參數；若一定要讀長文件，就用一個放在靠後位置、答案可核對的資訊點；若要固定 JSON，就檢查解析和必要欄位。對照OpenRouter 工具呼叫文件與當日 model/endpoints 頁記錄支援範圍。這些測試能證明「這條交付路徑能否完成我的工作」，不會替你鑑定模型家譜。

如果你需要完整的協定級 fixture 與 release gate，可接著讀 OpenRouter 契約測試；若已經知道模型與供應商，想比較同一模型不同 endpoint 的品質，讀 Provider Pinning 實戰。本文處理的是兩者之前的證據問題：供應商說自己交付哪一款，應該如何核對。

⑤ 定「處置門檻」：分三級寫結論

1. 契約違反：在你明確禁止替代路由、且保存了請求與回應的情況下，回應或收據持續顯示不同 model ID；或文件承諾的必要能力在相同請求條件下穩定失敗。先排除 alias、版本更新與已授權 fallback，再附 ID 向供應商申訴。這是交付契約問題，仍非底層權重鑑定。
2. 可疑：metadata 一致，但盲評、工具呼叫或上下文表現反覆偏離原廠對照，且設定、模板與時間差已記錄。先將受影響任務切到另一條已驗收路徑，保留未剪輯樣本，要求供應商解釋。
3. 無法判定：只有單張截圖、模型自稱或少量答案差異；又或者收據缺失、對照端點版本不明。結論寫「目前證據不足」，補收據與重複試跑。

完整示意：一句「我是舊版」該怎麼追？

假設你請求模型 A，回答卻寫「我是模型 B」。第一格先查送出的 model 與候補模型名單；第二格查回應 model 與 generation 收據；第三格才用預先寫好的題集比對原廠端點。如果回應 model 其實是 B，且你的設定允許 models fallback，應查為何觸發替代；如果不允許卻持續記 B，保存 request ID 詢問供應商。若 metadata 都寫 A，只剩自稱 B，則記為低等級線索，繼續看能力契約。這是一個判讀路徑示意，沒有替任何真實供應商做測試。

把查核結果寫成一頁事件卡：UTC 時間 → request ID → 請求路由 → 回應 model/provider → 題集版本 → 重複結果 → 判定等級 → 下一動作。和Shadow Eval 回歸診斷共用題庫很方便，但兩者回答不同問題：前者追「交付宣稱是否可核對」，後者追「產品今天是否比基準退步」。

模型身分查核常見問題 FAQ

模型自稱另一款，就能公開指控換模嗎？

不能。那是輸出文字。先保存請求、回應、收據與路由設定，再讓供應商有機會核對 request ID。

回應的 model 欄位能證明底層權重嗎？

不能單獨證明。它是平台交付紀錄的一部分，能用來查宣稱與收據是否一致；可信程度仍取決於平台與上游紀錄。

system_fingerprint 一樣就代表同一款嗎？

不代表。官方把它定義為後端設定的訊號，應放在同一 API 的重現性分析裡解讀，不要把它當跨供應商的權重序號。

延遲突然變快，是偷換小模型嗎？

不一定。排隊、快取、輸出長度、網路與服務容量都會改變耗時。先看相同條件下的分布和收據。

長上下文測試失敗，等於模型是假貨嗎？

不一定。路由、endpoint 上限、截斷與請求格式也可能造成失敗。這先是能力契約問題，再追根因。

用很多題就能確證模型權重嗎？

仍不足以把黑箱輸出當成權重證書。更多配對題能提高對服務表現的信心；遇到有意對抗的供應商，有限題集仍有盲點。

什麼時候應該切換供應商？

當你的必要任務穩定過不了驗收，或明確路由契約反覆不符時。先把新路徑跑過相同測試，再切流量，避免把一個未知問題換成另一個。

申訴要附哪些東西？

附可重做的最小事件包。包含 UTC 時間、request/generation ID、去識別化請求、完整回應、設定、收據、題集版本與判定理由；金鑰與個資留在自己手裡。

給新手的三個重點

• 名字先看收據：模型自稱是線索；請求與平台回應才能核對交付宣稱。
• 表現要做配對：同題同設定、重複試跑，再看任務通過率與原始樣本。
• 結論要有級別：契約違反、可疑、無法判定分開寫；不要從服務異常跳到權重指控。