企業如何降低 LLM API 成本？Switchyard + AI Gateway 成本優化實踐

單次請求可能觸發多次模型呼叫，真正的浪費往往不在模型單價，而在錯誤路由、重複上下文、失敗重試與沒有成本歸屬。 因此，企業要落實 Switchyard AI Gateway 成本優化，應先拆分請求類型和品質門檻，再依序建立模型分層路由、上下文壓縮、快取、預算限額與異常檢測；Switchyard 用來做路由實驗，AI Gateway 則負責統一治理、記錄和核算。

最後更新於 2026 年 8 月 13 日；路由能力、快取行為與計費規則已核對 Switchyard 官方文件及模型供應商官方文件。

這篇文章適合三類讀者：需要為不同業務設定模型預算的平台工程團隊、正在核算 Agent 與多模型應用成本的技術負責人，以及準備部署路由實驗與用量監控環境的企業。

先拆解成本為甚麼會被放大

LLM API 成本持續上升時，直接把所有請求換成低價模型，通常只能處理「單價」這一層，卻不一定降低總支出。企業應先把一次業務請求拆成以下成本公式：

總成本 = 請求數 × 每次實際模型呼叫數 ×（輸入用量成本 + 輸出用量成本）+ 快取失效、重試與治理成本

其中至少有五個容易被忽略的放大點：

成本放大來源	常見表現	應追蹤的欄位
模型錯配	摘要、分類等低難度工作也使用高階模型	任務類型、模型、品質分數
上下文重複	系統提示、歷史訊息、工具結果每次完整重送	輸入用量、重複區塊、提示版本
快取缺失	相同規則文件或工具定義反覆計費	快取命中、失效原因、資料時效
重試與回退	逾時、限流、無效輸出後重複呼叫	重試次數、錯誤類型、回退模型
預算失控	團隊共用金鑰，無法確認哪個功能消耗最多	租戶、專案、環境、請求 ID

還有一個權限問題：如果 AI Gateway 只記錄模型名稱和總用量，財務或平台團隊仍然不知道成本屬於哪個產品功能；如果快取只用完整提示作為鍵，又沒有加入租戶與權限範圍，則可能把一個專案的結果錯誤地重用到另一個專案。

第一步：先建立請求分類與品質門檻

模型路由不應從「最便宜的模型」開始，而應從「哪些任務可以接受較低品質」開始。可將請求分為四層：

請求層級	典型任務	路由原則	失敗時的處理
低風險、格式固定	標籤、欄位抽取、簡短分類	優先使用低成本模型	格式錯誤時重試一次或升級
一般生成	摘要、客服草稿、內部搜尋回答	依長度、工具需求和語言路由	低信心時升級
複雜推理	多步分析、程式碼審查、規則衝突判斷	使用較強模型或專用路由	禁止無條件降級
高風險任務	合約、金融、醫療或外部發布內容	先通過權限與品質門檻	人工審核或固定強模型

Switchyard 官方文件列出的路由策略包括固定或隨機路由、分類器路由、階段式路由及自訂路由；其架構也把請求正規化、路由、執行、回傳分開處理。這代表它適合拿來驗證「哪一類請求可以交給哪一層模型」，但不代表分類器可以直接取代品質評估。Switchyard 官方功能與路由說明 (github.com)

實施時，平台團隊應先抽取一批已完成的真實請求，為每筆資料標記任務類型、可接受輸出、是否需要工具及人工評分，再比較固定模型與分類路由的結果。若錯誤路由集中在某些長度、語言或工具場景，應先修正分類條件，不要只調低路由門檻。

第二步：把上下文預算放進請求設計

無效上下文是 LLM API 成本中最常見、也最容易在應用程式內被忽略的部分。一次 Agent 請求可能同時包含系統提示、完整歷史對話、檢索內容、工具定義、工具回傳及中間推理；其中不少內容對當前任務已經沒有作用。

較穩妥的處理順序如下：

1. 將長期規則與本輪任務分開，不要每次重新拼接整份說明文件。
2. 對歷史對話保存摘要與關鍵決策，而不是無條件保留全部原文。
3. 對檢索結果設定欄位白名單，只傳入回答所需欄位。
4. 對工具結果設定大小上限，超出後先轉成結構化摘要。
5. 為每種請求設定輸入上下文預算，超出時改走壓縮流程或要求使用者縮小範圍。
6. 保留審計所需的原始資料索引，但不必把全部原文再次送進模型。

快取不能替代上下文治理。官方文件顯示，部分模型的提示快取會依可重用前綴運作，並在回應用量中提供快取用量欄位；另一類模型則要求快取區塊完全一致，且快取有明確的存活時間與最小長度條件。提示快取與用量欄位說明 (openai.com) 提示快取的匹配與隔離規則 (platform.claude.com)

因此，應用程式必須記錄快取命中與失效原因，而不是只看輸入用量總數。若提示版本、動態工具結果或權限資訊每次都放在可快取前綴之前，命中率自然會下降；若把不應共享的租戶資料放進共用鍵，則成本問題會變成資料治理問題。

第三步：設計不會跨租戶污染的快取

適合快取的內容通常符合三個條件：結果具備高確定性、內容更新頻率較低，而且業務允許在指定時間內重用。常見例子包括工具定義、產品規則、固定格式指示、低頻更新的知識片段，以及經過權限檢查的中間結果。

快取鍵至少應包含以下欄位：

快取鍵元素	目的	缺少時的風險
模型與供應商端點	確保不同能力不共用結果	輸出品質或格式不一致
提示版本	讓規則變更後自然失效	舊提示繼續產生結果
租戶與權限範圍	防止不同團隊互相讀取	跨租戶資料外洩
資料時間戳	控制內容新鮮度	以舊資料回答新問題
工具與結構版本	確保輸出仍符合目前介面	解析器或工具呼叫失敗

對近似問題採用語意快取時要更保守，因為「相似」不等於「可互換」。涉及權限、即時庫存、客戶個人資料或交易狀態的請求，不應只因文字相似便重用答案。

第四步：限制失敗重試與回退放大

失敗重試常常不會出現在一般成本報表內，因為業務方看到的只是一次成功回應，但後端可能已經呼叫了數個模型。常見放大路徑包括：

錯誤類型	不建議的做法	較穩妥的治理方式
逾時	立即無限重試	設定有限次數、退避和總時限
限流	同一端點持續重送	切換健康端點並記錄回退
網路錯誤	把所有錯誤當成可重試	依狀態碼和錯誤類型分類
無效輸出	重送完全相同提示	修正格式約束或升級模型
工具失敗	模型與工具來回循環	設定工具呼叫上限與熔斷

最重要的指標不是「平均每次 API 呼叫成本」，而是「每個業務請求實際觸發了多少次模型呼叫」。AI Gateway 應將原始請求 ID貫穿主請求、重試、回退與工具呼叫，並同時記錄總延遲、輸入輸出用量、錯誤原因和最後使用的模型。

在路由配置中，回退也必須有條件。例如限流可以切換到另一個可接受端點，但高風險任務不應因成本限制而自動切換到未驗證模型；無效 JSON 可以先進行一次格式修復，但連續失敗後應停止，而不是讓 Agent 繼續消耗用量。

第五步：在 AI Gateway 建立預算與成本歸屬

AI Gateway 的價值不只是把多個供應商包裝成一個介面，更重要的是將身份、權限、用量、限流、快取和模型政策集中管理。現有 Gateway 文件普遍把專案級成本追蹤、預算和速率限制列為核心治理能力；實際欄位與限制方式仍應以部署版本的官方文件為準。Gateway 成本追蹤與專案預算功能說明 (docs.litellm.ai)

建議採用三層預算：

• 告警預算：接近上限時通知平台、財務和產品負責人。
• 控制預算：超過門檻後限制高階模型、降低並行度或要求審批。
• 硬性預算：超過上限後停止非必要請求，僅保留關鍵業務路由。

每筆成本紀錄至少要對應租戶、專案、環境、功能、模型、提示版本、請求 ID、輸入用量、輸出用量、快取狀態、重試次數和最終結果。只有這樣，平台團隊才可以回答「哪個產品最花錢」、「哪種錯誤造成最多重試」以及「低價模型是否真的維持了品質」。

需要部署隔離測試環境時，可先參考 nuvcloud 控制中心 的環境管理方式；若團隊要估算不同 Mac 算力方案的測試成本，也可對照 Mac mini 方案價格，但不要把隔離環境成本和 LLM API 帳單混在同一個專案中。

第六步：用品質護欄驗證模型降級

模型降級只有在品質門檻明確時才有意義。若企業只比較單價，可能把失敗率、人工修正、重試和客訴成本排除在外，最後出現 API 帳單下降、業務總成本上升的情況。

驗證集不需要一開始就很大，但必須覆蓋最容易出錯的案例，包括長上下文、罕見語言、格式嚴格、工具回傳不完整、敏感內容及需要多步推理的請求。每次路由變更至少檢查：

• 任務成功率是否維持在產品要求內；
• 結構化輸出是否能被下游程式正確解析；
• 工具呼叫是否出現錯誤循環；
• 低信心請求是否能正確升級；
• 平均延遲與尾端延遲是否惡化；
• 重試、人工修正和人工審核是否增加。

模型供應商的最新模型指南也提醒，評估模型時不能只看呼叫數下降，還要同時比較任務完成、輸出完整度、總用量、延遲與成本。模型選擇與評估指引 (developers.openai.com)

上線前的可勾選檢查清單

• [ ] 已按照任務難度、風險、工具需求和品質門檻分類請求。
• [ ] 已記錄至少一段連續實際流量，並將請求 ID 與模型用量關聯。
• [ ] 已區分輸入用量、輸出用量、快取命中、快取寫入和重試用量。
• [ ] 已為每個專案、環境和功能設定預算告警。
• [ ] 已在 Switchyard 路由實驗中使用驗證集檢查錯誤路由。
• [ ] 已為逾時、限流、網路錯誤和無效輸出設定不同重試政策。
• [ ] 已為快取鍵加入模型、提示版本、租戶、權限和資料時效。
• [ ] 已設定低信心、敏感任務和輸出格式錯誤的升級條件。
• [ ] 已將成本、品質、延遲和失敗率一起納入上線驗收。
• [ ] 已安排回滾方式，能在路由異常時返回固定模型。

建議的落地順序：先看清楚，再開始省

企業不宜一開始就上線動態模型路由。較安全的順序是：

1. 先做可觀測性與成本歸屬：確認每個業務請求究竟呼叫了哪些模型。
2. 再減少無效上下文：處理歷史訊息、檢索內容、工具輸出和提示版本。
3. 接著控制重試與回退：把一次請求的最大模型呼叫數限制在可解釋範圍。
4. 然後加入快取：先從權限清晰、內容穩定的區塊開始。
5. 最後才上線動態路由：以驗證集和小流量逐步放大，並保留固定路由作為回退。

這個順序的重點，是避免把「低價模型」誤認成「低總成本」。若沒有請求級資料，企業不知道浪費來自哪裡；若沒有品質驗收，企業也不知道節省是否由失敗轉換而來。

常見問題

企業的 LLM API 帳單為甚麼會在沒有明顯流量增長時上升？

常見原因不是單價變高，而是每次業務請求觸發了更多模型呼叫，例如工具失敗後重試、Agent 重複帶入歷史內容、回退模型再次生成，或高階模型被用於低難度任務。治理時應把業務請求 ID、模型、輸入輸出用量及重試次數放在同一筆紀錄中，才可看見真正的成本放大位置。

Switchyard 可以怎樣按請求選擇不同模型？

Switchyard 可按照固定權重、請求訊號、分類器或階段式路由選擇後端，並支援將不同模型端點包裝成對外路由。企業不應直接相信分類器結果，應先用已標註的驗證集檢查錯誤路由，再設定低信心回退、關鍵任務升級和異常流量的保護條件。

AI Gateway 應如何設定每個專案的預算？

預算不應只按 API 金鑰切分，較可追蹤的做法是同時記錄租戶、專案、環境、功能、模型和請求 ID。先設定月度軟性告警，再設定硬性限制或降級路由；測試環境與正式環境必須分開計算，否則團隊很難判斷成本究竟來自開發試驗還是實際業務流量。

啟用快取真的可以降低大模型 API 用量嗎？

快取只能降低可重用內容的重新計費或重新處理成本，不能取代輸入裁剪。適合快取的通常是穩定的系統提示、工具定義、規則文件或低頻更新的檢索內容；快取鍵仍要包含模型、提示版本、權限範圍和資料時效，否則可能造成舊資料回答或跨租戶資料外洩。

模型降級後，企業如何確保回答品質沒有失控？

先為關鍵任務建立小型驗證集，明確定義結構正確、引用完整、工具呼叫成功及人工可接受等驗收條件，再讓低成本模型承擔通過測試的任務。若出現格式錯誤、低信心、敏感內容或工具失敗，應升級到較強模型，而不是用隨機回退掩蓋品質問題。

如果目前方案是讓每個產品直接連接不同模型供應商，常見缺點是 API 金鑰分散、預算無法按專案歸屬、重試邏輯散落在各個程式庫，而且路由變更往往需要重新部署應用程式。相較之下，將 Switchyard 放在路由實驗層、把 AI Gateway 放在治理層，能先在隔離環境回放真實流量，再決定是否遷入正式系統。若需要短期測試路由、快取和預算政策，使用獨立的 Mac 算力環境通常比直接改動生產伺服器更容易控制風險；可先了解 nuvcloud 的支援與操作說明，再按實驗週期選擇合適方案。

常見問題

企業的 LLM API 帳單為甚麼會在沒有明顯流量增長時上升？

常見原因不是單價變高，而是每次業務請求觸發了更多模型呼叫，例如工具失敗後重試、Agent 重複帶入歷史內容、回退模型再次生成，或高階模型被用於低難度任務。治理時應把業務請求 ID、模型、輸入輸出用量及重試次數放在同一筆紀錄中，才可看見真正的成本放大位置。

Switchyard 可以怎樣按請求選擇不同模型？

Switchyard 可按照固定權重、請求訊號、分類器或階段式路由選擇後端，並支援將不同模型端點包裝成對外路由。企業不應直接相信分類器結果，應先用已標註的驗證集檢查錯誤路由，再設定低信心回退、關鍵任務升級和異常流量的保護條件。

AI Gateway 應如何設定每個專案的預算？

預算不應只按 API 金鑰切分，較可追蹤的做法是同時記錄租戶、專案、環境、功能、模型和請求 ID。先設定月度軟性告警，再設定硬性限制或降級路由；測試環境與正式環境必須分開計算，否則團隊很難判斷成本究竟來自開發試驗還是實際業務流量。

啟用快取真的可以降低大模型 API 用量嗎？

快取只能降低可重用內容的重新計費或重新處理成本，不能取代輸入裁剪。適合快取的通常是穩定的系統提示、工具定義、規則文件或低頻更新的檢索內容；快取鍵仍要包含模型、提示版本、權限範圍和資料時效，否則可能造成舊資料回答或跨租戶資料外洩。

模型降級後，企業如何確保回答品質沒有失控？

先為關鍵任務建立小型驗證集，明確定義結構正確、引用完整、工具呼叫成功及人工可接受等驗收條件，再讓低成本模型承擔通過測試的任務。若出現格式錯誤、低信心、敏感內容或工具失敗，應升級到較強模型，而不是用隨機回退掩蓋品質問題。