LLM 成本在上線後暴增，是因為正式流量改變了每個請求帶的 token 數，而能控制它的金鑰、上限與模型限制，仍停留在試行階段的設定。費率表很少變動。本文先試算一次真實的上線後暴增，再逐一說明五個控制缺口會出現的症狀、修法，以及五天內補齊的計畫。
上線後 LLM 成本暴增的試算
一個客服機器人在 claude-sonnet-4-6 上以檢索增強生成（RAG）回答問題；截至 2026 年 10 月，ATP 牌價為每百萬 token 輸入 3 美元、輸出 15 美元。它每天處理 40,000 個請求，每則回答約寫出 400 個輸出 token。
試行期間，平均每個請求帶 2,000 個輸入 token。上線後，使用者把合約與整串郵件貼進對話，檢索也為了回答較長的問題加入更多段落。平均輸入增加到 9,000 token。
每月差額是 25,200 美元，帳單變成 2.75 倍。模型、價格與請求數都沒有改變，任何價格表都不會提醒你。唯一的訊號是每個請求的平均輸入 token，而只有逐次記錄 token，你才看得到它。
缺口 1：共用金鑰，花費沒有主人
症狀：用量頁顯示當月大部分 token 都來自同一把金鑰。三個服務、一個排程工作，還有一位約聘人員的 notebook 都在用它。約聘人員離開時，撤銷這把金鑰會讓正式環境當天下午就中斷，所以沒人動手。
上線後為何更糟：試行期流量小，共用的代價不明顯。上線後任何一個使用者都可能暴衝，而唯一的手段是替所有人關掉這把金鑰。
修法：以專案作為歸屬單位，每個正式系統一個專案、一把自己的金鑰。金鑰只屬於一個專案，並繼承該專案的允許模型與餘額；API 金鑰頁會列出所有工作區與專案中的每把金鑰（管理 API 金鑰）。撤銷的金鑰立即失效，並留在清單中供稽核。
缺口 2：沒有上限，帳單就是警報
症狀：那個跑了整個週末的 staging 工作。一個重試迴圈每秒送出 2 個請求，持續 48 小時：345,600 個請求，每個在 claude-sonnet-4-6 上帶 3,000 個輸入與 300 個輸出 token。每個請求 0.009 + 0.0045 = 0.0135 美元，整個週末花了 4,665.60 美元，週一才被發現。
上線後為何更糟：批次工作、agent 與重試都在無人看管時執行。每個工作負載沒有上限，一條熱路徑就會動用整個組織的餘額。
修法：沿著組織、工作區、專案的層級分配點數，把每個專案的分配額度當成上限。專案只能花被分配到的額度；餘額用完時，請求會回傳 402。若 staging 只分配 50,000 點（500 美元），同一個迴圈約在 37,000 個請求、大約 5 小時後就會停下。步驟見設定有預算上限的團隊。每一層的已分配與已消耗都顯示在用量頁（點數如何運作）。
缺口 3：沒有逐請求紀錄，月帳單無法自我說明
症狀：財務看到機器人從 14,400 美元變成 39,600 美元。工程團隊說什麼都沒變：同一個模型、同一個價格。會議結束時仍找不到原因。
上線後為何更糟：上線同時帶來很多變化：更長的提示、新的檢索設定、重試策略、更多使用者。月總額無法把它們分開。
修法：每次呼叫都記錄專案、金鑰、模型、狀態與輸入／輸出 token。ATP 的請求紀錄正是逐請求顯示這些欄位，可依時間範圍、範圍、模型、狀態與 request ID 篩選（用量與紀錄）。以上面的例子來說，把請求紀錄篩選到機器人的專案，會看到每列約帶 9,000 個輸入 token。對照試行期記下的 2,000，幾分鐘內就能回答問題，前提是有人把試行期的數字記下來。請把「每個專案每個請求的平均輸入 token」當成每週追蹤的數字。
缺口 4：沒有模型白名單，昂貴路徑變成預設
症狀：政策寫著預設用中階模型。接著某位開發者為了處理一則語氣客訴，把機器人換成更強的模型，然後就上線了。
上線後為何更糟：流量會放大模型之間的價差。同樣的上線後流量（每天 40,000 個請求、輸入 9,000 與輸出 400 token），成本差異很大：
修法：每個專案維護一份允許模型清單。清單外的模型請求會在抵達任何供應商之前被以 403 拒絕（運作方式）。GET /v1/models 會列出金鑰可以呼叫的模型。如此一來，更換機器人的模型就成為由管理員在專案上做的變更，而不是一行程式碼的修改。
缺口 5：沒有檢視節奏，問題等到帳單才出現
症狀：兩次帳單之間沒人打開用量頁。為一次性遷移調高的上限一直沒調回來，已結束試行的閒置金鑰仍然有效。
上線後為何更糟：上線前檢查過一次的控制，之後會慢慢偏移：新的金鑰、更寬的白名單、更大的分配額度。
修法：建立輕量、固定的節奏：
活動紀錄會記下登入、邀請、額度變更與資源更新，涵蓋每季檢查的大部分內容。
五個工作天補上五個缺口
第 1 天（週一）：盤點
打開 API 金鑰頁，它會列出所有工作區與專案中的每把金鑰。逐一記下每把金鑰被哪些系統使用、負責人是誰，並標出被多個系統共用的金鑰。
第 2 天（週二）：拆分
為每個正式系統建立一個專案並發新金鑰。先搬花費最高的服務，並替每把共用金鑰訂好撤銷日期。
第 3 天（週三）：分配上限
取每個專案過去 30 天的消耗量，加上預計成長的餘裕，分配為每月上限。以上線後的客服機器人為例，至少是 3,960,000 點。staging 與實驗專案只給小額分配。
第 4 天（週四）：縮小白名單
每個專案只啟用需要的模型。從每個專案呼叫一次不在清單上的模型，確認會得到 403。
第 5 天（週五）：埋點與排程
把每個回應的 x-request-id 標頭，和你自己的功能或租戶 ID 一起記錄。把每週檢視排進行事曆，並完整演練一次金鑰撤銷：撤銷、查紀錄、重新發放。
同一個問題在每一步層級的版本，見什麼是 agent tax。要建立第一個專案與金鑰，請依照快速開始。
