想把AI接進網站，第一個問題往往不是程式怎麼寫，而是「這麼多API網站，究竟要選哪一家？」

有的平台讓你用同一個帳戶切換模型；有的幫你記錄呼叫、限制用量；還有的只提供軟體，需要自己架設。它們都可能叫AI Gateway，但你買到的服務、要負責的工作並不相同。

對第一次接觸的人，選型順序可以很簡單：先決定要完成什麼工作，再找能做這件事的服務，最後用自己的測試材料檢查結果與費用。

下面先解釋基本名詞，再比較六種候選，最後用一次真正的訂單資料擷取測試，把「網站寫支援」和「這次確實完成」的差別說清楚。

1. 先弄懂：API網站、模型和聊天會員差在哪裡

API是讓程式使用服務的入口

你在聊天網站輸入問題，是人透過畫面操作；網站後端透過API發送問題，則是程式在操作。

假設要做一個「貼上訂單文字，自動整理成表格」的小工具，流程就是：

使用者貼上訂單
→ 你的程式把文字送到API
→ 模型擷取訂單編號、金額與幣別
→ 程式檢查資料
→ 顯示結果，或交由使用者確認後儲存

因此，購買API額度不代表自動獲得完整應用，也不一定包含原廠聊天會員的權益。只想在網頁聊天的人，應先比較聊天工具；需要讓自己的程式處理資料，才進一步比較API。

模型負責回答，API服務負責讓你接入

同一個模型可能透過不同服務呼叫。比較時要分開看兩件事：

• 模型是否做得好：有沒有漏欄位、看錯金額、補出原文沒有的內容。
• 接入服務是否適合：帳戶能不能用這個模型、請求是否有紀錄、出錯能否追查、費用是否看得懂。

換了網站又換了模型，即使結果變好，也不能直接判定是網站比較好。比較條件要記清楚。

BYOK與自建，也不是同一件事

BYOK是Bring Your Own Key，意思是把自己已有的模型提供者金鑰交給閘道使用。閘道是否另收費、失敗時是否改走平台的其他憑證，仍須查看方案。

自建則是把閘道軟體部署到自己的伺服器。這代表要自己管理軟體，不代表模型推理也在公司內部。如果自建閘道仍向外部模型發送資料，資料就仍然會離開內網。

2. 六種API服務，分別適合解決什麼問題

下表根據各家的官方文件整理用途，不是效能排名。「值得評估」也不表示所有帳戶、模型或方案都具有相同能力。

用途示意圖；實際功能與方案條件仍以當下文件和帳戶驗收為準。

2.1 還不知道哪個模型合適：先比較模型，再決定長期入口

例如做客服回覆，真正需要的是「能根據提供的規則回答，不自行承諾退款」。先準備含退款規則、例外情況及缺失資料的材料，再評估OpenRouter、SiliconFlow等候選目錄內的模型。

不要只問一道常識題。常識題答對，不代表模型會遵守你的退費規則。候選模型還應能在資料不足時說明缺口。

2.2 同時需要文字、圖片或影片：先確認完整任務流程

Crazyrouter等多模態入口可以列入候選，但每種任務要分別驗收。

文字通常直接回傳回答；部分媒體任務會先回傳工作編號，之後再查進度。拿到編號只表示已提交，還需要等終態、取得檔案並確認可讀。

本次實測只驗證文字資料擷取，沒有生成圖片或影片。因此不能把文字測試成功延伸成多模態品質或速度的保證。

2.3 已有Web應用：優先檢查目前工具鏈是否順手

若現有專案使用AI SDK，可以先評估Vercel AI Gateway與既有流程的搭配。要測的不是只有「能顯示一句話」，還包括串流中斷、錯誤顯示、使用量紀錄與重試。

若不熟悉伺服器維運，先完成託管API的小型驗證，比立刻建一套自管閘道更容易釐清需求。這是導入順序的建議，不是對任何產品品質下結論。

2.4 想看清花費，或必須自主管理：再考慮控制層

Cloudflare AI Gateway可作為觀測與控制的候選；LiteLLM Proxy則適合需要自己部署和管理的人。

例如公司有不同部門使用模型，需要知道哪個專案產生費用。除了總餘額，還要確認能否把呼叫歸到部門、專案或金鑰，並驗證撤銷金鑰後是否真的不能繼續呼叫。

3. 實際測一次：把訂單文字整理成可檢查的資料

以下是2026-10-08透過Crazyrouter執行的真實API請求。輸入使用虛構訂單，沒有真實客戶資料。

測試目的不是選出最強模型，而是確認一個小工具能否取得完整、正確的欄位。兩個模型各接收相同的兩份材料，共四次請求。

3.1 先查帳戶模型目錄，不從舊文章抄模型名

先前不帶金鑰呼叫模型目錄時，伺服器回傳HTTP401，錯誤為「未提供令牌」。加入有效金鑰後，同一路徑回傳HTTP200，當次目錄包含175個模型識別值。

這裡的175只是此次帳戶查詢結果，不是平台全部模型數量的宣傳數字，也不表示每一個都已經呼叫成功。

此次從目錄選出gpt-4o-mini與qwen-turbo進行測試。只驗證這兩個，不把目錄中的其他名稱標為已測。

3.2 測試環境與合格條件

temperature是生成設定，設為0不代表所有環境下都必然得到完全相同的文字。max_tokens是輸出上限，不是固定扣款金額，也不是整次請求的總token數。

3.3 用有資料和缺資料的情況對照

第一份材料：

這是測試用的虛構訂單。訂單編號A-001，商品合計新臺幣1200元。未記載運費。

第二份材料：

這是測試用的虛構訂單。訂單編號B-002，商品合計1200。幣別與運費皆未記載。

為什麼要準備第二份？因為只測「資料齊全」，很容易漏掉模型自行補資料的問題。第二份沒有寫幣別，正確行為是保留未知，而不是因為文章使用繁體中文就猜成新臺幣。

此次要求固定回傳四個欄位：訂單編號、金額、幣別、運費。缺失內容使用null，意思是「未知或未提供」，和數值0不同。

3.4 實際送出的請求內容

下面是第一份材料搭配gpt-4o-mini的請求本文。測第二個模型時只改model；測缺失資料時換成第二份材料。

{
  "model": "gpt-4o-mini",
  "messages": [
    {
      "role": "system",
      "content": "你是資料擷取程式。只輸出一個JSON物件，不要Markdown。欄位為order_id、total、currency、shipping_fee。只根據原文擷取：total必須是數值或null；currency僅在原文明確提供時填ISO幣別字串，否則null；shipping_fee未提供時必須null，不可猜測或填0。不得加入其他欄位。"
    },
    {
      "role": "user",
      "content": "這是測試用的虛構訂單。訂單編號A-001，商品合計新臺幣1200元。未記載運費。"
    }
  ],
  "temperature": 0,
  "max_tokens": 160,
  "response_format": {
    "type": "json_object"
  }
}

不熟悉程式的人可以先讀這段：system放處理規則，user放本次材料，model決定呼叫哪個模型。

JSON物件模式並不等於嚴格的欄位驗證。本次除了解析JSON，還另外檢查四個欄位和值是否與預期一致，避免把「格式看起來對」當成「資料確實對」。

3.5 四次請求實際回傳了什麼

四次請求皆為HTTP200，finish_reason皆為stop。訂單編號與金額也都符合預期。A-001的實際輸出為：

{
  "order_id": "A-001",
  "total": 1200,
  "currency": "TWD",
  "shipping_fee": null
}

B-002的實際輸出為：

{
  "order_id": "B-002",
  "total": 1200,
  "currency": null,
  "shipping_fee": null
}

第一筆請求的回應ID為chatcmpl-EWYYY8M7ZdaJz7hc88eBfKmXurTcU，回傳模型識別值為gpt-4o-mini-2024-07-18。應保留這類回應ID，日後才能把問題對應到同一次呼叫。它不是影片任務ID；這次是直接回傳文字的同步請求，沒有輸出檔案網址。

表中的耗時是本機從啟動請求到取得完整回應的時間，包含網路與程式啟動等成本，不是模型單純生成時間。樣本只有四次，不能據此宣稱qwen-turbo長期更快，也不能推出Crazyrouter比其他平台更穩。

這次能確認的是：在這個帳戶、入口和測試時間，兩個模型都完成了這兩份簡單材料的擷取，並且沒有替缺失的幣別和運費亂填值。

3.6 接到真正的應用前，還要補什麼

如果接下來要用在收據整理，應再加入金額有千分位、不同幣別、正文互相矛盾或欄位缺失等材料。

程式也不能拿到JSON就直接寫入帳務。至少先檢查金額是否為數值、訂單編號是否一致，以及未知欄位是否仍需人工補齊。此次小測試驗證的是接入與簡單資料擷取，不是完整的財務系統。

4. 比價格時，先看同一種計費單位

4.1 輸入與輸出，可能是不同單價

輸入token是模型讀入的內容，輸出token是模型生成的內容。token不是固定的一個中文字，也不是固定的一個英文字。

若價格表採「每百萬token」標示，基本計算方式是：

基本用量費
＝輸入token數÷1,000,000×輸入單價
＋輸出token數÷1,000,000×輸出單價

這只是基本口徑。快取、回退、工具或平台附加能力若有其他計費，還要另外核對。

本次四次回應的total_tokens合計712。這是回應中的用量紀錄，不是已核對的實際扣款；沒有把帳單金額查清楚，就不寫「這次花了多少美元」或「省了多少百分比」。

4.2 有免費額度，也要確認何時失效

Vercel官方Pricing頁面提供一個具體例子：免費層每月有5美元額度，但只覆蓋符合免費層資格的模型；購買額度後，帳戶進入付費層，月度免費額度不再適用。

所以「我先買一點，再把免費額度一起加上去」未必成立。這是文件條件核對，不是本次付款實測。

同一份文件也說明，BYOK請求使用自備憑證失敗後，可能使用系統憑證回退，回退用量會扣平台額度。選型時應先問清楚失敗如何處理，再估算長期費用。

4.3 低單價之外，還要算完成工作的成本

如果便宜模型經常需要人工重做，而另一個模型一次就能交付，單看token單價會失真。但沒有實際資料，也不能反過來說貴的就一定划算。

比較候選時，把同一批材料的通過情況、重試次數、用量和人工修改一起記錄。最有用的問題是「完成這批合格結果付出了什麼」，而不是「首頁哪個價格數字比較小」。

5. 團隊使用前，要測預算、權限和快取

5.1 預算告警與阻擋，是兩種能力

告警只負責通知；阻擋才會拒絕新請求。還要看「正在執行但尚未入帳」的請求如何處理。

舉一個合成算術例子：上限10單位、已用8單位，同時進來兩筆各預估1.5單位的請求。如果兩筆都只看目前已用8，就可能都獲准，最後來到11。

LiteLLM官方文件說明，預算預留會先考慮正在處理的請求成本。文件也提醒，停用預留可能讓並行流量超支；批次工作只提供輸入檔案ID時，無法在提交當下估算全部工作費用。

這不是本次部署LiteLLM得到的測試結果，而是官方機制加上可驗算的例子。真正導入時，應在小額測試專案驗證，而不是只確認後台有預算輸入欄。

5.2 問題一樣，不代表可以共用答案

假設人資與業務都問「出差可以報銷哪些項目」，但能讀到的規章版本與權限不同。若只用問題文字當快取鍵，可能重用不適合另一個人的結果。

快取可以理解成「把曾經算過的結果保存，下次符合條件就直接取出」。Cloudflare的Caching文件說明，快取預設停用；啟用後依完全匹配的請求處理，預設鍵包含提供者、端點、模型、認證及完整請求內容。

這不代表它自動理解公司內部的人員權限。若應用共用上游金鑰，權限差異又沒有反映到送出的內容或快取鍵，就應另外設計隔離條件，或對該類請求停用快取。

5.3 交接要真的做一次撤銷測試

人員退出專案時，能否撤銷他的憑證？撤銷後重發請求會不會被拒絕？其他專案是否繼續運作？

這比在採購表填上「支援團隊」更具體。日常也應指定一個查帳窗口和一個應用維護窗口，避免問題發生時每個人都去問供應商，卻沒有保存同一筆請求的紀錄。

6. 第一次試用，可以照這個順序做

**第一步：寫清楚只做哪件事。**例如「把訂單文字整理成固定欄位」，先不要同時加入聊天、圖片與影片。

**第二步：準備材料與正確答案。**至少涵蓋資料齊全和資料缺失，明確規定未知欄位要怎麼處理。不要一開始就上傳真實客戶資料。

**第三步：核對帳戶能用的模型。**從當前目錄挑選，而不是照抄舊文章。確認認證成功後，再發送小型請求。

**第四步：保存完整結果。**記錄模型識別值、請求設定、回應ID、結束原因、用量及解析結果。看到HTTP200後仍要檢查內容。

**第五步：才開始比較候選。**同樣的材料、同樣的合格條件，才有比較基礎。若換平台時也換了模型或輸出設定，要將差異記錄下來。

**第六步：擴大前先處理失敗。**斷線時先查是否仍在處理，不要盲目重送；會寫資料的功能還要防止重複建立。權限、預算和支援窗口也在這一步驗收。

7. 新手常問的幾個問題

已經有聊天會員，還需要買API嗎？

要看產品權益，不能預設互通。聊天介面與API通常是不同的使用入口，應確認你的程式需要哪一種。

模型在清單上，就代表一定能成功呼叫嗎？

不代表。目錄確認只是起點，還會受到帳戶權限、路由、服務狀態及請求參數影響。本次175個識別值之中，只實際驗證了兩個模型。

多模型服務可以取代所有官方介面嗎？

不能一概而論。文字聊天相容，不表示圖片、工具呼叫、結構化輸出和每個原生參數都完全相同。應按需要的功能核對。

用自建閘道是不是比較安全、比較便宜？

自建增加控制權，也增加維運工作。安全取決於部署、權限、上游資料路徑和日誌管理；成本還包括伺服器與人力，不能只看軟體是否免費。

這次兩個模型都通過，應該選哪個？

先把它們保留在候選中，再用更接近真實工作的材料驗證。這次只是簡單訂單擷取，沒有足夠證據替長文件、圖片、複雜推理或大流量服務下判斷。

如果今天才開始，先完成一次可檢查的小任務就好。當你能說清楚輸入是什麼、結果為何合格、失敗要去哪裡查，才有依據決定是否增加用量。

資料與利益說明：實際呼叫與官方文件核查日期為2026-10-08；測試環境為Windows、Node.js 24.21.0，四次文字請求依序執行。