决策模型不必生成解释：SGLang 的 Score API 让多候选打分复用共享查询，延迟随候选数几乎不涨
核心概要
面向订单状态这类决策任务，应用往往只需要一个类别或分数，而不是一段解释。SGLang 的 Score API 让调用方显式声明标签 token 并直接取分，多条目打分（MIS）则在一次请求内复用重复的查询计算、同时保持各候选相互隔离。在 Open-Jev 选择题负载上，候选数从 2 增到 16 时 MIS 延迟近乎持平：Qwen3-0.6B 为 18.7 ms，对照 Generate 的 39.6 ms 与 SIS 的 24.3 ms；这一优势随负载上升最明显，低负载下并不总是更快。
深度剖析
决策类应用现在可以要求模型直接返回指定标签的分数，而不必从生成结果的 top-k logprobs 里碰运气找标签。 此前用单 token 生成加 logprobs 是可行基线，但 top-k 响应可能漏掉应用真正需要的那个标签。 SGLang 的 /v1/score 通过 label_token_ids 显式声明标签，按请求的标签顺序为每个条目返回一行分数，并以 Open-Jev 的独立候选提示作为具体负载。
多条目打分把同一请求内重复出现的查询计算复用起来，同时让每个候选只能看到该查询和自身 token。 单条目打分把每个查询加条目的组合当作独立逻辑序列，即使一次请求里含多个条目也是如此；连续批处理和前缀缓存有帮助，但批处理本身不保证共享计算。 在单张 NVIDIA H200、CUDA 13.0 的 SGLang 上，用 Qwen3-0.6B、Qwen3-8B 和 Qwen3.5-4B 跑 Open-Jev 选择题，候选数从 2 增到 16 时 MIS 延迟近乎持平，16 个候选下 Qwen3-0.6B 为 18.7 ms，Generate 为 39.6 ms，SIS 为 24.3 ms。
负载升高时，MIS 的延迟优势才明显拉开，但它推迟饱和而不是消除饱和。 低负载下 MIS 并不总是更快，Qwen3.5-4B 在低负载时 Generate 反而更快。 Qwen3-0.6B 的 p95 在绘图范围内保持约 100 ms 以下，而 Generate 与 SIS 升到秒级；Qwen3-8B 的 MIS 在 90 问题/秒内维持约 130 ms，下一负载点急剧上升；Qwen3.5-4B 在最高绘图负载下 MIS 的 p95 约为另两条路径的三分之一。
启示与展望
这些测量只评估服务性能，覆盖 Open-Jev 选择题上的点式候选评估，以及同一服务器配置下 Fused-Choice 与基于锚点的 Setwise 打分对比；它们不证明不同提示形式或执行方式会给出等价决策。
MIS 需要受支持的模型、后端和服务器配置，仅选择 /v1/score 并不会启用它；候选数分组包含不同问题与不同 token 长度，因此这是观测到的工作负载趋势，而非隔离候选数效应的实验；高负载点还包含大量客户端排队，且每个负载只扫一次。