AI token 是什麼?為何中文字數不等於 token 數?

黏土機器人整理長短不同的紙片積木,旁邊放著筆記本,象徵文字被切分成模型處理的單位

把一篇兩千字的中文文章交給 AI,是否就等於送入兩千個 token?答案是:不能直接這樣換算。AI token 是模型處理內容的單位,不等於中文字數、英文單字數,也不等於檔案大小。

真正容易出錯的地方,不只是中文怎麼分詞,還包括用了哪個 Tokenizer,以及你數的是一段正文,還是包含系統指令、對話與工具定義的完整請求。這篇先說清楚 token 的概念,再整理實際計數時應注意的邊界。

AI token 是什麼?不是一個字,也不一定是一個詞

OpenAI 官方說明指出,token 可以代表一個字元、單字的一部分、整個單字或標點;空白也會影響文字如何被切分。因此,「一個中文字固定等於一個 token」或「一個英文單字就是一個 token」,都不是通用規則。

文字經過 Tokenizer,會被轉成模型可處理的 token 序列與對應編號。這個過程常稱為 tokenization,中文可稱詞元化或分詞,但它不一定依照人類閱讀時認為完整的詞義切分。

這也表示,看到 token 邊界很零碎,不代表模型只理解零碎的字;同樣地,某段文字剛好只用少數 token,也不能據此推論模型比較理解它。計數單位與理解品質,是不同的問題。

為何中文字數不等於 token 數?

中文、英文、混合語言、數字與符號,會遇到不同的編碼情況。模型使用的編碼方式不同,同一段原文也可能得到不同的 token 數。

例如,「你好」與「你好!」不只是字數不同,實際如何切成 token,還要看指定的 Tokenizer。繁體字、專有名詞、網址、程式碼與特殊符號混在一起時,更不應只靠肉眼估算。

官方常見的「約四個字元是一個 token」等說法,是對英文文字的粗略估計,不是可以直接套用到所有中文文章、所有模型的換算公式。即使文章長度相同,只要內容與編碼不同,token 計算結果就可能不同。

因此,也不能一概認為把中文翻成英文就一定更省 token。翻譯會改變文字長度與表達方式;實際結果仍要用目標模型對應的計數方法檢查,還要確認原意沒有因此改變。

帶有抽象紋路的長紙條、長短不同的青綠紙片與筆記本並列,象徵不同編碼會有不同切分方式
原創概念插圖,非實際分詞結果:不同 Tokenizer 對相同文字的切分與計數,可能不同。

同一段文字,換 Tokenizer 就可能換一個數字

OpenAI 的 tiktoken 教學提供固定編碼的比較示例:同一個英文單字 antidisestablishmentarianism,在 r50k_base 編碼中是 5 個 token,在 cl100k_base 中則是 6 個。

這個例子說明的是相同文字不保證在不同編碼下得到相同計數,而不是哪種編碼在所有內容上都比較好。該教學已標示為封存資料;這裡只引用其固定字串與編碼示例,不把舊模型對照表當成現行模型支援清單。

實際工作時,先確認目標模型與其支援的計數方式。不要拿某個網站預設的 Tokenizer 結果,當成所有平台通用的精確值;模型或編碼更新後,也應重新檢查。

只數正文,為何可能低估完整輸入?

你貼進計數工具的文章,未必就是模型實際收到的全部輸入。完整請求還可能包含:

  • 系統指令與其他角色的訊息。
  • 本次一起送入的對話內容。
  • 工具名稱、用途描述、參數結構與其他格式定義。
  • 圖片、檔案或其他多模態內容,以及服務使用的請求格式開銷。

OpenAI 官方說明特別區分「純文字 token 計數」與完整請求的計數,指出訊息結構、工具、schema、圖片與檔案都可能影響輸入總數。純文字工具即使把那段文章數對了,也不代表它已涵蓋完整請求。

Claude 官方計數文件也提醒,計數結果屬於估算,實際輸入用量可能有小幅差異;其計數功能支援的請求組件亦有範圍限制。使用前要確認工具支援什麼,不要假設所有外部工具與附件都已自動算入。

圖片、音訊與影片,不能用可見字數推算

如果你交給 AI 的不是只有文字,單純計算中文字數就更不適用。Google Gemini 官方 token 文件說明,文字、圖片、音訊與影片等輸入都涉及 token 計數,不同媒體會依其處理方式計算。

一張看起來沒有文字的照片,也可能佔用輸入用量;影片也不是只把字幕拿來計數就完整。實際結果要依模型、媒體處理模式與官方支援的計數方法確認,不能靠「畫面上有幾個字」代替。

手拿裝有文件、圖像與對話紙卡的文件夾,桌上有測量工具,象徵計數時需考慮完整請求內容
原創概念插圖,非用量圖表:完整輸入可能含訊息、工具與媒體,不只是使用者可見的一段正文。

輸入 token、輸出 token 與可見回答,要分開看

輸入 token是請求提供給模型的內容;輸出 token是模型生成的內容。輸入計數工具能協助檢查送入多少,卻不能預先精確知道模型最後會產生多少輸出。

OpenAI 官方文件也指出,推理模型可能使用不直接顯示為回答文字的內部推理 token。因此,可見回答很短,不一定代表整次生成只使用那段文字所對應的 token。

此外,上下文視窗、最大輸出與請求頻率限制,也不是同一種限制。這篇不把不同模型的上限混成一套公式;使用時要查看指定模型與端點的文件,並為需要的輸出保留空間。關於長文件的另一個問題,可延伸閱讀AI 上下文視窗:放得下為何仍可能漏重點。

實際做 token 計算,可以照這個順序

先確定你要量哪一種東西

如果只是想觀察一段文字怎麼被切分,可以用對應模型的 Tokenizer。若要判斷整個 API 請求的輸入大小,則應使用該服務支援的完整輸入計數功能,並確認它涵蓋哪些訊息、工具與媒體。

保留會真正送出的內容與格式

計數時用實際要送出的版本,包括標點、換行、網址與必要說明。不要為了讓數字好看,先把來源、欄位名稱或重要條件刪掉,卻用另一份內容正式執行。

如果需要把文字貼進外部網站,先確認服務來源與資料處理方式;敏感文件可改用不含私人資料的測試文字,避免為了估算而多一次不必要的資料分享。

最後對照實際請求的使用紀錄

有 API 使用紀錄時,對照該次請求回傳的 usage 等用量欄位,分清楚輸入、輸出及其他服務提供的分類。事前計數與事後紀錄用途不同,不能把一次正文估算當成後續所有請求都固定相同。

如果團隊會持續修改提示詞,也可以把模型、提示版本與計數結果一起保存;但驗收仍要看答案是否符合要求,而不是只選 token 最少的一版。提示詞版本的管理方法,可參考AI 提示詞管理與測試題的做法。

結論:先選對計數對象,再談數字大小

AI token 不是中文字數的另一種寫法。它取決於文字內容、Tokenizer 與模型,也可能受到完整請求中的訊息、工具與媒體影響。

下次看到「這段文字有多少 token」,先問兩件事:用哪個模型的計數方式?數的是純文字,還是完整輸入?把這兩點說清楚,數字才有比較意義,也比較不會把估算、上下文容量與實際使用量混在一起。