🤖 AI

XGrammar-2: Efficient Dynamic Structured Generation Engine for Agentic LLMs

XGrammar-2 是一款专为动态代理式大语言模型工作负载设计的高效结构化生成引擎，其通过标签触发的结构切换与跨语法缓存复用，实现了相较于先前系统超过 6 倍的编译速度提升以及近乎零的端到端开销。

原作者： Linzhang Li, Yixin Dong, Guanjie Wang, Ziyi Xu, Alexander Jiang, Tianqi Chen

发布于 2026-05-27

📖 1 分钟阅读☕ 轻松阅读

原作者： Linzhang Li, Yixin Dong, Guanjie Wang, Ziyi Xu, Alexander Jiang, Tianqi Chen

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你是一位厨师（即 AI），正试图遵循一份极其严格的食谱。有时，食谱很简单：“做一个三明治。”但在 AI 智能体（Agent）的世界里，食谱往往是一组复杂且不断变化的指令，例如：“写一句话，然后切换到 JSON 代码块以调用天气工具，接着切换回写一句话，再切换到数据库查询的特定格式。”

问题在于，传统的“厨房”（AI 引擎）非常擅长遵循单一固定的食谱，但当食谱在运行中发生变化，或者厨师需要在数十种不同的复杂格式之间瞬间切换时，它们就会显得力不从心。它们往往不得不暂停，从头开始重写整本食谱，然后才能开始烹饪，这使得整个过程变得缓慢。

XGrammar-2 是一款全新的、超高效的厨房引擎，专为这些混乱且动态的烹饪场景而设计。以下是它的工作原理，通过简单的类比来说明：

1. “魔法开关”（TagDispatch）

问题所在： 想象一份食谱写着：“保持正常书写，直到看到单词'STOP'，然后切换到数学模式，再切换回来。”用旧方法来实现这一点，就像试图编写一本庞大且纠缠不清的说明书，其中每一个可能的单词都指向不同的页面。这既混乱又庞大。

XGrammar-2 的解决方案： 他们引入了一项名为 TagDispatch 的功能。将其想象为一个 魔法开关 或 交通信号灯。

AI 正常书写（绿灯）。
一旦它看到特定的触发器（例如标签 <function=weather>），信号灯瞬间变红，引擎便确切知道要切换到哪个“子食谱”（即天气的 JSON 格式）。
一旦该子食谱完成，信号灯再次变绿，AI 便恢复正常的书写。
为何酷： 引擎无需编写一本巨大且令人困惑的说明书，只需跟随交通信号灯即可。这使得在自由流动的文本和严格的代码之间进行切换变得瞬间且轻松。

2. “共享库”（Cross-Grammar Cache）

问题所在： 想象你要烹饪 100 道不同的菜肴。其中 90 道菜都使用完全相同的“切洋葱”步骤，但旧引擎将每道菜视为全新的任务。它每做一道菜都要从头重新学习如何切洋葱。这是对时间的浪费。

XGrammar-2 的解决方案： 他们构建了一个 共享库（Cross-Grammar Cache）。

即使最终的菜肴（完整语法）不同，但食材和步骤（子结构）往往是一样的。
XGrammar-2 会查看步骤。如果它发现“哦，我已经为类似的菜肴算过如何切洋葱了”，它就不会重新计算。它直接从共享库中取出预先切好的洋葱。
为何酷： 它阻止了引擎反复进行相同的计算。即使整体请求不同，它也会重用已经完成的“工作”。

3. “即时”厨师（JIT Compilation）

问题所在： 在过去，在你能吃上一口之前，引擎必须为每一个请求阅读整本食谱。如果食谱非常庞大（例如包含 500 种可能工具的调用请求），引擎会在开始烹饪前坐在那里几秒钟，仅仅是在阅读食谱。

XGrammar-2 的解决方案： 他们采用 即时（JIT） 方法。

厨师不再先阅读整本书，而是只阅读此刻需要的页面。
当 AI 思考前几个词（即“预填充”阶段）时，引擎正在悄悄准备食谱的后续几页。
为何酷： 它隐藏了准备时间。当 AI 准备好说出下一个词时，引擎已经准备好了下一步。这使得“第一个词”几乎瞬间出现，即使对于复杂任务也是如此。

4. “压缩地图”（Repetition State Compression）

问题所在： 有些食谱包含重复的步骤，例如“重复此动作 1,000 次”。旧引擎会尝试绘制一张地图，为每一步画 1,000 个独立的点。这张地图变得巨大，并拖慢了所有进程。

XGrammar-2 的解决方案： 他们使用 重复状态压缩。

他们不再绘制 1,000 个点，而是画一个大的“循环”箭头，并说：“在这里绕 1,000 圈。”
为何酷： 无论 AI 需要重复一个步骤多少次，它都能保持地图小巧简洁。这防止了引擎被长长的列表或循环所拖累。

结果：他们发现了什么？

该论文将这款新引擎与当前最佳方法进行了测试：

速度： 它编译“食谱”（即语法）的速度比之前的引擎快 6 倍。
效率： 它给 AI 的响应时间增加了几乎 零延迟。它快得 AI 甚至察觉不到它的存在。
兼容性： 它与流行的 AI 系统（如 SGLang 和 vLLM）无缝协作，并能轻松处理调用工具或遵循严格响应格式等复杂任务，毫不费力。

简而言之，XGrammar-2 就像是将 AI 的大脑从一位缓慢、僵化的图书管理员（他在回答问题前必须重新整理每一本书）升级为一位超快、灵活的助手，他确切知道在哪里找到答案，重用之前的知识，并在不打断节奏的情况下瞬间切换话题。

技术摘要：XGrammar-2

问题陈述

现代大型语言模型（LLM）智能体日益依赖动态结构化生成，特别是在工具调用和响应协议方面。与输出模式静态且预先已知的传统结构化生成任务不同，智能体工作负载表现出显著的结构动态性：

请求间动态性：每个请求可能暴露一组不同的工具和模式（通常带有每工具访问控制），导致可能的输出语法空间呈组合式爆炸。现有的在请求级别缓存整个语法的引擎变得无效，迫使进行昂贵的每请求预处理，并增加首字元时间（TTFT）。
请求内动态性：在单个请求中，模型必须根据触发器（例如特定的工具名称或通道标签）在自由文本和结构化子语法之间切换。使用标准巴科斯 - 诺尔范式（BNF）或扩展巴科斯 - 诺尔范式（EBNF）来表达这些条件切换既笨拙又低效，且随着工具数量的增加扩展性差。

现有的受限解码方法（如 XGrammar、Outlines、llguidance）难以应对这些动态性。它们要么需要预先进行完整的语法编译（对于动态工具集而言不可行），要么缺乏有效机制来处理单个生成流中自由文本与结构化约束的交错。

方法论

XGrammar-2 是专为动态智能体工作负载设计的结构化生成引擎。其架构建立在两个核心设计原则之上：对标签触发的结构切换的一等支持以及跨具有不同输出结构的请求进行细粒度复用。

1. TagDispatch：动态分发语义

为了解决请求内动态性，XGrammar-2 引入了TagDispatch，这是一种语法原语，允许在自由文本和结构化子语法之间高效切换。

机制：TagDispatch 由标签 - 语法对 $(t_i, G_i)$ 列表和一组停止字符串参数化。
操作：引擎在两种模式下运行：
- 分发模式：引擎接受普通文本，同时使用Aho–Corasick (AC) 自动机增量匹配生成的文本与已注册的标签。
- 已分发模式：一旦匹配到标签，引擎切换到相应的子语法 $G_i$ 。一旦 $G_i$ 完成，控制权返回到分发模式。
优势：这避免了将复杂的条件逻辑编码到庞大的 EBNF 规则中，显著减小了语法大小并降低了编译复杂度。

2. 跨语法缓存

为了解决请求间动态性，XGrammar-2 实现了跨语法缓存，以便在共享公共子结构的不同语法之间复用令牌掩码缓存。

挑战：当有限状态机（FSM）包含规则引用和循环时，确定两个 FSM 是否等价非常困难。此外，令牌掩码缓存不仅取决于 FSM 结构，还取决于该 FSM 被引用的方式（上下文扩展）。
解决方案：系统使用分层哈希算法：
- 它构建 FSM 引用图。
- 对于无环部分，它自底向上计算结构哈希，纳入所引用 FSM 的哈希值。
- 对于循环引用，它使用临时哈希，随后进行循环哈希细化，以确保唯一结构标识符。
复用策略：当遇到新的语法状态时，系统检查全局缓存池。如果找到完美匹配（相同的 FSM 和向前看），则复用缓存。如果仅存在部分匹配（相同的 FSM，不同的向前看），系统会重新检查不确定的令牌并更新缓存。

3. 基于 Earley 的自适应令牌掩码缓存

XGrammar-2 摒弃了先前版本中使用的下推自动机（PDA），转而利用Earley 解析器构建其自适应令牌掩码缓存。

理由：在非确定性语法中，PDA 状态可能呈指数级增长。Earley 解析器维护一组部分解析状态（前沿），对于复杂的上下文无关语法更为高效。
实现：缓存仅针对可扫描状态（下一个符号是终结符）构建。不可扫描状态在运行时通过预测和完成操作进行扩展。令牌被分类为接受、拒绝或上下文依赖，后者需要运行时上下文检查。

4. 即时（JIT）编译

为了缓解大型动态语法的高编译成本：

策略：XGrammar-2 采用可配置的 JIT 系统，而不是预先实例化完整的令牌掩码缓存。
执行：在预填充阶段，系统估算为特定状态生成缓存的成本。它优先在预填充期间编译耗时最多的 $K$ 个状态，使编译与预填充重叠。剩余状态在解码阶段按需编译，使掩码生成与解码重叠。旨在隐藏编译延迟。

5. 重复状态压缩

为了处理 JSON 模式中常见的重复结构（例如 MinLength、MaxItems）：

问题：重复规则的朴素展开会导致语法状态数量相对于重复次数呈线性增加。
解决方案：引擎压缩重复状态。对于大的重复范围，它将结构转换为一个基础规则重复 $t$ 次的序列，后跟一个代表剩余范围的压缩状态。这将状态数量限制为常数，无论重复限制如何，从而显著减小缓存大小并降低不确定性。

关键结果

实验使用了 BFCL-v3 和 JSONSchemaBench 等数据集，在各种模型（Qwen、Llama 系列）上将 XGrammar-2 与最先进的引擎（XGrammar、llguidance、Outlines）进行了比较。

编译速度：在动态设置中，XGrammar-2 的编译速度比之前的结构化生成引擎快 6 倍以上。例如，XGrammar 编译动态语法需要 >1000 毫秒，而 XGrammar-2 仅需约 10 毫秒。
端到端开销：在现代 LLM 服务系统中，该系统产生的端到端开销几乎为零。在函数调用场景中，受限生成（XGrammar-2）与无受限生成之间的延迟差距小于 6%。
吞吐量：XGrammar-2 在不同批次大小和模型规模下表现出优于 XGrammar 的令牌吞吐量（例如，在 Llama-3.2-1B 上，批次大小为 16 时吞吐量提高了 2.5 倍）。
可扩展性：跨语法缓存的内存开销保持低位，并随使用的唯一工具总数而非请求数量扩展，从而防止动态环境中的内存爆炸。
消融实验：移除 JIT 使预处理时间增加了 8.1 倍；移除跨语法缓存显著增加了掩码生成时间；对于长尾重复情况，重复状态压缩使预处理时间减少了 99.6 倍。

意义与主张

该论文声称，XGrammar-2 为支持智能体应用的 LLM 服务系统提供了必要的演进。通过将动态工具集的处理与静态语法编译解耦，它实现了：

可靠性：严格强制执行结构有效性（例如 OpenAI Harmony 响应格式、工具调用模式），而无需依赖事后修正。
效率：能够以与静态工作负载相当的编译和运行时成本服务动态工作负载。
采用：该引擎已集成到SGLang和vLLM等开源框架中，证明了其在生产级推理系统中的实际可行性。

作者将 XGrammar-2 定位为模型训练技术的补充而非替代品，它是一个互补的推理时引擎，可与现有的微调或提示策略结合，以确保在复杂的智能体场景中输出稳健的结构化结果。