API 轉接站是什麼：工作原理、常見風險與選擇清單

一次請求在轉接站裡走過的路

先把名詞說清楚。所謂「轉接 API」，是指在你的程式和真正跑模型的後端之間，多放一個對外暴露標準端點的閘道器。你的程式仍然按 OpenAI 的格式發請求，只是把 base_url 指向閘道器位址，把金鑰換成閘道器發給你的那一把。

閘道器在這一跳裡通常做三件事。

• 請求轉發：校驗請求體格式，必要時補全預設參數，再把請求交給後端；後端返回的內容（包括串流輸出的 SSE 分片）原樣或輕度加工後回傳給你。
• 金鑰映射：你持有的是閘道器簽發的金鑰，它只在閘道器裡有意義。閘道器據此識別你是誰、餘額多少、能呼叫哪些模型；真正與後端打交道的憑證始終留在閘道器內部，不會出現在你的程式裡。
• 計費與限流：每個請求返回後，閘道器按 usage 裡的輸入、輸出 token 數乘以單價扣減餘額，同時按金鑰統計每分鐘請求數，超出就返回 429。

把這三件事串起來看，就能理解為什麼轉接站的體驗差異很大：轉發層的實現決定了延遲抖動和串流是否穩定，金鑰層決定了洩漏後的損失範圍，計費層決定了帳單是否透明可對帳。

和單一模型直連服務有什麼區別

直連服務指的是你直接向模型提供方的官方域名發請求，通常一個帳號對應一套模型、一套計費規則、一份文件。轉接服務則有兩種常見形態，區別在於「後面接了多少東西」。

維度	直連單一服務	聚合型轉接	單模型轉接
模型數量	提供方自家的幾個	幾十個甚至上百個	一個
端點格式	各家自有格式	統一成 OpenAI 相容	OpenAI 相容
除錯難度	最低，鏈路最短	最高，模型名映射多	較低，只有一個模型
適合場景	只用一家的穩定業務	需要頻繁換模型對比	固定模型、追求可預期

如果你的業務只依賴一個模型，聚合的好處就用不上，反而要承擔「模型名對應到誰」的不確定性。反過來，如果你每週都要換模型做對比測試，聚合型會省掉很多適配工作。沒有絕對的優劣，關鍵是搞清楚自己屬於哪一類。

本站屬於最後一種：只提供一個模型，模型 id 為 uncensored，端點是 OpenAI 相容的對話補全。這類取捨和成本的討論，可以接著看 無限制 AI API 的成本與權衡。

三類最常見的风险

金鑰安全

轉接金鑰等同於一張預付額度的儲值卡，誰拿到就能花你的餘額。常見的洩漏路徑有：把金鑰寫進前端程式碼、提交到公開倉庫、貼進工單或群聊截圖。建議只放在伺服器端環境變數裡，前端永遠透過你自己的後端轉一次；懷疑洩漏時立刻重置，舊金鑰應當馬上失效。同時留意服務是否允許你自助重置，以及重置後舊金鑰是否即時作廢，而不是「過幾個小時才生效」。

模型被替換

這是聚合型服務裡被討論最多的問題：你請求的是 A，實際返回的卻是更便宜的 B。它很難靠文件判斷，只能靠行為驗證。可以固定一組帶標準答案的小題、固定 temperature 反覆測試，觀察輸出風格是否穩定；也可以請求 /v1/models 看清單是否與計費頁一致。模型名稱含糊、同一個名字不同時間表現差異很大，都值得警惕。

限速不透明

有些服務在文件裡只寫「合理使用」，實際在高峰期悄悄降速或直接丟請求，你的程式表現為偶發逾時。成熟的做法是把每個金鑰的每分鐘請求數寫明，超限時返回規範的 429，而不是讓連線掛起。選型時務必問清：限流按金鑰還是按帳號，超限返回什麼，餘額用完是否返回獨立的錯誤碼。

選擇中轉服務的檢查清單

下面這份清單可以直接複製到你的評估文件裡，逐項打勾。

1. 是否提供公開的 GET /v1/models，返回的模型清單與定價頁一致？
2. 錯誤回應是否是結構化 JSON，包含 code 與 message，並且 401、402、429、503 各有區分？
3. 每個金鑰的每分鐘請求上限是否寫在文件裡，而不是只在客服口中？
4. 上下文長度、單次最大輸出 token、請求體大小是否有明確數字？
5. 計費是否按 usage 裡的 token 數精確扣減，餘額是否可隨時查看？
6. 預付費餘額是否會過期？試用額度的有效期是否寫清？
7. 金鑰是否可自助重置，舊金鑰是否即時失效？
8. 是否支援串流輸出，最後是否帶有 usage 統計，方便你自己對帳？
9. 關於提示詞是否用於訓練，是否有明確的一句話說明？
10. 不支援的能力（例如向量、圖像、語音）是否如實標註，而不是含糊其辭？

滿分並不現實，但前五項裡只要有兩項答不上來，就建議先小額試用，不要一次充大額餘額。

拿到金鑰後的十分鐘驗證

不管選哪家，上線前都值得花十分鐘做最基礎的驗證。第一步，列出模型清單，確認返回的 id 和你預期一致：

复制curl -s https://api.llmzhongzhuan.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

第二步，發一個小請求，同時觀察回應裡的 usage 欄位是否存在、數量是否合理。下面的例子故意讓模型複述日期，用來觀察它是否會編造它無從得知的資訊，這是一個粗略的行為檢查，不是嚴格評測：

复制curl -s https://api.llmzhongzhuan.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "用一句话介绍你自己，然后复述今天的日期是几号。"}],
    "max_tokens": 200
  }' 

把這兩步寫進你的部署腳本裡，每次換金鑰或換服務時跑一遍。如果回應裡沒有 usage，或者 usage 的數字與輸入長度明顯對不上，就說明計費透明度有問題，需要在大額使用前先弄清楚。想了解如何在各類框架裡接入，可以看 框架配置指南。

本站的參數，便於你對照清單

這裡把本站的實際參數列出來，便於你拿上面的清單逐項核對，不用來回翻文件。

• 介面地址：https://api.llmzhongzhuan.com/v1，支援 POST /v1/chat/completions 與 GET /v1/models，鑑權使用 Bearer 金鑰。
• 只有一個模型，id 為 uncensored；僅限文字，沒有向量、圖像、語音、影片和微調。
• 上下文共 100,000 token（輸入加輸出），max_tokens 預設 2048、單次最高 32,000；請求體不超過 8 MB。
• 每個金鑰每分鐘 300 次請求，超限返回 429；503 的 upstream_busy 表示稍後重試即可；餘額用完或試用過期返回 402 的 no_credit。
• 價格為輸入每百萬 token 0.25 美元、輸出每百萬 token 1.00 美元，預付費儲值，無訂閱，餘額不會過期。
• 提示詞不會被用於訓練。

具體數字以 定價頁 和 文件 為準。新帳號有 0.50 美元試用額度，有效期 7 天，註冊不需要填寫支付資訊，可以先用它走完上面的驗證流程。