大模型如何保证输出json格式？

大模型结构化输出指的是通过设计模型的输出方式，使其以固定格式或特定结构（如JSON、表格、序列、层次化数据等）返回结果。实际的应用中可能是通过多个提示词策略组合来执行任务，那么控制每一步模型的输出格式就成为了一个核心且关键的问题。

目前能控制大模型进行结构化输出的主要方式是后处理或约束性解码。后处理只能等待大模型输出完成之后才能介入，这样可能导致token浪费且有时候可能会存在字段缺失的情况。但是使用约束性解码可以在LLM生成每个token时基于策略选择满足约束的token，从而指导LLM生成给定的json格式，优势明显。

1、约束性解码

约束性解码(Constrained Decoding)是一种常用的结构化生成方法。在每个解码步骤中，受限解码同时检查词汇表，并通过将无效标记的概率设置为零来过滤违反指定结构的标记。

这种方法可以应用于多种场景下，比如保证生成的内容符合某种格式要求、包含特定词汇或者避免某些不希望出现的信息等。约束性解码对于提升自然语言处理任务的效果非常重要，尤其是在需要高度定制化输出的应用中，比如FunctionCall、文本分类预测、标签信息抽取等纯NLP时代的分类任务。

可以执行哪些约束条件？

1）词汇约束：限制输出必须包含/排除特定词或短语。

示例：生成必须包含“可持续发展”的句子。

2）格式约束：强制符合模板（如JSON、表格、诗歌等）。

示例：生成符合“问题-答案”对结构的内容。

3）逻辑约束：确保数值、时间等符合逻辑关系。

示例：生成的日期必须晚于前文提到的日期。

4）长度约束：控制生成文本的token数量或句子长度。

具体怎么实现？

前缀树（Trie）：动态限制下一步可选的token，避免无效输出，主要结合上下文语法，将下一个token的预测空间缩小。比如一般的json中，key是字符串，所以逗号,后面通常跟着引号"；

受限采样（Constrained Sampling）：在采样阶段过滤不符合约束的候选词；

基于搜索的算法：如Beam Search结合约束条件；

后处理修正：先生成文本，再通过规则或小模型调整；

2、vLLM

2.1 核心技术和原理

这里介绍vLLM主要是其已原生支持了各种约束性解码的方案，但是笔者在实操过程中还是遇到了一些问题，不过可以先罗列下其核心原理和功能，加深对结构化输出方案的理解。

在当前大模型推理框架领域，vLLM 以其卓越的高吞吐性能和简洁易读的代码而备受瞩目，已经成为许多团队二次开发的首选。其优雅的设计和高效的实现不仅使其在实际应用中表现出色，也使其成为学习和理解推理的理想框架。

vLLM 是在加州大学伯克利分校开发，配备了PagedAttention的vLLM重新定义了 LLM 服务的最新技术水平：它的吞吐量比 HuggingFace  Transformers 高出 24 倍，比TGI框架快3.5倍，且无需更改任何模型架构。

当max token较小时，batch间不同序列生成的长度差异不大，因此生成速度相差无几。当max token增加至1536时，可看出使用Continuous batching的生成速度明显更快，且vLLM提升极高。

PageAttention技术

在 self-attention 中，计算速度比内存速度快得多，因此进程(操作)越来越多地受到内存(HBM)访问的瓶颈。PagedAttention是vLLM的核心技术，它解决了LLM服务中内存的瓶颈问题。PagedAttention采用了虚拟内存和分页的经典思想，允许在非连续的内存空间中存储连续的键和值。通过将每个序列的KV缓存划分为块，PagedAttention可以高效地进行注意力计算。

ContinuousBatching技术

通常情况为，batch szie保持不变，当max token越大时，不同batch结束的位置差异越大，GPU利用率越低。LLM的推理截止是随机的，当max token较小时，batch间不同序列生成的长度差异不大，可以认为大致是一起开始一起推理结束，GPU利用最大化，生成速度也相差无几。当max token增加至1536时，普通推理的GPU利用率较低，使用Continuous batching的利用率明显更高，生成速度更快。

2.2 结构化输出的打开方式

1）输出指定选项

适用于各种文本分类问题，比如情感分析、意图识别等等；

2）按照正则格式输出

结合正则和大语言模型可以在ocr识别后的文本出现轻微错乱的时候对关键信息进行有效还原；

3）嵌套结构输出

可以完成各类json格式结构的输出，包括嵌套结构等；

4）按照自定义的语法输出

最后也是最强大的是guided_grammar，它允许我们定义完整的语言，比如SQL查询。它通过使用上下文无关的EBNF语法工作，例如，我们可以用它来定义特定格式的简化SQL查询。考虑到NL2SQL的工作暂时还没有广泛应用在工作中，这里暂时不做衍生，有兴趣的读者可以详细参考下vllm的说明文档。

5）详细参数

上面使用的参数对应的详细参数列举在下面，作为总结也简单做一个回顾：

guided_choice：输出将恰好是选项中的一个;

guided_regex：输出将遵循正则表达式模式;

guided_json：输出将遵循JSON模式;

guided_grammar：输出将遵循上下文无关CFG语法;

guided_decoding_backend：用于选择要使用的引导式解码后端。可以在后端名称后面跟冒号，然后用逗号分隔列表提供额外的特定后端选项。例如，"xgrammar:no-fallback"将不允许vLLM在出错时回退到不同的后端。

默认情况下，哪个引擎将用于引导解码（JSON schema / regex等）。目前支持mlc-ai/xgrammar和guidance-ai/llguidance。有效的后端值为"xgrammar"、"guidance"和"auto"。使用"auto"时，将根据请求内容和后端库当前支持的功能做出有主见的选择，因此这种行为可能会在每个版本中发生变化，默认值为xgrammar。

3、Xgrammar

接下来再详细介绍下Xgrammar，是Xgboost的作者陈天奇大佬团队提出的方法，可以有效准确无延迟的控制大语言模型的格式化输出。同时也是vLLM默认的约束性解码引擎；

3.1 核心思路

XGrammar通过将词汇表分为上下文无关的标记和上下文相关的标记来加速上下文无关文法的执行。上下文无关的标记可以预先检查，而上下文相关的标记需要在运行时解释。XGrammar还构建了转换以扩展文法上下文并减少上下文无关标记的数量。此外，XGrammar构建了一个高效的持久栈来加速上下文相关标记的检查，并与LLM推理引擎共同设计以重叠文法计算与GPU执行，从而实现结构化生成的近零开销。

关键思想：在下推自动机的每个位置将词汇表分为上下文无关和上下文相关的标记，预先计算并缓存上下文无关的标记在自适应标记掩码缓存中，然后在运行时检索，其他上下文相关的标记则在运行时检查。此外，实施了各种优化以减少上下文相关标记的数量并提高处理效率，从而加速这些标记的运行时处理。

图2展示了带有每个token掩码的约束解码的过程，每个token掩码在每一步中防止LLM在该步骤中构建结构无效的token。图中显示了输出logits、掩码logits和概率分布的转换过程，强调了如何通过设置无效token的logits为负无穷来确保只采样有效token。这种方法对于提高生成速度至关重要，因为有效识别并掩码无效的token会直接影响生成效率。

图3展示了一个用于数组和字符串的上下文无关文法（CFG），可以递归组合。上半部分显示了CFG的定义，其中包括多个规则，每个规则包含字符或对其他规则的引用，允许递归组合以定义复杂结构。下半部分展示了两个可能的匹配栈，用于将字符串[\"a与CFG进行匹配。每个栈代表CFG规则的可能扩展。

3.2 主要结果

1）XGrammar在JSON语法和JSON Schema的处理上实现了高达3倍和100倍的速度提升，适合低延迟LLM推理。在H100 GPU上，集成XGrammar的Llama-3.1模型的LLM服务引擎在端到端LLM服务中实现了高达80倍的加速。

2）不同批量大小下，XGrammar引擎与其他结构生成引擎（如llama.cpp、vLLM和SGLang），XGrammar在JSON模式和上下文无关语法的设置下，均表现出最佳的平均时间，尤其在批较大时；

3）XGrammar进行结构化生成在Mac和IPhone的浏览器JavaScript环境中设置下，进行结构化生成与非结构化的端到端生成，但是几乎没有额外的开销，显示出其在高性能设备上支持未来设备端代理的巨大潜力。

以上结果表明XGrammar引擎在处理复杂语法时具有显著的效率提升，适合低延迟的LLM推理任务。

图9展示了每个token的掩码延迟。上图显示了在JSON Schema下，XGrammar、Outlines和llama.cpp-Grammar的性能对比，其中XGrammar的延迟最低，为35.73微秒/每token。

另外，在Context-free Grammar (JSON)下的性能对比中，XGrammar同样表现出最低的延迟，为36.42微秒/每token。这些结果表明，XGrammar在处理结构化生成任务时具有更高的效率，显著降低了掩码生成的延迟，从而减少了对LLM推理过程的影响。

图10展示了在Llama 3.1推理中使用结构约束的端到端评估。图中比较了不同批量大小下，XGrammar引擎与其他结构生成引擎（如llama.cpp、vLLM和SGLang）的每个输出token所需时间（ms）。整体来看与SGLang旗鼓相当，二明显领先其余两种方式。

4、实际效果对比

测试数据集：笔者所在公司提供了一份越南公司的商业登记证（大概600个左右的样本），需要从中提取核心关键信息（例如公司名、成立日期等等），并保存为json格式。

测试效果：直接调用XGrammar进行识别能够取得不错的效果，相比原生的3B-VL模型整体提升了接近20个点！其效果接近Qwen2.5VL7B，并超越了gpt4o-mini。

实测发现vLLM的版本（0.8.2+qwen2.5VL3B）在支持结构化输出方面有些问题，例如在前序上下文较长且无直接含义的时候，即使定义了backend和json格式还是有一定的概率重复输出或者截断输出。

然后对耗时做下补充解释，因为vLLM无法稳定保证有效的json化格式输出，经常会出现截断或者重复输出的现象。因此直接采用了flask+pytorch-float32进行推理，导致耗时较长。本次实验主要为了对比效果，可以仅参考准确率指标。