TokTier 省掉代理式 LLM 分詞開銷

TokTier 讓代理式 LLM 在維持分詞完全一致的前提下，避免每次呼叫都重做整段 tokenization。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：tokenization 最多占首 token 時間 64%
• 突破點：狀態式分詞修復

代理式 LLM 的瓶頸，常常不在模型本身，而是在前處理。TokTier 這篇工作想解的，就是「每次工具呼叫都把整段文字重新分詞一次」這種隱性浪費。它主打的不是改變模型行為，而是把既有 tokenizer 的工作變少，同時保證輸出的 token ID 跟完整重算完全一致。

這點對做 coding agent、長對話工作流、或反覆追加上下文的服務特別重要。因為這類系統每次送進來的內容，通常不是全新 prompt，而是在舊 transcript 後面再接一小段。只要能把這種「小追加」做成狀態式，而且不犧牲 exactness，就有機會直接砍掉一大塊延遲。

這篇在解什麼痛點

LLM serving 的快取，很多人第一時間想到的是 KV cache。但這篇指出，前端的 tokenization 也可能變成大成本。問題在於，服務端即使已經保留了 prompt 的 KV 狀態，前面那層還是常常把整段 request text 重新跑一次 tokenizer。

在一般聊天裡，這種重算也許還能忍。但在 agentic workflow 裡，情況會放大很多。因為同一段對話歷史會被一再送回來，只差最後一小段工具結果或補充文字。這種模式下，重做整段分詞就像每次只改一行程式，卻把整個檔案重新編譯一次。

作者用兩個 agent 生態系統的 153,951 次呼叫來描述這個工作負載。中位數每次只會追加約 1.4K 字元，而且只有 1.0–3.6% 的呼叫是重新建立 session，或是從頭重建超長上下文。這代表常態不是「新 prompt」，而是「長狀態上的小幅追加」。

在 94.1% 的 fleet prompt-cache hit rate 下，tokenization 仍然可以吃掉高達 64% 的 time to first token。這就是 TokTier 要處理的核心問題：當模型端快取已經有效，前處理反而成了延遲主因。

TokTier 怎麼做

TokTier 的核心想法很直接：把 tokenization 變成有狀態的服務，但輸出的 token IDs 必須和完整 reference tokenization 一模一樣。它不是做近似分詞，也不是發明新格式，而是想在不改變結果的前提下，少做工作。

在 session continuation 的情境下，TokTier 不會把整段 transcript 重跑。它只會針對追加內容附近的一小段重新分詞，再搭配 per-request 的 stable-boundary 檢查來決定能不能安全拼接。如果邊界不安全，就把窗口加大；如果還是不行，就直接退回完整 tokenization。也就是先走最便宜、但仍然 exact 的路徑，再視情況擴大。

對沒有可重用 prefix 的請求，TokTier 走另一條路。它把 GPT 家族的 regex pre-tokenization 拆成 run-local 規則，然後在 GPU 上做 exact pre-tokenization 與 BPE。這讓它即使不能靠 session state，也還是有一條加速路徑。

另外，系統還加了 sampled shadow verifier，會抽樣檢查線上流量。這是很實際的工程設計：不只追求吞吐，也要持續確認快路徑真的和完整 tokenization 對得上。

它實際證明了什麼

這篇的評估範圍不小。作者對 17 種 tokenizer family 做 differential campaigns，涵蓋 1.5×10^10 次 split checks、12.4 TB 真實文字語料，以及超過 93,000 個 replayed agent steps，結果是 zero divergence。這是最重要的正確性訊號：在測過的情境裡，TokTier 沒有偏掉。

速度方面，incremental repair 在 100K 到 3M 字元之間只要 0.5–1.1 ms。論文說這比 Hugging Face tokenization 快到 437 倍，且在 1M 字元時，比最強的 cache-based baseline Gigatoken 在 fully prewarmed 的條件下還快 2.1 倍。這些數字在講同一件事：真正賺到的是「小追加」那條路。

如果是沒有可重用 prefix 的完整 tokenization，GPU 路徑可以在 0.87 ms 內編碼 1M 字元。作者報告這比 Hugging Face 快到 491 倍，也比已發表最快的 CPU 方法快 23.4 倍。這篇摘要是有公開 benchmark 數字的，而且這些數字正是它主張的核心。

放到 vLLM 這種服務框架裡，結果也不只是 microbenchmark。作者說 median time to first token 降了 16–34%，P99 在 recorded bursts 下下降 23%。如果用 50 ms 的 P99 目標來看，4 個 repair cores 加 1 張 GPU 可以撐到 1,821 requests/s；相對地，16-core 的 stateless front end 會在 40 requests/s 就飽和。這表示 TokTier 不是只在實驗室快，而是真的可能改變 serving 容量。

對開發者代表什麼

如果你在做 agent infra，這篇最值得記住的一句話是：tokenization 會變成第一級延遲問題。尤其是 coding agent、工具型助手、或任何長生命週期 workflow engine，只要它一直重送很像的上下文，就很容易在分詞上付出重複成本。

TokTier 的價值在於，它守住了 serving 團隊最不能妥協的事：exactness。工程上可以把它理解成一個有狀態的前端，保證 token ID 跟完整 tokenizer 一樣，但靠 repair window、fallback 邏輯與 GPU 加速，把常態路徑的工作量壓下來。

不過，這篇也還留了一些實作上的空白。摘要雖然給了很強的效能與正確性結果，但沒有展開說明整體整合成本、部署複雜度，或在 production 裡到底多常會退回 full tokenization。它也沒有宣稱所有 tokenizer family 都一樣容易加速，只是報告了 17 種 family 的覆蓋與測試中的 exactness。

限制與還沒回答的問題

最值得追的問題，是 TokTier 的收益到底有多少來自 agentic workload 本身，而不是 tokenizer 的結構。論文已經說明，在它觀察到的生態系統裡，小追加很常見，但不同產品的 transcript 形狀、cache hit rate、session 壽命，可能差很多。

另一個問題是，stable-boundary repair 在真實流量下會不會常常需要擴窗。作者用 shadow verifier 和大規模 differential testing 來保證 correctness，這很讓人安心。但對 production 團隊來說，真正的 trade-off 仍然是：有多少請求會走到 fallback，以及這會怎麼影響 tail latency。

即使有這些限制，這篇還是把一件事講得很清楚：tokenization 不再只是前處理細節。在 agent serving 裡，它可能就是主要延遲來源之一，而 TokTier 提供了一條不放棄 exactness、卻能實際減少成本的路。

對台灣開發者來說，這也提醒了一個常被忽略的方向：當模型推理已經優化得差不多，真正卡住產品體驗的，可能是更前面的那一層資料處理。尤其是做長上下文、工具呼叫密集、或多輪重送 request 的系統，這類優化很可能比再換一個更大的模型更有感。

換句話說，TokTier 不是在重新定義 LLM，而是在修 serving stack 裡一個很實際、很容易被低估的洞。它證明了：只要工作負載夠像 agent，tokenization 就值得被當成核心效能問題來處理。

• TokTier 針對 agentic LLM 反覆重送長上下文的情境，降低重複分詞成本。
• 它用 stable-boundary repair 和 fallback，維持 tokenization 結果完全一致。
• 論文同時給出 correctness 與 latency/throughput 的實測數字，顯示這是可部署的加速路線。