AI模型處理文字的基本單位。一個 token 通常是單字或單字片段 — 「understanding」可能是單個 token，而「un」+「der」+「standing」則可能是三個。平均來說，一個 token 大約相當於英文單字的 3/4。模型會以 token 為單位進行讀取、運算與計費。
詞元（token）是由分詞器（tokenizer）產生的，分詞器是一種在神經網絡處理您的文本之前運行的獨立演算法。目前最常見的方法是字節對編碼（Byte Pair Encoding，BPE），此方法被 GPT、Claude 和 Llama 所使用。BPE 從單個字元（或字節）開始，反覆合併出現頻率最高的字元對為新的詞元。經過足夠次數的合併後，常見的單字如 "the" 或 "and" 會成為單一詞元，而較少見或專業的單字則會被拆分成子詞元。單字 "tokenization" 本身可能會被拆分成 "token" + "ization" 或 "token" + "iz" + "ation"，這取決於所使用的分詞器。這種子詞元方法正是現代模型能合理處理拼寫錯誤、新造詞和程式碼的原因——它們從來不會遇到真正的「未知」單字，只會遇到由已知片段組成的不熟悉組合。
不同模型使用不同的分詞器與詞彙表，這一點比大多數人意識到的更重要。GPT-4 的分詞器（cl100k）約有 100,000 個詞元類型。Claude 的分詞器則不同。Llama 使用的是另一種分詞器。相同的英文句子根據所使用的模型，可能會被拆分成不同數量的詞元，這直接影響上下文窗口的使用與 API 的成本。程式碼通常比散文的詞元效率更低，因為變數名稱和語法詞元在訓練資料中出現的頻率可能不足以獲得自己的詞彙表條目。非英文語言的差異則更加顯著——使用拉丁字母的語言通常與英文一樣高效地進行詞元化，但中文、日文、韓文、阿拉伯文和印地文往往需要更多詞元來表達相同的意思，因為這些語言的字元在分詞器訓練期間可能沒有被充分代表。
分詞器的詞彙表大小會產生真正的工程權衡。較大的詞彙表意味著常見的單字和短語會有專屬的詞元，因此您的文本可以壓縮成更少的詞元（成本更低、速度更快、能放入更多上下文）。但較大的詞彙表也意味著模型輸入和輸出層的嵌入表（embedding table）會更大，這會增加模型大小和記憶體使用量。在模型維度為 4,096 的情況下，100,000 個詞元的嵌入表已經有 4 億個參數——這對較小的模型來說已經是一個不小的數字。這就是為什麼詞彙表大小通常集中在 32K–128K 範圍內：這是壓縮效率與參數開銷之間的最佳平衡點。
當服務商宣傳上下文窗口大小（例如 8K、128K、1M 個詞元）時，這些數字包含了所有內容：您的系統提示、對話歷史、您貼入的任何文件，以及模型自身的回應。開發者常見的錯誤是將上下文窗口填滿參考資料，卻為模型留下太少的詞元來生成具體的回應。大多數 API 允許您設定回應的 max_tokens 參數，但如果您的輸入已經消耗了大部分上下文窗口，模型可能會截斷其思考過程或拒絕回答。實際上，您需要進行規劃：了解模型的上下文限制、估算輸入大小（3/4 字詞法則是一個粗略的指南——如需精確，請使用服務商的分詞器程式庫），並為所需的輸出保留足夠空間。
還有另一個大多數人低估的成本維度。在 API 定價層級中，輸出詞元通常比輸入詞元貴 3–5 倍，因為生成每個輸出詞元需要完整的模型前向傳播（forward pass），而輸入詞元可以平行處理。這種不對稱性意味著提供長而冗長回答的聊天機器人成本會遠高於訓練為簡潔回答的模型。這也是為什麼像提示緩存（prompt caching）這類技術（在多個請求中重複使用處理過的輸入詞元）可以顯著降低應用程式成本，特別是在許多查詢共用相同系統提示或文件上下文的情況下。理解詞元經濟學不僅僅是理論——這差異可能讓一個 AI 功能每月運行成本從 50 美元變成 5,000 美元。