AI 專案帳單突然變大時，先別急著全面限制 Token。Google Cloud 8 月 22 日討論的 AI Tokenomics，核心是把模型消耗連回業務結果：同樣花一筆錢，成功完成可採用的客服分流，和產生一堆被人工退回的答案，價值完全不同。
Google 文中提到一個客戶的 AI 支出單月增加超過五成，問題在於團隊無法回答是哪個部門、專案或 Agent 造成。這是 Google Consulting 的客戶案例，不代表普遍平均；但它指出一個常見盲點：Token 帳單告訴你花了多少，沒有告訴你為什麼值得。
Agent 成本為何特別難估
傳統軟體常以席次或固定資源規劃。Agent 的成本會跟著上下文長度、推理模型、重試、子 Agent、搜尋與工具呼叫變動。同一個使用者問題，可能一次完成，也可能反覆規劃、查詢與自我修正。
因此，每百萬 Token 價格只能比較一層原料。Google Cloud 成本最佳化文件從完整 AI 工作負載檢查成本；團隊還應把向量搜尋、資料庫、外部 API、執行環境、監控、評測與人工覆核納入自己的預算。這也是企業 AI ROI 成本衝擊常被低估的原因。
FinOps Foundation也區分 Token 與完整的 AI 單位經濟，不能把 Token 成本直接等同所有 AI 成本。自建模型的固定投入、資料授權與團隊維運仍要算進去。
先追四組欄位
第一組是歸屬：部門、產品、環境、用例與責任人。第二組是執行：模型、輸入與輸出 Token、快取、工具呼叫、重試與延遲。第三組是品質：通過評測、人工退回、錯誤與完成率。第四組是結果：節省時間、完成交易、解決案件或產生可採用內容。
Google 的模型 API 支援自訂中繼資料標籤，可用於成本歸因；帳務權限與資源分組另依 Cloud Billing 指南設定。跨供應商時也可沿用相同欄位，搭配模型路由成本策略比較，而非每家各用一套報表。
最值得看的指標是「每次成功結果成本」：總執行成本除以通過品質門檻的結果數。旁邊再放重試率、人工覆核分鐘與錯誤成本，才能辨認便宜模型是否只是把工作轉嫁給人。
便宜模型真的省錢嗎？用客服分類算一次
假設你要把客服訊息分成退貨、出貨與帳務三類，最後由人員確認再進入工單。下面是自行設定的試算，不是 Google 客戶資料、模型報價或本站實測。兩個方案都處理同一批 1,000 件訊息；每件只有分類正確、格式合格且可直接交接，才算一次成功結果。
| 同一批 1,000 件 | 方案 A | 方案 B |
|---|---|---|
| 模型、工具與重試的合計費用 | NT$300 | NT$500 |
| 可直接採用的件數 | 700 | 900 |
| 需人工處理的件數 | 300 | 100 |
| 假設每件人工處理 2 分鐘 | 600 分鐘 | 200 分鐘 |
| 假設人力每小時 NT$300 | NT$3,000 | NT$1,000 |
| 本批完整處理成本 | NT$3,300 | NT$1,500 |
只看模型端，A 的費用低；但加上返工，B 反而便宜。人力換算是「分鐘 ÷ 60 × 時薪」，所以 A 為 600 ÷ 60 × 300＝3,000 元。表中的人力是本批返工估算，不是裁員後一定能省下的現金；若員工仍領固定薪水，首先得到的是可用工時，而非立即減少薪資支出。
接著分清兩個分母。若比較自動完成能力，A 的每次直接成功成本為 300 ÷ 700，約 0.43 元；B 為 500 ÷ 900，約 0.56 元。若比較整批案件都處理完的總成本，在假設人工最後都能完成的前提下，則分別是 3,300 ÷ 1,000＝3.30 元與 1,500 ÷ 1,000＝1.50 元。前者衡量自動化支出，後者把剩下的工作也算進來，不能把兩者混稱同一個成功率。
接著應找出 A 的失敗集中在哪裡。如果大多是同時談退貨與帳務的混合訊息，可以只把這類案件送給 B，再用新的實際成本驗證。若人工錯誤也增加、分類結果根本不會被採用，就應先修分類規則與標註，再決定是否增加模型支出。
哪些費用應歸到同一件工作？
一張工單即使呼叫模型多次，業務上仍是一張工單。第一次回答失敗、第二次重試成功，不能在分母記兩次成功；但兩次呼叫、搜尋與工具費用都要進分子。可用自己系統的工單編號串起呼叫紀錄，另外留下模型版本與最終採用狀態，避免只看 API 的成功回應。
人工核對成本也要說清範圍。若每一件都要讀一遍，這段共同覆核時間應在兩方案都計入；若只有退回件需要額外處理，才可以像上表分開算。資料清理、評測設計與系統維護則適合另外記為固定投入，再依實際使用量攤提，不要只報最漂亮的單次費用。
台灣中小企業的最低可行做法
先選一個已在付費的用例，連續記錄一段正常營運週期。不要一開始就做全公司儀表板。把每次執行標上用例與版本，區分正式、測試與個人實驗；超過基準時先看上下文變長、迴圈增加、流量成長或模型切換，再決定限額。
我不建議只設每日 Token 上限。硬上限能止血，卻可能在最有價值的流程中途切斷。比較好的護欄是每個用例有預算、單次執行上限、異常提醒與降級模型，並保留Shadow AI的未授權支出盤點。
當某個 Agent 成本上升但成功率與收入同步改善，可以擴大；成本下降、人工退回卻增加，通常只是把帳藏到另一個部門。這才是 Tokenomics 真正要解的問題。
常見問題
AI Tokenomics 和加密貨幣 Tokenomics 一樣嗎？
不同。這裡的 Token 是模型讀寫與推理的計量單位，Tokenomics 指如何把 AI 用量、成本與業務價值連起來，不是在分析代幣供需。
只看每百萬 Token 價格夠嗎？
不夠。你還要計入上下文、重試、工具、基礎設施、監控與人工覆核；最終用每次成功結果成本比較才有意義。
沒有 FinOps 團隊也能開始嗎？
可以。先為一個用例記錄模型、Token、工具呼叫、成功與人工退回，建立正常基準。資料穩定後再擴大到部門與跨供應商報表。
參考來源
- Google Cloud Blog：Tokenomics: Why smart teams spend more on AI, on purpose（2026-08-22）
- Google Cloud Docs：AI and ML perspective: Cost optimization（2026-08-24 查核）
- Google Cloud Docs：Custom metadata labels（2026-08-19）
- FinOps Foundation：Token Economics: The Atomic Unit of AI Value（2026-05-10）
- Google Cloud Docs：Guide to Cloud Billing Resource Organization and Access Management（2026-08-24 查核）