PLAY AI 筆記回 PLAY AI
AI 知識科普發布 · 更新 · 2 分鐘 · 約 1,106 字

Token 是什麼，為什麼 AI 收費要用這個單位算

Token 不是固定等於一個字或一個單字。搞懂文字怎麼被 tokenizer 切開，才能理解上下文限制與 API 帳單。

PLAY
PLAY AI 編輯部把複雜概念拆成一般人也讀得懂的版本，聚焦名詞解釋、比較、來源與實作脈絡。
本篇內容
一條青紫色光帶逐步分解成許多發光方塊，象徵文字被 tokenizer 切成 token。
一條青紫色光帶逐步分解成許多發光方塊，象徵文字被 tokenizer 切成 token。

模型先看到的是 token，不是你眼中的字數

送進語言模型之前，文字通常會先經 tokenizer 轉成 token id。Token 可以是一個完整單字、單字的一部分、標點、空白，或某些語言中的一個或多個字元；實際切法取決於那個模型使用的 tokenizer。

同一句問候的切分對照：英文 How are you today 被切成數個片段，中文「你今天過得好嗎？」也被切成數個片段。
示意重點不是哪個語言一定比較省，而是「你看到的字元數」不等於模型真正計算的 token 數；不同模型與 tokenizer 也可能切得不一樣。

為什麼同一句話換模型，token 數可能不同

Tokenizer 的詞彙表與切分演算法是模型系統的一部分。常見片段可能被合併成一個 token，少見字串則可能拆成很多個。程式碼、URL、特殊符號、混合語言與罕見專有名詞尤其容易出現和肉眼字數差很多的結果。

因此不要把「一個 token 大約等於幾個字」當成精確換算公式。估算內容長度可以用經驗值，但真正做成本控制或避免超出上下文時，最好用該模型對應的 tokenizer 或供應商回傳的 usage。

上下文視窗到底在裝什麼

一次請求裡常見的 token 來源

來源會不會吃上下文容易被忽略的地方
System / developer 指令會每輪都可能跟著請求送出
使用者訊息會長文件與附件轉成文字後可能很大
歷史對話會對話愈長，重送的歷史愈多
工具結果／檢索內容會搜尋摘要、RAG 片段也會佔空間
模型輸出通常計入總上下文限制回答愈長，就留給輸入的空間愈少

所以「模型支援很長上下文」不代表你可以把整個資料庫每次都塞進去。可用容量還要留給系統指令、歷史對話、工具結果與最終輸出，而且長上下文本身也會增加延遲與成本。

帳單為什麼常常不是你以為的字數

API 常把輸入與輸出 token 分開計價，價格也可能不同。真正容易讓成本增加的情況，不只是一段回答太長，而是每次請求都重複帶著大量不必要的歷史、文件或工具結果。

先從這些地方找不必要的 token

症狀可能原因可以先做什麼
對話越聊越慢每輪都帶完整歷史摘要舊內容或只保留必要狀態
RAG 成本突然變高取回片段太多或太長調整 top-k、chunk 與重排策略
固定模板很長大量不變文字反覆傳送縮短指令；若供應商支援再評估快取機制
輸出費用高回答沒有長度界線明確設定輸出格式與合理長度

實際做產品時，我會怎麼看 token

  1. 先記錄每個 route 的 input / output usage，不要只看整月總帳單。
  2. 把長 prompt 拆開看：哪些是固定指令、哪些是歷史、哪些是檢索結果。
  3. 對不同模型不要直接沿用同一個 token 換算假設，實際跑 tokenizer 或看 usage。
  4. 成本優化最後才考慮換便宜模型；先清掉不必要的上下文，通常比較不傷品質。