本文结论先行：把「分类 / 路由 / 判定」这类任务从生成模型里拆出来，交给专门的决策模型（decision model），能把单次延迟从几百毫秒压到 sub-100ms，成本降到原来的几十分之一。SGLang 已在 nightly 加入
/v1/decisions与/v1/systemone端点，AWS 也开源了 Strands Decider 2B，这个方向已经从概念变成可落地的工程选项。
一、原理：决策模型到底省在哪传统做法里，Agent 每到一个分支点，就调一次大模型让它「生成一段文字说明理由再选择」。比如路由用户问题，你得 prompt 它输出 {"route": "codegen"}，然后解析 JSON。问题有三：生成式解码慢、输出长度不可控、还要做脆弱的字符串解析。决策模型（decision model）换了个思路：它只在有限选项里挑一个 ，不生成自由文本。例如 AWS 开源的 Strands Decider 2B，权重和训练配方都按 Apache 2.0 放出，专门干「从预设选项里选一个」的活，官方标称 sub-100ms 延迟。SGLang 在 v0.5.21 的 nightly 里加了 /v1/decisions 路由，社区实测用 Qwen3.8-27B 当多模态决策器，在 Pokémon FireRed 这类决策基准上一次过、延迟在 100ms 以内。比如 Agent 要判断「这条用户消息该转给检索、写代码还是计算器」，用决策端点返回的就是一个带置信分的选项，省掉了整段解码。例如 要对一批工具调用做「安全 / 危险」二分类，决策模型比让 GPT 写一段分析再归纳要稳得多，也快得多。## 二、环境准备与启动决策端点在 SGLang 的 nightly 构建里，先装版本≥0.5.21 的 nightly：bashpip install "sglang[all]>=0.5.21" --pre -U# 启动一个支持决策端点的服务（以 Qwen3.8-27B 为例）python -m sglang.launch_server \ --model-path Qwen/Qwen3.8-27B-Instruct \ --host 0.0.0.0 --port 30000 \ --enable-decision-endpoint # nightly 开关，具体以官方 release note 为准
启动后会有两个关键路由：- POST /v1/decisions：多选项打分并返回最优项；- POST /v1/systemone：系统级单步决策（system-one / 原子决策）。> 注意：决策端点是 2026-09 底才进 nightly 的能力，生产环境请用 sglang>=0.5.21 并核对实际参数名；若你的版本没有该开关，可退回「用普通 chat 端点 + 低 max_tokens + 强约束」的兜底方案（见第五节）。## 三、把大模型当分类器：Agent 意图路由下面是一个可直接复制的客户端，把用户问题路由到四个处理分支。它不解析自由文本，而是拿回一个 {choice, scores}：pythonimport requests, timeDECISION_URL = "http://localhost:30000/v1/decisions"OPTIONS = ["retrieval", "codegen", "calculator", "chitchat"]def route_query(text: str) -> dict: payload = { "model": "Qwen3.8-27B-Instruct", "input": text, "options": OPTIONS, "return_scores": True, } t0 = time.perf_counter() r = requests.post(DECISION_URL, json=payload, timeout=5) dt = (time.perf_counter() - t0) * 1000 resp = r.json() return { "choice": resp["choice"], "scores": resp.get("scores", {}), "latency_ms": round(dt, 1), }if __name__ == "__main__": for q in ["帮我查一下上季度的退货率", "用 Python 写个快排", "3.14 乘以 200 等于多少", "今天心情有点丧"]: print(q, "->", route_query(q))
跑起来你会看到每条消息都在 100ms 内拿到了 choice 和归一化 scores。比如 「帮我查退货率」的 retrieval 分会显著高于其他项；「写个快排」的 codegen 分会拉满。相比调一次 GPT 类生成模型再 json.loads，这套路径延迟能降一个数量级。## 四、工程取舍：延迟、成本、准确率怎么选决策模型不是免费午餐，三个维度要权衡：1. 延迟 vs 模型大小 ：Decider 2B 这类小模型 sub-100ms，但只适合简单二分类/多分类；复杂语义路由还是得上 27B 级别，延迟会上到几十毫秒到一百多毫秒。2. 成本 ：Respan 的 Span-01 把行为检测（prompt injection / 幻觉 / 工具滥用）做到每 100 万输入 token 仅 0.02 美元；而同样的事让旗舰生成模型干，单价高几十倍。例如 在一个每天千万次调用的网关上，把「安全二分类」从 GPT 级换到决策模型，月度账单能从五位数掉到两位数。3. 准确率天花板 ：决策模型在「选项边界清晰」的任务上很强，但选项定义模糊时会乱选。务必把选项写成互斥且可观测的动作，而不是抽象形容词。## 五、踩坑清单- 选项措辞决定上限 ：["好", "不好"] 这种抽象标签，模型容易漂移；改成 ["allow", "block"] 或 ["route_search", "route_llm"] 这类动作化标签，分数分布立刻变干净。- 版本开关不一致 ：SGLang 决策端点是 nightly 特性，不同提交参数名可能变；上线前先 curl 一下 /v1/models 确认端点存在，别直接硬编码。- 别拿它做需要解释的决定 ：决策端点不返回推理链。审计、合规、退款这类「要给人看理由」的环节，仍应走生成模型并留日志。- fallback 必须有 ：当决策服务 5xx 或超时，用一条基于关键词 / 嵌入相似度的规则兜底，保证链路不中断。示例：pythondef route_with_fallback(text, latency_budget_ms=120): try: return route_query(text) except Exception: # 关键词兜底，绝不抛错中断 Agent if any(k in text for k in ["算", "乘以", "等于"]): return {"choice": "calculator", "scores": {}, "fallback": True} if any(k in text for k in ["查", "检索", "文档"]): return {"choice": "retrieval", "scores": {}, "fallback": True} return {"choice": "chitchat", "scores": {}, "fallback": True}