推論系統
Trie Automata 預算 token mask，vLLM 有限選項解碼吞吐達 XGrammar 的 29 倍
新方法針對數千至一萬個合法字串預先建立 trie 狀態與 token mask，避開通用文法編譯的基數瓶頸。作者測得批次 256 時每秒處理 219 個請求，但尚未公開實作，數字也包含繞過既有 guided-decoding 路徑的整合收益。
工具呼叫、商品檢索與分類 API 經常要求模型只能輸出一組預定名稱；現有服務通常把選項編譯成文法，再於每個解碼步驟計算合法 token。8 月 12 日提交、列入 [COLM 2026 接受論文](https://colm.eventhosts.cc/Conferences/2026/AcceptedPapers)的研究指出，當合法值增至數千個，通用編譯器會遇到「基數牆」，即使各選項只是短字串，編譯與逐步狀態更新仍會迅速膨脹。
[Trie Automata](https://arxiv.org/abs/2608.12574)先把所有合法字串按共享前綴組成 trie，再以 Aho–Corasick 多模式匹配預算每個節點可接受的 token mask。服務時只需按目前節點取出 mask，成本不再隨選項數目增加；作者在七種、詞彙量介乎 32K 至 262K 的 tokenizer 上，測得一萬個候選值仍可在 100 毫秒內完成編譯，並保持輸出完全屬於合法集合。
對照組是已整合於 vLLM、SGLang 與 TensorRT-LLM 的通用 [XGrammar](https://github.com/mlc-ai/xgrammar)。論文報告 trie 的逐步合法 token 計算為 0.65 微秒，XGrammar 為 5.8 微秒；候選數不少於 300 時，編譯快 2 至 6.5 倍。在 vLLM、批次 256 的端到端測試中，吞吐則由每秒 7.5 個請求升至 219 個。
29 倍不能直接解讀為自動機本身快 29 倍：它同時來自預算 mask，以及可繞過通用 guided-decoding 管線的無狀態整合。方法也只適用於已知、有限的字串集合，不能取代 XGrammar 對 JSON Schema、正規表示式或上下文無關文法的支援。工程團隊下一步應留意作者會否公開 vLLM 修改、記憶體占用與多租戶快取策略，並在真實選項長度及批次分布下重現結果。