前言

每次看 API 帳單或看到 Token 耗盡的錯誤時，是不是都會有一種「這到底是什麼東西在計費」的懵懵懂懂？

LLM 的 Token 機制和 Context Window，聽起來很高深，但其實就是這兩個東西在決定你的程式會花多少錢、會不會卡。我今天不講大道理，只用最實際的方式拆解它們，還有我在實務上踩過的坑。

Token 到底在算什麼？

最常見的迷思是：Token 等於一個英文字母，或等於一個中文字。

其實 Token 是模型底層的「碎塊」。英文大概 4 個字元等於 1 個 Token，中文因為每個字佔用空間較大，通常 1 個中文字會被拆成 1 到 2 個 Token（視語言模型而定）。

舉個例子，Prompt 寫這樣：

1
請將以下文章翻譯成英文：今天天氣很好。

這句話大約會消耗 15-20 個 Token（Input token）。你會發現，中文的 Token 消耗速度比英文快很多，這也是為什麼台灣工程師特別需要注意的地方。

Context Window 不是越大越好

Context Window 就是模型一次能記住的「工作記憶」容量。你可以想像成你開會時能同時記憶的紙張數量。

早期的模型可能只有 4K 或 8K Token，現在有些模型已經有 128K 甚至 1M。聽起來很爽，但實務上並不是越大越好。

首先，Context 越大，每次請求的延遲通常會越高。模型需要花更多時間去「讀」進去的所有內容。其次，成本也會跟著長。

實務上我們常見的坑是：一個長輸入的請求把 Context Window 塞滿了，下次請求的時候，前面已經被擠出去，模型「前後記憶斷線」，開始胡言亂語或遺忘前面的指令。

計費的不對稱：Input vs Output

這一點在實務上最容易被忽略，但對成本影響最大。OpenAI 的計費通常分 Input（輸入）與 Output（輸出），而且 Output token 的單價通常比 Input 高上不少。

這代表什麼？代表你如果在 Prompt 裡塞了 10 萬 Token 的長文給模型分析，再讓它回覆 100 Token，這筆交易花費的錢，絕對不會只是 100 Token 的價格。

舉個對比：

  • 做法 A：把 50 頁的 PDF 全丟進去，讓模型自己 summarize。
  • 做法 B：先用簡單的指令把 PDF 拆成段落，逐段 summarize 最後再合併。

做法 A 的 Input token 非常貴；做法 B 雖然多跑幾次 API，但單次 Input 短，總花費反而比較划算。所以在設計 RAG 或長文處理流程時，一定要把 Input 的 Token 量考慮進去。

實務上的可操作建議

怎麼避免 Token 吞噬你的預算？我有幾個很實用的做法：

  1. 控制輸入長度：長文先分段處理，不要一頁全丟。
  2. 使用結構化輸出：在 Prompt 中要求 JSON 格式的回應，這樣模型不會產出大量多餘的解釋文字，能省下 Output token。
  3. 善用快取：對於固定不變的 System Prompt 或常見查詢，透過快取機制（如 OpenAI 的 Prompt Caching）直接減少重複計費的 Token 數量。

小結

Token 不是玄學，而是你程式碼裡真實的資源消耗。Context Window 是容積，不是要塞滿才好。了解它們的運作方式，才能在寫 Prompt 與設計 AI 系統時，把價格與效能拿到最好的平衡。如果下次看到 API 帳單卡很高，不妨先算算你的 Token 到底在哪裡跑掉了。