Token 是什麼？AI 看到的文字，跟你看到的不完全一樣

你在聊天框輸入「台北今天會下雨嗎？」時，畫面上看起來只有九個中文字和一個問號。但大型語言模型真正開始計算以前，這串文字還會先經過一道處理：tokenizer 會把文字切成模型詞彙表裡可以辨認的單位，再把每個單位換成數字 ID。模型後面處理的，不是螢幕上的字形，而是這串 token 對應的數值表示。

Token 可以先理解成：模型處理文字時使用的基本單位。 它可能是一個完整的字、一個常見詞的一部分、標點符號，甚至只是某段位元組序列。它不等於「一個字」，也不等於「一個英文單字」。真正怎麼切，要看那個模型使用哪一套 tokenizer 與 vocabulary。

一句話為什麼不能直接丟進模型？

神經網路真正運算的是數字。文字本身不能直接拿去做矩陣乘法，所以系統需要先建立一套「文字片段 ↔ 數字」的對照。tokenizer 做的事情，就是按照既定規則把輸入拆成 token，再查詞彙表把它們換成 ID。

假設某個 tokenizer 把「learning」切成一個 token，另一個 tokenizer 可能切成「learn」和「ing」。中文也一樣，不保證一個中文字就是一個 token。有些常見字詞可能被合在一起，有些罕見符號、混合語言或特殊字元則可能被拆得更細。這也是為什麼只看「幾個字」很難精確推算 token 數。

不同模型甚至可能用不同的 vocabulary，因此同一句話丟進兩個模型，token 數量可以不一樣。Token 不是語言本身自然存在的切法，而是模型訓練與 tokenizer 設計共同決定的表示方式。

Token ID 也不是文字的「意思編號」

如果「雨」剛好被 tokenizer 編成 ID 18432，這個數字本身沒有「潮濕、天空、降水」之類的意義。它首先只是詞彙表裡的一個索引。模型會再把這個 ID 對應到向量，也就是 embedding，讓後面的 Transformer 能在連續的數值空間裡處理它。

所以 tokenization 和 embedding 是連在一起的兩步，但不是同一件事。前者處理「文字要切成哪些離散單位」，後者處理「這些單位要用什麼向量表示」。把兩者混在一起，很容易誤以為 tokenizer 已經理解句子的意思；其實它主要負責的是編碼。

Context Window 為什麼用 token 算？

模型一次能處理的上下文有上限，這個上限通常用 token 數表示，也就是常說的 context window。你送進去的 system prompt、對話紀錄、文件內容，以及模型要產生的輸出，都會依模型與 API 的規則占用上下文空間。

這也是「上下文很長」不等於「模型記得所有事情」的原因。Context window 描述的是一次推理時模型能接觸到多少 token，不是永久記憶。如果舊訊息已經不在這次輸入裡，模型不會因為以前看過就自動保留；產品若有長期記憶，通常還需要資料庫、檢索或其他額外系統。

而且更多 token 也不等於一定更好。輸入越長，計算量、延遲與成本通常也會增加，真正重要的是把相關資訊放進去，而不是把所有資料毫無選擇地塞滿 context window。

Token 為什麼也會變成帳單上的單位？

許多模型 API 會依輸入與輸出的 token 數計量，因此同樣是一頁文字，不同語言、符號密度、程式碼比例與 tokenizer 都可能產生不同 token 數。這不是因為某種語言「比較難」，而是因為切分方式不同。

這也代表「一千字大概等於幾個 token」只能當粗略估算。真正需要精準控制長度、成本或 context window 時，應該使用該模型實際對應的 tokenizer 計算，而不是用固定的字數比例硬換算。

模型產生文字時，其實也是一個 token 一個 token 往後接

在 LLM 裡，我們提過語言模型的核心任務是根據目前的上下文預測下一個 token。模型不是先在腦中寫完一整段，再一次把答案倒出來；它會根據前面的 token 計算下一個 token 的機率分布，選出一個結果，再把新 token 放回上下文，繼續預測下一個。

最後，系統再把模型產生的 token ID 交給 tokenizer 的解碼流程，重新組回你在螢幕上看到的文字。從使用者的角度看是一段自然語言；從模型的計算流程看，則是一串一步一步延伸的 token。

所以 Token 並不是 AI 世界裡為了計費才發明的小單位。它位在文字和模型計算之間：決定輸入怎麼被切開、模型一次能接觸多少內容，也構成語言模型逐步生成輸出的基本節奏。理解 token 之後，context window、prompt 長度、生成速度與 API 用量，就不再是幾個互不相干的名詞。