別再被帳單嚇到：API 計費基礎與省錢實戰

你以為「少打幾句 prompt」就會省錢？真正把你錢燒掉的，常常是輸出太長和你不自知的上下文。那到底一個請求誰最貴、哪裡最坑、怎麼一眼看穿？

這不是一篇給你心靈雞湯的技術文章，這是一份幫你止血的急救手冊。

現在，請把你在社群媒體上看到的那些「10 分鐘學會 AI 開發」、「零基礎打造百萬 AI 應用」的速成影片先忘掉。那些影片像是在賣一張通往未來的單程票，但它們不會告訴你，當你的 AI 應用程式從 Demo 變成產品，跑在真實使用者的手機上時，你會面臨什麼樣的財務災難。

我見過太多充滿熱情的開發者，在週五晚上興奮地部署了一個新功能，覺得自己改變了世界。結果週一早上醒來，看到的不是用戶的讚美，而是一張高達 5,000 美元的 OpenAI 帳單 。那一刻，他們的表情不是驚喜，是驚嚇。你可能覺得這很誇張，心想「我只是個小專案，怎麼可能？」但請聽我說，災難從來都不會敲門，它只會踹門。

為什麼會這樣？因為大部分人對 LLM（大型語言模型）API 的計費邏輯，還停留在「我發一則簡訊，電信公司收我一塊錢」的線性思維裡。這種思維在 Web 2.0 時代或許適用，但在 GenAI 時代，這是致命的。

真相是，API 計費更像是在玩一場規則極其複雜的期貨交易。

這裡面有你看不見的「推理 Token」、有你以為免費其實貴得要死的「High-Detail 圖片處理」、還有那個每分每秒都在膨脹的「歷史上下文」。你以為你只是問了一句「你好」，但在系統後端，你可能剛剛把整本百科全書重新傳了一遍。

這篇文章不談虛無縹緲的 AI 未來，只談錢。我會用最犀利的視角，帶你拆解那張看不懂的帳單，並給你一套經過血淚驗證的「砍帳」工法。我不會跟你說「優化體驗」，我會教你「優化存摺」。

帳單不是貴，是你看不懂它怎麼長出來

想像一下，你走進一家餐廳，點了一盤 100 元的義大利麵。結帳時，店員遞給你一張 5,000 元的帳單。

你大怒：「我就吃了一盤麵！」

店員冷冷地看著你：「先生，您點麵的時候，使用了我們的『高級餐具』(System Prompt)，這餐具按秒計費；您用餐時，我們的廚師為了確保麵條口感，回憶了這家店過去十年的食譜 (Context History)，這也要收費；還有，您最後說了一句『真好吃』，這觸發了我們的『情感回應服務』(Output Tokens)，這是最貴的。」

聽起來很荒謬？這就是你每天在使用 API 時發生的事。

大眾認為：API 是按「次」收費的工具。

真相是：API 是按「資訊量 × 處理深度」收費的黑洞。

你不是被模型收割，你是被「不會拆帳的輸入法」收割

很多開發者在收到高額帳單時，第一反應是怪罪模型供應商：「OpenAI 太貴了！」、「Claude 是在搶錢嗎？」這種情緒很正常，因為我們習慣了 SaaS 軟體的「月費制」或雲端主機的「固定規格制」。我們不習慣這種「流動性成本」。

如果你仔細觀察那些帳單暴增的案例，你會發現一個共同點：同樣的功能、同樣的用量，某天帳單突然翻倍 。這不是因為模型漲價了（事實上，模型價格一直在跌 ），而是因為你的「請求形狀」（Request Shape）變了。

也許是你昨天加了一個「保留歷史對話」的功能，導致每次請求的 Context 像滾雪球一樣變大；也許是你把輸出的格式從純文字改成了 JSON，導致 Token 數量暴增 ；又或許是你不知不覺中啟用了一個會觸發「推理 Token」的高級模型 。

成本不是一個數，是 Input / Output / Cached / 文件路徑的疊加

要理解這一點，你必須放棄「總價」這個概念。如果你只看總價，你就像是在看著體重計上的數字尖叫，卻不知道是胖在脂肪、肌肉還是水腫。

成本是由四個維度疊加出來的：

1. Input (輸入)：你餵給它的，包含你看不見的歷史紀錄。
2. Output (輸出)：它吐出來的，這是最貴的部分。
3. Cached (快取)：你重複使用的，這是最省錢的部分。
4. Special (特殊)：圖片、搜尋、推理，這是隱藏的殺手。

這篇文章的目標很簡單，我只教你兩件事：拆帳與砍帳。

學會拆帳，你就不會被帳單嚇到；學會砍帳，你就能在別人破產的時候，依然活得滋潤。

如果你覺得自己已經準備好面對真相了，那我們就開始吧。下一段，我們要拿起手術刀，把那個看似簡單的 API 請求，切開來看看到底長什麼樣子。

一次請求的「拆帳四格」

很多人在優化成本時，第一反應是：「我要把 Prompt 寫短一點。」或者「我要把 'Please' 和 'Thank you' 刪掉。」

錯。大錯特錯。

在目前的計費權重裡，Prompt（輸入）通常是最便宜的。你刪掉那幾個禮貌用語省下的錢，可能連一粒米都買不起。真正宰割你錢包的，往往是你忽視的其他三個角落。

要掌控成本，你必須先把每一個 API 請求（Request），在腦海中拆解成這四個格子。這是我自創的「拆帳四格」，無論你是用 OpenAI、Anthropic 還是 Google Gemini，這把尺都通用。

你以為你只問了一句，其實你帶了整個世界

讓我們看一個經典的災難現場。這是我輔導過的一個真實案例。

你做了一個電商客服機器人。使用者問：「我的訂單在哪？」

這句話在你看來，只有 5 個 Token。你心算了一下，GPT-4o 的輸入費率是 $2.50 / 1M tokens ，這句話的成本趨近於零。

於是你放心地把這個功能上線了。

但真相是，你的後端系統在發送請求前，幹了這幾件事：

1. 注入 System Prompt (系統提示詞)：為了保證機器人不亂說話，你塞了一份 2,000 字的「客服守則」，告訴它語氣要溫柔、不能罵人、要先核對身分、遇到退貨怎麼處理、遇到奧客怎麼安撫。這是 2,500 Tokens。
2. RAG (檢索增強)：系統自動去資料庫抓了該用戶過去半年的 10 筆訂單詳情，加上最新的物流狀態和公司的退換貨政策文件片段。這又是 3,000 Tokens。
3. Chat History (對話歷史)：為了讓對話連貫，你把這用戶前 10 輪的廢話（包括他在問天氣、問你是不是真人）都帶上了。這又是 1,500 Tokens。

所以，使用者那句看似人畜無害的 5 Token 問題，實際上是一個 7,000+ Token 的巨型請求。

成本由「被塞進上下文的內容量」決定，不由你主觀感覺決定

這就是為什麼我說，優化 Prompt 的長度是微不足道的。真正的戰場在於上下文管理（Context Management）。

如果你不懂得拆解這四個格子，你就像是開著水龍頭在用勺子舀水，永遠止不住浪費。你以為你在省水（刪減 Prompt），其實水管在漏水（巨大的 Context）。

技術洞察： 大多數開發框架（如 LangChain 或 LlamaIndex）預設會幫你把所有東西都塞進去，因為它們追求的是「開發方便」，而不是「幫你省錢」。你必須手動介入，去檢查那個最終發送給 API 的 Payload 到底有多大。

把這個「四格圖」印在腦子裡。接下來的每一節，我們都要用這把尺去量一量你的程式碼。而首先要量測的對象，就是你最習以為常的「文字」。

下一段我會反轉你對 token 的直覺：字數，根本不是 token。你的格式，正在偷偷吃掉你的利潤。

反轉①：字數不是 token，你的「格式」才是隱形稅

如果你還在用 String.length 來估算成本，那你已經輸在起跑點了。

Token 不等於字數，也不等於字元。 它是模型理解語言的最小單位。在英文裡，一個單字可能是一個 Token；但在中文裡，一個字可能就是 1 到 2 個 Token；而在程式碼或 JSON 結構裡，一個括號、一個縮排，都可能是一筆開銷 。

最可怕的是，為了追求「程式穩定性」，我們往往會主動選擇一種最燒錢的格式。

JSON：工程師的蜜糖，錢包的毒藥

現在的開發主流是要求 LLM 輸出 JSON 格式。為什麼？因為 JSON 好解析，程式碼不容易報錯（Crash）。我們會在 System Prompt 裡寫：「請只輸出 JSON，不要有其他廢話，嚴格遵守 Schema。」

大眾認為 JSON 很乾淨，但真相是：JSON 是 Token 的燃燒機。

看看這個對比，這是來自 TensorLake 的真實測試數據 ：

選項 A：自然語言 (Plain Text / TOON)

Alice 25 歲，工程師。Bob 30 歲，設計師。

這段話非常精簡，模型大概只需要消耗 15-20 個 Token。

選項 B：JSON 格式

大量的雙引號 ""、大括號 {}、中括號 ``、冒號 :，還有為了美觀而存在的縮排與換行（即使你用 Compact JSON，符號依然存在）。

根據基準測試，同樣的資訊量，JSON 格式消耗的 Token 數通常是純文字或簡化格式（如 YAML 或 TOON）的 1.5 倍到 2 倍 5。

而且別忘了，這是 Output Token。還記得上一節說的嗎？Output 通常比 Input 貴 3 到 15 倍。你是在用最貴的費率，去買這些對使用者毫無意義的括號。你每多加一個 Key，每多一層 Nesting（巢狀結構），你的帳單就在滴血。

你的「整潔癖」正在讓你付費

很多開發者喜歡把 JSON Key 命名得很詳細，例如 customer_shipping_address_line_1。

在傳統程式開發中，這是好習慣（Clean Code）。但在 LLM 開發中，這叫揮霍。

如果你要生成一個包含 50 筆資料的列表，這個冗長的 Key 就會被重複 50 次。模型並不需要這麼長的 Key 才能理解它是地址，addr1 對模型來說意義是一樣的。

深度分析：XML vs JSON vs YAML

• JSON：最通用，但 Token 密度低（符號多）。適合複雜結構，但貴。
• XML：Anthropic (Claude) 非常喜歡 XML。雖然 XML 也有標籤 <tag></tag>，但在 Claude 的訓練資料中，XML 的權重很高，這讓它在處理 XML 時的穩定性極佳，有時候為了穩定性，多付一點 Token 是值得的 9。但純就 Token 數來說，它比 JSON 更慘。
• YAML：這是省錢的黑馬。YAML 依賴縮排而非符號，Token 效率通常比 JSON 高 20-30% 10。許多新模型對 YAML 的理解能力已經非常好了。

反直覺的解決方案：

1. 改用 YAML 或 Markdown 表格：如果你不需要極度複雜的巢狀結構，試試看叫模型輸出 YAML。你會發現 Token 數顯著下降。
2. 壓縮 Key Name：在 Prompt 裡定義 customer_shipping_address_line_1 = addr1。模型完全讀得懂，而你省下了大量 Token。
3. 使用 Schema：如果你用的是 OpenAI 的 Function Calling 或 Structured Output，請確保你的 Schema 定義盡可能扁平，不要層層巢狀。

行動建議： 先用 Token 計算器（如 Tiktokenizer）跑一遍你的 Output 範例，再決定格式。不要讓你的「程式碼潔癖」變成每個月多出來的那 20% 帳單。

搞懂了格式的稅，接下來我們要進入核心戰區。下一段我會把計費講成一條公式：只要你會代入這幾個變數，你就開始會算錢了。

把帳單寫成公式：Input / Output / Cached / Training 到底誰在燒

如果把 API 帳單看作一個黑盒子，你永遠會感到焦慮。但如果你把它看作一條數學公式，恐懼就會消失，取而代之的是算計。

現在的 LLM 計費模型，已經從單純的「依量計費」演變成了一套複雜的組合拳。我們來把這條公式寫出來：

這看起來很枯燥？別急，我們逐項拆解，你會發現每一項裡都藏著貓膩。

1. I (Input Tokens)：你餵了多少

這是最基礎的。但要注意，隨著 Context Window（上下文視窗）越來越大（現在動輒 128k, 200k 甚至 1M），開發者變得懶惰了。「反正塞得下，就全塞進去吧！」

真相： 塞進去是可以，但這就像你去吃自助餐，雖然盤子無限大，但每一克食物都要秤重收費。Gemini 1.5 Pro 的 1M Context 聽起來很爽，但如果你真的每次請求都塞滿 1M Token，一次呼叫就要好幾塊美金。跑個迴圈，你的卡就爆了 。

費率參考 (2025年)：

• GPT-5o: ~$2.50 / 1M input
• Claude 4.5 Sonnet: ~$3.00 / 1M input
• Gemini 2.5 Pro: ~$1.25 / 1M input (<=128k context)

2. O (Output Tokens)：你放任它講了多少

這是最貴的變數。目前 OpenAI GPT-4o 的 Output 價格是 Input 的 4 倍 ($10.00 vs $2.50) 4。Claude 3.5 Sonnet 也是類似比例 ($15.00 vs $3.00，5 倍！)。

常見誤區： 你以為限制了 Input 就能省錢，結果模型因為「幻覺」或「過度禮貌」，吐出了一大堆廢話。

控制開關： max_tokens 參數。這不是建議，這是保險絲。永遠要設定一個合理的上限，防止模型發瘋。

3. C (Cached Tokens)：你重複了多少

這是 2024 年底到 2025 年最重要的省錢關鍵字：Prompt Caching (快取)。

大眾認為： API 每次都是全新的，我每次都要付全額。

真相是： 如果你的 System Prompt 或上傳的文件（Context）沒有變，Anthropic 和 Google 都有機制讓你「半價」甚至「一折」使用這些重複內容 。

• Anthropic：Cache Read 價格是 Input 的 10%（省 90%！）。寫入 Cache 雖然貴一點（1.25 倍），但只要讀取第二次就回本了 。
• Google Gemini：Context Caching 對長文本有巨大的折扣，尤其是大於 32k 的內容。
• OpenAI：也有自動的 Prompt Caching，折扣約 50%，無感觸發 。

如果你還在每次請求都全額支付那些一模一樣的 System Prompt 費用，你就是在做慈善。

4. R (Reasoning Tokens)：你想省 Prompt 先付學費

這是最新的坑，主要來自 OpenAI o1 / o3 系列或 DeepSeek R1 等「推理模型」。

現象： 你問了一個數學題，Prompt 只有 10 個 Token，答案只有 5 個 Token。為什麼帳單顯示用了 5,000 Token？

分析： 因為模型在後台進行了「思維鏈」（Chain of Thought）推理。這些推理過程產生的 Token，你看不到，但你要付錢，而且通常是按 Output 的貴費率付錢 。DeepSeek 雖然便宜，但邏輯是一樣的。

結論： 用推理模型時，你付的不是「答案費」，而是「思考費」。對於簡單任務用 o1，就像是用超級電腦算 1+1，不僅慢，而且貴到離譜。

您的省錢對照表（建議存到團隊 Wiki）

有了這張表，你就不再是盲目地看帳單，而是可以精準地指著某一項說：「這裡是 Output 太多了，改 Prompt！」或者「為什麼 Cache 命中率這麼低？」

光說不練假把戲。下一段，我用 3 個真實算例 讓你親眼看到，原來錢是這樣在你不注意的時候燒掉的。

三個算例，把「心魔」變成「可控數字」

很多時候，恐懼源於未知。當你把具體的數字帶入公式，那些模糊的焦慮就會變成可執行的優化項目。我們來看三個極具代表性的場景，這些都是我在實戰中見過的真實「血案」。

算例 A：短問答的陷阱（你以為省，結果輸出超長）

場景： 你做了一個「創意寫作助手」App。

• Input: 用戶輸入：「幫我寫一個關於雨天的故事。」 (約 10 tokens)
• 開發者心態: 「輸入這麼短，肯定很便宜吧？」
• 實際發生: 模型興致大發，寫了一個 2,000 字的短篇小說，文情並茂。
• 計算 (假設 GPT-4o 價格):
  • Input: 10 tokens × $2.5/M = $0.000025 (幾乎免費，可忽略不計)
  • Output: 3,000 tokens (中文約 2000 字) × $10/M = $0.03

衝擊： 你可能覺得 $0.03 還是小錢？如果你的 App 火了，每天有 10,000 個請求：

• 單日成本：$0.03 × 10,000 = $300
• 單月成本：$9,000 美金 

反轉②： 在這個案例中，Input 成本可以忽略不計，Output 佔了總成本的 99.9%。你以為你在控制輸入，其實你放任輸出把你的錢包燒穿。

對策： 限制字數。在 Prompt 強制要求「請用 200 字以內寫作」。這一個簡單的動作，能幫你省下 90% 的錢。

算例 B：長上下文的膨脹曲線（溫水煮青蛙）

場景： 一個醫療諮詢 Chatbot，需要長時間對話。

• 第 1 輪: 用戶問症狀 (Input 100, History 0) -> 便宜。
• 第 10 輪: 用戶還在問。為了讓醫生（AI）記得前面的病情，你每次都把前 9 輪對話帶上。
• 計算: 假設每輪對話平均 500 tokens。
  • 第 1 輪 Input: 500
  • 第 2 輪 Input: 1,000
  • ...
  • 第 10 輪 Input: 5,000 tokens

衝擊： 雖然單價便宜，但 Input 是隨對話輪數「線性堆疊」的。到了第 20 輪，你每講一句話，都要付前面 19 句話的錢。這就是為什麼長對話越聊越貴。

對策： 摘要機制 (Summarization)。每過 5 輪，就用一個小模型（如 GPT-4o-mini）把前面對話摘要成 200 tokens 的「病情摘要」，取代原本的原始對話紀錄。這樣你的 Input 曲線就會從「線性上升」變成「鋸齒狀持平」。

算例 C：快取命中 vs 不命中（天壤之別）

場景： 企業內部的知識問答。你上傳了一本 10 萬字的《員工手冊》(約 150k tokens)，讓員工隨意問答。使用 Claude 3.5 Sonnet。

情境一：不命中 Cache (每次都重傳)

• Input: 150k tokens × $3/M = $0.45 / 每一次請求。
• 如果有 100 個員工各問一次 = $0.45 × 100 = $45。

情境二：命中 Cache (只傳一次，後面讀 Cache)

• 寫入 Cache (第一次): 150k × $3.75/M = $0.56 (比正常貴一點，這是「開卡費」)。
• 讀取 Cache (後續 99 次): 150k × $0.30/M = $0.045 / 次 (這是「一折優惠」)。
• 總計: $0.56 + (99 × $0.045) = $5.01。

結果： $45 vs $5。同樣的功能，同樣的內容，成本差了 9 倍 13。

如果這個系統每天運行，一個月下來就是 $1,350 vs $150 的差距。這已經不是優化，這是生存問題。

結論： 在長文件場景下，沒有 Cache 機制就是把錢丟進水裡。

你看，當你開始算帳，你就不會再糾結「要不要刪掉 Prompt 裡的兩個形容詞」這種微不足道的事了。你會發現，真正的槓桿在於：控制輸出長度、壓縮歷史紀錄、以及死命地命中 Cache。

你要優化的不是一句 Prompt，是你的「請求形狀」(Request Shape)。

說到請求形狀，有一個形狀最容易被忽視，也最容易把你炸穿——那就是「文件」。下一段我們進入最大坑：文件為什麼能把你炸穿。

反轉③：文件不是「附件」，是「兩份輸入」

大多數人把 PDF、Word 檔丟給 LLM 時，心態是把檔案當作 Email 的「附件」。你覺得它只是一個掛在旁邊的參考資料，應該不會佔太多資源。

錯。在 LLM 的世界裡，沒有附件，只有「被展開的 Token」。

當你上傳一個文件，系統其實是在做一件暴力的事：它把文件裡的文字挖出來，轉成 Token，然後硬生生地塞進 Input 框裡。這還算好的。如果你用的是 Vision（視覺）模型直接「看」文件，那恭喜你，你正在支付雙倍甚至三倍的隱形稅。

PDF 轉譯的成本陷阱：OCR vs Vision

讓我們看一個恐怖故事：文件處理的成本陷阱 。

假設你有一份 50 頁的掃描版合約 PDF，裡面有一些表格和簽名。你想把裡面的條款抓出來。

路徑 A：OCR 文字提取（便宜但麻煩）

你先用 OCR 工具（如 Google Cloud Vision OCR 或 Amazon Textract）把字轉成 Text。

• 50 頁文字量大約 20,000 字。
• 丟進 LLM 的 Input Cost ≈ 20k tokens。
• 這是最經濟的做法，因為你只付了文字的錢。

路徑 B：直接丟給 GPT-4o / Claude 讓它「看」（方便但昂貴）

你覺得省事，直接把 PDF 作為 Image 丟進去，或者使用支援 Vision 的 PDF 上傳功能。模型啟動 Vision 能力。

Vision 的計費邏輯是「算圖塊（Tiles）」。

• GPT-4o 處理圖片時，會先把圖片切成 512x512 的小方塊（Tiles）。
• 一張 1080p 的 A4 紙圖片，可能會被切成 4-6 個 Tiles。
• 每個 Tile 收費 170 tokens + 基礎費 85 tokens 16。
• 一張圖可能消耗約 800 - 1,000 tokens。
• 50 頁 PDF = 50 × 1,000 = 50,000 tokens。

發現了嗎？ 同樣一份文件，用「看圖」的方式，Token 消耗量是純文字的 2.5 倍以上。這還沒算上 Vision 模型通常單價更高，而且處理速度更慢。

檢索式（RAG）的隱形索引費

還有另一種情況，你使用 OpenAI Assistants API 的 file_search 功能。你以為上傳了就沒事了？

OpenAI 會在後台默默地把你的文件切塊、做 Embedding（向量化），存進 Vector Store。

帳單來了：

1. Storage 費：向量儲存是要收錢的（雖然現在每天每 GB 很便宜，但積少成多）。
2. 檢索費：每次查詢，它不是只讀「答案」，它是把「檢索到的片段」塞進 Input。如果你的檢索設定不佳（例如 top_k 設太大），一次檢索可能塞進來 20 個片段，瞬間撐爆 Context 19。

結論：先問一句：你需要模型「看版面」還是只要「讀內容」？

如果是後者，請永遠不要讓模型直接「看」PDF。你在用看名畫的眼光讓它看純文字，這是一種極致的浪費。

那到底該怎麼選？下一段我給你一張「文件路徑選擇表」，選錯就貴 10 倍。

文件三選一：貼全文 / 直接丟 PDF / 檢索式（RAG）如何選

處理文件沒有標準答案，只有「最適合你錢包」的答案。我們把常見的三種處理路徑拿來 PK，讓你以後面對文件時不再猶豫。這不僅僅是技術選擇，更是商業選擇。

路徑 1：暴力貼全文 (Full Context)

這是最簡單粗暴的方法。直接把文件內容複製貼上到 Prompt 裡。

• 優點： 模型能看到全貌，推理最準確（Global Understanding）。適合做摘要、大綱分析，或者需要理解前後文邏輯的任務。
• 缺點： 貴。每次請求都要付全文的錢。受限於 Context Window 上限（雖然現在 Context 很大，但錢也很多）。
• 何時選：
  • 文件較短（< 20k tokens）。
  • 你需要針對全文做深度分析。
  • 搭配 Prompt Caching 時的首選（如果文件不常變，這反而是最划算的，因為 Cache Hit 後極便宜）。

路徑 2：直接丟 PDF / 圖片 (Vision Based)

讓模型像人類一樣「閱讀」文件影像。

• 優點： 能理解圖表、排版、手寫字、簽名、複雜的表格結構（如財務報表）。這是純文字提取做不到的 。
• 缺點： 極貴（如前所述，Tile 計費）。速度慢。容易產生幻覺（看錯數字）。
• 何時選：
  • 文件裡有重要的圖表、數據圖。
  • 你需要辨識表單結構或手寫字。
  • 除此之外，嚴禁使用。

路徑 3：檢索式增強生成 (RAG / Retrieval)

把文件切碎存起來，問什麼抓什麼。這是目前企業級應用的主流。

• 優點： 支援海量文件（GB 級別）。單次請求 Input 小（只帶片段），便宜。成本可控。
• 缺點： 容易「斷章取義」。如果問題需要跨段落理解（例如「總結整本書的主旨」），RAG 常常抓不到重點。需要維護 Vector DB 的工程成本，還要調校檢索準確度 23。
• 何時選：
  • 文件極大（> 200k tokens）。
  • 典型的「查資料」場景（如：員工手冊問答、法規查詢）。
  • 你需要精準引用來源。

決策樹：別再用錢做盲測

拿著這個決策樹問自己，這能幫你省下無數的試錯成本：

1. 這份文件裡有圖表/版面資訊必須被理解嗎？
   • YES -> 路徑 2 (Vision) (但要有心理準備付高價，並考慮是否能只截圖關鍵部分)。
   • NO -> 往下一步。
2. 文件總字數是否超過模型的 Context Window (或超過 100k tokens)？
   • YES -> 路徑 3 (RAG) (切片處理，別無選擇)。
   • NO -> 往下一步。
3. 這份文件會頻繁變動嗎？
   • YES -> 路徑 1 (全文) (簡單粗暴，因為 Cache 容易失效)。
   • NO -> 路徑 1 + Prompt Caching (最優解！ 既有全文理解力，又享受 1 折價格。比 RAG 更準，比 Vision 更快)。

很多新手最大的錯誤，就是不管三七二十一全都上 RAG，結果發現模型回答品質很差；或者全都丟 Vision，結果破產。先定義任務，再選路徑。

現在你懂了拆帳，也懂了選路徑。接下來我們要動真格的了。下一段我開始砍帳：最有效的 5 刀，先砍哪裡。

砍帳 5 刀：影響最大排序（每刀都帶代價）

省錢不是「做更少」，是「做同樣事用更短的路徑」。我按照影響力大小與實作難度，為你排出了這 5 刀。每一刀砍下去都能見血（省錢），但也都有代價。這就像是外科手術，你切除病灶的同時，也要小心副作用。

第一刀：Prompt Caching (快取) —— 必砍之刀

這是目前 ROI 最高的優化手段，沒有之一。

• 原理： 如前所述，讓重複的 System Prompt 和 Context 打 1 折 14。Anthropic 和 Google 都有支援。
• 操作： 在 API 請求中啟用 Caching 標記（如 Anthropic 的 cache_control）。將不變的 System Prompt 和大文件放在最前面。
• 省錢幅度： ★★★★★ (最高可達 90%)
• 代價 (阻力)： 極度依賴「一致性」。你的 Prompt 前綴必須完全由一個字都不差。如果你習慣在 System Prompt 裡動態插入當前時間（Timestamp）或者用戶名字，Cache 就會失效。
• 解法： 把動態變數（如 User Name, Time）移到 Prompt 的後段，把靜態的大段規則移到最前段。

第二刀：限制 Max Output Tokens —— 止血之刀

這是防止意外的最強保險。

• 原理： 防止模型寫作文，防止模型陷入無限迴圈輸出。
• 操作： 簡單設定 max_tokens 參數。
• 省錢幅度： ★★★★ (避免意外暴費)
• 代價 (阻力)： 可能截斷內容。如果設定太嚴（例如設 100），模型話講一半被卡掉，使用者體驗極差。
• 解法： 需要根據任務精準調校（例如摘要任務設 500，聊天任務設 1000）。並在前端處理截斷時的 UI 提示。

第三刀：Model Routing (模型分流) —— 智慧之刀

不要用殺雞的牛刀去切豆腐。

• 原理： 簡單的「分類」、「提取關鍵字」任務，交給 GPT-4o-mini 或 Claude 3.5 Haiku；複雜的「推理」、「創意」任務才給 GPT-4o 或 Sonnet 26。
• 操作： 在程式碼裡寫一個路由器（Router），或者使用第三方 Gateway (如 Portkey, Helicone)。先用一個極小的模型判斷意圖，再轉發給大模型。
• 省錢幅度： ★★★★ (小模型通常是大模型的 1/10 甚至 1/30 價格)
• 代價 (阻力)： 開發複雜度上升。你需要維護多個模型的 Prompt（不同模型對 Prompt 的敏感度不同），還需要測試小模型是否夠聰明。

第四刀：Batch API (批次處理) —— 延遲之刀

用時間換金錢。

• 原理： 告訴 OpenAI：「我不急，你 24 小時內幫我算完就行。」換取 50% 的折扣 28。
• 操作： 將即時請求改為上傳 JSONL 檔案到 Batch Endpoint。
• 省錢幅度： ★★★ (穩定的 50% off)
• 代價 (阻力)： 非即時。這完全不適合 Chatbot。只適合後台任務，例如「每天凌晨把昨天的新聞做摘要」、「批次標註數據」。而且需要處理異步架構的錯誤重試。

第五刀：壓縮上下文 (Context Compression) —— 精簡之刀

不要把垃圾帶進下一輪對話。

• 原理： 在把歷史對話餵給模型前，先用演算法或小模型把「廢話」擠乾。只保留關鍵資訊。
• 操作： 使用 LangChain 的 SummaryMemory 或類似機制。或者用 RAG 方式只檢索相關的歷史紀錄。
• 省錢幅度： ★★ (長期積累可觀)
• 代價 (阻力)： 資訊遺失。摘要後的內容可能會丟失細節（例如用戶提到的具體日期），導致模型變「健忘」。

結論： 如果你只能做一件事，請立刻去研究 Prompt Caching。對於大文件應用，它的效果是立竿見影的。

刀法學會了，但很多人是在「上線後」才發現砍錯了地方。下一段給你上線前檢查表：避免優化變災難。

上線前檢查清單：你要盯的不是成本，是「成本機制」

很多團隊的悲劇是這樣的：上線前測了幾次，覺得很便宜。上線後用戶行為一變（例如大家開始上傳 100 頁的 PDF，或者有人寫腳本狂刷你的 API），帳單瞬間爆炸。

省錢不是一次性的活動，是一個監控機制。在按下 Deploy 按鈕前，請逐條核對這張清單。這張清單是用錢買來的教訓。

1. 監控指標 (Metrics) 裝了嗎？

不要只看 OpenAI Dashboard 的總金額。你需要更細的顆粒度 30：

• Cost per Request (單次請求成本): 平均一次對話花多少？如果有異常飆高，是為什麼？
• Cost per User (單用戶成本): 誰是你的「超級大戶」？通常前 1% 的用戶會消耗你 50% 的預算，這些人可能是重度使用者，也可能是惡意攻擊者。
• Cache Hit Rate (快取命中率): 你的快取策略真的生效了嗎？（目標應 > 80%）。如果命中率低，檢查你的 Prompt 前綴是否變動了。
• Token Ratio (Input/Output): 監控這個比例。如果 Output 異常飆高，可能是 Prompt 被注入攻擊了（例如有人叫模型「一直寫別停」）。

工具推薦： 不要自己造輪子。使用 Helicone, LangSmith, 或 Portkey。這些工具能只需改一行程式碼（Base URL），就能幫你把上述指標視覺化 。

2. 硬限制 (Hard Limits) 設了嗎？

永遠不要相信你的程式碼邏輯是完美的。一定要在 API 層或 Proxy 層設下保險絲 33：

• 單日預算上限： 設定一個閾值（例如 $50），超過自動停機。寧可服務中斷，也不要破產。OpenAI 和 Google Cloud 都有這個功能，請現在就去開。
• 單次請求上限： 防止某個 Bug 造成的無限迴圈（Infinite Loop）在一夜之間燒掉幾萬美金 。

3. 異常告警 (Alerts) 通了嗎？

當成本曲線出現「垂直爬升」時，你的 Slack 或 Email 能收到通知嗎？

• 設定：當每小時花費超過 $X 時，立刻發送告警。
• 故事： 曾經有個開發者寫錯了一個 While 迴圈，導致程式不斷地重試錯誤的 API 請求。因為沒有告警，這個迴圈跑了整個週末。如果有即時告警，他可以在 5 分鐘內止損。

4. 你的 Prompt 經過「壓力測試」了嗎？

不要只用「你好」來測試。

• 試著丟進去 10 萬字的亂碼。
• 試著要求模型輸出 10,000 字的廢話。
• 試著上傳 10 個最大的 PDF。
• 看看你的系統會不會因此崩潰，或者產生預期外的天價帳單。

結論： 把 Usage 記錄 + 告警 + A/B Test 變成標準流程，而不是事後檢討的遮羞布。會寫程式是技術，會控制成本才是工程。

FAQ：把「不確定」變成「可控」

最後，我整理了幾個最常被問到的、也是最讓人睡不著覺的問題。我們一次拆掉這些疑慮，讓你讀完這篇報告後，能有底氣地去按那個「部署」按鈕。

Q1: 我真的很怕無限迴圈（Infinite Loop）把卡刷爆，除了設限額還有救嗎？

A: 有。將你的卡換成「簽帳金融卡 (Debit Card)」或「虛擬信用卡 (Virtual Card)」。

不要綁定額度 50 萬的本尊信用卡。去申請一張專門付 API 費用的虛擬卡（如 Privacy.com 或銀行提供的類似服務），每個月只存入固定金額（例如 $100）。這是物理層面的熔斷機制。就算 Google / OpenAI 算錯帳，扣不到錢就是扣不到錢，頂多帳號被鎖，但你的房子保住了 。

Q2: OpenAI 的 o1 / o3 這些推理模型這麼貴，到底值不值得用？

A: 對於 90% 的 CRUD 應用來說，不值得。

只有當你的任務涉及「複雜數學」、「高難度程式碼重構」或「多步驟邏輯推理」時才用。如果你只是拿它來做聊天機器人或文本摘要，那就像是用法拉利送外賣——又貴又沒必要。請務必分流：預設用 GPT-4o-mini，遇到難題再切換到 o1 35。

Q3: 使用開源模型（Llama 3, DeepSeek）自架會比較省嗎？

A: 通常不會，除非你的量巨大。

自架模型有隱形成本：GPU 租賃費（好顯卡很貴）、維運人力、待機成本（沒人用的時候 GPU 也在燒錢）。API 的好處是 Pay-as-you-go（用多少付多少）。通常要達到每個月數千美金以上的規模，自架才會開始顯現成本優勢。對於初創專案，Token-based API 依然是現金流最友善的選擇。

Q4: 聽說 DeepSeek 的 API 價格便宜到可以忽略不計，我是不是該全部遷移過去？

A: 價格上確實是破壞式的（約 OpenAI 的 1/10 甚至更低）。

但要注意穩定性和數據隱私。如果你是做企業級應用，SLA（服務層級協議）可能比單價更重要。建議採用「混合策略」：非核心、對延遲不敏感的任務（如後台數據清洗）丟給便宜模型；核心用戶體驗依然留給最穩定的主流模型（如 GPT-4o 或 Claude 3.5 Sonnet）。

結語：你要做的是工程師，不是賭徒

這篇文章從開頭的焦慮，講到了拆帳的邏輯，再到具體的砍帳刀法。

一開始，你怕的是帳單；現在你應該明白了，你真正怕的其實是「不可解釋的成本」。當你能看懂每一個 Token 是怎麼產生的，當你能精準預測下個月的預算是 $50 還是 $500 時，帳單就不再是威脅，而是你的儀表板。

AI 開發不再是寫寫 Prompt 就好的時代了。這是一個精算的時代。誰能用最少的 Token 換取最大的智能，誰就是贏家。

最後送給大家三句話，希望你貼在螢幕旁邊，時刻提醒自己：

「API 成本不是被模型決定，是被你餵給它的習慣決定。」

「你以為在省 Prompt，其實你在放任輸出燒錢。」

「不會拆帳的優化，叫運氣；會拆帳的優化，才叫工程。」

現在，別再刷手機了。去打開你的 IDE，檢查你的 System Prompt，把那個該死的 JSON 輸出改成 YAML，去申請一個 Cache Key。那裡正躺著好幾張百元美鈔，等你把它們撿回來。