定義
Token 是 AI 模型讀取與產生文字時使用的基本語言單位。它可能是一個中文字、一個英文單字、單字的一部分、數字、標點或特殊符號；模型不是直接以人眼看到的「字數」運算，而是先將內容切成 Token，再進行預測與生成。Token 數量會影響可處理長度、回應速度與使用成本。
不同模型使用的分詞器不同，所以同一段內容不一定得到相同的 Token 數。中文、英文、混合語言、表格與程式碼也可能有不同切法。這也是為什麼企業不應只用字數或頁數推測 API 用量，而要以實際模型測量。
為什麼 Token 數量影響費用？
Token 會影響費用，因為模型服務通常分別計算送入模型的輸入內容與模型產生的輸出內容；輸入越長、回答越長，單次請求的用量通常越高。重複送出相同背景資料、保留過長對話紀錄，或因格式不清造成反覆重試，都是常見的隱形成本。
企業應先把每個流程拆成「固定指令、使用者資料、檢索內容、模型回答」四部分，再觀察哪一部分最長。客服若每次都附上完整手冊，可能比先找出相關條款更浪費；報表若只需要三個欄位，也不必讓模型重寫整份原始資料。可參考 LLM（大型語言模型） 與 上下文窗口 理解模型的處理邊界。
中文與英文的 Token 差異
中文與英文的 Token 數不能用固定比例互換，因為分詞器會根據字詞是否常見、字元組合與語言特性切分。中文短句常以字元或常見片段拆分；英文常見單字可能是一個片段，罕見拼字、網址、代碼與混合符號則可能被切成更多片段。
這個差異會出現在多語客服、翻譯、跨國報表與程式碼分析。估算時，抽取一批代表性資料，使用目標模型的 tokenizer 或 API 回傳資訊測量，再用輸入量、輸出量和尖峰情境建立範圍。不要把第三方模型的換算結果直接套到另一個模型。
如何估算 Token 用量？
估算的第一步是界定一次請求真正需要的內容：問題、必要背景、文件片段、輸出格式與歷史訊息。第二步以實際模型測量輸入 Token，並用幾種代表性問題測量輸出 Token。第三步將單次用量乘上預期的請求量，同時加入重試、人工追問與高峰流量等情境，形成可供採購與監控使用的區間。
長文件不要只用頁數估算，因為頁面可能包含表格、掃描影像、頁首頁尾與格式標記。先抽取文字、去除重複頁首頁尾，再測量會更接近實際。若流程還包含圖片或音訊，則應依該模型的輸入規則另外確認，不要把它們當成一般文字 Token。
實務上的成本控制
有效的成本控制不是單純要求模型少回答，而是減少無效輸入並提高一次回答的命中率。固定任務可用短而清楚的模板；長對話可定期摘要，只保留仍會影響決策的資訊；知識庫問答可用 RAG 先檢索相關內容，避免每次載入整份文件。
同時要設定輸出格式，例如欄位、項目數與必要的結論，並記錄每個流程的 Token 用量、延遲、錯誤與人工重做率。若要做語意檢索，可延伸閱讀 Embedding 與 向量資料庫。資料治理、權限與內容正確性不能因節省 Token 而被省略。
實際應用範例
企業可把採購信件先分成詢價、交期、規格與售後等類別，只把與當前任務相關的段落交給模型，再要求輸出固定欄位。這比把整個信箱或完整附件反覆送出，更容易查明用量，也方便人工覆核。
內容團隊也可以先用模型產生摘要，再讓後續步驟只讀取摘要與必要原文。摘要不能取代重要原文的查核，但能在大量資料整理流程中減少重複背景，讓 Token 用在真正需要推理的地方。
導入時的檢查清單
導入前確認目標模型的計費方式、分詞工具、輸入輸出限制與資料保存政策；上線前用真實但已去識別化的樣本測量一般與尖峰用量；上線後依流程追蹤成本、品質與失敗重試。若成本上升，先找出哪個輸入區塊膨脹，再調整切分、檢索或輸出規格，而不是盲目更換模型。
還要把 Token 預算和品質一起看。過度壓縮可能刪掉例外條件，導致人工返工；只追求短回答也可能讓重要依據消失。可為每個流程設定最低必要來源、最大輸出範圍與超限處理，讓成本控制不會犧牲可稽核性。
建立成本基準時，分開記錄輸入與輸出，並標記模型、流程版本、文件類型與重試原因。這樣才能分辨是使用量增加、提示變長、資料切分失效，還是品質下降造成返工。每次調整後用同一批案例比較，避免只看帳單總額做錯判斷。過度壓縮可能刪掉例外條件，導致人工返工；只追求短回答也可能讓重要依據消失。可為每個流程設定最低必要來源、最大輸出範圍與超限處理，讓成本控制不會犧牲可稽核性。