HopBase
先說答案:驗證一個 API 渠道有沒有偷換模型、有沒有降智,靠三類可復現的檢查——成本結構類(prompt cache 的命中行為偽造不了)、行為邊界類(模型族的硬邊界在偽裝時會露餡)、質量盲測類(固定任務集、足夠樣本量的對照)。任何供應商如果不歡迎你跑這些檢查,這本身就是答案。
企業選 AI 中轉/聚合渠道最大的焦慮是三件事:模型是不是真的、有沒有被降智、數據去了哪。市面上的回應幾乎全是口頭承諾——「不路由不降智不偷換」。承諾不可驗證,方法才可驗證。我們做上游供應鏈審計兩年,把內部用的檢測思路整理成這篇公開方法,你可以拿它驗證任何渠道,包括我們。
第 0 步:忘掉「你是什麼模型」
最常見的驗證方式是問模型「你是誰」,這毫無意義:一條系統提示就能讓任何模型自稱任何名字。身份要用行為驗證,不能用自我聲明驗證。
檢查一:prompt cache 的成本結構(最難偽造)
Claude、GPT 系的 prompt cache 有官方定義的計費結構:緩存寫入有溢價、緩存讀取是折扣價,且 usage 欄位裡 cache_read_input_tokens 可見。這構成一個天然的測謊儀:
- 用同一個長系統提示連續請求,第二次起應出現穩定的 cache 命中(讀 token 佔比高、首字更快);
- 拼池、隨機路由的渠道,命中率會顯著低甚至為 0;
- 命中率背後是真金白銀的成本差,長期偽造等於渠道自己賠錢,經濟上不成立。
檢查二:模型族的硬邊界
每個模型族有改不掉的行為邊界,偽裝者會在邊界處露餡:上下文窗口的真實上限、tokenizer 差異(同一段文本的 token 計數對照 usage 數字)、參數支持面(不支持的參數是報錯還是靜默忽略)、停止序列與流式分塊的細節習慣。單項不構成證據,多項組合的指紋很難全部偽造。
檢查三:注入痕跡
部分渠道會在你的系統提示前後注入自己的指令。檢測思路是行為對照:同一組請求分別打到官方直連與被測渠道,比較模型對系統提示的服從細節。我們審計中見過從單行偽裝到 4KB 大段注入的各種形態,它們在對照測試下都會顯形。
檢查四:降智盲測(樣本量是關鍵)
「感覺變笨了」不是證據。可信的做法:固定 20-50 個有標準答案的任務,官方與渠道各跑一遍,比通過率;溫度設 0 降低方差;隔週復測,防止時段性把戲。通過率差距持續超過噪聲區間,才能下結論。
檢查五:工程質量面
看首字延遲的分佈而不是均值(P95 抖動大=鏈路不穩)、長輸出的斷流率(流式中途靜默截斷是最惡劣的故障形態)、上游錯誤碼是否透傳(把 429/529 吞掉改成超時的渠道,會毀掉你的重試邏輯)。
為什麼我們敢公開這套方法
因為 HopBase 自己就是這麼選上游的——每個通道接入前都過這套審計,不合格的直接否決。我們的定價頁把每條通道的屬性寫得明明白白:Claude Max、AWS Bedrock、Kiro,各是什麼渠道、什麼倍率,全部公開。透明的通道屬性 + 可復現的驗證方法,比一百句「絕不偷換」有說服力。歡迎拿這篇文章裡的每一項檢查來測我們。