SGLang 生产落地案例

五、生产落地案例

案例一：合同信息抽取，从「重试到成功」变成「一次解析成功」

业务背景：一家法务科技公司做合同要素抽取，早期用通用模型 + 提示词要求输出 JSON，实际约有相当比例的输出无法直接解析，需要重试或人工兜底，成本和延迟都高。

怎么用：把服务换成 SGLang，用约束解码把输出限制成固定 schema 的 JSON；同时把「合同模板说明 + 输出格式说明」这段固定前缀放在最前面，让 RadixAttention 复用；批量提交时按合同类型分组，让同类型请求的前缀更一致。

关键配置：context-length 按最长合同的切片长度设置并留余量；mem-fraction-static 从较低值开始试，逐步上调到吞吐不再提升为止；采样温度设得低以保证抽取的稳定性。

效果指标：解析失败率大幅下降（具体数值取决于 schema 复杂度与模型能力，以自家评测集为准），下游重试链路基本可以撤掉；固定前缀复用后，长合同的处理成本明显下降。

踩过的坑：一是schema 一开始设计得太自由，字段嵌套过深导致约束解码效果不佳，后来把 schema 拍平成可枚举字段；二是前缀不统一，每次拼接时字段顺序不同，缓存命中率极低，规范了 prompt 生成顺序后才好转；三是把 mem-fraction-static 一次设到高位，服务在某些权重上直接启动失败，改成从小往上调。

案例二：Agent 多步流程统一到一个服务里

业务背景：一个智能助手的后端由多个模型调用串起来（意图识别 → 工具选择 → 结果整理），每步都是独立的 HTTP 请求，步骤间往返延迟叠加，且每步都要重新计算相同的前缀。

怎么用：把多步流程改写成前端 DSL 里的一个函数，一次提交、运行时分步执行；共享的系统提示与工具描述放在函数开头，形成稳定前缀；对分支里的早退路径（比如意图是闲聊就不走工具调用）由函数逻辑直接控制。

关键配置：每步的最大输出长度分别设置，避免中间步骤啰嗦；对温度做分层（识别类步骤温度低，生成类步骤温度适中）；把工具调用结果作为变量拼进下一步的 prompt。

效果指标：端到端往返次数减少，整体延迟下降（下降幅度取决于步骤数与网络往返占比）；相同前缀的重复计算被消除。

踩过的坑：一是把长上下文当免费资源，多步流程不断往 prompt 里追加历史，导致中间步骤上下文爆炸，后来加了历史摘要；二是中间步骤输出未做长度限制，某一步输出过长挤占了整批的缓存；三是分支逻辑没设兜底，模型输出不在预期枚举里时流程卡住，补了默认分支与超时。