為什麼你的 LLM 帳單是預期的 3 倍

利益揭露:我是 DigitalOcean 的 Solutions Architect,所以文中提到 DigitalOcean 產品時,是「業內人的觀點」而非中立第三方——這些地方我都會明確標示,其餘分析則盡量保持廠商中立。以下皆為個人觀點。

前言

有位創辦人在一個開發者 Slack 裡貼了張截圖。他們的 Gemini API 帳單在短短一個月內，從 $200 暴增到 $6,000。沒有任何警示被觸發。沒有任何儀表板亮起紅燈。團隊裡也沒有人察覺到任何異樣——直到帳單寄來。

這個故事——記錄於一篇分析 60 多個 LLM 模型的公開報告中——並不是什麼例外。當團隊在不了解完整成本結構的情況下就採用 LLM API，這幾乎就是預設會發生的結果。同一份分析發現，相較於光是透過更好的模型選擇與使用模式就能達到的水準，企業普遍多付了 50–90%。

本文將完整說明這一切究竟為什麼會發生——並提供一套具體的框架，幫你把這道落差補起來。

重點摘要

• 廣告上標示的輸入 token 價格是地板，不是天花板——真實的生產環境帳單常常是這個數字的 2–3 倍，原因在於五個會層層相乘的因子。
• 輸出 token 的成本是輸入的 3–5 倍，而思考 token 是以輸出費率計費的，卻完全不會出現在使用者看得到的回應裡。
• 非生產環境流量——CI、staging、負載測試、本機開發——會悄悄被算進同一張帳單，而且金額往往不輸給生產環境的花費。
• 長 context 加價可能會讓整個工作階段的每 token 費率翻倍甚至翻到四倍，只要你跨過了供應商的門檻（例如 GPT-5.5 超過 272K 輸入 token）。
• 有四個槓桿能補上這道落差——提示快取（prompt caching，快取讀取約打 1 折）、批次處理（約打 5 折）、量大折扣，以及模型適當選型——但這一切的前提都是對「錢究竟花到哪裡去」具備可見性。

廣告價是菜單價，不是結帳金額

把 LLM 的定價頁面想成一份餐廳菜單。價格看起來很合理，直到你發現那個標出來的價格只是前菜。主菜（輸出 token）要貴上三到五倍。接著還有高級座位的加價（長 context）、看不見的主廚備料服務費（思考 token），而且不知怎地，廚房連你週六早上練習備料的時段都一直在幫你記帳（非生產環境）。

當你把這一切全部加起來，實際帳單很少會跟你當初編列預算時參考的那些數字長得一樣。

以下就是造成這道落差的五個隱藏相乘因子。

標示價與實際帳單之間落差背後的五個隱藏相乘因子。

隱藏因子 #1：輸出 token 比輸入貴 3–5 倍

每家供應商都拿輸入 token 費率當開場白，因為那是比較小的數字。真正撐起成本的主力是輸出 token——也就是模型生成的那些 token——定價高出 3 到 5 倍。

以 Claude Sonnet 4.6 為例：輸入是 $3.00/M token，輸出是 $15.00/M token。對於一個典型的對話式應用來說，模型每收一個輸入 token 就會生成兩個輸出 token，這樣一來，你的有效混合成本就已經是廣告輸入費率的 3 倍了。

這正是那個 50–90% 多付模式背後的主要推手。團隊照著定價頁面上的輸入數字編預算，等到實際帳單反映出更沉重的輸出現實時，才大吃一驚。

該檢查什麼： 拉出過去 30 天你實際的輸入對輸出 token 比例。如果你落在 1:2 或 1:3（輸入:輸出），那你的運作成本早就遠高於那個招牌數字了。

隱藏因子 #2：思考 token 是水面下的冰山

具備延伸思考或思維鏈推論能力的模型——Claude 的延伸思考模式、o4-mini、o3——會在生成回應的過程中產生「思考 token」。這些是模型內部的推論步驟，永遠不會出現在你的使用者看到的內容裡。

它們是以完整的輸出 token 費率計費的。

把它想成你聘了一位按小時計費的顧問。你只要一頁的備忘錄，他寫只花了 15 分鐘——但他還會把寫下第一個字之前，花在研究、斟酌、打草稿的那 3 個小時也一起跟你收費。備忘錄看起來一模一樣，帳單可不一樣。

在 Claude Opus 4.8（輸出 $25/M token）上，一個有 500 個可見輸出 token 加上 2,000 個思考 token 的回應，成本是同一個回應但不開延伸思考時的 5 倍。你的使用者看到的是 500 個 token 的回應，你付的卻是 2,500 個。

這不是什麼瑕疵——思考 token 能在複雜的推論任務上大幅提升表現。但如果你在開啟延伸思考時沒有設定明確的 token 預算，你付的錢可能遠遠超過你的使用情境實際所需的斟酌量。

該檢查什麼： 檢視你的部署有沒有開啟延伸思考，以及預算是否有明確的上限。把簡單分類任務的 max_thinking_tokens 設在 1,000、把複雜的多步驟分析設在 10,000——這就是「成本可控」與「成本失控」之間的差別。

隱藏因子 #3：非生產環境的影子帳單

這裡有個對工程主管特別有感的比喻：想像有家咖啡店，每次有人練習做你點的那杯飲料就跟你收一次錢——不只是把成品端給你的時候才收。咖啡師受訓時拉的每一杯濃縮、測試時重做的每一杯、開店前團隊試喝時做的每一批——通通算到你帳上。

當你的 LLM API 帳戶不去區分生產與非生產用量時，發生的大致就是這種事。

你的 CI 流水線在每一個 pull request 上都會重跑同一批測試情境。開發者在調整提示詞時會在本機反覆跑流程。staging 環境會複製生產流量來做驗證。負載測試則對著模型端點猛打，用來確認應用——而不是模型——能不能擴展。這一切全都算進同一個 API 計費帳戶。

Speedscale 對企業 AI 部署的分析記錄了這個模式：大多數團隊都沒注意到自己的 AI 帳單裡有多少來自非生產環境，直到那個數字已經痛到不行。一個用 Claude Sonnet 每天處理 10,000 張工單的中型客服中心，會產生一筆可預測的生產環境花費。再加上 CI 流水線、開發者測試、以及 staging 驗證——真實帳單可能會是你光算生產流量所得數字的 2–3 倍。

該檢查什麼： 依環境（production、staging、CI、local）為你的 API 呼叫加上標籤。大多數第一次這麼做的團隊，都會被這個比例嚇一跳。

隱藏因子 #4：輸出冗長度——為你不需要的字數買單

Claude 傾向把話說得很完整。o4-mini 則傾向簡潔。同樣一個提示，輸出 token 數可能會因為你用的是哪個模型而相差 2–4 倍。

這裡的比喻是電子郵件的長度。請一位注重細節的同事確認一個開會時間，你可能會收到三段話，裡頭塞滿了背景、替代方案和各種但書。請一位簡潔的同事，你得到的是「週二下午 2 點可以」。兩個回答含有同樣的資訊，但其中一個產生起來的成本貴上不少。

到了一定規模，這就很要緊了。如果你用 Claude Sonnet 來做一件你其實只需要一個標籤或是非題決策的任務，而模型每次都回給你一段論述周全的解釋，那你就是在為成千上萬個對你的應用毫無價值的 token 付錢。

解法幾乎都是提示工程，而不是換模型：像是「只回答分類標籤，不要解釋」這種明確的指示，在合適的任務上可以把輸出 token 數減少 60–80%。但長期來看，正確的做法是把模型的冗長度偏好對應到任務需求——並且要實際測量每種任務類型的輸出 token 數，而不是假設它跟輸入成正比。

隱藏因子 #5：長 context 加價——看不見的過境關卡

國際數據漫遊的運作方式是這樣的：你的電信業者給你看一個看起來合理的每 MB 費率，一切都好端端的，然後你在沒注意到的情況下跨過了一條國界。突然之間，同樣的動作貴了 4 倍——而且是回溯套用到整個工作階段，不只是門檻之後的那段流量。

LLM 的長 context 定價，運作方式一模一樣。

GPT-5.5（依 OpenAI 的模型文件）的定價是輸入 $5/M、輸出 $30/M，搭配 1M token 的 context 視窗。超過 272K 輸入 token 之後，定價會切換成 2 倍輸入（$10/M）與 1.5 倍輸出（$45/M）——而且是套用到整個工作階段，不只是門檻之上的那些 token。

Gemini 3 Pro（依 Google 的定價文件）在 200K context 以內收取輸入 $2.00/M、輸出 $12.00/M。超過 200K，費率就跳到輸入 $4.00/M、輸出 $18.00/M——而且關鍵在於，那個請求裡的所有 token（輸入和輸出）都會以長 context 費率計費，不只是超過門檻的那些 token。

一旦跨過供應商的 context 門檻，較高的費率會套用到整個請求——不只是超過門檻的那些 token。

對於一個把大塊文件硬塞進 context 的 RAG 應用，或是一個在很長的對話歷史中跑多輪推論的 agent 來說，這些門檻可能在相當高比例的請求上都會被跨過。如果你還沒拿自己的 p95 context 長度去對照供應商的加價門檻，那你很可能在大量流量上付了雙倍卻渾然不知。

該檢查什麼： 拉出你的 p95 與 p99 輸入 context 長度分佈。如果這些數字正逼近任何一家供應商的門檻，就要搞清楚究竟有多少比例的請求正以長 context 費率計費。

「本機推論值得嗎？」的計算

在談成本槓桿之前，有個自然會冒出來的問題值得先處理：到什麼程度，自行架設會徹底贏過託管 API 的成本？

託管 API vs 自行架設：取捨取決於流量與可預測性。

有家 SaaS 公司記錄了他們從雲端 LLM API（每月 $6,700）遷移到 AWS EC2 G4dn.xlarge 上的三個 Ollama 執行個體的過程，用來做審核、摘要與嵌入。新基礎設施成本：每月 $1,280。每月省下：$5,420。他們維持了 99.9% 的可用時間，以及 312ms 的中位數延遲——遠在他們 500ms 的 SLA 之內。

這個取捨是真實存在的，值得看清楚：

對於擁有高量、可預測、能容忍延遲的工作負載的團隊——大量文件處理、夜間分析、大規模內容審核——自行架設可以帶來 70–80% 的成本降幅。對於需要前沿模型品質、流量不規律、或需要快速迭代模型的團隊，託管 API 仍然是正確的預設選項。大多數生產團隊最後都會跑混合架構：可預測的高量層用本機推論，複雜推論與變動負載則用託管 API。

真正能撼動全局的四個槓桿

假設你會繼續留在託管 API 上，以下就是在最佳化投入上回報最高的四個槓桿——依「實作難易度對上成效」排序。

1. 提示快取——輸入成本降低 60–80%

提示快取（prompt caching）會在多個請求之間重複使用已經算好的前綴——你的系統提示、few-shot 範例，以及 RAG context 範本——省去每次呼叫都重新處理同一批 token 的成本。

把它想成影印機的暖機：第一張要等一下，但第二張到第兩千張既即時又便宜。Anthropic 的快取讀取成本是基礎輸入費率的 10%（打 1 折）。快取寫入則是 1.25 倍（5 分鐘 TTL）或 2 倍（1 小時 TTL）——你付一次錢把前綴存起來，之後每次快取命中都享有 90% 的省下。

調校得當的部署可以達到 60–80% 的快取命中率。要如何做到——包括那個會把命中率打到個位數的常見「單一欄位」錯誤——都在本系列第 3 篇裡有完整說明。

2. 批次 / 非同步處理——打 5 折，不需要工程投入

對於任何不需要同步回應的工作負載——文件處理、夜間分析、大量分類、評測跑批——批次推論 API 提供大約 5 折的折扣，搭配 24 小時的 SLA。如果你的使用情境相容卻還沒用批次，那這就是現成可用、實作工作量最少、槓桿卻最高的單一改動。

3. 量大折扣——規模一大就有 25–40%

大多數供應商在每月花費 $50K 以上時都會提供議定折扣。許多符合資格的團隊只是單純沒去問。這個對話值得開啟。

4. 模型適當選型——往往降低 3–10 倍成本

最大的單一槓桿，就是把簡單的請求導向更小、更便宜的模型。Claude Haiku 4.5 的輸入是 $0.25/M；Claude Sonnet 4.6 的輸入是 $3.00/M——價差 12 倍。對於 Haiku 就能產出同等品質的任務（分類、摘要、從檢索到的 context 中回答 FAQ），跑 Sonnet 就是浪費。

挑戰在於如何把這套路由落實到日常運作中，又不必維護自製的路由邏輯。如何不自己造輪子就做到這件事的架構，會在本系列第 5 篇裡說明。

這一切的前提：可見性

貫穿這五個隱藏相乘因子的共同點，就是它們在預設情況下都是看不見的。大多數 LLM API 的計費儀表板只會顯示總 token 數和總花費。它們不會拆解出：

• 依環境區分的 token（生產對非生產）
• 快取命中率與錯失的省下
• 思考 token 對可見輸出 token 的比例
• 各請求的長 context 加價暴露程度
• 各任務類型的輸出 token 分佈

建立這種可見性是一次性的投資，卻會持續回本。本文裡的每一項最佳化都從「該檢查什麼」開始——而少了在你推論層上的儀表化可觀測性，這些檢查一項都做不了。

DigitalOcean 在哪裡派上用場

本文刻意保持供應商中立，因為這些模式適用於每一家 LLM API 供應商。話雖如此：這些問題有一部分是架構性的，而擁有合適的工具層確實有差。

DigitalOcean 的 Gradient AI Platform 包含具備成本控管的分級計費，而 Inference Router 會自動處理模型適當選型——把每個請求導向最適合該任務的模型，而不是預設就用最強（也最貴）的那個。DigitalOcean 表示，客戶使用 Inference Engine 後看到推論成本最多降低 67%；其中一位客戶 Workato 的 Research Lab 回報，首字回應時間（time-to-first-token）快了 77%、端到端延遲降低 79%、推論成本降低 67%。（截至撰稿時，Inference Router 處於公開預覽階段，不額外收費。）

Inference Router 會把每個請求導向最適合該任務的模型。想了解運作原理，參見 Inference Router 架構深入解析。

但不管你在哪個平台上，前提都一樣：搞清楚你真實的成本結構。對 token 類型拆解、環境標籤、快取命中率與 context 長度分佈具備可見性的團隊，總是能找到可觀的省下空間——靠的不是什麼花招，而是終於看見了錢都花到哪裡去。

總結：五個隱藏相乘因子

網站上的價格與你實際付出的金額之間的落差，來自五個會層層相乘的因素：

1. 輸出 token 比輸入 token 貴 3–5 倍——而大多數生產工作負載都是輸出偏重的
2. 思考 token 以完整的輸出費率計費，且在回應中看不見
3. 非生產環境——CI、staging、本機測試——會算進同一張帳單，而且金額常常超出預期
4. 輸出冗長度 因模型而異甚大——放任的冗長度是有成本卻無品質
5. 長 context 加價 會在大多數團隊從沒拿自己的 p95 context 長度去對照過的門檻上，讓每 token 費率翻倍甚至翻四倍

補上這道落差的四個槓桿：提示快取、為非同步工作負載做批次處理、量大折扣，以及模型適當選型。它們合在一起，可以在不犧牲品質的前提下，把一筆典型的生產環境 LLM 帳單減少 40–80%。

而這一切的前提是可見性。少了依環境的標籤、快取命中率監控，以及各任務類型的 token 拆解，你就是在盲飛——而盲飛正是一筆 $200 的帳單變成 $6,000 驚喜的方式。

參考資料

• I Analyzed 60+ LLM Models and Found Companies Overpay by 50-90% — DEV Community
• The Hidden Cost of Using LLM APIs in Production — Medium
• The Hidden AI Bill: Why Non-Prod LLM Costs Spiral — Speedscale
• LLM for SaaS: 5 Production Use Cases — MarkAICode
• Anthropic API Pricing 2026: Prompt Caching Guide — Finout
• GPT-5.5 Long-Context Pricing — LangCopilot
• Inference Router：架構深入解析 — DigitalOcean