1 個 token ≈ 多少字：LLM 計費裡的隱形單位

如果你算過 AI API 的帳單，會發現計量單位不是「字」也不是「詞」，而是 token。工程師常見的第一個問題：一個 token 是不是等於一個字？不完全是。

token 是怎麼切出來的

現在的大模型幾乎都用 BPE 一類的分詞器，思路是：從字元甚至位元組出發，看訓練語料裡哪些相鄰片段出現得最頻繁，就把它們合併成一個新符號，重複這個過程，直到詞表達到預定大小。高頻詞整塊保留，低頻組合被拆開，詞表裡沒有的（生僻字、emoji、特殊符號）落到位元組級編碼。

後果是不同語言差別很大：

- 英文：一個 token 約 4 個字元，折合 0.75 個單字

- 中文：一個常用字約 1~2 個 token，生僻詞、地名、人名經常一字一切

- 日文、韓文和 emoji 同樣偏貴

所以同樣 1000 字的正文，中文比英文貴 2~3 倍。這不是定價歧視，是詞表覆蓋率的直接結果。

程式碼也比自然語言「貴」。識別字、底線、camelCase、特殊符號在語料裡出現頻率低，往往兩三字元一切；一筆和中文一樣長的提交訊息，token 數可能是日常對話的兩倍。

別用肉眼數。兩個做法：

1. 用 API 回應裡的 usage 欄位。prompt_tokens 和 completion_tokens 就是結算值，系統提示詞、few-shot 範例、之前所有輪次都算在內。

2. 請求前想離線估算，就用對應模型族的分詞器（如 OpenAI 系對應 tiktoken 的編碼）。注意不同模型族詞表不同，同一段文字的 token 數不一樣，別把 GPT 系的數直接套到 Qwen 或 Claude 上。

量級估算夠用就行：英文 1 token ≈ 4 個 ASCII 字元；中文 1 字 ≈ 1.5 個 token，上下浮動 30%。

1. **系統提示詞每次都算錢。** 2000 token 的系統提示詞調用 1 萬次，就是 2000 萬 token 的固定開銷。支援 prompt caching 的平台，把靜態內容放最前面，命中快取後單價大幅下降。

2. **輸出 token 單價通常是輸入的 2~4 倍。** 影響成本最大的參數是模型話多話少。把回答限制在 500 token 內，往往比塞 2000 token 背景更省錢。

3. **除錯與迴圈。** 復算、重試、多輪 function calling 的中間產物都是隱形 token。開發期把 usage 和回覆一起列印，別只看文字。

假設一個客服問答系統：系統提示詞 3000 token，使用者提問平均 200 token，回答限制 600 token，每天調用 1 萬次。單價按輸入 3 元、輸出 15 元每百萬 token 算（數字僅作範例，套你實際用的價格）。

單次開銷：輸入 3200 token 約 0.0096 元，輸出 600 token 約 0.009 元，合計約 0.0186 元；放大到每天 1 萬次就是 186 元。

優化方向有兩個，效率差別很大：把系統提示詞砍半，每次省 1500 個輸入 token，一天省 45 元，帳單降四分之一；把回答平均長度從 600 壓到 400 個 token，一天只省 1 元，毛毛雨。先動最大項，再用監控驗證效果，比憑感覺改提示詞靠譜。

標稱上下文視窗是輸入加輸出的總預算。處理長文字時，可用輸入 = 視窗上限 − 你還要生成的輸出。計畫「塞幾篇文件進去」，要按扣除輸出後的剩餘額度算，不然會撞上截斷或報錯。

token 同時是三件事的單位：模型理解的最小顆粒、上下文預算的刻度、帳單的計價單位。把 usage 欄位打出來記下來，成本核算就從猜測變成四則運算：先量，再算，然後按金額從大到小一項項壓。