簡介
大型語言模型的運作，不只是靠模型權重與提示詞 其每一套系統的核心都是一個Tokenizer（分詞器，又稱標記器），也就是決定文字該如何拆解成「詞元」(token) 的元件。而這些詞元將決定算力的需求、API 呼叫的成本，以及模型的情境窗口 (context window) 能塞得下多少文字。
分詞器的行為一旦發生變化，其影響將對工程與業務績效帶來連鎖反應。同樣的一段文字，可能突然需要用到二倍至三倍的詞元量。對開發人員和平台團隊來說，這將顯現在 CPU 用量攀升、情境變短，以及延遲變長等問題。對 CIO、CISO、CFO 或 FinOps 領導人來說，這將顯現在帳單金額激增、服務不穩定，以及有些語言的使用者體驗變差。
此風險的起因可能有兩種：
- 意外漂移：分詞器檔案出現錯誤、組態設定不當，或是未經檢驗的變更。
- 對抗性操弄：有人刻意試圖篡改分詞器的產出物 (artifact) 來升高成本、消耗配額，或是削弱模型的安全性。
這種現象我們稱之為「詞元化漂移」(tokenization drift)，這是一種隱藏性陷阱，因為模型表面上仍正常運作，但成本、效能和公平性卻默默變得對您不利。本文說明此陷阱如何運作、在實務上看起來如何，以及技術團隊和決策者該如何偵測及防範。
詞元化漂移的威脅模型
有些情況是出於意外 (如錯誤、組態設定漂移)，有些則來自蓄意對抗 (如惡意上傳、針對性攻擊)。但兩者對企業所造成的衝擊是一樣的：成本升高、服務品質下降。詞元化漂移出現在真實系統的情況有幾種：
惡意上傳： 有人將一個已修改過分詞器的模型上傳到公共儲存庫，下載和使用該模型的團隊一開始可能不會注意到有任何問題，因為模型還是可以正常執行。
意外漂移： 在公司內部，工程師可能會複製另一個專案的分詞器，或者從儲存庫拉取 (pull)「最新的版本」而未加以檢驗。分詞器的檔案只要出現微差異，就可能默默墊高成本。
經濟式阻斷服務 (EDoS)： 駭客只要提高詞元量，就能燒光 API 配額，或者讓雲端帳單金額飆升。這雖然不會造成當機，但仍是一種阻斷服務 (DoS) 手法，因為系統將因成本過高而無法運作。
語言偏見： 駭客 (甚至一個未仔細測試的分詞器) 可能會讓某些語言變差，比方說，英文不受影響，但中文或印度文的處理成本卻突然爆增三倍。這會導致不同使用者所獲得的服務品質不一。
弱化安全規則： 分詞器也含有一些關於特殊詞元的資訊，如系統、使用者、AI 助理的標記。如果這些 ID 遭到更換或修改，模型的安全指示就可能在無人察覺的情況下被忽略或繞過。
CPU 用量攀升： 詞元變多，意味著分詞器和模型的工作量也會變多，CPU 用量將急遽攀升，請求變慢，自動擴充機制會開始介入。如此將產生更多負載、增加 Pod 消耗量，導致基礎架構帳單金額飆高。原本就很忙的系統，佇列可能爆滿而無法消化、逾時時間拉長，分租共用的工作負載可能受到影響。看似「正常的文字」很可能變成耗光算力的殺手。
本文探討兩件事情：
- 分詞器的變更如何影響硬體的用量、成本與延遲。
- 修改過的詞元化範本如何改變模型輸出，進而被用來觸發下游指令，導致像 MCP 系統上看到的行為。
第一部分：成本、延遲與硬體經濟學
為了示範分詞器檔案的微小變更可能造成什麼影響，我們做了一項實驗來測量這樣的變更如何改變詞元量、成本與效能訊號，完全不需變更模型權重。
環境設定
模型： 我們使用在 CPU 上執行的小型開放式模型。以下是這項實驗用到的模型：
資料集： 我們使用一個混合了英文、印度文及中文短句的資料集，以純文字形式保存，以確保一致性與安全性。
變體：
- 從官方來源取得的基準分詞器。
- 修改過的分詞器 (作為對照控制組)。為了安全起見，我們只調整了分詞器的合併策略 (細節省略) 來誘發詞元量的膨脹而不改變模型權重。
硬體： 本實驗是在一台單 CPU 主機或小型虛擬機器 (VM) 上執行。
執行次數： 每個變體都執行三次來平滑雜訊。
有效性檢查：
- 每次執行的輸入內容必須完全相同。
- 測量期間不執行網路呼叫。
- 清楚標明模型權重並未改變。
實驗限制
- 小型測試集無法捕捉每一種工作負載。
- VM 雜訊可能影響延遲和 CPU 數據。
- 結果會隨著模型家族和分詞器的設計而變化。
我們測量什麼
- 每種語言的每字元詞元數。
- 每一請求的分詞器延遲。
- 有效情境可在一個 4,000 詞元的窗口塞入多少字元。
- 預測成本，單純以每 1,000 詞元的價格來推算。
程序
- 載入基準分詞器。處理固定相同的輸入集。記錄所有數據。
- 載入修改過的分詞器。處理完全相同的輸入。記錄相同的數據。
- 將同樣方式執行的幾次結果平均起來。
- 比較基準與修改過的分詞器之間有何不同，主要看改變了多少百分比，而非原始數字。
結果
我們的實驗顯示，不需駭客介入，控制組只要一個微小變更就會讓成本和 CPU 用量顯著增加。這說明了為何偵測對工程和財務都很重要。
每字元詞元數 (詞元/字元)
P95 詞元化延遲，單位：毫秒 (ms)
每 1,000 次請求的成本預測
一般常見熱門模型每 1 百萬詞元的平均成本是 8 美元，我們用這個成本來推估每 1,000 次請求的成本：
- 每次請求的平均字元數：1,500
- 每一百萬詞元的成本：8 美元
- 每一詞元的成本：0.000008 美元
我們使用的公式如下：每 1,000 次請求的成本 (美元) = (每字元詞元數) * (每次請求的平均字元數) * 1,000 * (每詞元成本，單位美元)
實驗結果與洞見
- 詞元數量爆增。 在各模型中，修改過的分詞器每一字元大約會增加 2.09 倍的詞元數。這可不是微小的漂移。這意味著，在代管的 API 中，相同的工作負載現在大約需要 2.09 倍的費用，如果是在自行代管的叢集上，則是消耗更多算力。
- 情境容量變小。 一個情境窗口為 4,000 詞元的模型，可容納的英文大約從 12,500 個字元下降至 5,900 個字元 (0.321→0.681 詞元/字元)。中文的縮小幅度類似或更大。這意味著提示、歷史記錄與系統指示的長度全都會被截短。安全規則與記憶功能將首當其衝。
- 延遲和 CPU 用量攀升。 詞元化的延遲時間大約增加 8% – 40% (P95)，視模型而定。每一請求的 CPU 用量會隨著詞元化延遲而增加。這顯示，「詞元化成本陷阱」不僅會影響帳單，還會拖慢整體系統的速度，提高自動擴充機制介入的壓力。
- 不同語言受到影響的不一致 (僅在 GPT-2 中測試)。 例如，中文和印度文增加的百分比高於英文。如此一來不同使用者所獲得的體驗將不公平，某一族群支付了更高的費用，但卻莫名其妙地獲得較差的效能。
- 潛伏的問題。 上述影響對一般使用者或開發人員來說一開始並不明顯，模型的回答都很正常，在成本、CPU 儀表板數據或客戶抱怨開始越堆越高之前，這個陷阱都默默地暗中運作，使得它成為一種真實的供應鏈風險。
我們的實驗顯示，分詞器的漂移不單只是一項實作上的細節，而是可能改變營運系統的成本、效能、安全性和公平性。請將它當成一種模型權重或關鍵程式碼相依性的變更來對待。
這實驗揭露了什麼
- 分詞器只需微小的改變就可以讓詞元數量增加二或三倍。
- 同樣的情境窗口可容納的文字將少很多。
- 分詞器延遲會增加。
- 每一請求的 CPU 用量增加。
- 預測成本的成長與詞元數量成正比。
對高階主管來說，以上結果意味著 AI 服務可能悄悄地變得更貴、更不穩定，儘管表面上似乎沒什麼改變。分詞器的漂移表面上看不出來，但帳單、CPU 儀表板及針對使用者體驗的抱怨卻是可具體衡量的。
詞元化如何影響成本與延遲
要了解詞元化成本的陷阱為何重要，可從分詞器內部的運作開始觀察。
改變了什麼
今日的 LLM 大多使用所謂的「位元組對編碼」(Byte Pair Encoding，簡稱 BPE) 或「GPT 式」分詞器。這類分詞器都會使用一個合併字元表 (merges table) 來將常用的「字元對」(character pair) 合併成更大的詞元。
- 例如：「New 」這個英文字可儲存成單一詞元，而非分開成「N」、「e」、「w」及「 」(空格) 四個詞元。
- 如果將常見的合併字元 (如空格、標點符號或「ing」之類的結尾) 移除，同樣的一段文字，就會變成許多較小的詞元。
這樣的改變完全不會動到模型的權重，只會動到分詞器的產出物，但卻會造成連鎖反應，影響整個系統。
為何 CPU 用量、延遲與成本都會上升
- CPU 用量： 詞元化本身就是一項 CPU 密集的工作，更多的詞元意味著要做更多事來將文字轉換成輸入代碼 (input ID)，進而提高每次請求的 CPU 利用率。
- 延遲： 就算您只增加幾個新的詞元，模型的後續運算量也會隨著輸入變長而擴大。較長的輸入序列會增加注意力的負擔與鍵值快取 (KV-cache) 的設定，讓回應速度變慢。
- 成本： 帳單通常是根據輸入和輸出詞元的多寡來計算。如果分詞器從文字拆解出來的詞元量變成了 3 倍，那麼針對同樣的請求，您將支付 3 倍的費用。
範例
使用健康的分詞器：
| "New York City!" | ["New", " York", " City", "!"] | 4 tokens |
| "New York City!" | ["N", "e", "w", " ", "Y", "o", "r", "k", " ", "C", "i", "t", "y", "!"] | 15+ tokens |
同樣的句子，但伺服器現在必須使用 CPU 來處理更多詞元，而模型也必須處理更長的輸入序列。結果：CPU 負載變高、請求速度變慢，帳單也更嚇人！
總結一句話
改用一個合併字元更零散的分詞器，將使得「每字元詞元數」(tokens per character) 變大，光是這項改變，不需修改模型的權重，就會增加 CPU 用量、延遲，以及每次請求的可計費詞元數。
第二部分：漂移的資安層面：回應操弄與指令注入
當部署在代理式堆疊中時，模型只是流程的其中一環。一個分流器 (router) 或 AI 代理控制器 (agent controller) 會讀取模型輸出、尋找結構化訊號 (函式呼叫、JSON Blob 或特殊詞元序列)，並且在這些訊號出現時將工作指派給工具或外部動作來執行。由於分流器通常信任模型所輸出的格式，因此只要輸出看起來像是有效的工具呼叫，分流器就可能採取行動。
正是這樣的信任，才會讓正規化 (normalization) 階段的分詞器漂移變成真正的資安問題。原始文字在詞元化之前會先經過正典化 (canonicalization)，所以若正典化的方式遭到小幅暗中修改，很可能讓原本無害的使用者內容在正規化 (normalization) 之後變成像控制字串一樣，或者導致模型輸出原本不曾出現的控制詞元。在這些情境中，模型的權重並未改變，而且模型看起來仍正常運作，但分流器卻可能被騙執行一些違反操作者意圖的動作。
以下一節我們將聚焦 tokenizer.json 檔案中的正規化器 (normalizer) 遭到修改的情況。正規化器負責處理 Unicode 表達形式、將大小寫統一、去除變音標符號、處理空白字元，以及對應控制字元，這一切都會決定模型所看到以及輸出的詞元串流 (token stream)。
什麼是正規化器 (Normalizer)？
正規化器負責的是原始文字在被拆解成詞元之前的第一個步驟，那就是：清理原始文字並將其標準化。它不會改變原本的意圖，只是讓輸入內容變得一致，如此一來，分詞器才能以相同的方式處理類似的文字。由於正規化器是在詞元化之前執行，所以，此處的任何微小變動都會改變詞元的邊界，並且改變模型「接收」到的內容以及後續的「輸出」。一些由正規化器負責的工作包括：正典化、大小寫與變音符號處理、空白與換行/換段、控制字元與隱藏字元、標點與符號、數字/日期/格式、引號與分隔符號等等。
高階攻擊情境
- 駭客會修改模型套件的 tokenizer.json 正規化器規則，然後上傳到某個公開儲存庫 (使用類似或原本的儲存庫名稱)。
- 當團隊下載並使用這個 (未經檢驗的) 模型時，這個新的正規化器將會以非預期的方式將使用者提供的內容正典化 (例如將常見的詞元置換成惡意指令)。
- 此時，模型的輸將包含會讓下游分流器視為工具呼叫的詞元序列。分流器會執行這些工具，因為它信任 AI 助理的輸出格式。
- 結果就是：一段看似無害的使用者輸入在操作者未明確指示的情況下，間接觸發了一個 MCP/工具動作。
由於模型本看起來運作正常，因此操作者可能會沒注意到這一點，直到模型遭到濫用或造成損害為止。
個案研究：只是單純回答個「是」卻觸發了 EICAR 下載
目的。 以下範例展示為何分詞器或正規化器層的微小變化，會讓看似無害的回答變成觸發動作的指令。模型的權重並未改變，其效果來自於流程如何解讀模型輸出的文字。
情境。 一個客戶支援聊天機器人將模型的回應傳送至一個名為「分流器」的元件 (決策層)，分流器根據 AI 助理的輸出內容來挑選工具並加以執行。如果有一條簡單的政策說：「若模型的回應是 (或變成) 一行可執行的字串，那分流器就單純地將文字對應到動作」，這將直接經由工具/AI 代理觸發指令。
安全提示。 此處我們下載了這個 eicar 測試檔作為示範。
展示
在本情境中，某家商店的客戶支援聊天機器人正在接受客戶的詢問。AI 代理堆疊內含一個決策層，負責讀取聊天機器人助理 (也就是模型) 輸出的訊息，並決定是否要執行指令。有一條簡單的政策說：若模型的回應是一行可執行的字串，那就執行動作。這很危險，如果正規化或詞元化的方式改變了輸入和輸出文字的樣貌，分流器 (決策層) 有可能錯誤解讀回覆內容，並執行了錯誤的工具/AI 代理。
[觀賞影片]
這件事為何重要
對格式的信任。 系統對文字格式的信任超越了意圖，它並未檢查其來源、背景或政策。
改變悄然無聲。 正規化方式的改變，使得某些輸入和輸出在正典化之後等於某種預先設計的文字或指令，即使原始文字並未直接提供確認指令。
從文字對應到動作。 一旦系統將回應成功對應到動作，就會執行指令，使得文字上的微小差導致了非預期的動作。
防範策略
- 將分詞器的產出物鎖住。
→ 將分詞器的每個檔案 (tokenizer.json、vocab.json、merges.txt、 tokenizer_config.json) 的雜湊碼 (總和檢查碼) 儲存起來。
→ 在 CI/CD 當中和模型載入時比對這些雜湊碼。如果雜湊碼出現不預期變更，請鎖住該版本。
為何要這麼做： 雜湊碼提供您可靠的指紋讓您判斷是否有任何檔案曾經修改過。分詞器的檔案可能已被人調包或更改，但看起來卻沒有問題。
如果不這麼做： 一個惡意或被篡改的分詞器就可能潛入您的流程中，暗中增加您的成本或削弱安全機制，而您在系統上線運作之前可能都不會察覺。 - 加入統計檢查
→ 將一小部分用來校正的句子以多國語言方式保存。
→ 記錄「每字元詞元數」(tokens per character) 與「每字詞元數」(tokens per word) 的正常平均值。
→ 定期執行這項檢查。若漂移幅度超過 10% – 15% 就發出警報。
為何要這麼做： 詞元數膨脹將導致「每字元詞元數」暴增。建立基準有助您快速偵測異常狀況。
如果不這麼做： 即使檔案雜湊碼變了，您或許也不會注意到有什麼影響。但成本卻可能一夕之間翻了三倍，而且只會顯現在後來的 API 帳單或 CPU 儀表板上。 - 監控營運環境→ 追蹤每次請求所使用的字元數和詞元數。
→ 當每字元詞元數、每次請求 CPU 用量，或分詞器延遲突然增加時發出警報。
→ 將這些數據依據不同的語言來細分，以便揪出不公平的變化。
為何要這麼做： 即使持續整合 (CI) 檢查沒問題，系統上線之後還是會遇到實際的流量，到時可能就會暴露出隱藏的問題。監控可以即時偵測成本暴增或不同語言之間不公平的問題。
如果不這麼做： 直到客戶抱怨或成本暴增之前，詞元數量膨脹的問題可能都不會被人發現。分租共用服務可能會看到某一族群影響了其他所有族群的體驗。 - 設下限制
→ 硬性規定輸入詞元與輸出詞元數量的最大上限。
→ 若某個請求看起來會展開成太多詞元，請直接拒絕或加以摘要。如此可防範所謂的「錢包耗盡攻擊」(denial-of-wallet attack)。
為何要這麼做： 限制可作為一張安全網，防止駭客利用一些「看起來便宜」但詞元化之後變得極其昂貴的文字來淹沒您的系統。
如果不這麼做： 駭客可能發動錢包耗盡攻擊，CPU 使用率可能暴增、佇列爆滿，但正常的請求卻遭到延遲或捨棄。 - 保護供應鏈安全
→ 僅從可信任來源下載模型和分詞器。
→ 任何對內部分詞器的變更都必須經過程式碼審查與簽署。
→ 將分詞器更新當成程式碼相依性更新一樣謹慎處理。
為何要這麼做： 絕大多數的分詞器問題都來自於供應鏈，掌控來源並經過核准，可從源頭防止意外或惡意的漂移。
如果不這麼做： 您將冒著從網路上下載到有毒分詞器的風險，或將未經審查的變更併入內部。這等於敞開大門迎接前述成本陷阱，並且避開安全機制。 - 將詞元化與服務分開
→ 可以的話，請在一個受到嚴密管控的服務中執行詞元化，這些服務會有自己的監控與限制。
→ 如此就更容易在詞元數量膨脹的情況到達模型後端之前預先看到問題。
為何要這麼做： 分開可以更容易在早期偵測到異常狀況，不讓異常狀況進入昂貴的推論階段。
如果不這麼做： 詞元數量膨脹的問題會直接衝擊模型的生成工作，您的模型伺服器會消耗更多 CPU 和記憶體，但您卻無法清楚掌握問題的根源。
給決策者的啟示
分詞器不應經常變動，若要變更，必須以書面方式記錄下原因。對領導者來說，很重要的是要知道怎樣的可衡量徵兆意味著出現問題：
一些值得觀察的營運與成本訊號：
- 詞元效率：觀察每詞元字元數 (characters per token) 的比值。突然升高 (例如，英文從大約每詞元 4 個字元，掉到每詞元 1–2 個字元) 代表詞元數量膨脹的訊號。
- 每一請求成本：若您的雲端帳單金額在流量沒有相對增加的情況下攀升，那或許不是使用者數量有所成長，而是隱藏的分詞器漂移現象。
- 情境窗口縮小：使用者可能抱怨對話到一半被提早結束，或者再也無法處理較長的文件。
- CPU 用量與延遲趨勢：每一請求的 CPU 用量增加、詞元化延遲變長，或者出現更多自動擴充事件但流量卻沒有成長，這些都是警訊。
- 語言差異：如果某些語言的處理速度變慢或成本變高，請檢查是不是分詞器出了問題。
值得觀察的資安警訊：
- 格式異常： 輸出內容突然包含工具呼叫標記、JSON blob 或是用分隔符號包圍的詞元 (看起來像是結構化指令)。
- 回應的改變： 模型的回應語氣或意圖在部署之後發生變化，即使權重和提示都沒有改變。
- 源頭不明： 自動執行的動作，無法清楚確認其觸發來源 (使用者還是系統)。
總歸一句話 – 將非預期成本暴增、CPU 用量飆高，或是針對特定語言的抱怨，以及模型的回應或工具觸發方式突然改變視為可能是分詞器漂移的跡象。請您的團隊利用雜湊碼、校正測試、執行時期監控，以及回應稽核來證明分詞器的穩定性。
結論
分詞器漂移已不是一個理論上的問題，而是一項實際影響成本和安全的供應鏈與營運風險，而且其衝擊取決於您的模型來自何處，以及它們被使用的方式。
採用封閉式系統的大型 LLM 廠商，很可能早已知道這個問題。所以他們會控管好自己的分詞器，確保它們維持穩定，並強制落實內部安全機制來避免它默默漂移。這類平台的客戶固然風險較低，但還是值得好好監控成本、公平性以及非預期的回應行為。
開放原始碼與自行代管的模型會面臨較大的風險，來自公共儲存庫的分詞器不一定有經過檢驗，而且有可能無預警地被偷偷塞入細微的修改。企業若基於業務需要而客製化自己的分詞器 (例如加入特定領域的詞元) 同樣也必須小心：即使是小小的修改，也可能導致雲端帳單金額暴增、系統速度變慢、情境窗口縮小，或導致模型輸出看似非預期的確認指令或工具呼叫。
一個很清楚的啟示就是，在封閉的生態系下，您可以信任，但仍要隨時確認成本和行為。在開放或自行管理的環境下，請將分詞器的穩定性列為治理的首要考量，並且同時兼顧成本控管與資安。雜湊碼、校正測試、執行時期監控，以及回應稽核已經不是可有可無的選項，而是預先揪出漂移、不讓漂移演變成營運或資安痛苦的唯一辦法。
風險上的差異
