LLM Structured Output 工程真相 2026：从 JSON Schema 约束、xGrammar FSM 到生产级 SLO 防御的三层架构

一句话摘要

当 LLM 输出 JSON / SQL / 工具调用成为生产刚需，Structured Output 已从 prompt trick 演化为 token-level CFG 强约束 + FSM 状态机的硬工程，三大流派（Outlines / SGLang grammar / xGrammar）的工程真相与 SLO 权衡是本文唯一主题。

引言：从 soft prompt 到 hard token

2024 年之前，开发者拿到 LLM 输出后做的第一件事是 json.loads(response)，然后祈祷它不要包一层 markdown fence。2026 年，这条链路在生产推理引擎里已经被彻底改写：当 LLM Serving 把 PagedAttention、Continuous Batching、Speculative Decoding 这些工程优化都卷到极致后，输出格式的正确性成了最后一道最隐蔽的 SLO 瓶颈。一段流式输出里第一个非法字符（一个意外的 }、一个未闭合的字符串、一个未注册的工具名）会让整个 tool-calling 链路进入 retry-thrash——而 vLLM 0.7、SGLang 0.4、TensorRT-LLM 1.0 等新一代推理引擎给出的答案是：让模型在 token 采样阶段就从图灵机降级为受限文法机。

本文以 2026 年 6 月的工程现状为基础，沿着「structured output 的三层实现路径 × 三大流派的开源库 × 与主流推理引擎的集成深度」三个维度，剖析这个赛道从 prompt 工程到编译工程的范式跃迁。

§1 三层实现路径：constrained decoding、JSON repair、grammar-guided sampling

Structured output 在 LLM 推理栈里有三种实现深度，分别在 token 采样链路的三个不同时刻介入：

§1.1 Token-level Constrained Decoding（编译时）

直接在 sampling step 之前把 output token logits 屏蔽到「合法 token 子集」。对于上下文无关文法的 JSON Schema，算法基础是 Earley parser + trie-based mask，但真正的工程难题是把 mask 计算降到微秒级，否则会拖慢整个推理延迟。

设 vocab 大小为 $|V|$，grammar 大小为 $|G|$，第 $t$ 步采样时 mask 的 token 数 $m_t$ 满足：

$m_t = |\{v \in V \mid G(\text{ctx}_t) \text{ accepts } v\}|$

论文 Outlines（2023, arXiv:2307.09702）的实测 baseline 是 $O(|G| \log |V|)$ per token，对于 JSON Schema 100+ 节点的对象，第一 token 平均 mask 集合 ~30k 量级，latency 已经超过 5ms——按 300ms 的 P99 TTFT 预算，这就是 1.7% 的常数开销，不可忽略但可接受。

§1.2 JSON Repair（后处理时）

不修改 sampling，让模型自由输出，后处理阶段用 ast-grep、json-repair、Tolerant JSON Parser 等做修复。优点是与推理引擎零耦合，缺点是「修复失败的尾部重采样」会把 P99 抖动 5–10×。这种路径适合工具调用容错预算极宽松的场景，目前只在 prototype / research 类生产被允许。

§1.3 Grammar-Guided Sampling 工具（hybrid）

第三种是 hybrid 方案，把 grammar 编译成 FSM（finite-state machine），FSM 状态作为 scheduler 维护，每一步 logits mask 实时由 FSM transition 决定。这种方案在 SGLang 0.4 与 xGrammar 0.1 里是默认实现。

# xGrammar 的伪代码简化版
class GrammarFSM:
    def __init__(self, schema: JSONSchema):
        self.states = compile_json_schema_to_fsm(schema)
        self.cur_state = self.states[0]  # 初始 state
        self.tokenizer = AutoTokenizer.from_pretrained(...)

    def mask_logits(self, logits: torch.Tensor) -> torch.Tensor:
        # 关键路径：FSM transition + trie lookup
        allowed = self.cur_state.allowed_tokens(self.tokenizer)
        mask = torch.full_like(logits, float('-inf'))
        mask[allowed] = 0.0
        return logits + mask

    def advance(self, sampled_token_id: int):
        self.cur_state = self.cur_state.transition(sampled_token_id)

实测这条路径在 vLLM 0.7 上把 JSON Schema 100 节点的 mask 计算从 5ms 压到 0.3ms——核心 trick 是用 regex-DFA 代替 Earley parser，牺牲少量 grammar 表达能力换取常数因子 10× 提升。

§2 三大流派：xGrammar / Outlines / SGLang grammar

§2.1 xGrammar：字节级 DFA + LR parser 的混合派

xGrammar 是 2024 年末发表的（arXiv:2411.15195）、由 SGLang 团队推出的 grammar 引擎。它把 JSON Schema 编译成 byte-level DFA（regex 引擎） + LR(1) parser（语法引擎） 双层结构。在 production 行为上：

• 大多数 token 的合法性判定走 DFA（regex 匹配），单步 0.05ms
• 少数边界 token（字符串边界、数字起始位）走 LR parser，单步 0.3ms
• pre-compile cache 命中率达 95%+ 时 P99 mask < 0.5ms

xGrammar 的 trade-off 是 grammar 表达力不完全等于 CFG：嵌套对象超过 5 层时 DFA 状态爆炸，需要手动 schema flatten。生产上常见做法是限制 JSON Schema 深度 ≤ 4。

§2.2 Outlines：CFG-first 的 schema 自由派

Outlines（前称 outlines.dev，arXiv:2307.09702）的设计哲学是「让用户写 regex 就行，不需要学 JSON Schema 语义」。它把 grammar 表达统一成 regex + CFG 的 Python DSL，运行时编译成 WFST（weighted finite-state transducer）。

Outlines 在 SGLang / vLLM 之外的 standalone 推理（HF Transformers、llama.cpp）里是事实标准。但缺点是与推理引擎的集成需要写 custom forward hook，在 vLLM 0.7 + continuous batching 流式输出场景下，每个新 batch 的 grammar 编译 latency 30–80ms——对 TTFT 预算紧的生产服务非常不友好。

§2.3 SGLang grammar runtime：原生集成的工程派

SGLang 0.4 把 xGrammar 集成进 runtime API（gen(..., schema=...)），是「无需用户写 mask 调用」的工程事实标准。

# SGLang 0.4 server 启动时启用 grammar
python -m sglang.launch_server \
    --model-path meta-llama/Llama-3.3-70B-Instruct \
    --port 30000 \
    --grammar-backend xgrammar  # 或 outlines / llguidance

这条命令的关键参数 --grammar-backend 决定 grammar 引擎实现。三选一背后是 12+ 个细粒度参数：--grammar-cache-size、--grammar-prefill-only 等。生产部署时通常配 --grammar-cache-size 64（最多 cache 64 个 schema 实例），LRU 命中率 95% 时 cache miss 走 on-the-fly compile。

§3 与主流推理引擎的集成深度矩阵

§3.1 vLLM 0.7 + xGrammar 默认

vLLM 0.7 把 xGrammar 作为默认 grammar backend，在 --guided-decoding-backend xgrammar 下启用。反直觉的工程事实是：xGrammar 在 vLLM 上的实测性能优于 SGLang 同等配置 8%，原因是 vLLM 的 scheduler 把「等待 grammar compile」与「其他 batch 的 prefill」做 overlap 调度。生产部署推荐 vLLM 0.7 + xGrammar。

§3.2 TensorRT-LLM 1.0 + llguidance

NVIDIA TensorRT-LLM 1.0 的 structured output 路径选择走 llguidance（微软 2024），它把 JSON Schema 编译成 LR parser + tokenizer-trie，纯 C++ 实现，单步 mask latency < 0.1ms。代价是仅支持 NVIDIA GPU + tensorrt backend，AMD / TPU / 国产 NPU 全部要走 Outlines fallback。

§3.3 llama.cpp + GBNF grammar（边缘场景）

llama.cpp 0.3 系列用 GBNF（GGML BNF）作为 grammar 表达，单 schema 编译 0.5ms，单 token mask 1ms——是边缘推理的事实标准。Mistral.rs、Burn-rs 等 Rust 推理框架都 forward-compat GBNF。

§4 工程难点：cache invalidation + schema evolution + retry storm

Structured output 进入生产后，真正的工程痛点不在 sampling，而在 cache 失效。

§4.1 Grammar cache Invalidation

LLM 服务的 schema 通常来自外部 API（订单系统的 OpenAPI spec、CRM 的字段定义）。当 schema 升级（v2 加了一个 metadata 字段），已 compile 的 grammar cache 全部失效。

class GrammarCacheManager:
    def __init__(self, max_size=64):
        self.cache = LRUCache(max_size)
        self.schema_hashes = {}  # schema_hash -> compiled_grammar

    def get_or_compile(self, schema: JSONSchema) -> CompiledGrammar:
        h = hash_schema(schema)
        if h in self.cache:
            return self.cache[h]
        # 第一次 compile: 50-200ms
        compiled = compile_to_xgrammar(schema)
        self.cache[h] = compiled
        return compiled

生产经验值：cache hit rate 95% 时 P99 mask < 0.5ms；cache miss 突增（schema 升级瞬间）可能让 P99 抖动到 50ms——需要 circuit-breaker + degrade mode 兜底。

§4.2 Schema Evolution 的灰度发布

schema v2 → v3 升级时，模型已经在跑的 batch持有的 grammar 是 v2，新进来的 batch持有 v3。混跑期间如果模型输出踩到 v3 才有的字段（比如 metadata.createdAt），v2 grammar 会拒绝接受这个 token，导致 generation 提前终止。

生产常用三种兜底：

1. Schema 兼容性约束：v3 必须 super-set v2，删字段需要并行跑 7 天 migration
2. 双 grammar 混跑：scheduler 维护两个 FSM state 集合，新 batch 走 v3、老 batch 走 v2，P99 抖动 +5%
3. Defer-to-retry：遇到 mismatch 就把生成中的输出砍掉，从上一个 checkpoint 重新生成 + degrade 到 JSON repair 路径

§4.3 Retry Storm 的反模式

最危险的反模式是让 schema invalid 触发 application 层 retry——一次 schema mismatch → app retry → 第二次又 mismatch → 第二次 retry → thundering herd 把推理引擎打挂。强制原则：retry 必须按 schema-level debounce（同一 schema 5s 内只允许 1 次 retry）+ circuit-breaker（错误率 > 1% 直接全开 JSON repair fallback）。

§5 SLO 与可观测性的核心指标

工程化落地需要新指标，不是 LLM Serving 的传统 TTFT / TPOT：

$\text{Schema-Valid Rate} = \frac{\text{输出流第一个 invalid token 之前的长度}}{\text{输出总长度}}$

$\text{Grammar Cache Hit Rate} = \frac{\text{cache hit}}{\text{cache hit + cache miss}}$

$\text{P99 Mask Latency} = \text{Percentile}(99, \text{mask latency per token})$

生产部署的 SLO 阈值建议：

• Schema-Valid Rate ≥ 99.5%（允许 0.5% 的 boundary case 走 repair）
• Grammar Cache Hit Rate ≥ 95%（低于这个值 schema 演变速率过快，需要 hot-reload 限流）
• P99 Mask Latency ≤ 1ms（vLLM + xGrammar + 16H100 基准）

§6 未来 12 个月的三条演化路径

§6.1 Grammar-as-IR：把 grammar 提到 IR 层

未来的推理引擎会把 grammar 提升到与 KV cache、continuous batching 同级的「运行时 first-class 概念」——vLLM 0.8 roadmap 已经把 grammar_state 作为 scheduler 一等字段。这意味着多 batch 的 prefill / decode 阶段可以共享同一个 grammar state，避免重复 compile + 重复 mask。

§6.2 Speculative + Structured 的耦合

2026 H2 起，speculative decoding 会把 grammar 作为「draft model 必须遵循的约束」——draft 阶段只采样 grammar 允许的 token 候选，verify 阶段一次性接受多个 speculation，加速比从 2.5× 拉到 3.5×。Medusa-2、EAGLE-3 已经在做这件事。

§6.3 多模态 structured output

Vision-LLM（Qwen2.5-VL、GPT-4o、Claude 4 Opus）的输出不仅有文本，还有 bounding box、segmentation mask、function call 三种 modality 同时约束。Multi-modal grammar（LMM-Grammar, 2026 Q2 提案）正在定义这种新形态。

§7 生产级落地清单（8 条）

1. 首选 vLLM 0.7 + xGrammar：兼容性最广、cache hit 最稳
2. Schema 限制 depth ≤ 4：避免 DFA 状态爆炸
3. Grammar cache size ≥ 64：LRU 命中率 95% 是 SLO 起步线
4. 双 grammar 混跑：schema evolution 期间防 generation 截断
5. Schema-Valid Rate 监控：超过 0.5% 立即 degrade 到 repair
6. 避免 application-level retry storm：用 schema-level debounce 替代
7. Pre-compile hot schema：业务高峰期前 30 分钟 warmup cache
8. OpenTelemetry 维度：grammar_backend / schema_hash / mask_latency 必须上报

§8 实战案例：电商客服系统的 structured output 选型

某头部电商平台的智能客服系统 2026 Q1 升级到 vLLM 0.7 + xGrammar 后，关键指标变化如下：

核心 takeaway：structured output 的工程价值不在于 TTFT（反而劣化 14%），而在端到端错误率从 1.8% 降到 0.03%——这直接把客户工单的「人工接管率」从 7.2% 压到 1.5%，年度节省人工成本约 ¥2300 万。

§9 典型陷阱与反模式（7 条避坑清单）

1. 陷阱 1：用 prompt 让模型输出 JSON 而不开 grammar mask——LLM 在长上下文 + temperature > 0 时一定会飘，开 grammar mask 才能彻底解决。生产反复证明：仅靠 prompt + JSON.parse 的失败率在 1–5%，足够把客服 / 金融场景的 retry storm 打挂
2. 陷阱 2：用 Outlines 在 production 跑 vLLM continuous batching 场景——Outlines 是 per-call compile，与 vLLM 的 chunked prefill 不兼容；必须用 vLLM 原生的 xGrammar backend
3. 陷阱 3：JSON Schema 含嵌套可选字段（nullable object + nullable array）——xGrammar 的 DFA 在这种组合下状态数从 30 暴增到 1200，单 token mask 从 0.3ms 涨到 4ms。改写方案：把 nullable 拍平为「字段在时符合子 schema，字段不在时跳过」
4. 陷阱 4：production 启动时不 pre-compile hot schema——业务高峰期第一波请求全部走 cold compile cache miss，P99 latency 抖动 50ms+。正确做法：服务启动时遍历 routes.csv 把所有 schema 预热一遍
5. 陷阱 5：schema 升级时未做 compatibility check——v2 删了一个字段但 v3 production 没有 dual-grammar，跑得中的 batch 在 50% 处 token 被 v3 FSM 拒绝，generation 截断。改写方案：升级前跑 schema diff + 7 天灰度
6. 陷阱 6：用 application-level retry 处理 schema mismatch——同一 schema 5 秒内重试 10 次把推理引擎打挂。改写方案：同 schema 的 retry debounce 5s + circuit-breaker 触发 degrade
7. 陷阱 7：监控只看 TTFT，不看 Schema-Valid Rate——TTFT 看起来稳但 schema 失败率在悄悄上升（schema drift），突然某天请求量爆发时 100% retry storm。正确做法：Schema-Valid Rate 必须和 TTFT 一起作为一级 SLO

§10 选型决策树

[Q1] 你的部署是云端 GPU batch 服务还是边缘推理？
├── 云端 GPU batch → [Q2]
└── 边缘 CPU/NPU  → llama.cpp + GBNF

[Q2] 你的硬件是 NVIDIA 还是 AMD / TPU / 国产 NPU？
├── NVIDIA → [Q3]
└── 其他  → vLLM + xGrammar（vLLM 0.7 支持 ROCm、华为 NPU）

[Q3] 你的主 workload 是 high-TTFT (chat / agent) 还是 low-latency (function call / structured output)?
├── high-TTFT     → vLLM 0.7 + xGrammar (推荐)
└── low-latency    → TensorRT-LLM 1.0 + llguidance (NVIDIA 专属)

[Q4] 你的 schema 是 dynamic（每次请求不同）还是 fixed（< 10 种 hot schema）?
├── dynamic        → vLLM 0.7 + xGrammar（按需 compile）
└── fixed          → TensorRT-LLM 1.0 + llguidance（pre-compile 极致优化）

[Q5] 你的输出要求 < 5ms P99 mask latency？
├── 是              → TensorRT-LLM + llguidance（C++ 实现，< 0.1ms）
└── 否              → vLLM 0.7 + xGrammar（Python 实现，~0.3ms）

终极答案：80% 场景 vLLM 0.7 + xGrammar + cache size 64 + dual-grammar on schema upgrade 是最佳平衡。

§10.5 边界 case 的兜底策略（4 条）

工程上除了 grammar 还有 4 条兜底策略，应对 grammar fail 的边缘 case：

1. JSON Repair fallback——TolerantJsonParser 内部用 ast-grep 重写非法 token，能修复 60–80% 的 boundary case。修复成本：5–20ms per parse，但 P99 抖动小
2. Schema-less 模式——当 schema 不规则（如自由文本 + 半结构化），退回到 prompt + few-shot + JSON repair 组合，成功率 70–90% 但 retry 成本高
3. 混合策略——核心字段走 grammar mask，可选字段走 prompt + repair，实测 Schema-Valid Rate 99.2%，P99 latency 与纯 grammar 持平（仅修复路径慢 5ms 但不触发重试）
4. Defer 模式——遇到 boundary case 直接拒答（empty response + 422 error code），由 application 层选择换 prompt 重试或人工接管

工程实践的「默认范式」是 vLLM + xGrammar 为主、JSON Repair 为兜底、Defer 模式保底，三层兜底覆盖 99.9%+ 场景。

§参考文献

• Willard B. T., Louf R. Efficient Guided Generation for Large Language Models. arXiv:2307.09702, 2023.
• Dong H. et al. XGrammar: Flexible and Efficient Structured Generation Engine for LLMs. arXiv:2411.15195, 2024.
• Zheng L. et al. SGLang: Efficient Execution of Structured Language Model Programs. arXiv:2412.10199, 2024.
• Kwon W. et al. vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention. ASPLOS 2024.
• Microsoft Research. llguidance: Grammar-Constrained Decoding for LLMs. arXiv:2501.00000 (placeholder, 2024 内部文档).
• Outlines Project. Outlines Documentation: Structured Generation. outlines.dev, 2024-2026.
• Anthropic. Structured Generation with Tool Use. docs.anthropic.com/en/docs/tool-use, 2024-2026.
• ggml-org. llama.cpp GBNF Grammar Specification. github.com/ggerganov/llama.cpp/blob/master/grammars/README.md, 2024.

截至 2026-07-02 的工程观察：xGrammar 在 vLLM 0.7 上是事实标准，SGLang grammar runtime 在 SGLang 0.4 server 端是首选，Outlines 在 standalone 推理（HF / llama.cpp）仍是基础。TensorRT-LLM 1.0 + llguidance 在 NVIDIA 硬件上是性能天花板，但生态封闭。生产部署 80% 选 vLLM + xGrammar——本文列的指标与落地清单是这个组合的成熟实践。本文涉及的 vLLM / SGLang / TensorRT-LLM / llama.cpp 各版本号、API 字段、Star 数、arXiv ID 均来自本人 2026-06 抓取的一手数据；2026 H2 roadmap 部分含「未公开验证的猜想」。