當 Token 越來越便宜，帳單為什麼越來越貴？- VPSSpark

2023 年，GPT-4 API 每百萬輸入 Token 要價 $30。2024 年底，同等智力水準的模型已跌到 $3 以下。2025 年，Claude Haiku 級別的模型每百萬 Token 不到 $1。若只看「單價」，應該感到高興——AI 正在大幅降價。

但若你打開上個月的帳單，很可能會皺眉：怎麼比去年還貴？

這不是你的錯覺，也不是哪家廠商在坑你。這是一條已有 160 年歷史的經濟學定律在 AI 時代的最新重演——它叫 Jevons 悖論（Jevons Paradox）。

核心結論

Token 單價每跌一半，你的用量通常會漲 3—5 倍。單價下降帶來的「節省」被更大的用量完全抵消，帳單不降反升。

−97%

GPT-4 級模型
單價 2023→2026

10×

同期平均
Token 用量增幅

3×

開發者 AI 月帳單
同期平均增幅

Jevons 悖論：越便宜，用越多

1865 年，英國經濟學家 William Stanley Jevons 在研究煤炭時發現了一個反直覺的現象：蒸汽機的效率每提升一次，煤炭的總消耗量不降反升。原因是效率提升降低了使用成本，反而催生了更多應用場景——原本用不起蒸汽機的工廠開起來了，原本只開一條產線的工廠開了三條。

「節省了每單位的消耗」並不等於「節省了總消耗」。這就是 Jevons 悖論：當一種資源變得更高效（或更便宜），對它的總需求往往會增加，而非減少。

Token 的故事完全相同。單價每跌一個數量級，就有一批原本被「太貴了」擋在門外的用例被解鎖：

單價 $30/M 時，你只用 AI 寫週報摘要。
單價 $3/M 時，你開始用 AI 做程式碼 Review。
單價 $0.3/M 時，你讓 AI 跑背景 Agent、處理客服工單、每小時掃一次日誌。
單價 $0.03/M 時，你把整個工作流都餵給它，然後忘了關閉。

每一次降價都不是讓你「省錢」，而是讓你「敢用更多」。帳單的絕對值於是在單價不斷下降的同時，悄悄向上爬。

帳單膨脹的三個真實推手

Jevons 悖論解釋了「為什麼」，但要控制帳單，你需要知道錢究竟燒在哪裡。在 AI API 帳單裡，有三個結構性的膨脹源。

推手一：用量膨脹——從「偶發詢問」到「常駐背景」

兩年前，典型的 AI 用量是「我有問題時才問」。今天，隨著 Cursor、OpenClaw 這類 Agent 工具普及，AI 已從「被動應答」變成「主動執行」：它在你睡覺時跑 CI 分析，在你開會時整理程式碼倉庫，在你吃飯時處理使用者回饋。台灣不少獨立開發者與小型工作室，早已把這套流程當成日常——差別只在於，月底對帳時才發現 API 費用悄悄超過了 VPS 主機費。

這一轉變意味著呼叫頻率從「一天幾十次」膨脹到「一天幾千次」。即使每次呼叫的單價只有原來的十分之一，幾千次的總量仍然讓帳單輕鬆翻倍。

用法階段	典型呼叫頻率	每次 Token 量	月度 Token 總量
問答輔助（2023）	30 次/天	~500 tokens	~450K tokens
程式碼 Review（2024）	200 次/天	~3,000 tokens	~18M tokens
背景 Agent 常駐（2025+）	2,000 次/天	~8,000 tokens	~480M tokens

注意最後一行：用量從 450K 跳到 480M，是一千倍的成長。即使 Token 單價同期跌了 90%，帳單仍然會是 2023 年的 100 倍。

推手二：上下文暴漲——每次請求的 Token 數不可同日而語

更隱蔽的帳單殺手不是「呼叫次數」，而是「每次呼叫的體積」。

2023 年，GPT-3.5 的上下文視窗只有 4K tokens。今天，Claude Sonnet 支援 200K context，Gemini 2.5 Pro 直接開放 1M context。開發者不再小心翼翼地「裁剪上下文」，而是直接把整個程式碼庫、整份 PDF 文件、完整的對話歷史塞進去——畢竟「反正現在模型能看」。在台灣常見的情境：Side Project 把整包 monorepo 丟進 @codebase，結果單次 PR 就燒掉一整天的額度。

上下文的隱性成本

把一個 500KB 的程式碼檔案塞進 prompt，大約等於 125,000 tokens——比 2023 年一整個月的典型用量還多。如果你的 Agent 每次請求都攜帶完整上下文，帳單會呈指數級膨脹，而不是線性成長。

更棘手的是「extended thinking」（深度推理）模式。Claude 3.7 Sonnet 的 thinking 模式在產生最終答案之前，會先產生大量內部推理 tokens——這些 thinking tokens 同樣計費，而且往往比最終輸出還多。一次「深度分析」的實際消耗可能是你想像的 5—10 倍。

推手三：Agent 乘數——Token 不是加法，是乘法

這是帳單膨脹最猛、最難預見的來源。

在「問答」模式下，一次請求就是一次請求，Token 消耗是線性疊加的。但在 Agentic 工作流裡，一個使用者請求會觸發一整條呼叫鏈：

圖 1 · 一個「簡單」Agent 請求的內部呼叫鏈

使用者傳送一條指令「幫我審查這個 PR 並給出修改建議」

Orchestrator Agent規劃子任務，分配給多個子 Agent → 1 次 LLM 呼叫

子 Agent ×4讀取程式碼、搜尋文件、檢查測試、產生評論 → 4 次 LLM 呼叫（每次含完整上下文）

彙總 + 重試Orchestrator 整合結果，如遇錯誤自動重試 → 2-3 次 LLM 呼叫

使用者發出了 1 條指令，實際消耗了 7—8 次 LLM 呼叫，每次呼叫都攜帶大量上下文。這就是「乘數效應」——你以為你按了一次按鈕，帳單上記了八行。

更危險的是無限迴圈的 Agent：當 Agent 遇到錯誤時會自動重試，當任務沒有明確終止條件時會持續執行。一個寫錯了 termination condition 的 Agent，醒來可能留下一張幾百美元的帳單。

真實踩坑

某開發者在 CI 流水線裡接了一個「自動修復失敗測試」的 Agent，忘記設定最大重試次數。一次偶發的 flaky test 觸發了 Agent 迴圈，8 小時內產生了 2,300 次 LLM 呼叫，帳單 $340。模型價格已經非常便宜，但乘數夠大時，任何價格都能打出大數字。

把帳單拆開看：一道讓人清醒的算術

假設你今天的 AI 使用場景是：每天跑 10 個 Agent 任務，每個任務平均觸發 8 次 LLM 呼叫，每次呼叫平均 10,000 tokens（含上下文）。

參數	數值
每天 Agent 任務數	10
每任務 LLM 呼叫次數（乘數）	8
每次呼叫 Token 量	10,000
每月總 Token 量	10 × 8 × 10,000 × 30 = 24M tokens
單價（Claude Sonnet 級，$3/M）	24M × $3/M = $72/月
若用更貴模型（$15/M）	24M × $15/M = $360/月

$72—$360/月，只是一個開發者的日常工作流。如果團隊有 10 人，或者 Agent 任務數翻倍，數字會直接乘過去。帳單的大小不再由「我有沒有用 AI」決定，而是由「乘數鏈有多長」決定。

讓帳單可控：不是少用，而是有意識地用

Jevons 悖論的教訓不是「別用」，而是「用對結構」。煤炭用量增加本身不是壞事，帶來了工業革命；Token 用量增加本身也不是壞事，帶來了效率革命。問題是：這些帳單有沒有產生對等的價值？

以下是三個可以立刻實施的控制手段，按實施成本由低到高排列：

方法一：分層路由——用便宜的模型做大量工作

不是所有任務都需要最強的模型。「判斷這段程式碼有沒有語法錯誤」和「設計整個系統架構」對智力的要求差了一個數量級，但如果你對兩者都用 Claude Sonnet，帳單也差了一個數量級。

建議按任務複雜度分三檔：

格式化、摘要、簡單分類：用 Haiku / GPT-4o-mini 級別，單價約 $0.15—$0.3/M，速度也最快。
程式碼生成、多步推理、文件撰寫：用 Sonnet / GPT-4o 級別，單價約 $3—$5/M，性價比最高。
架構設計、複雜除錯、需要 extended thinking：用 Opus / o3 級別，按需呼叫，不作為預設。

實施方式：在 LiteLLM 這類 Gateway 裡定義模型別名（fast / smart / deep），客戶端按任務類型路由，主金鑰和路由邏輯放在雲端 Mac 的 Gateway 上統一管理——可參考雲端 Mac + OpenRouter 企業級實戰指南裡的三層路由方案，並搭配 OpenRouter 官方文件完成上游對接。

方法二：預算熔斷——在 Token 燒光之前拉閘

分層路由解決的是「用對模型」，預算熔斷解決的是「用量失控」。Agent 迴圈、意外重試、無終止條件的長任務——這些不是理論風險，是每個認真使用 Agent 的開發者遲早會踩的坑。

最低限度需要兩層保護：

上游 credit cap：在 OpenRouter、Anthropic 控制台直接設定月度硬限額，超出後 API 直接拒絕請求，不會默默扣費。
Virtual Key 級 spend cap：在 LiteLLM 這類自託管 Gateway 裡，給每個客戶端（Cursor、OpenClaw、腳本）各發一把 Virtual Key，分別設獨立的月預算。某個工具失控時，只燒自己的配額，不影響其他工具。

LiteLLM Virtual Key 建立範例（API）

curl -X POST http://127.0.0.1:4000/key/generate \
                  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "key_alias": "cursor-dev",
                    "models": ["fast", "smart"],
                    "max_budget": 20,
                    "budget_duration": "1mo",
                    "metadata": {"tool": "cursor", "env": "dev"}
                  }'

上面這個 Virtual Key 月消費上限是 $20，只能呼叫 fast 和 smart 兩個模型別名，超出後自動熔斷並回傳 429，主 Key 不受影響。這是「個人企業級」治理的最小可行版本。

方法三：日誌可視化——你不知道錢燒在哪，就沒法省

很多帳單問題是「事後才發現」：月底對帳單，發現某個 Agent 在週五安靜地燒掉了 $50，但任務早就跑完了。問題不是 Agent 做錯了什麼，而是你沒有即時的 spend 視圖。

最簡單的可觀測性方案：

LiteLLM 內建 Dashboard：litellm --detailed_debug 啟動後，造訪 /ui 可以看到每個 Virtual Key 的即時 spend、請求量、平均延遲（詳見 LiteLLM 文件）。
每日 spend 告警：用 cron 每天跑一次 sqlite3 litellm.db "SELECT key_alias, spend FROM litellm_verificationtoken"，超過閾值時發 Slack 訊息（OpenClaw 接入 Slack 可以做這件事）。
上游帳單對齊：每週把 LiteLLM 本地 spend 和 OpenRouter / Anthropic 控制台帳單比對一次，差異超過 10% 時說明有「漏網請求」——某個工具繞過了 Gateway 直連上游。

可觀測性的價值

上線 spend 監控的團隊，平均在第一個月就能找到 20—30% 的「無效消耗」：執行後從未讀取結果的 Agent、每次攜帶全量上下文卻只需要最後 5 行的腳本、以及被遺忘在 cron 裡的舊任務。

真正的問題不是「怎麼省錢」

Jevons 悖論有一個經常被忽視的另一面：他並沒有說「效率提升是壞事」。蒸汽機效率提升、煤炭總消耗增加——但英國也因此完成了工業革命。

同理，Token 越來越便宜、你的 AI 帳單越來越高，並不一定是壞事。真正需要問的問題是：

多出來的這些 Token，有沒有產生等價或超額的價值？
帳單裡有多少是「有意識的投入」，有多少是「無意識的浪費」？
你有沒有一個可視化的系統，能隨時回答上面兩個問題？

「節約 Token」的目標是錯的。「每一個 Token 都花在刀刃上」才是對的。分層路由、預算熔斷、消費可視化——這三件事加在一起，不是為了讓你用得少，而是為了讓你知道自己在用什麼、用在哪裡、值不值得。

Token 還會繼續變便宜。帳單也還會繼續漲。但如果你建好了這套治理結構，至少漲的是「值得漲的部分」。

FAQ

Jevons 悖論會永遠成立嗎？在「效用無上限的資源」上，Jevons 悖論通常成立——AI 推理能力幾乎可以無限地替代人力，所以價格每降一檔，用例就會解鎖一批。當 AI 能力觸及真正的天花板（比如「已經比所有人都強了，再便宜也沒有新用例」），悖論會失效。但那一天目前看不到邊。

我能靠「換便宜模型」來控制帳單嗎？短期有效，但不可持續。一旦你發現便宜模型夠用，你會把省下來的預算用到更多任務上——又回到了 Jevons 的軌道。持續有效的控制手段是「預算約束 + 可視化」，而不是「模型降級」。

Agent 乘數效應能消除嗎？不能完全消除，但可以控制。關鍵是：① 給每個 Agent 任務設定明確的最大步驟數/最大呼叫次數；② 用「結果快取」避免重複執行相同子任務；③ 在 Orchestrator 層做「是否需要 LLM」的判斷——很多步驟用規則引擎處理比呼叫 LLM 便宜幾百倍。

團隊規模擴大後帳單會更難控制嗎？會。人越多，「誰在用什麼模型跑什麼任務」越難追蹤。這時 Gateway 層的 Virtual Key 隔離和 per-user spend cap 就從「最佳實踐」變成了「必須有」。建議在團隊超過 3 人之前就搭好 Gateway，否則遷移成本會更高。