部落格 / 模型觀察

中轉站模型真假怎麼驗證：五項自己能做的一致性檢查

2026-10-18cdnping 編輯部約 7 分鐘讀完

中轉站模型真假，沒有一種方法能百分之百確認：你只能看到請求和響應，響應裡的 model 欄位、錯誤資訊、甚至“你是誰”的回答都可以被中間層改寫。能做的是一致性檢查，把同樣的請求分別發給官方介面和中轉介面，比較 token 計數、上下文邊界、工具呼叫格式、延遲吞吐和固定提示的輸出分佈，幾項都對得上，掉包的可能性就很低；有一項明顯對不上，就值得追問。

#為什麼不能直接問模型“你是誰”？

模型的自我介紹來自訓練資料和系統提示，不是執行時讀取的身份資訊。幾個常見情況：

• 中轉層可以在系統提示裡寫“你是某某模型”，大部分模型會照說。
• 很多模型訓練語料裡混有其他模型的對話，自己會報錯名字。
• 響應 JSON 裡的 model 欄位是服務端填的，中轉層改一個字串就行。

所以“問一句看回答”只能排除特別粗糙的替換。真正有用的訊號來自模型難以偽裝的部分：分詞器、上下文上限、協議細節和推理速度。

#中轉站常見的“不一致”有哪幾種？

先分清楚問題型別，檢查才有方向。讀者遇到的“不像官方”，大致是下面四種，只有第一種是真正的掉包：

第二種情況在開源模型上很普遍，而且不一定是有意為之。cdnping 在 2026-10-17 採集的 OpenRouter 公開資料快照裡（視窗為當天單次採集，資料見 /models），一個 DeepSeek 輕量模型的 id 下有 36 個供應商端點，其中 17 個標註 fp8、3 個 fp4、1 個 mxfp4，另外 15 個沒有標註精度；一個 Kimi 新模型的 id 下有 26 個端點，9 個 fp4、7 個 mxfp4、2 個 fp8、8 個未標註。同一個模型名，背後可能是精度差別很大的部署。量化對輸出的影響和怎麼鎖定精度，可以看模型變笨還是換了供應商：推理供應商與 fp8、fp4 模型量化。

閉源模型的情況不同。同一份快照裡，Anthropic、OpenAI、Google、xAI 的模型端點精度全部是“unknown”，供應商只有官方自己和幾家大雲廠商。閉源模型的權重不對外發布，第三方無法自行部署。中轉站如果聲稱提供某個閉源模型，不管中間轉了幾手，最終的推理只能來自官方或這類授權雲平臺，這一點是檢查的出發點。

#五項一致性檢查怎麼做？

準備工作：拿到一個官方 API Key 作為基準（下面的檢查請求量不大），再拿中轉站的 Key。下面的命令以 OpenAI 相容格式為例，<模型 id> 換成你要驗證的模型名。中轉站的介面地址怎麼配，可參考 Claude Code 自定義 API 與 Codex、OpenCode 介面地址配置。

先寫一個小函式，後面反覆用：

# 用法：ask <BASE_URL> <API_KEY> <JSON 請求體檔案>
ask() {
  curl -s "$1/v1/chat/completions" \
    -H "Authorization: Bearer $2" \
    -H "Content-Type: application/json" \
    -d @"$3"
}

#檢查一：輸入 token 計數對得上嗎？

不同模型家族用不同的分詞器，同一段文字切出來的 token 數不一樣。這是最難偽裝的一項，因為中轉層要偽造就得重新實現目標模型的分詞器。

做法：

1. 準備一段固定文字，最好中英文、程式碼、emoji 混合，長度一千字左右，儲存為 probe.txt。
2. 構造請求體，max_tokens 設為 1，只看輸入計數：

jq -n --arg t "$(cat probe.txt)" --arg m "<模型 id>" \
  '{model:$m, max_tokens:1, messages:[{role:"user",content:$t}]}' > req.json

ask https://官方地址 $OFFICIAL_KEY req.json | jq '.usage.prompt_tokens'
ask https://中轉地址 $RELAY_KEY req.json | jq '.usage.prompt_tokens'

3. 兩個數字應該完全相同或只差幾個 token（訊息模板的固定開銷）。如果中轉返回的數字多出幾十上百，通常是中轉層注入了系統提示；如果差出一個比例（比如多了 20%），很可能分詞器根本不是同一家。

Anthropic 官方還提供不消耗額度的 token 計數介面（Messages API 的 count_tokens），OpenAI 系模型可以用官方開源的 tiktoken 在本地算。注意 usage 欄位本身也可以被改寫，所以要配合下面幾項一起看。

#檢查二：上下文長度的邊界在哪裡？

每個模型有公開的上下文上限。中轉站如果換成了上限更小的模型，或者在中間截斷了長對話，邊界測試能直接測出來。

1. 查官方文件裡該模型的上下文上限。
2. 構造一個接近上限（例如上限的 90%）的輸入，在開頭寫一個隨機字串，最後問“開頭的字串是什麼”。
3. 再構造一個明顯超過上限的輸入。

判斷：官方介面在超限時會返回明確的錯誤；如果中轉對超限請求也能正常回答，說明它悄悄截斷了內容。如果 90% 的請求答不出開頭的字串，說明實際可用上下文比宣稱的小。

#檢查三：工具呼叫的格式和行為一致嗎？

工具呼叫（function calling）的細節各家不同：引數 JSON 的寫法、並行呼叫時一次返回幾個、tool_call 的 id 格式、stop_reason 或 finish_reason 的取值。這些是協議層面的東西，模型換了很容易露出來。

做法：定義兩個簡單工具（例如查天氣、查時間），發一個需要同時呼叫兩者的問題，各跑 5 次，記錄：

• 是否一次返回兩個呼叫，還是分兩輪
• 呼叫 id 的字首和長度
• 結束原因欄位的值
• 引數裡有沒有多餘的欄位或格式錯誤

官方和中轉的結果放在一起對比，結構上的差異比內容差異更說明問題。

#檢查四：延遲和吞吐像不像？

不同模型、不同部署的生成速度有明顯特徵。用流式輸出測兩個數：首 token 時間（TTFT）和每秒輸出 token 數。

# 記錄首位元組時間和總耗時；BASE、KEY 分別換成官方或中轉的地址與 Key
jq '. + {stream:true, max_tokens:500, stream_options:{include_usage:true}}' req.json > stream.json
curl -s -N "$BASE/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @stream.json -o out.txt \
  -w "首位元組 %{time_starttransfer}s 總耗時 %{time_total}s\n"
# 最後一個資料塊裡的 usage.completion_tokens 是輸出 token 數
grep -o '"completion_tokens":[0-9]*' out.txt | tail -1

吞吐大致等於輸出 token 數 ÷（總耗時 − 首位元組時間）。有些服務會先返回響應頭再開始生成，首位元組時間只能近似看作 TTFT。stream_options 是 OpenAI 相容格式的引數，個別中轉可能不支援，這時可以去掉它，改用非流式請求的 usage 來數輸出 token。

TTFT 會受網路影響，中轉多一跳，慢幾百毫秒是正常的，不能單憑這個下結論。連線建立、閘道器往返和首 token 怎麼拆開看，見 AI API 延遲拆解：連線建立、閘道器往返與首 token 時間。更有區分度的是吞吐：網路隻影響開頭，不影響生成過程中的速度。如果中轉的每秒 token 數比官方快很多，反而要懷疑是更小的模型。

網路這一段可以先用 cdnping 的線上測速看一下你本地到各家官方 API 入口的首次連線和往返時間，把網路因素和模型因素分開。

#檢查五：固定提示的輸出分佈一致嗎？

單次回答沒有可比性，但多次回答的分佈有。選幾個有確定答案、又有一定難度的題（例如一道需要多步推理的算術題、一段有固定輸出的程式碼題），temperature 設為 0，各跑 10 次：

• 統計正確率
• 看輸出長度的範圍
• 看措辭習慣，比如是否習慣用列表、開頭是否有固定句式

同一個模型在 temperature 為 0 時輸出通常高度相似（不一定完全一致）。中轉的結果如果正確率明顯偏低、或者風格完全不同，結合前幾項一起看。這一項受量化影響較大，開源模型出現小幅差異不一定是掉包。

#結果怎麼判斷？

經驗上，前三項最可靠，後兩項用來佐證。只要 token 計數和工具呼叫都對得上，基本可以排除換模型；剩下的問題多半是量化、引數或網路。

#檢查完之後還要持續關注什麼？

一次檢查只說明當下。中轉站的上游可能隨時調整，官方模型本身也會更新。幾個低成本的做法：

• 把上面的指令碼儲存下來，每週或每次覺得“變笨”時跑一遍，和第一次的結果對比。
• 在 /models 看開源模型在各推理供應商上的量化精度和可用率變化。同一份 2026-10-17 快照裡，那個 DeepSeek 輕量模型的 36 個端點，過去 24 小時可用率最低約 88.1%，有 4 個低於 90%，22 個為 100%，詳細分析見同一模型換個 OpenRouter 供應商，可用率能差多少。
• 在 /changes 跟蹤官方更新日誌和價格頁。官方換了預設版本，你看到的差異可能來自上游而不是中轉。
• 遇到“突然變笨”，先在 /down 看有沒有其他人報告“變笨了”或故障，再判斷是不是自己的通道有問題。

選中轉站時能提前問清楚的事，比事後檢測更省事：上游是誰、是否注入系統提示、是否做快取、用量怎麼計。完整的檢查清單見 AI API 中轉站怎麼選：可用率、計費、資料政策 8 項檢查，Claude 相關的風險點見 Claude API 中轉靠譜嗎：主要風險與自查方法。

最後提醒一點：透過任何第三方渠道使用模型，都應該遵守上游服務的使用條款和當地法規，這些檢查只用來核實你買到的服務是否名實相符。