推理服务为什么一开 Structured Output 就开始掉吞吐：从 Constrained Decoding 到 Grammar State Cache 的工程实战

明明输出 token 不多为什么一开结构化约束吞吐反而先掉下去很多团队给LLM接上Structured Output后第一反应往往是“输出更短了服务应该更快”。⚠️ 线上结果却经常相反抽取、审核、工单分发这类场景刚切到JSON Schema单卡TPS就先掉一截P95还会明显抖动。 真正变慢的不是模型前向而是 decoder 每一步都要先算合法 token 集再决定能不能采样。这类问题在离线冒烟阶段并不明显。 小批量、单一 schema 和短响应很容易掩盖约束成本一到真实流量普通对话和结构化请求混跑批次里的 request 会迅速分叉到不同语法状态共享 decode 立刻失效。 结构化输出不是“多一道格式检查”而是改写了 token 选择逻辑。图 1结构化输出会把 token 选择改造成逐步受限的语法路径 真正拖慢服务的不只是合法 token 变少而是状态爆炸、批次分叉和缓存失效Constrained Decoding的典型瓶颈有三层。 一是状态爆炸嵌套对象、长enum和数组重复项会放大自动机规模二是批次分叉同批请求落在不同字段和括号层级mask 很难复用三是缓存失效schema 临时编译、合法 token 集反复重算GPU 只能等 CPU 侧准备约束。 这些问题叠在一起就会把 decode 变成尾延迟放大器。一组32路并发的抽取服务压测里普通文本生成模式单卡吞吐为118 tok/s切成“直接按请求动态编译 schema”后掉到81 tok/sP95从142 ms抬到236 ms。✅ 当系统把 schema 版本固定、预编译语法树并引入grammar_state_cache后吞吐回到103 tok/s同时无效JSON仍维持在0.2%以下。 关键结论不是“结构化输出一定慢”而是不能把它当成零成本开关。方案单卡吞吐P95 时延GPU 利用率无效 JSON 率主要瓶颈普通生成118 tok/s142 ms74%3.6%主要受模型前向限制动态 schema 约束81 tok/s236 ms51%0.1%语法编译和状态分叉预编译 状态缓存103 tok/s168 ms68%0.2%约束仍有成本但可控图 2大多数 Structured Output 慢路径都不是单点故障️ 更稳的工程做法是把 schema 预编译、状态做缓存再把流量按约束强度分层更稳的做法不是让每个请求带着原始 schema 直接进采样器而是先把 schema 编译成可复用自动机再把运行中的语法状态做成热缓存。️ 缓存键至少要包含model_id、tokenizer_rev、schema_hash和约束模式避免不同模板互相污染。 对高频任务服务应直接复用 automata snapshot并把自由文本字段改成尾段宽松模式别让整段说明文字也被最严格的enum拖住。流量侧最好再做一次分层。 固定字段抽取、路由决策和函数参数生成适合强约束长摘要和理由生成更适合“核心字段强约束 尾段弱约束”的混合路径。 团队至少要持续盯住grammar_cache_hit_rate、masked_vocab_ratio、constrained_batch_mix和tail_p95否则只会看见格式正确率提升却忽略 GPU 已经被拖出最优批处理区间。defget_decoder_plan(model_id,tokenizer_rev,schema_text,task_kind):schema_hashsha1(schema_text.encode()).hexdigest()cache_key(model_id,tokenizer_rev,schema_hash,task_kind)plangrammar_plan_cache.get(cache_key)ifplanisNone:automatacompile_schema_to_automata(schema_text)planbuild_decoder_plan(automata,allow_relaxed_tailtask_kindmixed)grammar_plan_cache.put(cache_key,plan)returnplandefdecode_with_constraints(request):ifrequest.task_kindnotin{extract,route,tool_args,mixed}:returnplain_decode(request)planget_decoder_plan(request.model_id,request.tokenizer_rev,request.schema_text,request.task_kind,)returnconstrained_decode(request,plan,state_cachegrammar_state_cache)图 3把 schema 编译和状态复用前置才能把慢路径收窄 接下来 3 到 6 个月Structured Output 的分水岭会从格式正确率转向推理引擎能力接下来3到6个月结构化输出的竞争点会继续右移。 真正拉开差距的不会只是“谁支持更多 schema 语法”而是谁能把约束逻辑稳定地塞回高吞吐 decode 管线里。 如果引擎层没有 grammar cache、批次亲和调度和 schema 宽度治理团队很容易得到一个“格式更准但服务更贵”的系统。笔者认为Structured Output最终会从应用层功能变成推理服务的基础设施能力。 线上真正该问的不是“模型能不能吐出合法JSON”而是“在高并发和混合流量下服务还能不能维持稳定批处理”。 你们当前遇到的更像是哪一种schema 太复杂导致状态爆炸还是普通请求和约束请求混跑后把尾延迟一起拖高欢迎交流。图 4上线后要盯缓存命中、合法词表宽度和尾延迟一起变化