引言

过去一个月，我连续写了两篇决策模型的文章：Jev vs Laya 对比了闭源的 Jev 和开源的 Laya，Microsoft-Decision-1 详解 又加入了微软。写完之后，被问得最多的问题是：能不能自己训练一个？

答案是可以，而且门槛比想象中低。看看第三方榜单 JevBench 就知道：截至 10 月中旬，开源权重榜上已经有 160 多个参与排名的系统，绝大多数出自社区和中小团队之手。排在前面的也不神秘：综合分第一的 H2O-Lightning-4B 是在阿里开源的 Qwen3.5-4B 上微调出来的，能力分第一的 Quyet-1.0-Large 则是 Gemma-4-31B 加一个适配器；微软的 Microsoft-Decision-1，底座同样是开源的 Qwen3.5-9B。

这说明一件事：决策模型的核心竞争力不在模型结构，而在数据、训练目标和评测体系。 这三样东西，普通团队完全可以自己掌握。

本文按一个真实项目的顺序，把训练一个“自己的 Jev”的全过程走一遍：

1. 原理：决策模型到底在学什么，为什么训练目标必须是“严格适当评分规则”
2. 数据：去哪里找，怎么统一格式、清洗、增强和切分
3. 算力：需要多少显存、多少 GPU 小时、多少钱
4. 底座：怎么选基础模型
5. 训练：从零写一套可以直接运行的 LoRA 训练脚本
6. 评测：用哪些指标打分，怎么和 JevBench 上的模型同场比较
7. 调优：分数不理想时，按什么思路改进

文中的脚本我都在 Qwen3.5-0.8B 上实际跑通过（CPU 冒烟测试，只用来验证代码正确性），文中引用的榜单和模型数据均来自公开资料，链接列在文末。

一、先想清楚：决策模型到底在学什么

1. 本质是一个“条件概率”

先回顾一下决策模型的接口：调用方给出一段状态（state）和一个问题，问题的候选答案由调用方提前定义好，模型返回每个候选答案的概率。三种问题原语都可以统一成同一件事：

所以，训练一个决策模型，就是让模型学会估计 P(选项 | 状态, 问题)。和普通的文本分类模型相比，它有两个关键区别：

• 类别不是固定的：每次请求的问题和选项都不一样，模型必须读懂选项的含义，而不是记住一组固定的标签。这就是它需要“零样本泛化”能力的原因。
• 概率本身就是产品：下游程序会直接拿概率做 if 判断，所以概率必须“诚实”，也就是校准过的。这决定了训练目标的选择，后面会专门讲。

2. 三条技术路线

目前社区的做法大致分成三类：

JevBench 的数据给出了很清楚的信号：

• 几个编码器路线的系统，零样本智能分都只有个位数（Laya 1.8、modernbert-jev v2 2.6、open-jev-deberta-v3-large 2.8），和随机猜测差不多；
• 完全不做决策微调、直接读取 Qwen3-4B-Instruct-2507 的 logits，智能分就有 34.0；
• 在 Qwen3.5-4B 上做过决策微调的 H2O-Lightning-4B 达到 60.0，接近 Jev 1.13.0 的 63.6；
• 更大的 Gemma-4-31B 底座（Quyet-1.0-Large）达到 73.4。

结论很明确：如果目标是 Jev 那样的“零样本通才”，应该走解码器路线，大模型预训练时学到的知识是零样本能力的来源，决策微调则把这些知识“对齐”到选项概率上；如果只服务一两个固定任务，对延迟要求极高，而且有足够的标注数据，Laya 这样的编码器路线依然是性价比最高的选择。

本文的主线是第二条路线：解码器 + 选项字母。它的推理过程是这样的：

1. 把状态、问题和带字母编号的选项拼成一段对话提示词，以助手回复的开头结束；
2. 模型做一次前向计算（只有预填充，没有逐 token 生成）；
3. 在最后一个位置（答案位）取出 A、B、C……这几个字母 token 的 logits，只在这 K 个 logits 上做 softmax，得到每个选项的概率。

H2O-Lightning-4B 的模型卡把这概括为“一次前向，一个输出 token”（one forward pass and one output token）。因为不生成文本，成本几乎只有输入 token；又因为输出空间被限定在 K 个字母上，模型不可能答出选项以外的东西。这条路线还有一个先天优势：大模型在选择题格式下给出的字母概率，本身就有不错的校准性（Kadavath 等人，2022），决策微调是在一个好的起点上继续打磨。

3. 训练目标：为什么必须是“严格适当评分规则”

决策模型输出的概率要直接进入程序的分支判断，所以我们要的不只是“答对”，还要校准：在所有给出 80% 把握的回答里，应该恰好有大约 80% 是对的。

第一个坑：只奖励“答对”会毁掉校准。 假设一道题的真实分布是 p（比如 70% 选 A、30% 选 B），模型报告的分布是 q。如果把模型当成策略，按 q 抽一个答案，答对得 1 分，期望奖励就是 Σ p_k · q_k，它对 q 是线性的，最优解是把全部概率押在最可能的选项上，也就是让 A 的概率等于 1。模型被训练成“永远 100% 确定”，准确率没变，概率却失去了意义。

解决办法是用严格适当评分规则（strictly proper scoring rule）做目标。 它的定义是：只有当模型报告的分布 q 等于真实分布 p 时，期望得分才能达到最大值，说真话是唯一的最优策略（经典论述见 Gneiting 和 Raftery 2007 年的论文）。常用的有四种：

记 q = (q_1, …, q_K) 为模型给出的分布，y 为标签（one-hot 或软标签）

对数评分（越大越好）     S_log(q, y) = Σ y_k · log q_k            就是负的交叉熵
Brier 分数（越小越好）   B(q, y)     = Σ (q_k − y_k)²
球面评分（越大越好）     S_sph(q, y) = Σ y_k · q_k / ‖q‖          取值 0～1，梯度比对数评分温和
排序概率分（越小越好）   RPS(q, y)   = Σ (Q_i − Y_i)² / (K − 1)   Q、Y 是累积分布，用于有序的 score

这里有一个经常被忽略的事实：交叉熵本身就是严格适当的（它就是对数评分）。那为什么用交叉熵训练出来的神经网络普遍过度自信？原因不在损失函数，而在于有限的训练数据：模型会把训练样本“背”下来，把它们的概率推向 1，到了没见过的数据上，自信程度就高于实际准确率（Guo 等人 2017 年的论文对此有系统的分析）。所以有两点要做到：

1. 训练时：用严格适当评分规则做目标；标签本身有不确定性时（标注员意见不一、多个教师模型投票不一致），用软标签代替 one-hot，让模型学会“诚实地不确定”；不要训练过多 epoch。
2. 训练后：在留出的开发集上做温度缩放（temperature scaling），即 p = softmax(z / T)，按问题类型拟合一个温度 T。它不改变排序，所以不影响准确率，只修正自信程度。

温度缩放的效果往往非常明显。Laya 的出厂检查点按“问题类型 × 选项数”重新拟合温度后，平均 ECE（期望校准误差）从 0.466 降到了 0.081。而 H2O-Lightning-4B 随模型发布的温度是 choice 0.75、noul 0.8、score 0.65，都小于 1，说明它的原始输出反而偏保守，需要“锐化”。方向因模型而异，只能实测，不能拍脑袋。

4. RLCD：Laya 公开的强化学习做法

Jev 把自己的训练方法称为 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习），但没有公开细节。Laya 沿用了这个名字，并公开了一个具体实现：

• 奖励：三种严格适当评分的组合，Reward = S_log + 0.5 × S_sph − RPS，其中 RPS 只对有序的 score 题生效；
• 探索：每道题对 logits 加 8 组高斯噪声（噪声在选项维度上减去均值，因为给所有 logits 加同一个常数不会改变 softmax），噪声的标准差从 1.0 逐步衰减到 0.3；
• 优势：8 个样本的奖励减去组内均值、除以组内标准差，和 GRPO 的组内基线是同一个思路（GRPO 的原理可以参考我之前写的 PPO vs GRPO）；
• 更新：用高斯分布的对数密度做 REINFORCE 式的策略梯度，完全不使用交叉熵损失。

我的理解是：当模型直接输出完整的概率分布时，评分规则本身就是可微的，直接对它求梯度（也就是把评分规则当损失函数）和用强化学习去估计这个梯度，在期望上指向同一个方向，前者方差更小、更省事。 强化学习的形式真正不可替代的场景，是奖励无法对输出直接求导的时候，比如奖励来自多步 Agent 任务最终是否成功、用户的真实反馈，或者 Laya 处理的多轮销售对话：奖励是对话最终是否成交，需要用 TD(λ) 把这个结果分摊到每一轮。

为了验证这个判断，我用后文训练脚本里的 reward() 函数做了两个小实验：一是把目标分布设为 [0.7, 0.2, 0.1]，直接对组合评分做梯度上升，模型输出的分布最终收敛到 [0.7, 0.2, 0.1]，说明这个组合评分确实“只奖励说真话”；二是对同一组 logits，用 RLCD 的方式（2 万组扰动，σ = 0.05）估计梯度，它和直接求导得到的梯度方向几乎完全一致（余弦相似度 0.999）。

所以本文的训练脚本两种都支持：默认直接优化评分规则（--objective proper），也可以切换成 Laya 式的 RLCD（--objective rlcd），自己对比。

5. 从概率到动作：阈值由代价决定

概率校准好之后，“什么时候自动执行、什么时候转人工”就不必拍脑袋了。Laya 给它的 Act / Escalate 头设计了一个代价矩阵：判对 +1，判错 −3，转人工 −0.5。自动执行的期望收益是 p × 1 + (1 − p) × (−3)，它大于 −0.5 的条件是 p > 0.625。一般地：

自动执行的阈值 = (转人工的收益 − 判错的收益) / (判对的收益 − 判错的收益)
              = (−0.5 − (−3)) / (1 − (−3)) = 0.625

只要概率是校准的，这个阈值可以直接从业务代价算出来，单独训练一个“该不该执行”的头反而不是必需的（Laya 的 README 也坦承它的 Act 头目前几乎没有信号，建议直接用置信度做门控）。H2O-Lightning-4B 在 3474 道留出题上给出了阈值的实际效果：

这张表就是你训练完之后要为自己的模型画出来的东西。

6. 全流程一览

把上面的原理落到工程上，一个完整的训练项目大致是这样的循环：

① 定义题目和验收标准：指标、阈值、上线门槛，先写下来再看结果
        │
② 找数据 → 统一格式 → 去重、去污染 → 按任务切分
        │
③ 零样本基线：直接读底座模型的选项字母概率，先知道起点在哪里
        │
④ LoRA 微调：选项随机乱序 + 严格适当评分规则（或 RLCD）
        │
⑤ 在开发集上拟合温度，在留出任务、公开集和私有封存集上打分
        │
⑥ 按切片做误差分析 → 补数据 → 回到 ④
        │
⑦ 合并权重，接入 /v1/systemone 接口，灰度上线，持续监控

接下来按这个顺序逐一展开。

二、数据：从哪里找，怎么准备

数据决定了决策模型的上限。H2O-Lightning-4B 在模型卡里总结的几条经验，几乎都和数据有关：留一份从不参与训练的封存评测集、上线标准先写下来再看结果、训练数据和所有评测集做精确和近似去重、按主题和题型找短板再补数据、标签只来自人工标注或多个独立强模型的一致意见。

1. 数据从哪里来

几个经验值得参考：

• Laya 坚持“零合成”：训练数据全部来自人工标注的公开数据集（客服意图、自然语言推理、内容安全、越狱与注入、评分细则打分、多轮对话结果等），理由是用模型生成的标签训练校准模型，只会把模型校准到“老师”的错误上。
• H2O-Lightning-4B 的数据配比：按场景分，文档、政策与规则 37%，数字、日期与概率 22%，游戏与模拟 12%，日常语言与知识 10%，客服与运营 10%，安全与护栏 7%，代码与工具调用 2%；按题型分，choice 54%、noul 29%、score 16%；超过 99% 是英文。训练分三个阶段：先广泛覆盖，再集中强化长文档和数字推理，最后把所有类型重新混合。
• 任务的多样性比单个任务的样本量更重要：FLAN 系列研究发现，指令微调时覆盖的任务种类越多，模型在没见过的任务上表现越好，这一点对决策模型同样成立。在总量相同的情况下，覆盖更多不同的任务，通常比在少数几个任务上堆样本更有利于零样本泛化。

如果只是做某个垂直领域的专用模型，几千到几万条高质量标注就能有明显提升：Laya 的 typed-decisions 检查点用约 3 万道题微调，准确率从 0.362 提升到 0.766；社区有人用单张 16 GB 显卡把 Laya 微调成浏览器 Agent 的操作决策器，约 45 个候选元素中选对目标的比例从 0.10 提升到 0.66。

2. 统一的数据格式

建议直接沿用 Jev 的请求格式，每行一道决策题：

{"task": "ticket_routing", "state": "Checkout returns HTTP 500 for every customer since 09:10.",
 "question": {"type": "choice", "instructions": "Which team should handle this ticket?",
              "criteria": {"billing": "Charges, invoices and refunds",
                           "engineering": "Bugs, errors and outages",
                           "support": "How-to and account questions"}},
 "answer": "engineering"}
{"task": "refund_check", "state": {"subject": "Charged twice", "body": "Please refund the duplicate."},
 "question": {"type": "noul", "instructions": "Does the customer ask for a refund?",
              "criteria": {"true": "yes, a refund is requested", "false": "no refund is requested"}},
 "answer": true}
{"task": "urgency", "state": "Payroll export fails and payroll runs today.",
 "question": {"type": "score", "instructions": "How urgent is this request?",
              "criteria": ["not urgent", "soon", "today", "blocking right now"]},
 "answer": 2}
{"task": "intent_soft", "state": "I was billed twice and the app keeps crashing.",
 "question": {"type": "choice", "instructions": "What is the main topic?",
              "criteria": {"billing": "payments", "technical": "bugs"}},
 "target": {"billing": 0.6, "technical": 0.4}}

几点约定：

• 为了便于阅读，上面的示例做了换行，实际文件中每条记录占一行（JSONL）；
• answer 对 choice 是选项名，对 noul 是布尔值，对 score 是等级下标；有不确定性的样本用 target 给出软标签；
• task 字段记录样本来自哪个任务，后面切分和按切片分析都要用到；
• 这个格式和 JevBench 公开题集的格式几乎一致（它用 expected 字段存答案），后面的评测脚本可以直接读取 JevBench 的公开题。

3. 清洗与增强

清洗要做三件事：

1. 去重：先做规范化后的精确去重，再用 MinHash 之类的方法做近似去重，避免同一条数据换个标点就出现好几遍；
2. 去污染：把所有评测集（自己的封存集、JevBench 公开题等）都和训练集做比对，有重叠的从训练集里删掉。JevBench 要求在公开题上训练过的模型必须主动声明，而且公开题成绩明显高于封存题的模型还会被扣分，“刷”公开题没有意义；
3. 配平：给每个任务设上限，防止某个大数据集主导训练；同时控制题型、语言、选项数的分布。

增强的目标是让模型学会“看内容，而不是看形式”：

要注意顺序：先切分，再增强，而且增强只作用于训练集，否则同一道题的不同变体会同时出现在训练集和评测集里，评测分数就虚高了。

4. 切分：一定要按“任务”留出

决策模型最重要的能力是泛化到没见过的问题，所以评测集要分层次：

真实项目里，每种题型下面都应该有多个任务，留出整个任务之后，训练集里仍然有同题型的其他任务。

下面是一个最小的数据准备脚本，把 Banking77（意图，choice）、BoolQ（是否题，noul）、SST-5（情感，score）和 OCNLI（中文推理，choice）四个公开数据集改写成决策题，完成去重、去污染和按任务切分：

# prepare_data.py
"""Turn a few public datasets into decision records, remove duplicates and eval overlap, split by task."""
import hashlib
import json
import random
from pathlib import Path

from datasets import load_dataset

random.seed(13)
SST5_LEVELS = ["very negative", "negative", "neutral", "positive", "very positive"]
OCNLI = {"entailment": "前提为真时，假设一定为真",
         "neutral": "前提为真时，假设可能为真也可能为假",
         "contradiction": "前提为真时，假设一定为假"}


def banking77():
    ds = load_dataset("mteb/banking77", split="train")
    intents = sorted(set(ds["label_text"]))
    for row in ds:
        # 77 intents do not fit 26 letters: show the gold intent among 9 random distractors
        shown = random.sample([i for i in intents if i != row["label_text"]], 9) + [row["label_text"]]
        random.shuffle(shown)
        yield {"task": "banking77", "state": row["text"],
               "question": {"type": "choice",
                            "instructions": "Which banking intent does the customer's message express?",
                            "criteria": {i: i.replace("_", " ") for i in shown}},
               "answer": row["label_text"]}


def boolq():
    for row in load_dataset("google/boolq", split="train"):
        yield {"task": "boolq", "state": row["passage"],
               "question": {"type": "noul", "instructions": row["question"].capitalize() + "?",
                            "criteria": {"true": "yes, according to the passage",
                                         "false": "no, according to the passage"}},
               "answer": row["answer"]}


def sst5():
    for row in load_dataset("SetFit/sst5", split="train"):
        yield {"task": "sst5", "state": row["text"],
               "question": {"type": "score", "instructions": "How positive is this movie review?",
                            "criteria": SST5_LEVELS},
               "answer": row["label"]}


def ocnli():
    ds = load_dataset("clue/clue", "ocnli", split="train")
    names = ds.features["label"].names
    for row in ds:
        if row["label"] >= 0:  # -1 marks unlabeled rows
            yield {"task": "ocnli", "state": {"前提": row["sentence1"], "假设": row["sentence2"]},
                   "question": {"type": "choice", "instructions": "假设和前提是什么关系？", "criteria": OCNLI},
                   "answer": names[row["label"]]}


def key(record):
    text = json.dumps([record["state"], record["question"]["instructions"]], ensure_ascii=False)
    return hashlib.sha1(" ".join(text.lower().split()).encode()).hexdigest()


def write(path, rows):
    with open(path, "w", encoding="utf-8") as f:
        f.writelines(json.dumps(r, ensure_ascii=False) + "\n" for r in rows)


def main():
    held_out_tasks = {"banking77"}  # whole tasks never trained on (choice is still covered by ocnli)
    banned = {key(json.loads(line)) for p in Path("eval").glob("*.jsonl")
              for line in open(p, encoding="utf-8")}  # JevBench public files, your lockbox, ...
    seen, train, dev, held_out = set(), [], [], []
    for source in (banking77, boolq, sst5, ocnli):
        rows = list(source())
        random.shuffle(rows)
        for r in rows[:20000]:  # cap every task so no single dataset dominates the mix
            k = key(r)
            if k in seen or k in banned:
                continue
            seen.add(k)
            if r["task"] in held_out_tasks:
                held_out.append(r)
            elif random.random() < 0.05:
                dev.append(r)
            else:
                train.append(r)
    random.shuffle(train)
    Path("data").mkdir(exist_ok=True)
    write("data/train.jsonl", train)
    write("data/dev.jsonl", dev)
    write("data/heldout_tasks.jsonl", held_out)
    print(f"train {len(train)}  dev {len(dev)}  held-out tasks {len(held_out)}")


if __name__ == "__main__":
    main()

把 JevBench 的公开题文件和自己的封存集放进 eval/ 目录后运行，就会得到 data/ 下的三个文件。我实际运行的结果是：训练集 36,044 条，开发集 1,917 条，留出任务（Banking77）9,993 条。这只是一个演示，真正的项目需要几十到几百个任务，但流程完全一样：每加一个数据源，就是再写一个这样的转换函数。

三、GPU 资源：到底需要多少卡

1. 显存怎么估

训练时的显存主要由三部分组成：模型权重、梯度和优化器状态、激活值。前两部分可以按“每个参数占多少字节”来估：

按这个规则，不含激活值的显存大约是：

激活值和 batch 大小、序列长度成正比。开启梯度检查点后，主要剩下每一层边界的隐状态：以 Qwen3.5-4B（32 层，隐藏维度 2560）为例，一条 4K token 的样本约 32 × 4096 × 2560 × 2 字节 ≈ 0.7 GB，batch 为 4 时约 3 GB，再加上单层重算的峰值和 CUDA 自身的开销。所以 4B 模型做 LoRA，单张 24 GB 的卡通常就能跑（序列在 4K 以内、batch 不大的情况下），80 GB 的卡则可以放开 batch 和序列长度。

这里有一个决策模型特有的大坑：语言模型头的 logits。Qwen3.5 的词表有 248,320 个 token，如果像普通 SFT 那样对每个位置都算 logits，一条 4K token 的样本光 fp32 的 logits 就要 4096 × 248320 × 4 字节 ≈ 4 GB，反向传播时还要再来一份。而决策模型只需要最后一个位置的 logits，前向时传入 logits_to_keep=1，这部分就只剩 1 MB 左右。后面的训练脚本就是这么做的。

2. 时间怎么估

训练的计算量可以用一个经验公式估算：每个训练 token 约 6 × 参数量 次浮点运算（LoRA 加梯度检查点：前向 2N、重算 2N、反向 2N；全参微调加梯度检查点约为 8N）。举个例子，用 Qwen3.5-4B 做 LoRA，20 万道题、平均每题 600 token、训练 2 个 epoch：

训练 token 数  ≈ 200,000 × 600 × 2 = 2.4e8
训练计算量    ≈ 6 × 4e9 × 2.4e8 ≈ 5.8e18 FLOPs
H100 实际吞吐 ≈ 989 TFLOPS（bf16 稠密峰值）× 35% 利用率 ≈ 350 TFLOPS
训练时间      ≈ 5.8e18 / 3.5e14 ≈ 16,500 秒 ≈ 4.6 小时

同样的任务在 A100 上大约要 3 倍时间。实际利用率和序列长度、padding 比例、算子实现都有关系，要以自己的 profiler 数据为准。Qwen3.5 是“Gated DeltaNet 线性注意力 + 门控全注意力”的混合架构，训练前一定要装上 flash-linear-attention 和 causal-conv1d，否则会退回到纯 PyTorch 实现，慢很多（加载模型时会打印提示）。

3. 推荐配置

成本方面，按 H100 按需价格每小时 2～3 美元估算（JevBench 的 GPU 成本计算器默认按 H100 PCIe 每小时 2.89 美元），一次 4B 的 LoRA 训练大约 15 美元。真正花钱的是迭代：一个项目通常要跑几十轮“改数据、重训、评测”，GPU 总花费在几百美元量级。算力不是最贵的，数据和评测才是。

部署的成本更低：H2O-Lightning-4B 的 bf16 权重约 9.1 GB，在一张 32 GB 的 RTX PRO 4500 上用 vLLM 服务，标准题单次判断的 p50 约 30 ms；按 JevBench 计算器的估算，在 RTX 5090 上自托管，每千次决策约 0.008 美元，大约是 Jev 在 JevBench 上实测成本（每千次 0.032 美元）的四分之一。

四、基础模型怎么选

1. 选择标准

1. 零样本底子：优先选指令版（经过对齐的对话模型），它们本来就会做选择题，起点高；Base 版需要更多数据才能追上。JevBench 专门放了几个“底座对照组”（不做任何决策微调，直接读 logits），能直接看出不同底座的起点。
2. 语言：中文场景优先考虑 Qwen；注意 H2O-Lightning-4B 的训练数据 99% 以上是英文，直接拿来处理中文要先自测。
3. 尺寸与延迟：决策模型的定位是几十毫秒级的快速判断，4B 左右是目前延迟、成本和能力的甜点。
4. 上下文长度：JevBench 里有 23 道 7.7 万～8.1 万 token 的超长题，Jev 和不少模型因为超出上下文而拒答，按答错计分。Qwen3.5 原生支持 262K，但序列越长，训练的显存和时间成本上涨得越快。
5. 许可证：Qwen3.5 全系列、Gemma 4、ModernBERT 都是 Apache 2.0，mmBERT 是 MIT，商用比较省心。
6. 生态：训练要有 Transformers 和 PEFT 支持，部署要有 vLLM、SGLang、llama.cpp 支持；另外，选项字母必须各自是一个独立的 token（训练脚本里有断言检查）。

2. 候选清单

3. 我的建议

• 起步用 Qwen3.5-4B（指令版）+ LoRA：中文能力好，社区已经证明它能做到接近 Jev 的水平，单卡就能训练和部署；
• 先在 0.8B / 2B 上把流程跑通：数据格式、评测脚本、阈值策略都在小模型上验证完，再换大底座，可以省掉大量试错成本；
• 想冲击更高的能力分，再上 9B 到 31B：收益是真实的（Quyet-1.0-Large 的智能分比 H2O-Lightning-4B 高 13 分以上），但训练和推理成本也会成倍增加；
• 使用 Qwen3.5 时关闭思考模式：它默认会先输出思考过程，构造提示词时要传 enable_thinking=False，让助手回复的第一个 token 就是答案字母。

五、训练脚本：一步步写出来

这一节给出一套完整、可以直接运行的代码。它刻意保持精简，没有依赖任何专门的训练框架，方便读懂每一步在做什么。

1. 准备环境

pip install torch transformers peft accelerate datasets fastapi uvicorn
# GPU 机器上再装 Qwen3.5 线性注意力层的加速算子
pip install flash-linear-attention causal-conv1d

项目结构如下：

my-jev/
├── prepare_data.py      # 数据准备（上一节）
├── decision_format.py   # 提示词渲染与一次前向打分，训练、评测、服务共用
├── train.py             # LoRA 训练
├── evaluate.py          # 打分测试与温度拟合
├── serve.py             # /v1/systemone 服务
├── eval/                # JevBench 公开题、自己的封存集
└── data/                # prepare_data.py 的输出

2. 共用模块：把一道题变成一次前向

训练、评测和线上服务必须用完全相同的提示词格式，否则训练出来的概率到了线上就不再准确。所以先把这部分抽成一个共用模块：

# decision_format.py
"""Shared by training, evaluation and serving: render a decision as a prompt and read option probabilities."""
import json
import string

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

LETTERS = string.ascii_uppercase  # up to 26 options per question
SYSTEM = ("You are a decision model. Read the state and the question, "
          "then answer with the letter of exactly one option.")


def load(base, dtype=torch.bfloat16):
    tok = AutoTokenizer.from_pretrained(base)
    tok.padding_side = "left"  # every row then ends at its answer slot
    model = AutoModelForCausalLM.from_pretrained(base, dtype=dtype)  # Qwen3.5 loads text-only here
    ids = [tok.encode(c, add_special_tokens=False) for c in LETTERS]
    assert all(len(i) == 1 for i in ids), "every option letter must be a single token"
    return tok, model, torch.tensor([i[0] for i in ids])


def options(question):
    """[(key, description)] in the caller's order; noul is shown as yes / no."""
    kind, crit = question["type"], question.get("criteria")
    if kind == "noul":
        crit = crit or {}
        return [("yes", crit.get("true", "")), ("no", crit.get("false", ""))]
    if kind == "score":
        return [(str(i), desc) for i, desc in enumerate(crit)]
    return list(crit.items()) if isinstance(crit, dict) else [(c, "") for c in crit]


def target(record, opts):
    """Target distribution over opts: a soft label if the record has one, else one-hot."""
    keys = [k for k, _ in opts]
    if "target" in record:  # e.g. {"billing": 0.7, "technical": 0.3}
        dist = [float(record["target"].get(k, 0.0)) for k in keys]
    else:
        ans = record.get("answer", record.get("expected"))
        if record["question"]["type"] == "noul":
            ans = "yes" if ans in (True, "yes", "true") else "no"
        dist = [1.0 if k == str(ans) else 0.0 for k in keys]
    if sum(dist) <= 0:
        raise ValueError(f"answer is not one of the options: {record.get('id', record['question'])}")
    return [d / sum(dist) for d in dist]


def prompt(tok, record, order, max_state_tokens=6000):
    """Chat prompt whose next token is the answer letter; slot s shows option order[s]."""
    q, opts, state = record["question"], options(record["question"]), record["state"]
    if not isinstance(state, str):
        state = json.dumps(state, ensure_ascii=False, indent=1)
    ids = tok.encode(state, add_special_tokens=False)
    if len(ids) > max_state_tokens:  # cut the state, never the options or the answer slot
        state = tok.decode(ids[:max_state_tokens]) + "\n[truncated]"
    lines = [f"{LETTERS[s]}. {opts[i][0]}" + (f": {opts[i][1]}" if opts[i][1] else "")
             for s, i in enumerate(order)]
    user = (f"<state>\n{state}\n</state>\n\nQuestion ({q['type']}): {q['instructions']}\n"
            "Options:\n" + "\n".join(lines) + "\n\nAnswer with the letter of one option.")
    messages = [{"role": "system", "content": SYSTEM}, {"role": "user", "content": user}]
    return tok.apply_chat_template(messages, tokenize=False, add_generation_prompt=True,
                                   enable_thinking=False)


def option_logits(model, tok, letter_ids, prompts, ks, device):
    """One forward pass for a batch: logits of the shown option letters at the answer slot."""
    enc = tok(prompts, return_tensors="pt", padding=True, add_special_tokens=False).to(device)
    out = model(input_ids=enc.input_ids, attention_mask=enc.attention_mask, logits_to_keep=1)
    z = out.logits[:, -1, letter_ids[: max(ks)].to(device)].float()
    mask = torch.arange(z.shape[1], device=device)[None, :] < torch.tensor(ks, device=device)[:, None]
    return z.masked_fill(~mask, -1e4), mask

几个关键点：

• 左侧 padding：一个 batch 里的提示词长短不一，左侧补齐之后，每一行的最后一个位置都是答案位，配合 logits_to_keep=1，语言模型头只需要算一个位置。Qwen3.5 有线性注意力层，我专门验证过：同一道题单独计算和放进左侧补齐的 batch 里计算，logits 的最大差异只有 6×10⁻⁵；
• 只加载文本部分：Qwen3.5 是原生多模态模型，但用 AutoModelForCausalLM 加载时得到的是纯文本的 Qwen3_5ForCausalLM，不会带上视觉编码器，省显存，LoRA 也不会挂到视觉层上；
• 只在 K 个字母上做 softmax：取出 A、B、C……对应的 logits，多余的槽位填一个很小的值，模型的输出永远落在合法选项里；
• state 过长时只截断 state：问题、选项和答案位必须完整保留；
• noul 统一渲染成“yes / no”两个选项，返回的 P(yes) 就是 noul 的答案；score 的各个等级按顺序排列，便于计算 RPS；
• 断言每个字母都是单独的 token：换其他底座时，这一行能第一时间发现问题。在 Qwen3.5 的分词器上，A 到 Z 都是单个 token，而且在答案位后面追加一个字母，恰好多出一个 token。

3. 训练主脚本

# train.py
"""LoRA fine-tuning of a decision model with strictly proper scoring rules, or Laya-style RLCD."""
import argparse
import json
import math
import random

import torch
from accelerate import Accelerator
from peft import LoraConfig, get_peft_model
from torch.utils.data import DataLoader
from transformers import get_cosine_schedule_with_warmup

from decision_format import load, option_logits, options, prompt, target


def reward(z, mask, y, ordinal):
    """Laya's composite of strictly proper scores: log + 0.5 * spherical - RPS (RPS for score only)."""
    logq = z.log_softmax(-1)
    q = logq.exp()
    s_log = (y * logq).sum(-1)                      # log score = minus cross-entropy
    s_sph = (y * q).sum(-1) / q.norm(dim=-1)        # spherical score, bounded in [0, 1]
    k = mask.sum(-1).clamp(min=2)
    rps = ((q.cumsum(-1) - y.cumsum(-1)) ** 2).sum(-1) / (k - 1)  # ranked probability score
    return s_log + 0.5 * s_sph - ordinal * rps


def rlcd_loss(z, mask, y, ordinal, sigma, group=8):
    """Policy gradient over Gaussian-perturbed logits with a group-mean baseline, as Laya describes RLCD."""
    m = mask.float()
    eps = torch.randn(group, *z.shape, device=z.device) * m
    eps = (eps - eps.sum(-1, keepdim=True) / m.sum(-1, keepdim=True)) * m  # softmax ignores a common shift
    sample = z.detach() + eps
    with torch.no_grad():
        r = reward(sample, mask, y, ordinal)            # [group, batch]
        adv = (r - r.mean(0)) / (r.std(0) + 1e-6)
    logp = -(((sample - z) ** 2) * m).sum(-1) / (2 * sigma**2)  # Gaussian log-density up to a constant
    return -(adv * logp).mean()


class Collate:
    def __init__(self, tok, max_state_tokens):
        self.tok, self.max_state_tokens = tok, max_state_tokens

    def __call__(self, records):
        prompts, ks, ys, ordinal = [], [], [], []
        for r in records:
            opts = options(r["question"])
            order = list(range(len(opts)))
            if r["question"]["type"] != "score":  # score levels keep their order, RPS relies on it
                random.shuffle(order)
            y = target(r, opts)
            prompts.append(prompt(self.tok, r, order, self.max_state_tokens))
            ys.append([y[i] for i in order])
            ks.append(len(opts))
            ordinal.append(float(r["question"]["type"] == "score"))
        y = torch.zeros(len(records), max(ks))
        for row, t in enumerate(ys):
            y[row, : len(t)] = torch.tensor(t)
        return {"prompts": prompts, "ks": ks, "y": y, "ordinal": torch.tensor(ordinal)}


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--base", default="Qwen/Qwen3.5-4B")
    ap.add_argument("--train", default="data/train.jsonl")
    ap.add_argument("--out", default="out/my-jev")
    ap.add_argument("--objective", choices=["proper", "rlcd"], default="proper")
    ap.add_argument("--epochs", type=int, default=2)
    ap.add_argument("--lr", type=float, default=1e-4)
    ap.add_argument("--batch-size", type=int, default=4)
    ap.add_argument("--grad-accum", type=int, default=8)
    ap.add_argument("--lora-r", type=int, default=32)
    ap.add_argument("--max-state-tokens", type=int, default=3000)
    ap.add_argument("--mixed-precision", default="bf16")
    args = ap.parse_args()

    acc = Accelerator(mixed_precision=args.mixed_precision, gradient_accumulation_steps=args.grad_accum)
    tok, model, letter_ids = load(args.base)
    model.gradient_checkpointing_enable(gradient_checkpointing_kwargs={"use_reentrant": False})
    model = get_peft_model(model, LoraConfig(
        r=args.lora_r, lora_alpha=2 * args.lora_r, lora_dropout=0.05, target_modules="all-linear"))
    if acc.is_main_process:
        model.print_trainable_parameters()

    records = [json.loads(line) for line in open(args.train, encoding="utf-8")]
    loader = DataLoader(records, batch_size=args.batch_size, shuffle=True,
                        collate_fn=Collate(tok, args.max_state_tokens))
    opt = torch.optim.AdamW([p for p in model.parameters() if p.requires_grad], lr=args.lr, weight_decay=0.0)
    total = args.epochs * math.ceil(len(loader) / args.grad_accum)
    sched = get_cosine_schedule_with_warmup(opt, max(1, int(0.03 * total)), total)
    model, opt, loader, sched = acc.prepare(model, opt, loader, sched)

    step, n_batches = 0, args.epochs * len(loader)
    for epoch in range(args.epochs):
        model.train()
        for batch in loader:
            with acc.accumulate(model):
                z, mask = option_logits(model, tok, letter_ids, batch["prompts"], batch["ks"], acc.device)
                if args.objective == "rlcd":
                    sigma = 1.0 - 0.7 * step / n_batches  # exploration decays from 1.0 to 0.3
                    loss = rlcd_loss(z, mask, batch["y"], batch["ordinal"], sigma)
                else:
                    loss = -reward(z, mask, batch["y"], batch["ordinal"]).mean()
                acc.backward(loss)
                if acc.sync_gradients:
                    acc.clip_grad_norm_(model.parameters(), 1.0)
                opt.step()
                sched.step()
                opt.zero_grad()
            step += 1
            if step % 20 == 0:
                acc.print(f"epoch {epoch + 1} step {step}/{n_batches} loss {loss.item():.4f}")
        acc.wait_for_everyone()
        if acc.is_main_process:
            acc.unwrap_model(model).save_pretrained(f"{args.out}/epoch{epoch + 1}")
    acc.end_training()


if __name__ == "__main__":
    main()

这段代码做了这几件事：

1. 训练目标：reward() 就是前面介绍的 Laya 组合评分（对数评分 + 0.5 × 球面评分 − RPS），默认的 --objective proper 直接把它的相反数当损失；--objective rlcd 则按 Laya 的方式，用 8 组高斯扰动和组内基线做策略梯度，探索噪声从 1.0 衰减到 0.3。因为加了球面评分，choice 和 noul 题的损失下限是 −0.5（完全确定且答对），日志里出现负数是正常的；RLCD 的损失则是策略梯度的代理目标，数值本身没有意义，两种目标都要以评测指标为准；
2. 选项乱序：Collate 每次取 batch 都重新打乱 choice 和 noul 的选项顺序，标签跟着一起换位，这是对抗位置偏差最简单有效的办法；score 题保持等级顺序；
3. LoRA：target_modules="all-linear" 会覆盖注意力、Gated DeltaNet 和 MLP 中的所有线性层。在 Qwen3.5-0.8B 上，r=8 时可训练参数约 541 万，只占 0.71%；
4. 省显存：开启梯度检查点，只计算答案位的 logits；
5. 单卡、多卡同一份代码：Accelerate 负责设备、混合精度和梯度累积，多卡时自动切换成数据并行。

4. 启动训练

# 单卡：有效 batch = 4 × 8 = 32 道题
python train.py --base Qwen/Qwen3.5-4B --train data/train.jsonl --out out/my-jev

# 8 卡数据并行：有效 batch = 4 × 2 × 8 = 64 道题
accelerate launch --num_processes 8 train.py --base Qwen/Qwen3.5-4B \
  --train data/train.jsonl --out out/my-jev --grad-accum 2

# 对比实验：换成 Laya 式的 RLCD
python train.py --base Qwen/Qwen3.5-4B --train data/train.jsonl --out out/my-jev-rlcd --objective rlcd

每个 epoch 结束会保存一份 LoRA 适配器（out/my-jev/epoch1、epoch2……），挑哪一份由下一节的评测决定。超参数可以从这里起步：

我在 Qwen3.5-0.8B 上用 CPU 跑过这份脚本的冒烟测试（几十道题、两种训练目标各跑一遍），确认能正常训练和保存。真正的训练请在 GPU 上进行。

六、打分测试：怎么知道模型好不好

1. 看哪些指标

只看准确率是远远不够的。一个合格的决策模型评测，至少要包含下面这些指标：

位置偏差绝不是小问题。学术界早有研究表明，大模型做选择题时会偏好特定的选项位置和选项字母（Zheng 等人，2023）。JevBench 也记录过一个例子：open-alternative-jev 在“判断回答是否合格”这类题上，按作者给的选项顺序（A. yes, B. no）准确率是 72%，把两个选项倒过来就只剩 21%。除了脚本里的倒序翻转率，上线前最好再补几项一致性检查：同一问题换种问法答案是否一致、问题和它的否定形式概率之和是否接近 1、state 里插入注入文本后答案是否被带偏。

2. 评测脚本

# evaluate.py
"""Evaluate a decision model: accuracy, chance-corrected accuracy, calibration, order robustness, latency."""
import argparse
import json
import statistics
import time

import torch
from peft import PeftModel

from decision_format import load, option_logits, options, prompt, target


@torch.no_grad()
def predict(model, tok, letter_ids, records, batch_size=8, reverse=False):
    """Logits over each record's options, in the caller's order."""
    result = []
    for i in range(0, len(records), batch_size):
        chunk, orders = records[i : i + batch_size], []
        for r in chunk:
            order = list(range(len(options(r["question"]))))
            if reverse and r["question"]["type"] != "score":
                order.reverse()
            orders.append(order)
        prompts = [prompt(tok, r, o) for r, o in zip(chunk, orders)]
        z, _ = option_logits(model, tok, letter_ids, prompts, [len(o) for o in orders], model.device)
        for row, order in enumerate(orders):
            logits = torch.empty(len(order))
            logits[order] = z[row, : len(order)].cpu()  # slot s showed option order[s]
            result.append(logits)
    return result


def ece(conf, correct, bins=10):
    groups = {}
    for c, ok in zip(conf, correct):
        groups.setdefault(min(int(c * bins), bins - 1), []).append((c, ok))
    return sum(len(g) / len(conf) * abs(statistics.mean(o for _, o in g) - statistics.mean(c for c, _ in g))
               for g in groups.values())


def summary(rows):
    conf = [p.max().item() for _, p, _ in rows]
    correct = [float(p.argmax() == y.argmax()) for _, p, y in rows]
    acc = statistics.mean(correct)
    chance = statistics.mean(1 / len(p) for _, p, _ in rows)
    out = {"n": len(rows), "accuracy": acc, "chance_corrected": (acc - chance) / (1 - chance),
           "log_loss": statistics.mean(-(y * p.clamp_min(1e-12).log()).sum().item() for _, p, y in rows),
           "brier": statistics.mean(((p - y) ** 2).sum().item() for _, p, y in rows),
           "ece": ece(conf, correct)}
    ordinal = [(p, y) for kind, p, y in rows if kind == "score"]
    if ordinal:
        out["rps"] = statistics.mean((((p.cumsum(0) - y.cumsum(0)) ** 2).sum() / (len(p) - 1)).item()
                                     for p, y in ordinal)
    return out


def metrics(records, logits, temps):
    rows = []
    for r, z in zip(records, logits):
        kind = r["question"]["type"]
        p = (z / temps.get(kind, 1.0)).softmax(-1)
        rows.append((kind, p, torch.tensor(target(r, options(r["question"])))))
    report = {"all": summary(rows)}
    for kind in ("choice", "noul", "score"):
        if any(row[0] == kind for row in rows):
            report[kind] = summary([row for row in rows if row[0] == kind])
    return report


def fit_temperatures(records, logits):
    """One temperature per question type, chosen to minimise log loss (fit on dev data only)."""
    grid, temps = [round(0.3 + 0.05 * i, 2) for i in range(55)], {}
    for kind in ("choice", "noul", "score"):
        pairs = [(z, torch.tensor(target(r, options(r["question"]))))
                 for r, z in zip(records, logits) if r["question"]["type"] == kind]
        if pairs:
            temps[kind] = min(grid, key=lambda t: sum(-(y * (z / t).log_softmax(-1)).sum().item()
                                                      for z, y in pairs))
    return temps


@torch.no_grad()
def latency_ms(model, tok, letter_ids, records, n=50):
    times = []
    for r in records[:n]:
        k = len(options(r["question"]))
        text = prompt(tok, r, list(range(k)))
        if torch.cuda.is_available():
            torch.cuda.synchronize()
        start = time.perf_counter()
        option_logits(model, tok, letter_ids, [text], [k], model.device)
        if torch.cuda.is_available():
            torch.cuda.synchronize()
        times.append((time.perf_counter() - start) * 1000)
    times.sort()
    return {"p50": times[len(times) // 2], "p95": times[min(len(times) - 1, int(0.95 * len(times)))]}


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--base", default="Qwen/Qwen3.5-4B")
    ap.add_argument("--adapter", help="LoRA directory; omit it to score the raw base model")
    ap.add_argument("--data", nargs="+", required=True)
    ap.add_argument("--fit-temperature", help="fit temperatures on --data (dev only) and save them here")
    ap.add_argument("--temperatures", help="temperatures fitted earlier")
    ap.add_argument("--batch-size", type=int, default=8)
    args = ap.parse_args()

    tok, model, letter_ids = load(args.base)
    if args.adapter:
        model = PeftModel.from_pretrained(model, args.adapter).merge_and_unload()
    model.to("cuda" if torch.cuda.is_available() else "cpu").eval()
    records = [json.loads(line) for path in args.data for line in open(path, encoding="utf-8")]

    logits = predict(model, tok, letter_ids, records, args.batch_size)
    temps = json.load(open(args.temperatures)) if args.temperatures else {}
    if args.fit_temperature:
        temps = fit_temperatures(records, logits)
        json.dump(temps, open(args.fit_temperature, "w"), indent=2)
    flipped = predict(model, tok, letter_ids, records, args.batch_size, reverse=True)
    flips = [bool(a.argmax() != b.argmax())
             for r, a, b in zip(records, logits, flipped) if r["question"]["type"] != "score"]

    report = metrics(records, logits, temps)
    report["flip_rate_reversed_options"] = sum(flips) / max(1, len(flips))
    report["temperatures"] = temps
    report["latency_ms"] = latency_ms(model, tok, letter_ids, records)
    print(json.dumps(report, indent=2))


if __name__ == "__main__":
    main()

典型的用法分三步：

# 1) 零样本基线：不加适配器，直接读底座模型的字母概率，先知道起点
python evaluate.py --base Qwen/Qwen3.5-4B --data data/dev.jsonl data/heldout_tasks.jsonl

# 2) 在开发集上评测训练好的模型，并按题型拟合温度
python evaluate.py --base Qwen/Qwen3.5-4B --adapter out/my-jev/epoch2 \
  --data data/dev.jsonl --fit-temperature out/my-jev/temperatures.json

# 3) 带上温度，在留出任务和 JevBench 公开题上打分（温度只能在开发集上拟合）
python evaluate.py --base Qwen/Qwen3.5-4B --adapter out/my-jev/epoch2 \
  --temperatures out/my-jev/temperatures.json --data data/heldout_tasks.jsonl
python evaluate.py --base Qwen/Qwen3.5-4B --adapter out/my-jev/epoch2 \
  --temperatures out/my-jev/temperatures.json --data eval/easy.jsonl eval/original.jsonl eval/hard.jsonl

作为示例，下面是 Qwen3.5-0.8B 原始模型（不加适配器）在 JevBench 公开的 easy 和 original 两组、共 120 道题上的结果（节选，保留三位小数）。这是在我的 Mac 上用 CPU 跑的，延迟没有参考意义，就不列出来了：

{
  "all":    {"n": 120, "accuracy": 0.642, "chance_corrected": 0.488, "log_loss": 1.326, "brier": 0.523, "ece": 0.108},
  "choice": {"n": 72,  "accuracy": 0.694, "chance_corrected": 0.614, "ece": 0.117},
  "noul":   {"n": 36,  "accuracy": 0.583, "chance_corrected": 0.167, "ece": 0.220},
  "score":  {"n": 12,  "accuracy": 0.500, "chance_corrected": 0.333, "rps": 0.151},
  "flip_rate_reversed_options": 0.620
}

几个值得注意的地方：

• noul 题的准确率只有 58.3%，去掉随机猜中的部分只剩 16.7%，基本是在猜；
• 选项倒序翻转率高达 62%：只是把选项顺序倒过来，六成以上题目的答案就变了。我还单独试了一道题：state 是“结账页面对所有客户返回 HTTP 500”，问题是“是否有生产系统宕机”，选项按 yes、no 排列时 P(yes) 是 0.18，换成 no、yes 排列就变成了 0.45。小模型的位置偏差比想象中严重得多，这正是训练时要不断打乱选项、评测时一定要报告这个指标的原因；
• 作为对照，H2O-Lightning-4B 在同样这 120 道题上答对了 119 道。两者规模不同，差距不能全部归功于微调，但足以说明决策微调要补的课有多少。

3. 和 JevBench 上的模型同场比较

JevBench 的 GitHub 仓库公开了 231 道题（datasets/public/ 下的 easy 48 道、original 72 道、hard 111 道），格式和本文的数据格式一致，evaluate.py 可以直接读取。作为参照，H2O-Lightning-4B 在这 231 道题上答对 205 道（88.7%）：easy 48/48，original 71/72，hard 86/111。

不过要注意三点：

1. 公开题只是参考：榜单分数基于每期 1500 道题（1200 道不公开的封存题加 300 道公开题，智能分里两部分各占一半），还做了去随机、分难度加权和公开 / 封存差距惩罚，公开题上的准确率不能直接换算成榜单分数；
2. 绝不能拿公开题训练：JevBench 要求在公开题上训练过的模型必须主动声明，prepare_data.py 里的去污染就是为此准备的；
3. 想上榜就提交：在 JevBench 网站提交模型后，会由维护者在他们自己的 GPU 上跑完整的封存题。

如果想完全按 JevBench 官方的方式测，可以先把模型包装成和 Jev 一样的 HTTP 接口，再用官方的评测工具去调用它。

4. 服务化：兼容 Jev 的 /v1/systemone

# serve.py
"""A minimal /v1/systemone server (Jev wire format) in front of the fine-tuned model."""
import json
import os

import torch
from fastapi import FastAPI, HTTPException
from peft import PeftModel

from decision_format import LETTERS, load, option_logits, options, prompt

BASE = os.environ.get("BASE_MODEL", "Qwen/Qwen3.5-4B")
ADAPTER = os.environ.get("ADAPTER", "out/my-jev/epoch2")
TEMPS = json.load(open(os.environ["TEMPERATURES"])) if os.environ.get("TEMPERATURES") else {}

tok, model, letter_ids = load(BASE)
model = PeftModel.from_pretrained(model, ADAPTER).merge_and_unload()
model.to("cuda" if torch.cuda.is_available() else "cpu").eval()
app = FastAPI()


@app.post("/v1/systemone")
@torch.no_grad()
def systemone(body: dict):
    questions = body.get("questions")
    if not isinstance(questions, dict) or not 0 < len(questions) <= 32:
        raise HTTPException(422, "questions must be an object with 1 to 32 entries")
    names, prompts, ks = list(questions), [], []
    for name in names:
        q = questions[name]
        try:
            k = len(options(q))
            ok = q["type"] in ("choice", "noul", "score") and isinstance(q["instructions"], str)
        except (KeyError, TypeError, AttributeError):
            ok = False
        if not ok or not 2 <= k <= len(LETTERS):
            raise HTTPException(422, f"{name}: malformed question or unsupported option count")
        prompts.append(prompt(tok, {"state": body.get("state", ""), "question": q}, list(range(k))))
        ks.append(k)

    z, _ = option_logits(model, tok, letter_ids, prompts, ks, model.device)
    answers = {}
    for row, name in enumerate(names):
        q, k = questions[name], ks[row]
        p = (z[row, :k] / TEMPS.get(q["type"], 1.0)).softmax(-1).tolist()
        if q["type"] == "noul":
            answers[name] = {"type": "noul", "noul": p[0]}  # P(yes)
        elif q["type"] == "score":
            answers[name] = {"type": "score", "score": sum(i * x for i, x in enumerate(p)),
                             "probabilities": {str(i): x for i, x in enumerate(p)}}
        else:
            probs = {key: x for (key, _), x in zip(options(q), p)}
            best = max(probs, key=probs.get)
            answers[name] = {"type": "choice", "choice": best, "probabilities": probs,
                             "confidence": (k * probs[best] - 1) / (k - 1)}
    used = sum(len(ids) for ids in tok(prompts, add_special_tokens=False).input_ids)
    return {"answers": answers, "usage": {"input_tokens": used, "output_tokens": 0}}

启动服务，然后用 curl 验证一下：

ADAPTER=out/my-jev/epoch2 TEMPERATURES=out/my-jev/temperatures.json \
  uvicorn serve:app --host 127.0.0.1 --port 8741

curl -s http://127.0.0.1:8741/v1/systemone -H 'Content-Type: application/json' -d '{
  "state": "Checkout returns HTTP 500 for every customer since 09:10.",
  "questions": {
    "team": {"type": "choice", "instructions": "Which team should handle this?",
             "criteria": {"billing": "charges and refunds", "engineering": "bugs and outages"}},
    "outage": {"type": "noul", "instructions": "Is a production system down?"}
  }
}'

返回结构沿用 Jev 的格式：每个答案都带 type，choice 返回 choice、probabilities 和按 Jev 公式 (K·p_max − 1)/(K − 1) 计算的 confidence，score 返回期望等级和以等级下标为键的概率，noul 直接返回 P(yes)，usage 里只有输入 token。这正是 JevBench 官方评测工具（typesafe 适配器）解析的字段，所以可以直接拿它来测，已有的 Jev 客户端通常也只需要改一下 baseUrl：

git clone https://github.com/fstandhartinger/jevbench && cd jevbench
python -m jevbench.cli run \
  --tasks datasets/public/easy.jsonl,datasets/public/original.jsonl,datasets/public/hard.jsonl \
  --adapter typesafe --endpoint http://127.0.0.1:8741 --key-env '' --model my-jev \
  --cost-basis self_hosted_gpu --reserve-usd 0 --delay-s 0 \
  --results RUN/results.jsonl --raw-dir RUN/raw --ledger RUN/ledger.jsonl --manifest RUN/manifest.json

# 汇总成绩
python -m jevbench.cli summarize \
  --tasks datasets/public/easy.jsonl,datasets/public/original.jsonl,datasets/public/hard.jsonl \
  --results RUN/results.jsonl --public-export RUN/summary.json

这个服务只是为了评测和演示：它一次处理一个请求，没有认证。正式上线时，推荐像 H2O-Lightning-4B 那样把合并后的模型交给 vLLM（连续批处理、前缀缓存），前面放一个很薄的协议转换层，并加上认证、限流和请求大小限制，不要直接暴露在公网上。

七、调整思路：分数不理想怎么办

1. 先有基线，再按切片找问题

动手调参之前，先确认两件事：一是零样本基线（不微调、直接读底座的字母概率）是多少，二是“永远猜最常见答案”能拿多少分。训练后的模型必须和这两个数字比，否则很容易被虚高的准确率骗到。

然后按切片拆开看：题型、任务、语言、选项数、state 长度、置信度区间。总分掩盖的问题，往往在切片里一目了然。H2O 把这叫作“找短板”（gap hunting）：按主题和题型和其他系统对比，跑对抗性题集，然后针对性地补充经过验证的新数据。

2. 症状与对策

3. 让迭代形成闭环

最后是几条流程上的建议，它们比任何一个超参数都重要：

1. 上线标准先写下来：比如“封存集上的去随机准确率不低于上一版，温度缩放后 ECE 不高于 0.05，选项倒序翻转率不高于 5%，p95 延迟不超过 100 ms”。先定标准再看结果，才能避免“看着结果改标准”。
2. 封存集只在发版时用一次：日常调参只看开发集和留出任务，封存集一旦被反复使用，它就变成了另一个开发集。
3. 每次只改一个变量：数据、超参数、底座同时改，就无法判断哪一个起了作用。
4. 固定版本，持续监控：底座或数据变化之后，温度和阈值都要重新标定；上线后持续记录概率分布并抽样复核，一旦分布漂移就回到飞轮的起点。

总结

把全文浓缩成几句话：

1. 路线：想要 Jev 那样的零样本通才，走“解码器 + 选项字母”，从 Qwen3.5-4B + LoRA 起步；只服务固定任务、追求极致速度，编码器路线依然划算。
2. 目标：用严格适当评分规则训练，再用温度缩放校准。RLCD 是其中一种实现方式，而不是魔法。
3. 数据：任务的多样性、标签的质量、严格的去污染和按任务切分，比模型结构重要得多。
4. 算力：4B 模型的一次 LoRA 训练，单张 H100 几个小时、十几美元，钱主要花在一轮又一轮的迭代上。
5. 评测：准确率之外还要看校准、位置偏差、阈值曲线和延迟；用 JevBench 公开题对标，用自己的封存集验收。

Jev 定义了“决策模型”这个品类，而短短一个月里，开源社区已经复刻出了上百个替代品，其中最好的一批在榜单上已经和 Jev 不相上下。训练一个自己的决策模型，已经从“能不能做到”变成了“值不值得做”。如果你有自己的数据、有合规要求，或者对延迟和成本格外敏感，答案多半是值得的。

参考资料

• JevBench：开源权重决策模型榜单
• JevBench：评测方法说明
• JevBench：评测工具与公开题集（GitHub）
• H2O-Lightning-4B 模型卡
• Laya GitHub 仓库
• Nandakishor M：I Built Non-Autoregressive Decision Models a Year Ago. Then a Frontier Lab Called It a “Breakthrough”.
• Qwen3.5-4B 模型卡
• Gneiting & Raftery：Strictly Proper Scoring Rules, Prediction, and Estimation（2007）
• Guo et al.：On Calibration of Modern Neural Networks（2017）
• Kadavath et al.：Language Models (Mostly) Know What They Know（2022）
• Zheng et al.：Large Language Models Are Not Robust Multiple Choice Selectors（2023）
• Wei et al.：Finetuned Language Models Are Zero-Shot Learners（2021）
• Hu et al.：LoRA: Low-Rank Adaptation of Large Language Models（2021）
• Jev vs Laya：闭源与开源 System One 决策模型的对比与选型
• Microsoft-Decision-1 详解：微软入局决策模型，与 Jev、Laya 的三方对比
• 玩转大语言模型：大语言模型（LLM）微调主流方式和使用场景全面解析对比
• PPO vs GRPO：两种主流 LLM 强化学习范式的对比与选择

引言

上个月我写了一篇 Jev vs Laya，对比了 TypeSafe AI 的闭源决策模型 Jev 和社区开源的 Laya。那时“决策模型”还是一个刚刚诞生的新品类：9 月 15 日 Jev 发布，三天后 Laya 开源。

仅仅三周之后，这个赛道就挤满了玩家：10 月 6 日，OpenAI 开放了基于 GPT-6 Luna 的 Decisions API；Liquid AI、Inception 等公司也陆续推出了自己的决策 API；第三方榜单 JevBench 上参与排名的开源权重系统已经超过 140 个。10 月 9 日，微软也正式入局，发布了 Microsoft-Decision-1。

和其他入局者相比，Microsoft-Decision-1 有几个特别值得关注的地方：

• 出自大厂，底座却是开源模型：它基于阿里开源的 Qwen3.5-9B 后训练而来，微软还表示后续会迁移到自家的 MAI 系列和 OpenAI 的模型上；
• 价格与 Jev 完全一致：输入每百万 token 0.042 美元，输出免费；
• 接口几乎与 Jev 兼容：同样是 state + questions，同样是 noul / choice / score 三种问题类型；
• 官方数据很亮眼：在 36 项基准、近 15 万道题的对比中平均准确率最高，中位延迟比 GPT-6 Sol 快约 35 倍。

但官方数据只是故事的一半。微软发布的第二天，第三方榜单 JevBench 就完成了独立实测，结论并不完全一致。本文将从以下几个方面展开：

1. Microsoft-Decision-1 是什么，又是怎么做出来的
2. 它与 Jev、Laya 的技术路线和接口有什么不同
3. 官方基准与第三方实测应该怎么看
4. Microsoft-Decision-1 的优势与劣势
5. 适用场景、选型建议与代码示例

一分钟回顾：什么是决策模型

决策模型（System One Model）不聊天，也不写文章，它只做一件事：接收一段状态（state）和一组预先定义好的问题（questions），直接返回带概率的类型化决策。三家都支持同样的三种问题原语：

由于答案空间被提前限定，模型不会返回格式错误或凭空编造的选项；校准过的概率则可以直接写进程序的 if 语句：高置信度自动执行，中置信度交给更强的模型复核，低置信度转人工。在一个 AI 系统里，比较合理的分工是：代码负责骨架，决策模型负责快速判断，大模型负责深度思考。

更详细的概念介绍和置信度分流的思路，可以参考上一篇，这里不再展开。

Microsoft-Decision-1 是什么

1. 基本信息

2026 年 10 月 9 日，微软首席技术官办公室（Office of the CTO）软件工程副总裁 Achint Srivastava 在微软的技术博客 Command Line 上发布了 Microsoft-Decision-1。文章开头是这样定义决策模型的：

Unlike LLMs, which are designed to generate text or reason through complex problems, decision models are purpose-built to deliver structured outputs that software can immediately act on.

与生成文本、推理复杂问题的大模型不同，决策模型专门用来输出软件可以立即据此行动的结构化结果。

微软给它的定位是一个“快速决策打分”（fast decision-scoring）模型，面向路由、分类、优先级排序、结果校验和工作流控制。主要信息如下：

按这个价格，如果每次判断平均消耗 1000 个输入 token，100 万次判断的费用约为 42 美元，和 Jev 完全相同。

2. 它是怎么做出来的

微软公开的技术细节不多，但有几个关键点：

• 在开源底座上后训练：微软在 Qwen3.5-9B 上做了后训练（post-training），让它学会“单次前向完成决策打分”（fast, single-pass decision scoring）。给定一组固定的候选答案，模型直接为每个选项输出一个校准过的概率，而不是逐 token 生成文字。
• 底座可以替换：微软明确表示，很快会把它迁移（rebase）到其他底座上，包括微软自研的 MAI 系列和 OpenAI 的模型。
• 没有公开的部分：训练数据、后训练方法和打分机制的具体实现都没有公开，权重也没有开放，只能以托管 API 的形式使用。

微软在博客里把打造一个可靠决策模型的难点归纳为五个方面，并给出了相应的自测结果：

3. 微软内部的四个试点

微软还公开了几个内部试用的案例（均为微软自测）：

其中 Xbox 的三个数据集，微软给出了更详细的对比数据：

按 100 万条文本折算，GPT-6 Sol 约需 2434 美元，Microsoft-Decision-1 约需 11 美元（微软注明成本为估算值）。两者读取的是同一份任务说明，输入 token 数相同，差距来自单价，以及 GPT-6 Sol 还需要为输出付费。

4. 适合哪些场景

微软在博客里列出了 16 个推荐场景，大致可以归为四类：

其中最值得关注的是 Agent 控制。今天的 Agent 每走一步都要做大量“小判断”：上一步成功了吗？要不要重试？这个工具调用会不会动到生产数据？如果这些判断都交给大模型，延迟和成本会随着步数线性累积。用一个百毫秒级的决策模型给 Agent 加一道“闸门”，是这类模型最有想象空间的用法。微软还演示了一个电脑操作（computer use）的例子：在完成“买一个背包”的任务时，由 Microsoft-Decision-1 选择下一步界面操作，完成速度明显快于 GPT-6 Sol。

另一个值得一提的场景是模型路由：根据请求的质量、成本和延迟要求，选择最合适的模型来处理。我之前写过一篇 让模型自己选模型：Embedding 驱动的 LLM 智能路由机制，决策模型提供了另一种思路：不再依赖向量相似度，而是直接把“该交给哪个模型”当成一道 choice 题来回答。

三条技术路线

把三个模型放在一起，会发现它们代表了三条截然不同的技术路线：

有几点值得展开说说：

1. 规模相差一个数量级以上。Laya 用 4 亿参数的编码器换取极致的速度和本地部署能力；Microsoft-Decision-1 用 90 亿参数的解码器换取更强的零样本泛化能力，代价是对算力的要求高得多，而且目前只能以云端托管的方式使用。
2. 底座正在变成可替换的零件。从 JevBench 榜单看，排名靠前的开源决策模型大多也是在 Qwen 或 Gemma 上后训练出来的，比如基于 Qwen3.5-4B 的 H2O-Lightning-4B、基于 Gemma-4-31B 的 Quyet-1.0-Large。微软直接选用阿里的开源模型做底座，又公开表示后续会换成 MAI 或 OpenAI 的模型，说明这类模型的竞争力主要来自后训练数据、评测体系和校准方法，而不是底座本身。
3. “单次前向”已经是共识。无论是 Laya 的编码器还是 Microsoft-Decision-1 的解码器，核心思路都一样：不生成文本，一次前向计算就给出所有候选项的概率。这也是决策模型能比通用大模型快一到两个数量级的根本原因。

同一套接口，三种后端

对开发者来说，一个非常实用的变化是：三者的请求格式几乎一致。

• Jev 的官方 API 是 POST https://api.typesafe.ai/v1/systemone；
• Microsoft-Decision-1 的端点是 Foundry 资源下的 /providers/microsoft/v1/systemone，微软文档也直接说明，它的请求模式与 System One API 类似；
• Laya 也提供了 laya-serve，在本地以同样的 POST /v1/systemone 协议对外服务，返回结构与 Jev 一致，已有的 Jev 客户端只需要修改 baseUrl。

三者在细节上的差异如下：

这意味着 state + questions 风格的接口正在成为决策模型的事实标准，就像当年 OpenAI 的 Chat Completions 接口之于大模型。微软把价格定得和 Jev 一模一样、接口也几乎一致，很难不让人认为这是在刻意降低 Jev 用户的迁移门槛。对用户来说，切换成本越来越低；对厂商来说，护城河只能来自效果、延迟、单次成本、合规能力和生态。

核心差异一览

基准数据怎么看

1. 微软公布的对比数据

微软把 Microsoft-Decision-1 和 JevBench 榜单上的几个头部模型、Jev 以及 GPT-6 Sol 放在一起，在 36 个公开和私有基准、共 147,137 道题上做了对比（准确率和校准分越高越好，延迟越低越好）：

注：Microsoft-Decision-1 的延迟是在 Foundry 同区域测得的，其余模型的延迟引用自 JevBench v1.6.1 的调整后中位延迟（10 月 7 日数据）。另外，AWS 的 Strands-Decider 2B 只能回答 36 个基准中的 23 个，平均准确率为 54.8%，未列入上表。微软的文章在发布后还专门更新了一次，补充了 Jev 的准确率和校准数据。

按这组数据，Microsoft-Decision-1 的平均准确率第一，速度最快：比第二快的 H2O-Lightning-4B v1.1 快 2.5 倍，比 Jev 快约 2.8 倍，比 GPT-6 Sol 快约 35 倍；校准分排第三。

需要注意的是，微软说的是 36 项基准的平均准确率最高，而不是每一项都排第一，一些报道中“36 项基准全部第一”的说法并不准确。

2. 第三方 JevBench 的实测

JevBench 是一个独立于 TypeSafe 的社区榜单（个人维护的开源项目 Benchmark Heaven），用 1500 道决策题（1200 道封存题加 300 道公开题），从智能（Intelligence）、校准（Calibration）、速度和成本四个维度评测决策模型。Microsoft-Decision-1 发布的第二天（10 月 10 日），JevBench 就通过 Azure Foundry 的原生接口完成了完整测试。下面是 API 榜单上的部分结果：

把 Jev 和 Microsoft-Decision-1 单独拿出来比较：

JevBench 的智能分是扣除随机猜测之后的得分（0 表示和随机猜测相当，100 表示全部答对），能力分是智能分和校准分的平均值，综合分则把智能、校准、速度和成本四个维度放在一起计算。它们和微软表格里的“平均准确率”不是同一个指标，不能直接换算。

3. 解读数据时必须注意的五点

第一，自测与第三方的结论并不一致。 在微软的 36 项基准上，Microsoft-Decision-1 的平均准确率比 Jev 高 1.2 个百分点；但在 JevBench 上，Jev 的智能分（63.6 对 57.2）和能力分（77.1 对 70.8）都明显领先。两边的题目、评分方法和统计口径完全不同，谁也不能代表“绝对真相”。比较稳妥的理解是：Microsoft-Decision-1 已经进入第一梯队，但还谈不上全面超越 Jev。这也再次说明，最可靠的基准永远是你自己的数据。

第二，校准仍是 Jev 的强项。 即使在微软自己的数据里，Microsoft-Decision-1 的校准分（92.2）也落后于 Jev（93.7）和 Quyet-1.0-Large（93.1）；在 JevBench 上差距更大（84.4 对 90.6）。对于依赖置信度阈值做分流的系统来说，校准质量往往比准确率高出一两个点更重要。

第三，延迟主要取决于部署位置。 微软的 85 ms 是在 Foundry 同区域测得的，而表中其他模型的延迟来自 JevBench 自己的测试环境。JevBench 原生调用 Microsoft-Decision-1 测得的中位延迟是 459 ms，在同一个榜单上，Jev 是 240 ms。两组数字都没有错，只是测量条件不同。决策模型的计算本身只需要几十毫秒，真正决定体验的是网络距离：把 Foundry 资源建在离应用最近的区域，对数据驻留有要求时选择 DataZoneStandard，并且一定要用真实流量实测。

第四，同样的单价，不同的单次成本。 两者的标价都是每百万输入 token 0.042 美元，但 JevBench 在同一批题目上实测的每千次决策成本，Microsoft-Decision-1 约为 0.019 美元，Jev 约为 0.032 美元，前者便宜约 40%。差异来自两者对同样的输入计出的 token 数不同。调用量很大时，这个差距值得算进总成本。

第五，Laya 不在同一条赛道上。 微软的对比中没有 Laya。JevBench 对 Laya 的三个检查点做了零样本测试，智能分只有 0.3～5.5，几乎等同于随机猜测。这和 Laya 作者自己的定位是一致的：它是一个需要在自有数据上微调的快速底座，而不是零样本决策引擎。再加上默认只有 512 / 1024 token 的上下文，Laya 在 JevBench 这种包含长文本、覆盖开放领域的考卷上吃亏是必然的。它的价值在于本地部署，以及特化之后的速度和成本，这一点在上一篇中已经详细讨论过。

此外，JevBench 中有 23 道约 7.7 万～8.1 万 token 的超长题。Microsoft-Decision-1 有 21 道因为超出上下文限制而失败，Jev 也拒绝了这 23 道超出其输入范围的题目，它们都按答错计分。

4. 小结

比较公允的结论是：Microsoft-Decision-1 进入了决策模型的第一梯队，优势在于同区域延迟、单次成本和微软生态；Jev 在校准和长上下文上仍然领先；Laya 则是另一条赛道上的选手，适合有数据、需要本地化的团队。

Microsoft-Decision-1 的优势与劣势

优势

1. 企业级集成：作为 Azure 直接销售的 Foundry 模型，它通过 Azure 订阅计费，受 Azure SLA 保障并由微软提供支持；支持 Entra ID 认证和 RBAC 权限控制，可以和现有的 Azure 网络、监控、合规体系一起管理。对已经在用 Azure 的企业来说，几乎不需要引入新的供应商。
2. 同区域延迟低：微软在同区域测得的 p50 约为 85 ms、p95 约为 125 ms，加上决策只需要一次前向计算，适合放进 Agent 的多步循环里。
3. 零样本能力进入第一梯队：不需要任何训练数据就能使用；在微软的 36 项基准上平均准确率最高，在 JevBench 的 27 个 API 产品中综合排名第 6。
4. 鲁棒性好：对同一请求做 8 种等价扰动，平均翻转率只有 1.3%，选项改写或重排时不翻转。在提示词和选项不断演进的生产环境中，这一点很重要。
5. 单次成本更低：标价与 Jev 相同，按 JevBench 的实测，每千次决策的成本还要低约 40%。
6. 接口兼容，迁移成本低：请求格式与 Jev 的 System One 风格接口几乎一致，已有的问题设计和分流逻辑可以直接复用（阈值需要重新标定）。
7. 有具体的落地参考：Xbox、Copilot、事故响应、Microsoft Discovery 等内部试点给出了可以借鉴的用法，虽然这些同样是自测数据。

劣势

1. 以自测数据为主，第三方结果不如官方亮眼：在 JevBench 上，它的智能分和校准分都低于 Jev，在 API 榜单上综合排名第 6。
2. 校准不是最强：无论官方数据还是第三方数据，它的校准都落后于 Jev，上线前一定要用自己的数据标定阈值。
3. 上下文只有 32K：比 Jev 的 64K 短，长邮件串、长合同或 Agent 的长执行轨迹需要先截断、摘要或分块。
4. 权重不开放，也不能微调：虽然底座是开源的 Qwen3.5-9B，但模型本身只能以托管 API 的形式使用，无法本地或离线部署；目前文档只介绍了通过 state、instructions 和选项来调优，没有提供基于自有数据的微调。
5. 版本和底座都可能变化：目前只有版本 1，而微软已经表示会把它迁移到 MAI 或 OpenAI 的底座上。底座一换，概率分布很可能随之变化，调好的阈值需要重新标定。
6. 没有解释，且对措辞敏感：模型只返回数字，不给理由。官方文档也提醒：问题和选项的措辞、顺序会影响分数；校准在熟悉的任务类型上最可靠；模型的知识可能已经过时；作为安全过滤器时，它可能漏掉隐蔽的有害内容，也可能误拦正常内容。
7. 跨境与数据驻留：中国大陆的团队目前需要通过 Azure 全球版的 Foundry 调用它，要同时考虑跨境网络延迟和数据出境的合规要求；GlobalStandard 部署可能在任意区域处理推理请求，对数据驻留敏感的场景应选择 DataZoneStandard。

与 Jev、Laya 相比，怎么选

1. 场景对照表

2. 选型时要回答的几个问题

可以按下面的顺序依次回答：

1. 数据能否离开自己的环境（以及境内）？
   └─ 不能 → Laya（硬约束，其他因素都要让路）
2. 是否已经在用 Azure，需要统一账单、Entra ID、RBAC 和数据区域部署？
   └─ 是 → 优先评估 Microsoft-Decision-1
3. 是否高度依赖置信度阈值，或者单次输入经常超过 32K token？
   └─ 是 → 优先评估 Jev
4. 是否有标注数据，并且需要每秒几十次以上的决策？
   └─ 是 → 微调 Laya，本地部署
5. 以上都不是硬约束？
   └─ 用同一组题目同时测试 Microsoft-Decision-1 和 Jev，
      按准确率、校准、延迟和单次成本综合选择

3. 组合使用：不必三选一

由于三者的接口几乎一致，组合使用的成本很低：

1. 多供应商容灾：把 Microsoft-Decision-1 和 Jev 配置成互为备份的两个云端后端，一方限流或故障时自动切换。两者的概率分布不同，阈值需要分别标定。
2. 影子测试：生产流量走一个后端，同时把请求异步发给另一个后端，积累两者结论不一致的样本，再交给人工或大模型裁决，为后续的选型和阈值调整提供依据。
3. 分层级联：本地的 Laya 先处理高频、短文本、高置信度的请求；低置信度或长文本请求升级给 Microsoft-Decision-1 或 Jev；仍然拿不准的，再交给推理型大模型或人工处理。
4. 按数据敏感度路由：涉及敏感数据的请求只走本地的 Laya，其余请求走云端。

代码示例：同一组问题，三种后端

1. 部署 Microsoft-Decision-1

可以在 Foundry 门户的模型目录中搜索 Microsoft-Decision-1 并一键部署，也可以使用 Azure CLI：

az cognitiveservices account deployment create \
  --name <ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --deployment-name decision-1 \
  --model-name "Microsoft-Decision-1" \
  --model-format Microsoft \
  --model-version "1" \
  --sku-name GlobalStandard \
  --sku-capacity 1

如果需要把推理限制在某个数据区域内，可以把 --sku-name 换成 DataZoneStandard（需要所在区域支持）。

2. 启动本地的 Laya 服务

pip install "laya[serve]"
# 只监听本机；如需对外提供服务，请设置 LAYA_API_KEY 并放在网关后面
LAYA_HOST=127.0.0.1 LAYA_DEVICE=cuda LAYA_PRELOAD=1 laya-serve

3. 用同一组问题调用三个后端

下面的示例使用 requests 和 azure-identity（pip install requests azure-identity）。注意 team 问题里加了一个 cannot_tell 选项，这是微软文档推荐的做法：当模型不应该被迫做出选择时，给它一个“无法判断”的出口。

import os

import requests
from azure.identity import DefaultAzureCredential

payload = {
    "state": {
        "message": "Checkout is down again. This is my third request.",
        "customer_contact_count": 3,
    },
    "questions": {
        "team": {
            "type": "choice",
            "instructions": "Which team should handle this request?",
            "criteria": {
                "billing": "Charges, invoices, and refunds",
                "engineering": "Bugs, errors, and outages",
                "support": "How-to and account questions",
                "cannot_tell": "The message does not say enough to decide",
            },
        },
        "severity": {
            "type": "score",
            "instructions": "How severe is this issue?",
            "criteria": ["Cosmetic", "Minor", "Major", "Critical"],
        },
        "repeat_contact": {
            "type": "noul",
            "instructions": "Has the customer contacted support before?",
        },
    },
}


def decide(url: str, headers: dict, model: str | None = None) -> dict:
    body = {**payload, "model": model} if model else payload
    resp = requests.post(url, headers=headers, json=body, timeout=10)
    resp.raise_for_status()
    return resp.json()["answers"]


# 1) Microsoft-Decision-1（Foundry）：model 填部署名称，推荐使用 Entra ID 认证
token = DefaultAzureCredential().get_token("https://cognitiveservices.azure.com/.default").token
answers = decide(
    f"{os.environ['AZURE_ENDPOINT'].rstrip('/')}/providers/microsoft/v1/systemone",
    {"Authorization": f"Bearer {token}"},
    os.environ["DEPLOYMENT_NAME"],
)
print("decision-1:", answers["team"]["choice"])

# 2) Jev（TypeSafe）：固定版本号，避免别名升级后调好的阈值失效
answers = decide(
    "https://api.typesafe.ai/v1/systemone",
    {"Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}"},
    "jev-1.13.0",
)
print("jev:", answers["team"]["choice"])

# 3) Laya（本地 laya-serve）：省略 model，由 Router 按语言自动选择检查点
answers = decide("http://127.0.0.1:8000/v1/systemone", {})
print("laya:", answers["team"]["choice"])

如果使用 API Key 调用 Microsoft-Decision-1，把请求头换成 {"api-key": os.environ["AZURE_API_KEY"]} 即可。

三个后端返回的 answers 都以问题名为键，但有几个细节需要留意：

• Jev 和 Laya 的 choice 结果都包含 choice、probabilities 和 confidence，不过 Laya 的 confidence 计算方式和 Jev 不同，所以它额外提供了一个按 Jev 公式计算的 x_jev_confidence，方便沿用 Jev 上调好的阈值；
• Microsoft-Decision-1 的文档说明会返回选中项和每个选项的概率，接入时建议先打印一次完整的响应，确认字段名之后再编写阈值逻辑；
• Microsoft-Decision-1 的 score 返回的是各等级下标的概率加权平均值（四级量表的取值范围是 0～3，可能落在两个等级之间），文档建议把它用于相对排序和阈值判断，而不是当作绝对的校准评分。

落地注意事项

Microsoft-Decision-1 的官方文档给出了不少实用的建议，它们同样适用于 Jev 和 Laya：

1. 先用代表性数据验证：用自己的标注样本测试准确率和延迟，再决定是否上线。
2. 按误判代价设置阈值：根据误报和漏报的代价分别设置置信度阈值；不应该强行选择时，加一个“无法判断”的选项。
3. 使用中性措辞，随机化选项顺序：测试改变选项顺序是否会影响结果。
4. 用 Coding Agent 迭代问题设计：让 Coding Agent 生成多组候选的 state、instructions 和选项，在标注集上评估、对比，人工审核之后再上线。
5. 涉及个人的重大决策必须有人参与：在信贷、招聘、住房、医疗、法律等场景中，只能把模型作为决策辅助，并告知受影响的用户有 AI 参与了决策；不要使用不必要的敏感属性，并持续监控不同群体之间的结果差异。
6. 阈值不能跨后端照搬：三个模型的概率分布不同，置信度的计算方式也可能不同，切换或混用后端时要分别标定。
7. 固定版本，持续监控：固定部署的模型版本，升级（包括底座迁移）之后重新标定阈值，并持续监控概率分布和校准漂移。

总结

用一句话概括三者：

Microsoft-Decision-1 是“Azure 里的企业级决策组件”，Jev 是“开箱即用的云端通才”，Laya 是“可以特化的本地专才”。

• 如果你已经在用 Azure，需要统一的计费、身份认证和合规体系，或者想给 Agent 加一道低延迟的“决策闸门”，Microsoft-Decision-1 是最省事的选择；
• 如果你最看重置信度校准和长上下文，Jev 目前仍然更稳；
• 如果数据不能离开本地，或者需要毫秒级、海量的决策，并且有能力准备标注数据，Laya 依然不可替代。

从更大的视角看，Microsoft-Decision-1 的意义不只是“又多了一个决策模型”。微软带着开源底座、与 Jev 相同的价格和几乎一致的接口入局，说明了两件事：一是 state + questions 风格的决策接口正在成为事实标准，用户的迁移成本越来越低；二是底座正在变成可替换的零件，竞争的焦点转向了后训练数据、评测体系、校准质量和分发渠道。对开发者来说这是好消息：把决策从大模型里拆出来，已经从创业公司和开源社区的尝试，变成了大厂也认可的工程实践。

参考资料

• Microsoft Command Line：Introducing Microsoft-Decision-1, our model for fast decision-making
• Microsoft Learn：Deploy and use Microsoft-Decision-1 in Microsoft Foundry
• Microsoft Learn：Foundry Models sold by Azure
• Microsoft Foundry 模型目录：Microsoft-Decision-1
• JevBench：Hosted decision API benchmark
• JevBench：Open-weights decision model leaderboard
• TypeSafe 文档：Models
• Laya GitHub 仓库
• Jev vs Laya：闭源与开源 System One 决策模型的对比与选型

在上一篇文章中，我把 OpenWebUI 的数据库迁移到了 Azure 托管 PostgreSQL。在日常使用 OpenWebUI 的过程中，我经常遇到两个问题：

1. 问不到最新的信息：模型有知识截止时间，问到最近的版本发布、新闻或价格，要么答不上来，要么答错。
2. 贴进去的链接不会被打开：把文章、文档或 GitHub 页面的 URL 贴进对话框，想让模型总结、翻译或对比，模型却不会去读这个链接，有时甚至会根据 URL 猜出一段“看起来很像”的内容。

这两个问题都可以靠 OpenWebUI 的联网能力解决。本文使用微软新推出的 Microsoft Web IQ 作为联网搜索引擎，并让模型自动识别消息中的 URL、读取网页后再回答。整个过程只需要在 Azure 门户中创建一个 Web IQ 资源，再到 OpenWebUI 的管理界面中完成配置，不需要写代码，也不需要部署额外的服务。

本文基于 Open WebUI v0.11.4（2026 年 9 月发布），界面名称以英文界面为准。文中的 API Key 均为占位符。

最终效果

配置完成后：

• 提问涉及最新信息时，模型会自己调用 search_web，由 Web IQ 返回搜索结果，回答附带参考链接；
• 消息中出现 http:// 或 https:// 链接时，模型会自己调用 fetch_url，通过 Web IQ 读取页面正文后再回答，读取过的页面会出现在引用来源中；
• 两者可以在同一次回答中组合使用，例如先读取你给出的文档，再搜索最新的变更说明做对比。

为什么选择 Microsoft Web IQ

打开 OpenWebUI 的 Settings → Admin → Web Search，在 Web Search Engine 中可以找到 bing。选中后需要填写 Bing Search V7 Endpoint 和 Bing Search V7 Subscription Key，看起来只要填上 Azure 上 Bing 资源的密钥就能用，但这条路已经走不通了：

• Bing Search v7 API（包括 Bing Custom Search）已于 2025 年 8 月 11 日退役，已有实例全部下线，也无法再创建新资源；
• 现在 Azure 上能创建的 Bing 资源是 Grounding with Bing Search，它只能作为 Microsoft Foundry 智能体的工具使用，不能拿密钥直接调用搜索接口。想接入 OpenWebUI，就得自己开发一个桥接服务。

Microsoft Web IQ 是微软在 2026 年 6 月发布的一组面向 AI 应用的 API，用来为模型提供实时的网络信息（grounding），可以理解为“给 AI 智能体用的搜索引擎”：

• 基于 Bing 的全球索引构建，并针对智能体的多轮检索重新设计；
• 返回的不只是链接列表，而是带来源的相关段落，可以直接放进模型上下文，用更少的 token 得到更好的回答；
• 覆盖网页、新闻、图片、视频等内容，支持 100 多种语言和市场。

更重要的是，OpenWebUI 已经内置了 microsoft_web_iq 引擎。它既可以作为搜索引擎，也可以作为读取网页的网页加载引擎，只需要一个 API Key。

工作原理

用户消息
  │
  ▼
OpenWebUI（模型以原生工具调用方式工作）
  │
  ├── search_web：联网搜索
  │     └── Web IQ /search/web：返回标题、链接和相关段落
  │
  └── fetch_url：读取消息中的链接
        └── Web IQ /browse：读取网页，返回 Markdown 格式的正文

几点说明：

• search_web 和 fetch_url 是 OpenWebUI 的两个内置工具，同属 Web Search 类别，由模型自己决定何时调用；
• 这两个工具依赖原生工具调用（Native Function Calling），这是 v0.10.0 起的默认模式；
• 网页加载引擎也设为 Web IQ 之后，网页由 Web IQ 读取，需要 JavaScript 渲染的页面也能读到内容。PDF 等文件仍然由 OpenWebUI 下载后自行解析。

第一步：创建 Web IQ 资源并获取 API Key

Web IQ 以 Azure 资源的形式提供。在 Azure 门户中搜索 Microsoft Web IQ，进入 Microsoft Web IQ resources，点击 Create，在 Basics 页填写：

• Subscription 和 Resource group：选择用于管理和计费的订阅与资源组；
• Name：资源名称；
• Region：固定为 Global，这是一个可以跨 Azure 区域使用的全局资源。

点击 Review + create 完成创建，然后在资源页面中复制 API Key，下一步会用到。

Web IQ 目前仍处于有限访问（limited access）阶段。如果在 Azure 门户中找不到或者无法创建这个资源，可以先到 Microsoft Web IQ 官网 点击 Join the waitlist 申请。

第二步：配置 Web IQ 搜索和网页读取

以管理员身份登录 OpenWebUI，点击左下角的头像，进入 Settings → Admin → Web Search。

1. Search 部分

几点说明：

• Microsoft Web IQ API Base URL：OpenWebUI 已经预先填好，一般不需要修改；如果 Web IQ 资源页面显示了其他终结点，以资源页面为准；
• Language：技术类内容用 en 通常效果更好；如果主要查询中文资讯，可以改为 zh（以 Web IQ 支持的语言代码为准）；
• Fetch URL Content Length Limit：默认不截断，遇到很长的页面会占用大量上下文，建议设置上限；
• Web Search Confirmation：可选。开启后，用户在对话中使用联网搜索前会先看到确认提示，例如默认的 “Your query will be sent to the configured web search provider.”，提醒用户查询内容会发送到外部服务。

2. Loader 部分

点击 Save 保存，配置立即生效，不需要重启容器。

Web Loader Engine 也可以保持 Default，由 OpenWebUI 服务器自己抓取网页。但默认加载器读不到需要 JavaScript 渲染的内容，它的 User-Agent 也容易被部分网站拦截，交给 Web IQ 读取会省心很多。

第三步：让模型自动识别并读取消息中的 URL

1. 模型设置

进入 Settings → Admin → Models，编辑对话使用的模型：

其中 Default Features 很关键：原生模式下，只有模型启用了 Web Search 能力，并且当前对话打开了联网开关，search_web 和 fetch_url 才会提供给模型。不勾选的话，用户每次都要在输入框的 + 菜单中手动打开联网搜索，否则贴进来的链接不会被读取。

原生模式要求模型具备可靠的工具调用能力，建议使用较新的模型，太小或太旧的模型可能不会正确调用工具。

2. 系统提示词

是否调用 fetch_url 由模型自己决定。为了让行为更稳定，在同一个页面的 System Prompt 中加入以下规则：

你可以使用 search_web 和 fetch_url 两个工具：
1. 用户消息中出现以 http:// 或 https:// 开头的链接时，先调用 fetch_url 读取链接内容，再根据读取结果回答；有多个链接时逐个读取。
2. 问题涉及最新动态、版本、价格等时效性信息，或者你不确定答案时，调用 search_web 搜索；搜索结果中的摘要不够时，再用 fetch_url 打开最相关的结果。
3. 链接无法访问或内容为空时，如实告诉用户，不要根据链接地址推测页面内容。
4. 在回答末尾列出参考链接。

第 3 条用来防止模型在读取失败后“编”一段内容；第 4 条则是因为原生模式下，search_web 的结果不会出现在引用来源中，只有 fetch_url 读取过的页面才会，所以需要模型在回答中写出来。

3. 手动附加网页

如果希望某个链接一定被读取，也可以手动附加：

• 在输入框中输入 # 后粘贴链接，然后选择该网页；
• 或者通过输入框的 + → Attach Webpage 添加链接。

这两种方式由 OpenWebUI 直接读取页面（同样使用上面配置的网页加载引擎），不依赖模型的判断。

效果验证

1. 读取链接

新建一个对话，输入：

帮我总结这篇文档的要点：https://docs.openwebui.com/features/chat-conversations/web-search/providers/microsoft-web-iq

预期：

• 回答过程中显示模型调用了 fetch_url；
• 回答下方的引用来源中出现这篇文档；
• 回答内容与文档一致，而不是泛泛而谈。

2. 联网搜索

Open WebUI 最新发布的版本是多少？有哪些主要更新？

预期：

• 模型调用 search_web，结果来自 Web IQ；
• 如果摘要不够，模型会继续调用 fetch_url 打开发布说明页面；
• 回答末尾列出参考链接。

3. 组合使用

先读取 https://github.com/open-webui/open-webui/releases 的内容，再搜索一下社区对最新版本的反馈，最后给我一个是否升级的建议。

预期模型会先读取给出的链接，再根据需要多次搜索，最后综合两部分信息给出建议。

4. 排查问题

如果没有达到预期效果，可以先查看 OpenWebUI 的日志：

docker logs --since 10m open-webui 2>&1 |
grep -Ei 'web iq|microsoft browse|fetch_url|blocked'

常见的日志：

• Error searching with Microsoft Web IQ API：搜索请求失败，通常是 API Key 不正确或者尚未开通；
• Error browsing ... with Microsoft Web IQ：Web IQ 读取网页失败；
• Blocked ...：链接指向内网地址或者在过滤列表中，被 OpenWebUI 拦截。

也可以直接用 curl 验证 API Key，下面的请求格式与 OpenWebUI 实际发送的一致：

curl -sS https://api.microsoft.ai/v3/search/web \
  -H "x-apikey: $WEB_IQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "Open WebUI", "maxResults": 3, "language": "en", "contentFormat": "passage"}'

正常情况下会返回包含 webResults 的 JSON，每条结果都有 url、title 和 content。

注意事项

• 数据会发送到 Web IQ：搜索词和需要读取的链接会发送到 Web IQ API（api.microsoft.ai），数据如何处理以 Web IQ 的服务条款为准。敏感对话可以关闭联网开关，或者开启 Web Search Confirmation 提醒用户。
• 请求中会附带用户信息：从 v0.11.4 的源码看，调用 Web IQ 搜索时，OpenWebUI 会在请求头中附带当前用户的名称、ID、邮箱和角色（X-OpenWebUI-User-*），目前无法通过配置关闭。如果组织对此有要求，上线前需要评估。
• 内网链接无法读取：读取链接之前，OpenWebUI 会先校验 URL，默认禁止访问内网地址和云元数据地址。这些防护默认开启，无需额外配置，Web IQ 本身也访问不到内网页面。
• 调用次数与成本：每次 search_web 和 fetch_url 都是一次 Web IQ 调用，原生模式下模型还可能为一个问题连续调用多次。建议 Search Result Count 保持在 3～5，只在需要联网的模型上把 Web Search 设为默认功能。Web IQ 的费用计入创建资源时选择的 Azure 订阅，可以为资源组设置预算告警。

常见问题

总结

Bing Search API 退役之后，OpenWebUI 内置的 bing 引擎已经无法使用。借助 OpenWebUI 内置的 microsoft_web_iq 引擎，只需要在 Azure 上创建一个 Web IQ 资源并拿到 API Key，就可以在管理界面中完成联网搜索的接入：

• 搜索和网页读取都交给 Web IQ，返回的是适合直接放进模型上下文的段落和正文；
• 在原生工具调用模式下，search_web 负责搜索，fetch_url 负责读取消息中的链接；
• 通过模型的 Default Features 和系统提示词，让模型自动识别 URL、先读后答，并在回答中给出参考链接。

整个过程不需要写一行代码。无论是询问最新的信息，还是直接丢一个链接让模型总结，现在都可以在 OpenWebUI 中完成。

参考资料

• Announcing Microsoft Web IQ
• Microsoft Web IQ
• Open WebUI: Microsoft Web IQ
• Open WebUI: Agentic Web Search & URL Fetching
• Open WebUI: Bing
• Open WebUI: Hardening

引言

2026 年 9 月，AI 圈突然流行起一类“不会说话”的模型。

9 月 15 日，由前 OpenAI 研究员 Diogo Almeida 创办的 TypeSafe AI 发布了 Jev：它不聊天、不写文章、也不生成代码，只接收一段状态（state）和一组预先定义好的问题，然后直接返回带有校准概率的结构化决策。

仅仅三天后，9 月 18 日，独立研究者 Nandakishor M（Convai Innovations）开源了 Laya。它同样是一个非自回归的 System 1 决策模型，采用 Apache 2.0 协议，权重可以直接从 Hugging Face 下载，三天内 GitHub 星标就超过了 6000，被社区称为“开源版 Jev”。

一边是背靠 4000 万美元种子轮、开箱即用的闭源 API，一边是 4.2 亿参数、一张 T4 甚至一台 MacBook 就能跑起来的开源模型。社交媒体上“Laya 反超 Jev”“Jev 的护城河只维持了两天”之类的说法很多，但如果把双方公开的资料仔细读一遍，就会发现结论远没有这么简单。

本文将从以下几个方面展开：

1. 什么是决策模型，它要解决什么问题
2. Jev 与 Laya 各自的技术路线
3. 核心差异与基准数据解读
4. 两者各自的优势与劣势
5. 适用场景与选型建议

什么是决策模型（System One Model）

1. 名字的由来

“System One”来自丹尼尔·卡尼曼的《思考，快与慢》：System 1 是快速、直觉式的判断，System 2 是缓慢、审慎的推理。在这个比喻下，生成式大模型（尤其是推理模型）更像 System 2，而决策模型负责的是毫秒级的“直觉反应”。

顺带一提，Jev 这个名字来自经济学家威廉·斯坦利·杰文斯（William Stanley Jevons）。TypeSafe 认为机器智能会重演“杰文斯悖论”：就像蒸汽机效率提升反而带动了煤炭需求一样，智能的单价每下降一个数量级，都会解锁更多数量级的新用例。

2. 用大模型做“选择题”的痛点

在真实的 AI 工程里，大量决策其实都是“小事”：

• 这张工单应该分给哪个团队？
• 这封邮件是不是钓鱼邮件？
• 这段提示词有没有注入攻击？
• Agent 下一步该调用哪个工具？上一步执行成功了吗？

今天常见的做法，是把这些问题交给一个擅长写作的大模型，再从它生成的文本里把答案“抠”出来。这会带来一系列问题：

3. 决策模型的思路

决策模型干脆把“生成”这一步删掉了。TypeSafe 用一句话概括它：

Unstructured state in, typed probabilistic decisions out.

非结构化的状态输入，带概率的类型化决策输出。

调用方只需要提交两部分内容：

• state：需要判断的当前状态，可以是字符串、JSON 对象或文本数组
• questions：一组类型化问题，每个问题的候选答案都由调用方提前定义

模型并行地回答所有问题，只返回数字和概率。Jev 与 Laya 采用了完全相同的三种问题原语：

由于输出空间被提前限定，模型不可能返回类型错误或凭空编造的选项。但需要注意：类型安全不等于判断正确，它仍然可能在合法的选项里选错，这一点后文会反复提到。

4. 它在系统中的位置

决策模型并不是用来取代大模型的，而是把大模型从一些“本不该由它来做”的位置上挪开。一个比较合理的分工是：

代码（确定性逻辑）
  └─ 流程编排、权限控制、数学与日期计算、执行动作
        │  遇到需要语义理解的“模糊 if 语句”
        ▼
决策模型（System 1：Jev / Laya）
  └─ 分类、路由、打分、校验、护栏，返回类型化答案 + 概率
        │  置信度不足，或需要生成文本 / 复杂推理
        ▼
大模型（System 2：GPT / Claude / DeepSeek 等）
  └─ 长上下文理解、规划、写作、代码生成

有了校准过的置信度，程序的控制流就不再只有“是 / 否”两种状态，而可以分成三档：高置信度自动执行，中置信度交给更强的模型复核或请求用户确认，低置信度转人工。这也是决策模型真正的价值所在：速度只是表象，可以被写进 if 语句的置信度才是关键。

两位主角

Jev：TypeSafe AI 的闭源云端服务

基本信息

• 发布时间：2026 年 9 月 15 日，以 early access 形式开放
• 团队背景：TypeSafe AI 是一家旧金山公司，创始人 Diogo Almeida 曾在 Google Brain 和 OpenAI 从事研究，是 InstructGPT 论文和 GPT-4 技术报告的作者之一。发布当天，公司同时宣布了由 DCVC 领投的 4000 万美元种子轮融资
• 产品形态：闭源，只提供 API（POST https://api.typesafe.ai/v1/systemone）以及 Python / JavaScript SDK
• 当前版本：Jev 1.13（jev-1.13.0），别名 jev-latest

技术路线

TypeSafe 声称为自动化场景重建了一整套技术栈：全新的模型架构、追求极致效率的并行采样器，以及一种名为 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习） 的训练方法。与 RLHF 优化“人类偏好”、RLVR 优化“可验证奖励”不同，RLCD 的目标是让模型在给出答案的同时，给出认知上诚实的概率。

不过，TypeSafe 目前并没有公开模型架构、参数规模和训练数据。社区有不少人认为它更接近 BERT 这类 encoder 模型，但这只是猜测。

关键规格

按这个定价计算，如果每次判断平均消耗 1000 个输入 token，100 万次判断的费用只有约 42 美元。

生态

Jev 发布后迅速走红：LangChain 很快发布了集成指南，Vercel 把它接入了 AI Gateway，社区也涌现出不少实验项目，比如用 Jev 给 Claude Code 的工具调用输出做相关性打分、进而压缩上下文的 fast-jev-compaction。

Laya：Convai Innovations 的开源本地模型

基本信息

• 发布时间：2026 年 9 月 18 日
• 作者：独立研究者 Nandakishor M（Convai Innovations）
• 开源协议：Apache 2.0，代码、权重、训练方法和微调 Notebook 全部公开
• 获取方式：pip install laya（要求 Python 3.10+），权重托管在 Hugging Face 的 convaiinnovations/laya

Laya 的诞生还有一段插曲。作者在 2025 年就先后发表过两篇相关论文（arXiv:2503.23303、arXiv:2510.01237），研究用强化学习训练非自回归的决策模型，最早用于预测销售对话的转化率。看到 Jev 以“突破”之名发布后，他把旧方案的架构缺陷全部修了一遍，做出了这个通用的开源版本。

模型架构

Laya 采用“双向编码器 + 决策头”的结构，总参数量 421M：

State（文本或 JSON）+ 类型化问题与选项
        │ 拼接为：[CLS] 问题 [SEP] [MASK] 选项1 [MASK] 选项2 ... [SEP] state [SEP]
        ▼
ModernBERT-large 编码器（395M，28 层双向注意力）
        ▼
决策头 Transformer（约 25M，2 层）
        ├─ 选项打分器：取每个 [MASK] 位置的隐状态 → logit → 温度缩放 → softmax
        └─ Act / Escalate 头：基于 [CLS] 与分布统计量，判断“自动执行”还是“升级处理”

每个选项前面放一个 [MASK] 标记，经过双向编码器之后，从这些标记的位置取出隐状态进行打分。同一个 state 上的多个问题会组成一个 batch，在一次前向传播中完成计算。

三个检查点 + 路由器

Laya 内置了一个纯 Python 实现的 Router，会在前向计算之前用不到 1 毫秒的时间检测文本的书写系统和语言，然后自动选择合适的检查点。之所以需要它，是因为英文检查点在非拉丁文字上会“自信地犯错”：在高棉语测试中，它的准确率为 0，置信度却高达 0.952。这种情况下，靠置信度阈值是拦不住的。

开放的 RLCD 实现

Laya 沿用了 RLCD 这个名字，并公开了具体做法：用严格适当评分规则（strictly proper scoring rules，由对数评分、球面评分和排序概率评分组合而成）作为奖励，采用 GRPO 风格的组内基线策略梯度进行训练，完全不使用监督交叉熵损失。严格适当评分规则的特点是：只有当模型报告真实的概率时，才能拿到最高的期望奖励，从而“逼”模型说实话。

Act / Escalate 头则用一个代价矩阵来训练：判对奖励 +1，判错惩罚 -3，升级人工惩罚 -0.5。由此可以推导出，只有当正确率超过 62.5% 时，自动执行才比升级人工更划算，模型也就学会了“没把握就上交”。

此外，Laya 还提供了开箱即用的工作流预设（模型路由、提示词护栏、内容审核、工单分诊），以及一个可以在 Kaggle 免费 2×T4 GPU 上运行的微调 Notebook：在约 3 万个问题上训练 4 个 epoch，耗时 4～5 小时。

核心差异一览

基准数据怎么看

1. Laya 公布的对比数据

Laya 的 README 中给出了一张与 Jev 1.13.0 的对比表（Laya 一侧为经过 Router 路由后的实测结果）：

乍一看，Laya 几乎全面领先。但如果只看这张表就下结论，很容易踩坑。

2. 解读数据时必须注意的五点

第一，Jev 的数据并非同场实测。 Laya 作者明确说明，自己没有 TypeSafe 的 API 权限，表中 Jev 的数字全部引用自第三方公开的结果，样本量和提示词都不相同。

第二，Laya 的高分来自针对性微调。 typed-decisions 上的 0.766 是 laya-typed-decisions 在该基准自己的训练集上微调后取得的成绩。未经微调的两个基础检查点只有 0.34～0.36，接近随机猜测（0.318），甚至低于“每题都猜最常见类别”的基线（0.461），而 Jev 不做任何训练就能拿到 0.727。作者自己也说得很直白：Laya 是一个适合特化的快速底座，而不是零样本决策引擎。 换句话说，这张表比的其实是“特化后的专才”和“零样本的通才”。

第三，校准优势需要额外的温度拟合。 表中 0.081 的 ECE 是用领域留出数据重新拟合温度之后的结果，出厂时为 0.466。而在同一个 typed-decisions 基准上，Laya 微调检查点的 ECE 为 0.213，反而高于 Jev 的 0.144；在衡量概率分布与参考分布吻合程度的“软准确率”上，Jev 也以 0.580 领先 Laya 的 0.471。当然 Jev 也并非完美：Laya 作者引用的数据显示，在 DAIR Emotion 上，Jev 对 16% 的样本给真实标签分配了 0 概率，这对依赖置信度做分流的系统来说是个硬伤。

第四，延迟对比的本质是部署方式的差异。 Jev 的延迟包含从客户端到 TypeSafe 云端的网络往返（TypeSafe 的评测大多从美国西海岸发起），而 Laya 的 32.8 ms 是在本地 T4 GPU 上的推理耗时。对于国内或其他地区的用户，Jev 的实际延迟还要叠加跨境网络的开销；反过来，如果把 Laya 部署成远程服务，同样要算上网络开销。

第五，Jev 自己的宣传数据同样需要打折。 TypeSafe 官网上“快 193.6 倍、便宜 444.6 倍”的数字来自其团队设计的 4 套工作流评测，参考答案取自 GPT-6 Astra 和 Fable 5.1 两个前沿模型的平均结果，官方也坦言这些数字处于真实收益的上限。自动化服务公司 AY Automate 发布的第三方测试则显示：Jev 比几款对照模型快约 2～3.6 倍；成本方面，相比便宜的小模型约节省 4.7～7.5 倍，相比昂贵的前沿模型才能达到 40～49 倍。

3. 社区实测

发布后短短几天，社区就做了不少对比测试，大多集中在高频交互场景：

• 贪吃蛇：在同一套决策逻辑下，本地运行的 421M Laya 在 30 秒内平均每秒决策 86.5 次，P50 延迟约 9 ms；云端 Jev 每秒只能决策 3.2 次，API 往返约 317 ms
• M5 Pro 测试：两者的中位耗时分别为 15.3 ms 和 298.1 ms，差距接近 20 倍
• Apple Silicon 移植：社区项目 laya-mlx 把模型移植到 MLX，运行时最高约占 1GB 内存，在 M3 Max 上运行贪吃蛇可以达到每秒 60 次决策

这些测试体现的主要是“本地推理”与“云端往返”的差异。对于每秒需要几十次决策的实时场景，这个差距是决定性的；但对于一次工单分流来说，30 ms 和 300 ms 的区别，用户几乎感知不到。

4. 小结

比较公允的结论是：在开箱即用、长上下文、选项复杂的场景下，Jev 更强；在有标注数据的垂直任务上，经过微调的 Laya 可以做到更快、更准、更便宜。

Jev 的优势与劣势

优势

1. 开箱即用，零样本能力强：不需要任何训练数据，写好 state 和问题就能直接使用。TypeSafe 称 Jev 在 System One 类任务上达到了与现有前沿 LLM 相近的智能水平；Karpathy 也评价说，它处在 LLM 帕累托曲线上一个长期被低估的位置：不需要复杂思考，只需要在低延迟下给出足够可靠的判断。
2. 长上下文与高基数选项：64k 的上下文可以直接放入长邮件串、合同条款或 Agent 执行轨迹；choice 最多支持 255 个选项，在 Banking77 这类细粒度意图分类上仍有 0.870 的准确率。
3. 出厂即校准：不需要自己拟合温度，返回的概率可以直接用于阈值分流；官方文档还给出了按风险等级设置不同阈值的最佳实践。
4. 免运维，生态成熟：托管服务加官方 SDK，已经接入 LangChain、Vercel AI Gateway 等生态，团队不需要操心 GPU、扩缩容和模型升级。
5. 单价极低：按每次 1000 个输入 token 估算，100 万次判断约 42 美元，对大多数业务来说，模型费用已经不是瓶颈。

劣势

1. 闭源黑盒：架构、参数量和训练数据都没有公开。决策模型本身也不输出解释，正如 Simon Willison 所提醒的，Jev 最终留给开发者的可能只有一个数字，判断出错时很难追问原因。
2. 数据必须出域：所有 state 都要发送到 TypeSafe 的云端，零数据保留（ZDR）仅面向企业客户，这对金融、医疗、政企等场景是硬伤。另据媒体报道，Jev 目前尚未面向中国大陆开放。
3. 网络延迟无法消除：几百毫秒的往返对于业务工作流已经足够快，但对于游戏 AI、实时风控这类每秒几十次决策的场景仍然太慢。
4. 无法微调：所有客户共用同一套权重，只能通过 state、instructions 和 criteria 来“调教”，在高度垂直的领域可能达不到专用模型的效果。
5. 英语优先：官方明确英语是主要训练语言，中文场景一定要先用自己的数据验证。
6. 早期产品的不确定性：速率限制仍在动态调整；官方预计价格只降不升，但也坦言暂时无法证明当前价格没有补贴；jev-latest 别名会随新版本移动，调好的阈值可能需要重新标定；此外还有厂商锁定的风险。
7. 已知的能力“锯齿”：官方文档专门列出了 Jev 1.13 的多种失效模式，包括过于字面地理解问题、不擅长计数和数学运算、日期比较不可靠、多跳的间接推理效果差、state 中无关内容过多会降低准确率、容易被 state 中的对抗内容（如提示词注入）带偏等。甚至一些“常识性”的一致性也无法保证：对同一个问题和它的否定分别提问，两个 noul 的概率之和可能是 1.19，而不是 1。

Laya 的优势与劣势

优势

1. 完全开源：Apache 2.0 协议，架构、训练方法、评测脚本和微调 Notebook 全部公开，可审计、可复现、可二次开发，没有厂商锁定。
2. 数据不出域：可以部署在本地、私有云甚至离线环境中，天然满足数据驻留和隐私合规的要求。
3. 极低延迟、高吞吐：T4 上单个问题约 33～40 ms，多语言检查点批量推理时每题约 7 ms，单卡吞吐约 100～330 题/秒，在实时交互类应用中优势明显。
4. 边际成本接近零：按单张 T4 每秒 100～300 题估算，100 万次判断只需要 1～3 个 GPU 小时。
5. 可微调、可特化：在自有数据上微调后可以超越 Jev（typed-decisions 上 0.766 对 0.727），而且整个流程在 Kaggle 的免费 GPU 上就能完成。
6. 多语言与自动路由：laya-multilingual 覆盖 100 多种语言，Router 会在推理前自动选择检查点，对中文等非英语场景更友好（但仍需自测）。
7. 面向生产的设计：Act / Escalate 头可以直接给出“自动执行还是升级人工”的建议；内置了护栏、审核、分诊等预设；文档还坦诚地列出了自身的各项短板。

劣势

1. 零样本能力弱：基础检查点在 typed-decisions 上接近随机水平，想要好的效果，就必须准备标注数据并进行微调。没有数据的团队拿到手的，基本上只是一个“待训练的底座”。
2. 上下文短：英文检查点默认只有 512 token（留给 state 的约 320 token），多语言和 typed-decisions 检查点为 1024 token（留给 state 的约 768 token）。长文档、长对话需要先做截断、摘要或分块。编码器最高支持 8192 token，但调大之后延迟会上升，效果也需要自行验证。
3. 高基数选项吃力：所有选项共享一个固定的 token 预算，77 个选项时每个选项只能分到 3～4 个 token，Banking77 的准确率随之跌到 0.425。需要调大 head_max_len、先用 embedding 做候选筛选（predict_shortlist），或者拆成“粗分类 + 细分类”两级问题。
4. 校准需要额外工作：出厂的检查点偏向“过度自信”，需要用领域内的留出数据拟合温度（ECE 可以从 0.466 降到 0.081）；多语言检查点出厂时则完全没有拟合温度。
5. score 是最弱的原语：有序打分任务的表现最差，例如 SST-5 五级情感分类的准确率只有 0.372。
6. 语言陷阱：英文检查点在非拉丁文字上会高置信度地犯错，必须使用 Router 或手动选对检查点。另外，默认的懒加载模式下切换语言会触发 7～10 秒的模型重载，生产环境需要开启预加载。
7. 运维与项目成熟度：需要自己负责 GPU 资源、扩缩容、监控和模型版本管理；项目刚刚发布，主要由独立研究者维护，长期演进存在不确定性。

适用场景与选型建议

1. 场景对照表

关于最后一点再多说一句：Laya 在未参与训练的提示词注入测试集上的准确率约为 0.698，Jev 的官方文档也承认 state 中的对抗内容可能带偏判断。决策模型可以作为一道低成本的前置过滤，但不能作为唯一的安全防线。

2. 选型时要回答的几个问题

可以按下面的顺序依次回答：

1. 数据能否发送到第三方云（以及境外）？
   └─ 不能 → Laya（硬约束，其他因素都要让路）
2. 是否有标注数据，并且愿意投入微调？
   └─ 没有 → Jev
3. 是否需要每秒几十次以上的实时决策，或者要在端侧运行？
   └─ 是 → Laya
4. state 是否很长（超过 1k token），或者选项是否很多（超过 20 个）？
   └─ 是 → Jev（或 Laya + 分块 / 候选筛选）
5. 月调用量是否达到数千万级？
   └─ 是 → 倾向 Laya；否则 Jev 的总拥有成本通常更低

关于成本，可以简单算一笔账：假设每次判断消耗 1000 个输入 token，Jev 每 100 万次判断约 42 美元；一台 T4 实例全天候运行，按每小时约 0.5 美元估算，每月约 360 美元，相当于 Jev 约 850 万次判断的费用，这还没算高可用冗余和运维人力。所以单纯从成本角度看，只有当调用量足够大时，自托管 Laya 才有明显优势。更多时候，选择 Laya 的理由应该是延迟、合规和可定制性，而不仅仅是省钱。

3. 组合使用：不必二选一

在实际项目中，两者完全可以组合使用：

1. 阶段式迁移：先用 Jev 快速上线，验证问题拆解、选项设计和置信度阈值是否合理，同时沉淀真实数据和人工复核的标签；当调用量上来或合规要求收紧时，再用这些人工标签微调 Laya，迁移到自托管。由于两者的请求格式（state + questions，以及 choice / score / noul 的 instructions、criteria 结构）几乎一致，迁移成本很低。需要注意的是，如果打算直接把 Jev 的输出当作训练标签，请先确认 TypeSafe 的服务条款；Laya 作者也提醒过，用模型生成的标签来训练，只会把新模型校准到“老师”的错误上。
2. 分层级联：本地 Laya 处理高频、简单、短文本的判断；低置信度或长上下文的请求升级给 Jev；Jev 仍然拿不准的，再交给推理型大模型或人工处理。
3. 按数据敏感度路由：涉及个人隐私或敏感业务数据的请求走本地 Laya，其余请求走 Jev。

4. 其他选择

除了这两者，社区还出现了一条“零训练复刻”的路线：直接读取现成开源 LLM 在候选项上的 token 概率来模拟 Jev 的输出。例如 SemIf 用一个现成的 4B 开源模型直接读取概率，据称与 Jev 的结论一致率在 85% 左右；Kev 则基于 Qwen 3.5 制作了 0.8B、4B 和 9B 三个 Jev-like 模型。这类方案在门槛和效果上介于两者之间，适合想先低成本尝鲜的团队。

代码示例：同一组问题，两种调用方式

由于 Jev 和 Laya 的问题格式几乎一致，同一组 state 和 questions 可以同时用于两者：

state = {
    "message": "I was charged twice for order A-104. Please refund the duplicate.",
    "order": {"charges": [49, 49]},
}

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
            "billing": "Payments, invoices, and refunds",
            "technical": "Bugs and integrations",
            "account": "Account access and profile issues",
        },
    },
    "urgency": {
        "type": "score",
        "instructions": "How urgent is this request?",
        "criteria": ["Not urgent", "Soon", "Critical or blocking"],
    },
    "refund_requested": {
        "type": "noul",
        "instructions": "Does the message request a refund?",
    },
}

调用云端的 Jev（固定版本号，避免别名升级后调好的阈值失效）：

import os
import requests

resp = requests.post(
    "https://api.typesafe.ai/v1/systemone",
    headers={"Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}"},
    json={"model": "jev-1.13.0", "state": state, "questions": questions},
    timeout=5,
)
resp.raise_for_status()
answers = resp.json()["answers"]

在本地运行 Laya：

from laya import Router

# 生产环境建议预加载，避免切换语言时重新加载模型
router = Router(preload=True)
answers = router.predict(state, questions)["answers"]

两者返回的结构基本相同：choice 包含 choice、probabilities 和 confidence，score 包含期望分数、等级概率分布和 confidence，noul 则直接返回“是”的概率。后续的置信度分流逻辑可以完全复用：

dept = answers["department"]

if dept["confidence"] >= 0.9:
    route_to_team(dept["choice"])     # 高置信度：自动执行
elif dept["confidence"] >= 0.6:
    review_with_llm(state, dept)      # 中置信度：交给更强的模型复核
else:
    send_to_human(state)              # 低置信度：转人工

这里的 0.9 和 0.6 只是示意，真实的阈值一定要用自己的数据来标定。

落地时的共同注意事项

无论选择哪一个，以下几点都同样适用：

1. 类型安全 ≠ 判断正确：校准描述的是一组预测的统计性质，并不保证单个答案正确，阈值必须用自己的数据标定。
2. 把问题拆小：不要问“这张工单该怎么处理”，而是拆成“是否申请退款”“紧急程度如何”“属于哪条业务线”等原子问题，再在代码里组合。
3. 计算交给代码：计数、数学运算、日期比较等确定性逻辑不要交给模型。
4. 精简 state：只放与问题相关的字段，无关内容会降低准确率；Laya 的上下文更短，这一点尤为关键。
5. 不可逆操作要兜底：付款、删除数据、医疗或合规审批等操作，不能仅凭一个概率就自动执行。
6. 防范注入：state 虽然是数据，但其中的恶意内容仍可能影响判断，不要把决策模型当作唯一的安全防线。
7. 固定版本，持续监控：固定模型版本（如 jev-1.13.0 或指定的 Laya 检查点），升级后重新标定阈值；上线后持续记录概率分布、抽样复核，并监控校准漂移。

总结

用一句话概括：

Jev 是“开箱即用的云端通才”，Laya 是“可以特化的本地专才”。

• 如果你追求快速上线、手上没有标注数据，或者面对长上下文和复杂的选项空间，Jev 是更省心的选择；
• 如果你有数据、有合规要求、需要毫秒级的实时决策或海量调用，并且有能力运维一个小模型，Laya 更值得投入。

两者并不是替代关系，而是同一条“决策光谱”上的不同档位。更值得关注的是这场对决背后的趋势：AI 系统正在从“一个大模型包打天下”走向分工协作，代码负责骨架，决策模型负责快速判断，大模型负责深度思考。Jev 定义了这个品类，Laya 则在三天之内证明了开源社区可以迅速跟上。对开发者来说，这意味着工具箱里又多了一种更快、更便宜、也更可控的构建模块。

参考资料

• TypeSafe AI：Introducing System One Models & Jev
• TypeSafe 文档：Models
• TypeSafe 文档：Jev 1.13 jaggedness
• TypeSafe 文档：Confidence
• TypeSafe Workflow Evals
• Laya GitHub 仓库
• Laya Hugging Face 模型页
• Nandakishor M：I Built Non-Autoregressive Decision Models a Year Ago. Then a Frontier Lab Called It a “Breakthrough”.
• 虎嗅：号称快200倍的Jev模型，拿不下LLM的大结果

本文将不依赖任何具体推理框架，从 模型推理执行流 的角度，系统阐述什么是 PD Disaggregated、为什么需要它，以及它为 LLM 推理系统带来的核心优势。

LLM 推理的两个本质阶段

所有自回归大语言模型的推理过程，本质上都可以拆解为两个阶段：

Prefill（预填充阶段）

Prefill 阶段负责处理用户输入的完整 Prompt，其主要任务包括：

• 对输入序列进行一次完整前向计算；
• 构建上下文对应的 KV Cache；
• 生成第一个输出 Token。

这一阶段具有如下特征：

• 计算密集型（Compute-bound）
• 大规模矩阵乘法（GEMM）占主导
• 序列长度通常较长
• 对批处理（Batching）高度友好

Decode（解码阶段）

Decode 阶段进入逐 Token 生成过程，每一步都会：

• 输入上一个生成的 Token；
• 读取历史 KV Cache；
• 生成下一个 Token，直到结束条件满足。

其特征与 Prefill 明显不同：

• 访存密集型（Memory-bound）
• 计算规模小，但 KV Cache 访问频繁
• 强延迟敏感
• 执行步数随生成长度线性增长

问题根源：Prefill 与 Decode 的“异构性”

Prefill 与 Decode 并非同一类工作负载，它们在多个维度上呈现出显著异构性：

如果将这两种阶段混合部署、统一调度，就会导致资源使用上的结构性低效。

什么是 PD Disaggregated

PD Disaggregated（Prefill / Decode 解耦），指的是在推理系统架构层面：

将 Prefill 与 Decode 视为两类不同的工作负载，并在调度、资源分配甚至部署拓扑上对它们进行解耦设计。

需要强调的是：

• 这并不是模型结构的拆分；
• 也不是参数的拆分；
• 而是推理执行路径与资源使用方式的解耦。

PD Disaggregated 的核心思想是： 让 Prefill 为吞吐服务，让 Decode 为延迟服务。

为什么必须进行 PD 解耦

GPU 利用率的结构性浪费

混合执行时常见现象包括：

• Decode 阶段算子太小，GPU 算力无法被充分利用；
• Prefill 阶段的大算子又会阻塞 Decode；
• 结果是整体 GPU 利用率“看起来不低，但效率很差”。

PD 解耦后，可以针对不同阶段采用不同的调度和批策略，显著改善有效算力利用。

延迟不可预测，尾延迟恶化

在在线推理场景中，Decode 阶段直接决定用户体验：

• 首 Token 延迟（TTFT）
• 单 Token 延迟（TPOT）
• P99 / P999 延迟

如果 Decode 被 Prefill 阻塞，哪怕吞吐提升，用户体验也会显著下降。 PD Disaggregated 能从架构层面隔离延迟敏感路径。

扩展性受限

在混合架构下：

• Prefill 和 Decode 只能按同一比例扩容；
• 无法根据实际负载特征独立扩展某一阶段。

而真实业务中：

• Chat、Agent 场景 Decode 占比极高；
• 离线生成、批处理 Prefill 占比更高。

PD 解耦使得 按阶段独立扩展成为可能。

PD Disaggregated 的典型架构形态

在工程实践中，PD Disaggregated 通常体现为以下形式之一：

调度级解耦（Soft Disaggregation）

• Prefill 与 Decode 共享模型参数；
• 但在调度层面对二者区别对待；
• Decode 拥有更高优先级。

这是最轻量、最容易落地的形态。

资源级解耦（Resource Disaggregation）

• Prefill 与 Decode 使用不同的 GPU 资源池；
• Prefill GPU 偏向算力型；
• Decode GPU 偏向显存带宽与 KV Cache 容量。

该模式在大规模集群中尤为常见。

服务级解耦（Service Disaggregation）

• Prefill 与 Decode 成为独立服务；
• 中间通过 KV Cache 或状态句柄连接；
• 可独立伸缩、独立调度。

这是 PD Disaggregated 的“完全形态”，也是复杂度最高的一种。

PD Disaggregated 带来的核心优势

更高吞吐与更低延迟并存

传统架构往往需要在吞吐与延迟之间取舍，而 PD 解耦允许：

• Prefill 极致批量化；
• Decode 极致低延迟。

更稳定的尾延迟

Decode 不再被大规模 Prefill 阻塞，P99 / P999 延迟显著改善，这对生产系统至关重要。

更合理的资源利用

不同阶段匹配不同资源类型，避免“用算力型 GPU 跑访存密集任务”这类结构性浪费。

更强的系统演进能力

PD Disaggregated 为后续优化打开空间，例如：

• KV Cache 分层存储；
• Decode 专用硬件；
• 面向 Agent 的长时会话优化。

总结

PD Disaggregated 并不是某个框架的特性，而是对 LLM 推理本质的抽象与再设计：

• Prefill 和 Decode 在计算形态上天然异构；
• 强行混合只会掩盖效率问题；
• 解耦是走向规模化、高质量推理服务的必经之路。

可以预见，随着模型规模继续增长、应用形态日益复杂，PD Disaggregated 将从“高级优化”演变为 LLM 推理系统的默认架构假设。

注意：本译文已获得的原文作者翻译授权，为避免广告嫌疑，本文中移除了特定产品和品牌的商业宣传内容，仅保留技术特性及企业级产品功能描述，相关内容请以原文为准。

随着各组织从大语言模型（LLM）的试验阶段迈向生产部署，选择哪种推理平台就成了一项关键的业务决策。这个选择不仅影响性能，也影响灵活性、成本优化，以及应对快速变化业务需求的能力。

对于技术人员和方案架构师在评估 LLM 推理平台时，应该重点考虑以下三大因素：

1. 架构灵活性：能否在不同硬件加速器和混合云环境间部署，而不会被某一家厂商锁定。
2. 运行可扩展性：支持从单 GPU 部署扩展到分布式多节点的高级部署模式。
3. 生态开放性：对最广泛的模型与内核支持，以及能与各种企业软件生态系统整合。

vLLM 在开源基础、先进内存管理能力，以及即将推出的分布式部署蓝图方面，独特地满足这些需求。与专有或硬件专用方案不同，这套组合提供了在成本、性能和运营需求上随时优化调整的自由。

本文将深入分析为何 vLLM 在其技术架构与能力上（尤其是其 KV-Cache 管理、并行策略，以及未来的 llm-d 分布式能力）提供了最可持续的生产级 LLM 部署路径。

开源优势

社区驱动的大规模创新

LLM 推理的发展，根本上受到开源创新的推动。过去一年半以来 vLLM V1: A Major Upgrade to vLLM’s Core Architecture | vLLM 博客（英文版），vLLM 在支持多样模型、功能和硬件后端方面取得显著成绩，从伯克利大学的研究项目成长为开源 AI 生态中的事实标准之一 vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。

vLLM 社区发展参考链接

vLLM 现在隶属于 PyTorch 基金会托管项目（GitHub — vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs），这保证了其长远的可持续性和治理机制。

企业支持与开源结合

许多企业及产品及解决方案对 vLLM 的态度类似于其对 Linux/OpenStack/Kubernetes 的策略：在社区驱动创新基础上，加入企业级支持、安全性和运维工具。这样模型即可部署在本地、公有云或混合云中，避免绑定。

这种方式带来的好处包括：

• 无厂商绑定：用户可自由选择部署环境
• 透明开发：安全漏洞与缺陷公开追踪与快速修复
• 社区贡献共享：一个组织开发的功能惠及整个生态
• 可定制性：源代码开放，可针对特定需求修改

此外，vLLM 在以下方面具备战略优势：

• 硬件无关性：不局限于 NVIDIA，支持 AMD、Intel、TPU 等多种平台（GitHub — vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs）
• 快速功能迭代：vLLM v1 对其核心模块（调度器、KV 缓存管理、worker、采样器、API 服务等）进行了全面重构（vLLM V1: A Major Upgrade to vLLM’s Core Architecture | vLLM 博客（英文版））
• 生态整合：原生兼容 Hugging Face、OpenAI API、Kubernetes 生态
• 成本优化：可以为不同工作负载选择最具性价比的硬件

架构灵活性与并行化策略

理解并行化（Understanding Parallelization）

大型语言模型带来了特殊的扩展挑战。例如：一个拥有 70B 参数 的模型，仅其权重（使用 FP16 精度）就需约 140GB 内存，这远远超过单一卡片的容量。基于 vLLM 及相关产品和解决方案通过四种互补的并行化策略来应对这些挑战，每一种策略都解决不同类型的扩展问题。

数据并行（Data Parallelism, DP）：跨请求扩展

数据并行是最简单的一种扩展模式：在多个服务器上运行完整模型的多个副本，每个副本处理不同的请求批次。在这种模式下：

• 维护完整模型：每个加速器／服务器保存整个模型的权重。
• 分配请求：请求由负载均衡器分发给不同的副本。
• 支持线性扩展：增加服务器数目可以线性提升吞吐量。
• 简化部署：部署相对简单，不需要对模型进行切分（sharding）。

          [负载均衡器]
               |
    ------------------------
    |          |           |
[Server1]  [Server2]  [Server3]
[Model A]  [Model A]  [Model A]
    |          |           |
[Batch 1]  [Batch 2]  [Batch 3]

关键：每台服务器都有完整的模型副本并行处理不同的请求

此模式与基于 KServe 的 Replica-Sets 用于模型副本服务很好的契合，能自动根据请求负载进行扩展，同时保有模型服务的简单性。

流水线并行（Pipeline Parallelism, PP）：按层分配

流水线并行将模型按照层（layers）分拆，不同的加速器处理不同的网络层：

• 顺序处理：请求在 GPU 间依次通过模型层进行处理。
• 内存均衡：内存需求在多个设备间较为均匀分布。
• 灵活部署：部署灵活，可以跨多个节点，不一定依赖特别高速的互联。
• 微批处理：通过微批处理（micro-batching）来保持 GPU 利用率。

Request → [GPU1:NN-Layers 1-8] → [GPU2:NN-Layers 9-16] → [GPU3:NN-Layers 17-24] → Response
             ↓                     ↓                      ↓
          [Memory]              [Memory]               [Memory]
          
时间线：请求按顺序流经 GPU

但流水线并行在现代 LLM 应用中也面临一些限制：

• “流水线气泡”（pipeline bubble）效率低下：某些 GPU 在等待上游阶段的数据时处于空闲状态。
• 通信开销高：阶段间数据传输成为瓶颈。
• 延迟敏感：每个阶段都会增加延迟，对“第一个 token 的时间”（time-to-first-token）有负面影响。
• 对 MoE（Mixture of Experts，混合专家模型）不友好：MoE 模型中只激活某些专家（非密集执行），这样无法很好地映射到按层划分的流水线结构中。

因为这些限制，很多生产环境更倾向于将张量并行（Tensor Parallelism）用于节点内部扩展，将数据并行（Data Parallelism）用于跨节点扩展。尽管如此，在内存受限或与其他并行策略组合使用的场景中，流水线并行仍然有价值。

张量并行（Tensor Parallelism, TP）：切分模型权重

当模型太大，单个加速器无法容纳其所有权重时，就使用张量并行来将模型权重拆分到多个 GPU 上：

• 水平层拆分：每次矩阵乘法操作被分配到多个 GPU，按部分计算。
• 同步计算：GPU 之间通过高速互联（如 NVLink、Infinity Fabric 等）进行同步和数据交换。
• 内存效率：可使得模型可服务的规模比单个 GPU 容量大出约 4～8 倍。
• 低延迟：如果硬件条件合适，通信开销低的话，张量并行还能保持较低的延迟。

Original Matrix Operation:
[Large Weight Matrix] × [Input] = [Output]

With Tensor Parallelism:
[Weight Part 1] → GPU1 ↘
[Weight Part 2] → GPU2 → [Combine] → [Output]
[Weight Part 3] → GPU3 ↗

关键：单矩阵运算跨 GPU 拆分，需要高速互连（NVLink）

vLLM 的张量并行实现是硬件无关的，支持多种互联技术和不同类型的加速器。

专家并行（Expert Parallelism, EP）：MoE 模型中的专家分布策略

对于混合专家模型（MoE），专家并行把不同的专家（experts）分配给多个 GPU 或多个节点，而不是让每个 GPU 都保存所有专家，由一个路由层（router layer）动态地将 token 分发给需要的专家：

• 分布式专家分片：专家（experts）被分片（shard）分布在不同的 GPU／节点，使拥有上百个专家的模型能扩展到远超过单设备的内存容量。
• 动态 token 路由：每个 token 只被发送到它应使用的一个或多个专家，以减少计算开销。
• 专家并行负载平衡（Expert Parallel Load Balancing, EPLB）：防止某些热门专家／专家组被频繁调用导致不均匀负载，通过动态复制或分布专家，以分散负载。
• 分层调度（Hierarchical Scheduling）：在多节点集群中，路由与复制先在节点间协调，再在节点内部的 GPU 间协调，确保整体利用率均衡且减少跨节点通信。
• 性能收益：对大型的 MoE 模型，这种专家并行在具有高速互联（NVLink、InfiniBand 等）的环境中可以实现接近线性扩展的吞吐效率。

               [Router Layer]
                      |
        ---------------------------------
        |          |          |         |
      GPU1        GPU2       GPU3      GPU4
    [Exp 1,2]   [Exp 3,4]  [Exp 5,6]  [Exp 7,8]
    
令牌流：路由器 → 选定专家 → 输出

vLLM 的统一策略

vLLM 的区别与优势在于它能够无缝结合这些并行策略，为分布式推理提供高度灵活性，使组织能够：

1. 混合使用策略：例如，在节点内部用张量并行，在节点间用流水线并行。
2. 根据硬件特性调整：基于可用的互联速度、GPU 内存、延迟敏感性等因素做最优规划。
3. 动态扩展：可以从单节点部署起步，随着需求增长扩展到多节点／多 GPU。
4. 保持 API 的一致性：无论使用哪种并行策略，道线路径、调用接口等对使用者尽量透明，不需要因为并行方式不同而改很多逻辑。

这种灵活性在混合云环境中尤其关键，因为不同环境（本地、云端、不同厂商硬件）之间的配置可能大不相同。

Hybrid TP+PP+EP+DP Deployment (MoE Model):

Pipeline Stage 1:               Pipeline Stage 2:              Pipeline Stage 3:
Node 1 (Attention Layers)       Node 2 (MoE FFN Layers)        Node 3 (Output Layers)
[Attn Part A] ←→ [Attn Part B]  [Router + Experts Subset]      [Out Part A] ←→ [Out Part B]
    GPU1           GPU2          GPU3: Experts 1-4                  GPU5            GPU6
         ↕ NVLink ↕              GPU4: Experts 5-8                       ↕ NVLink ↕
                                     ↕ NVLink ↕

Expert Distribution Detail (Node 2):
            [Router]
         GPU3  |  GPU4
        -------|-------
        Exp1   |  Exp5
        Exp2   |  Exp6  
        Exp3   |  Exp7
        Exp4   |  Exp8

Request Flow: → [Attention] → [MoE Layer/Router] → [Output] → Response
                              ↓
                    [Route to specific experts]

Parallelization Breakdown:
- Tensor Parallel (TP): Attention and Output layers split within nodes.
- Pipeline Parallel (PP): Different model stages across nodes .
- Expert Parallel (EP): MoE experts distributed across GPUs in Node 2.
- Data Parallel (DP): Entire pipeline can be replicated for more throughput.

更好的内存管理：KV-Cache（Key-Value 缓存）

在 LLM 推理中理解 KV-Cache

KV-Cache（键-值缓存）是 LLM 推理优化中最关键的特性之一。在注意力计算期间，模型必须访问先前 token 的表示 —— 随着序列长度增长，这个过程变得非常消耗内存。

高效的 KV-Cache 管理能决定同一硬件上能同时服务 10 个并发用户或 100 个并发用户，因为缓存复用将计算换成内存利用率。

(Q * K^T) * V computation process with caching

Step 1 (Prefill Phase)
                    Keys Transpose
                          ↓
    Queries              Keys              Values            Results
       |                  |                  |                  |
    [  Q  ]      ×     [  K  ]      →    [Scores]     ×    [  V  ]    →    [Output]
       |                  |                  |                  |
      64                 64                                    64              64
                          ↓                                     ↓
                    [Storing K]                           [Storing V]
                          ↓                                     ↓
                    ←── Cache memory (stores both K and V) ──→

Step N (Decode Phase)
                    Keys Transpose
                          ↓
    Query              Cached K            Cached V          Results
       |                  |                  |                  |
    [  q  ]      ×   [K₁...Kₙ]      →    [Scores]     ×   [V₁...Vₙ]   →    [output]
    (new)             (from cache)                         (from cache)       (new)
       |                  |                  |                  |
       1                 64                                    64               1
                          ↑                                     ↑
                    ←── Reading from cache (both K and V) ──→

Key Points:
- Prefill: Computes K and V for all input tokens, stores both in cache
- Decode: For each new token, reads ALL previous K and V values from cache
- Both K and V matrices must be cached (not just V)
- Cache size grows with sequence length

Prefill 阶段 vs Decode 阶段：两个截然不同的阶段

LLM 推理包含两个本质不同的阶段：

Prefill 阶段（Prompt 处理阶段）

• 并行处理所有输入 token。
• 计算密集型，GPU 利用率高。
• 为 prompt 中的所有 token 生成初始的 KV-Cache 条目。
• 延迟与 prompt 长度成正比。
• 大批量（larger batch sizes）带来好处。

Decode 阶段（Token 生成阶段）

• 一个 token 一个 token 顺序生成。
• 此阶段受限于内存带宽（memory-bandwidth bound）。
• 每新增一个 token，都要读取整个 KV-Cache 来自缓存的所有先前的 K 和 V。
• 延迟与输出 token 数量成正比。
• 依赖高效的缓存管理。

PagedAttention：vLLM 的内存革命

vLLM 引入 PagedAttention，这是一种在 KV-Cache 管理方面的突破性设计，它将 GPU 内存视为类似操作系统中的虚拟内存（virtual memory）来处理，其关键设计包括：

• 非连续存储（Non-contiguous Storage）：KV-Cache 块可以存储在 GPU 内存的任意地方，不必是连续的。
• 动态分配（Dynamic Allocation）：随着序列长度增长时才分配内存。
• 内存共享（Memory Sharing）：完全相同的 prompt 前缀（prompt prefixes）可以共享 KV-Cache 块。
• 几乎零浪费（Near-Zero Waste）：消除静态分配中常见的内部碎片问题。

这种设计让 vLLM 可以维持更大的批量大小、更高的并发性、以及比那些依赖静态、大型 KV-Cache 缓冲区的系统更好的 GPU 利用率。

连续批处理（Continuous Batching）：最大化 GPU 利用率

vLLM 的连续批处理机制带来了几个举措：

• 动态请求加入：新的请求可以在 decode 步骤之间加入正在运行的 batch。
• 提前完成处理：已经完成的序列立即释放资源。
• GPU 使用最优化：通过混合处理 prefill 与 decode 操作以保持高利用率。
• 支持抢占（Preemption）：可以暂停低优先级的请求以优先处理紧急请求。

在部署中的实际意义

这些内存管理上的创新在实际部署中带来了具体的效益：

1. 更高的并发性：在相同硬件上服务更多用户。
2. 更佳的成本效率：大幅减少基础设施需求。
3. 改善延迟：通过高效调度缩短 time-to-first-token。
4. 灵活性：可以处理变长的序列长度，而无需重新配置系统。

KV-Cache 优化在即将推出的 llm-d 分布式架构中变得尤为关键，因为高效的内存使用使得过去因内存约束而无法实现的新部署模式成为可能。

使用 llm-d 扩展：Kubernetes 原生的分布式推理

超越单服务器部署

虽然 vLLM 自身是高性能推理引擎，但在大规模生产环境中，还需要复杂的编排和智能请求调度。2025 年 5 月，红帽、Google Cloud、IBM 研究院、NVIDIA 和 CoreWeave 联手推出 llm-d，构建在 vLLM 之上的 Kubernetes 原生分布式推理栈。

llm-d 并不是 vLLM 的内置功能，而是一个补充的编排层。可以把它比作 Linux 与 Kubernetes 的关系：vLLM 负责推理引擎，llm-d 负责跨实例的调度与编排。它结合了三项开源技术：vLLM、Inference Gateway（AI 路由层）和 Kubernetes。

KServe 也在集成 llm-d，通过新的 LLMInference CRD，实现统一的服务接口，简化生成式 AI 的企业上手路径。

llm-d 将三大基础开源技术集成到一个统一的服务栈中：

• vLLM - 执行模型推理的高性能推理引擎。
• 推理网关（IGW） - 一个官方 Kubernetes 项目，通过 AI 感知路由扩展了 Gateway API。
• Kubernetes - 用于部署和扩展的行业标准编排平台。

通过整合这些技术，llm-d 使企业能够在混合云环境中大规模部署 LLM 推理，并实现最快的价值实现时间和极具竞争力的性价比。

三项关键创新

传统的负载均衡采用简单的轮询（round-robin）路由，对所有服务器一视同仁。llm-d 的 vLLM 感知调度程序能够做出智能决策，将请求路由到具有匹配缓存前缀的实例，根据实例是处理计算密集型预填充操作还是内存密集型解码操作来分配负载，并使用来自 vLLM 的实时可观测数据来避免实例过载，同时优先处理低延迟路径。这种智能路由可将基础设施成本降低 30% 到 50%，同时保持延迟 SLO。

解耦式服务（Disaggregated Serving）

llm-d 在生产规模上协调 vLLM 的本机分解服务（通过 KVConnector API），将预填充和解码分离到专门的工作节点中：

• 预填充工作节点：负责计算密集型的提示处理，使用高性能 GPU（如 H100、MI300X），并可根据需求独立扩展。

• 解码工作节点：专注于受内存带宽限制的 token 生成任务，使用具成本效益的 GPU（如 A100、L40S），并根据并发会话数进行弹性扩缩。

• KV 缓存传输：使用 NVIDIA NIXL 通过 UCX 提供高效的缓存移动，支持卸载到存储后端（未来交付）以及跨集群的全局缓存感知。

这允许适当规模的基础设施：昂贵的 GPU 仅用于预填充，成本优化的硬件可为数千个并发用户提供服务。

分布式前缀缓存（Distributed Prefix Caching）

llm-d 将 vLLM 的前缀缓存扩展到多个实例之间，通过两种方式实现：

• 本地缓存：在每个实例上将缓存卸载（offload）到内存或磁盘，几乎没有运维成本。

• 共享缓存（计划中）：通过实例之间的 KV 传输实现共享，并使用全局索引实现集群范围的缓存感知。

部署模式（Deployment Patterns）

llm-d 支持多种先进的企业部署模式：

• 异构硬件：根据工作负载混合 GPU 供应商和代数——用于预填充的高端 GPU、用于解码的成本优化 GPU 或用于低频请求的 CPU 集群。

• 动态扩缩：在高峰时段独立调整预填充容量，同时保持活动会话的稳定解码容量，并具有自动资源分配和故障转移功能。

• 地理分布（规划中）：在主数据中心部署集中式预填充工作者，并在用户附近部署边缘解码工作者，以实现低延迟响应。

多加速器与混合云支持

摆脱硬件锁定

AI 加速器快速演进，使市场变得多样化。专优化 NVIDIA 的方案如 TensorRT-LLM 虽然性能优秀，但容易导致锁定。vLLM 的硬件中立设计则允许用户自由选择最适合的加速器。

广泛硬件支持

vLLM 支持 NVIDIA GPU（针对 H100 进行一流的优化，支持 V100 及更新版本的所有 NVIDIA GPU）、AMD GPU（MI200、MI300 和 Radeon RX 7900 系列）、Google TPU（v4、v5p、v5e 和最新的 v6e）、AWS Inferentia 和 Trainium（trn1/inf2 实例）、Intel Gaudi（HPU）和 GPU（XPU）以及支持 x86、ARM 和 PowerPC vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。

这种广泛支持带来以下战略优势：

成本优化

• 选择 AMD MI300X，在特定工作负载下实现高性价比。
• 使用 AWS Inferentia，在 AWS 上进行经济高效的推理。
• 在低吞吐量用例中，可部署在现有 CPU 基础架构上。

供应链弹性

• 避免依赖单一 GPU 供应商的可用性。
• 通过多种选择协商更优惠的价格。
• 根据区域硬件可用性进行调整。

工作负载匹配

• NVIDIA H100 可实现最佳性能。
• AMD GPU 适用于开源部署。
• TPU 适用于 Google Cloud 部署。
• Intel Gaudi 适用于特定企业协议。

混合云部署模式

在企业级产品及解决方案中，vLLM 支持真正的混合云：

本地核心

• 在本地基础架构上处理敏感数据。
• 满足合规性要求的工作负载。
• 可预测的基线负载容量。

云爆发式扩展

• 利用云资源处理峰值负载。
• 试用新硬件（H100s、TPU v6e）。
• 无需基础设施投资即可实现地域扩展。

边缘推理

• 部署在适合边缘计算的硬件上。
• CPU 或更小的 GPU 推理。
• 与集中管理集成。

统一运维跨环境

借助企业级产品的相关功能，用户可从单一控制平面管理全部部署（公有云 + 私有云），主要从一下几个方面考虑。

• 单一控制平面：通过统一界面管理所有部署。
• 一致的 API：跨环境实现相同的应用程序集成。
• 统一监控：跨混合部署的聚合指标。
• 策略执行：一致的安全和合规策略。

模型生态与兼容性

支持广泛的开源模型体系

随着人工智能“淘金热”步伐的加快，vLLM 已发展到支持超过 100 种模型架构的高性能推理：涵盖几乎所有著名的开源大型语言模型（LLM）、多模态模型（图像、音频、视频）、编码器-解码器模型、推测解码模型、分类模型、嵌入模型和奖励模型。vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。与专注于有限模型系列的专业解决方案相比，这种全面的支持具有根本性的优势。

不只是传统 LLM

vLLM 的架构支持更多样的模型类型：

语言模型

• Llama 系列。
• Mistral 和 Mixtral 多模态模型。
• Google 的 Gemma 模型。
• IBM 的 Granite 系列。
• 阿里巴巴的 Qwen 模型。

多模态模型

• 视觉-语言模型（LLaVA, Qwen-VL）。
• 文档理解模型。
• 音频-语言模型。
• 视频理解能力。

专用架构

• 状态空间语言模型的生产支持，探索非 Transformer 语言模型的未来。vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。
• 混合专家（MoE）模型。
• 编码器-解码器架构。
• 嵌入和重排序模型。

模型集成简易流程

将新模型加入 vLLM 通常包括以下步骤：

1. 模型架构定义：使用熟悉的 PyTorch 模式实现。
2. Attention 后端集成：利用现有的优化内核。
3. Tokenizer 支持：兼容 Direct Hugging Face。
4. 配置映射：基于标准 YAML 的配置。

这样的标准化流程意味着组织能更快将新模型投入生产。例如，在 2025 年 8 月 GPT-OSS 发布后不久，vLLM 的 v0.11.0 版本就加入了对其生产部署的支持。

与 Hugging Face 生态整合

vLLM 与 Hugging Face 的原生兼容带来了便捷性：

直接模型加载

• 直接从 Hugging Face Hub 和/或兼容 S3 的对象存储后端（例如 MinIO）加载模型。
• 支持私有模型库。
• 自动权重转换处理。

分词器兼容性

• 使用现有的分词器实现。
• 支持自定义分词器。
• 快速分词器优化

配置保存

• 尊重特定于模型的配置。
• 支持自定义模型参数。
• 兼容经过微调的变体。

生产级模型管理

在一些企业级产品和方案中增加了模型生命周期的企业功能：

模型注册集成

• 已部署模型的版本控制。
• A/B 测试功能。
• 回滚机制。

模型监控

• 每个模型的性能跟踪。
• 使用情况分析和成本归因。
• 偏差检测功能。

面向未来的模型支持

模型创新速度极快，推理平台必须具备适应能力：

社区贡献

• 活跃的社区不断添加新模型。
• 供应商中立的开发流程。
• 快速集成突破性架构。

灵活的架构

• 模块化设计支持新的模型范式。
• 不受特定模型假设的约束。
• 为后转型架构做好准备。

企业验证

• 企业的测试和认证流程。
• 模型工件的安全扫描。
• 跨硬件性能验证。

这种全面的模型支持确保组织能够在新模型出现时立即采用它们，而无需进行平台迁移或架构更改，这是人工智能领域持续快速发展的一项关键能力。

使用企业级产品进行企业部署

从第一天起就是生产级

大多数企业级产品提供了一个灵活、可扩展的 MLOps 平台，提供构建、部署和管理 AI 应用的工具。它采用开源技术构建，为团队提供值得信赖且操作一致的功能，用于实验、模型服务和交付创新应用。了解更多关于企业级产品如何应对这一挑战的信息。

与 KServe 的整合：智能模型服务

在许多产品和方案中对 vLLM 与 KServe 的集成提供了企业级服务功能：

GenAI 功能

• 使用 vLLM 服务运行时进行多节点/多 GPU 推理。
• 通过 vLLM + LMCache 集成卸载键值缓存。
• 通过模型缓存高效重用模型。
• 集成 KEDA，允许基于外部指标自动扩缩。
• 通过与 Envoy AI Gateway 集成实现速率限制和请求路由。
• 通过 LLMInferenceService CRD 访问 llm-d 功能。

高级自动扩缩

• 基于请求的扩缩，实现资源利用率优化。
• 缩减​​至零功能，实现成本优化。
• 基于流量模式的预测性扩缩。
• 多指标扩缩（GPU 利用率、队列深度、延迟）。

流量管理

• 金丝雀部署，确保模型更新安全。
• 蓝绿部署，实现即时回滚。
• A/B 测试，用于模型比较。
• 影子流量，用于验证。

服务网格集成

• 使用 Istio 进行端到端加密。
• 高级路由和负载均衡。
• 熔断和重试逻辑。
• 用于调试的分布式跟踪。

自动化运维

• 健康检查和自动恢复。
• 资源优化建议。
• 自动化证书管理。
• 日志聚合和分析。

安全与合规

在企业部署中，必须重视安全：

访问控制

• RBAC 与企业身份提供商集成。
• 模型级访问权限。
• API 密钥管理。
• 所有操作的审计日志记录。

数据保护

• 静态和传输中加密。
• 私有端点选项。
• 网络策略实施。
• 合规性报告工具。

供应链安全

• 签名容器镜像。
• SBOM（软件物料清单）生成。
• 漏洞扫描。
• 基于策略的部署控制。

MLPerf 验证的性能

一些企业级解决方案和产品与众多知名服务器原始设备制造商（OEM）合作，使用搭载 NVIDIA GPU 和 vLLM 推理运行时的产品发布了令人印象深刻的 MLPerf 推理结果，在应对这一挑战方面取得了重大进展。加速生成式 AI 的采用，这些结果验证了：

• 规模化生产级性能。
• 高效的资源利用率。
• 负载下一致的延迟。
• 多实例协调能力。

集成可观测性

无需额外工具即可进行全面监控：

指标和仪表板

• 预建 Grafana 仪表板，用于 vLLM 指标。
• 预建 Grafana 仪表板，用于驱动路由决策的请求调度程序指标。
• 令牌生成率和延迟。
• GPU 利用率和内存使用率。
• 队列深度和拒绝率。

警报和响应

• SLA 违规自动警报。
• 与企业监控系统集成。
• Runbook 自动化功能。
• 容量规划洞察。

成本管理与优化（未来交付）

专为企业成本控制设计的功能：

• 计费/显示：按团队或项目跟踪使用情况。
• 资源配额：防止成本失控。
• 竞价型实例支持：降低批量工作负载的成本。
• 空闲检测：自动缩减未使用的资源。

这个企业级平台将 vLLM 从高性能推理引擎转变为完整的生产解决方案，可用于关键任务部署。

特性对比：vLLM vs TGI vs TensorRT-LLM

✓ = 全面支持，◐ = 部分/有限支持，✗ = 不支持

企业级产品与开源 vLLM 的主要区别

• 硬件灵活性：最广泛的加速器支持，包括 AMD、Intel、Google TPU 和 CPU。
• 模型生态系统：支持超过 100 种模型架构，而其他替代方案仅有 25-40 种。
• 分布式架构：即将推出的 llm-d 支持分解式预填充/解码和系统级 kv-cache 路由，以实现分布式最优扩展。
• 企业集成：企业级产品集成 KServe 自动扩展。
• 内存效率：先进的 PagedAttention 和 KV-Cache 管理。
• 开放开发：PyTorch 基金会项目，社区创新迅速。

如何作出正确选择

文中给出一个简单的决策框架：对每个判断点打 “Yes”：

• 0–2 个 “Yes”：可考虑专用方案（若其满足你的特定需求）
• 3–5 个 “Yes”：vLLM 在你的场景中将提供显著优势
• 6+ 个 “Yes”：基于 vLLM 的企业级产品是战略性选择

每个决策点都涉及基本的架构约束：

• 灵活性要求决定您是否需要与硬件无关的解决方案。
• 运营复杂性评估简化的运营是否值得采用开源技术。
• 模型与创新评估快速发展是否需要一个适应性强的平台。
• 长期可持续性考虑总体拥有成本和战略风险。

战略推荐

如果你对多个维度都倾向 “Yes”，那 vLLM + 企业级产品将提供：

• 最大的灵活性：可在任何受支持的硬件上部署。
• 优秀的运维体验：企业级平台，复杂性极低。
• 面向未来的能力：支支持新兴模型和架构。
• 成本优化：为每种工作负载选择最佳硬件。
• 风险控制：开源基础，提供企业级支持。

这些因素的融合使得 vLLM 成为构建可持续人工智能基础设施的组织的战略选择。

采纳步骤建议

立即阶段

• 在开发环境部署 vLLM + 企业级产品
• 用自己的模型和工作负载进行测试
• 验证硬件灵活性与性能

短期阶段

• 实施 KServe 的自动扩缩能力
• 建立监控与可观察性体系
• 培训团队操作流程

中期阶段

• 设计生产部署架构
• 若需要，实施混合云模式
• 为 llm-d 分布式架构做准备

长期阶段

• 优化成本（选硬件、资源调度）
• 引入更高级部署模式
• 将自己的改进贡献给社区

总结

选择 LLM 推理平台代表着一项战略承诺，它将影响您组织未来几年的人工智能能力。

我们的分析表明，企业级产品上的 vLLM 独特地满足了企业 LLM 部署的三个关键要求：

1. 灵活性：可在任意硬件与混合云环境部署
2. 可扩展性：先进内存管理与 llm-d 架构使资源利用效率提升 10–100 倍
3. 可持续性：开源基础 + 企业支持，避免陷入锁定

虽然 TensorRT-LLM 提供了 NVIDIA 专属优化，TGI 也提供了 Hugging Face 集成，但“只有 vLLM 能够提供快速发展的 AI 领域所需的架构灵活性”。 凭借对 100 多种模型架构的支持、与硬件无关的设计以及 PyTorch 和 Linux 基金会的支持，->“搭载 vLLM 的企业级产品为长期成功奠定了最坚实的基础”。

• 模型参数（Parameters, P）动辄上百 GB，需要长期驻留显存。
• 输入/输出数据（Data, D）则随请求动态变化，但往往和参数耦合在同一设备上，导致显存占用不均衡，扩展性受限。

为了解决这一问题，可以借助 vLLM 框架实现参数 / 数据（P/D）分离，提升推理系统的灵活性和吞吐。

大模型推理的资源瓶颈

以一个 70B 规模的 Transformer 模型为例：

• 参数权重（FP16 存储）约需 140GB 显存；
• 每次请求输入的序列数据、KV Cache 会消耗额外显存，并随 batch size 增长而急剧膨胀。

如果不加区分地将 P 与 D 放在同一块 GPU：

1. 参数长期驻留，挤压了用于动态数据的显存；
2. 多实例并发时，数据显存不足，限制了吞吐。

因此，在分布式推理系统中，业界逐渐采用 参数与数据分离（P/D Separation） 的架构思路。

vLLM 简介

vLLM 是一个高性能的大模型推理引擎，核心优势包括：

• PagedAttention：高效管理 KV Cache，支持大批量并发；
• 高吞吐率：相较于 Hugging Face Transformers 推理，吞吐提升数倍；
• 灵活的分布式支持：可结合 DeepSpeed、Megatron 等方案，支持参数/数据分布式存储与调度。

vLLM 的模块化架构，使其天然适合实现 P/D 分离。

P/D 分离的实现思路

在 vLLM 中，推理流程大致分为两个部分：

1. 参数侧（P）

   • 模型权重加载与存放；
   • 可通过 ZeRO-3 / Tensor Parallel 等策略将参数分布在多 GPU 节点上；
   • 参数在整个推理生命周期中保持常驻，不随请求波动。

2. 数据侧（D）

   • 动态输入序列、KV Cache、采样状态等；
   • 可使用 PagedAttention 管理显存分页；
   • 支持把部分 KV Cache 放到 CPU/Host 内存，再动态迁移到 GPU。

核心机制

其核心机制是显存资源隔离：

• 权重（P） 固定驻留在专门的 GPU（参数节点）；
• 数据（D） 可以按需分配到其他 GPU（数据节点），甚至利用 CPU 内存 / NVMe。

这样：

• 参数显存不与动态数据抢占空间；
• 数据可以根据请求动态扩展，提升并发能力。

在 vLLM 中的实现路径

实现 P/D 分离的常见方法：

1. 参数分片（Parameter Sharding）

   • 借助 vLLM 对 Megatron-LM / DeepSpeed 的支持，将模型参数按张量维度切分到多 GPU；
   • 仅在推理计算时聚合，不需要在每个设备上完整存放参数。

2. KV Cache 分离（Data Sharding）

   • 通过 vLLM 的 PagedAttention，可以把 KV Cache 存在独立的 GPU 或 Host 内存；
   • 在推理过程中按需调页，类似操作系统的虚拟内存机制。

3. Pipeline 并行化

   • 将模型计算划分为不同阶段，前几层专门占用参数节点，后几层在数据节点完成；
   • 在流水线中，数据逐层传递，而参数保持分片驻留。

基于 vLLM 的 P/D 分离实战

下面给出两部分内容：

• 配置示例：如何在多 GPU 环境下指定参数和数据分布；
• 代码示例：如何加载模型并运行推理，展示参数常驻、数据动态分配。

配置示例

假设我们有 4 张 GPU：

• GPU 0,1：专门存放模型参数（P）；
• GPU 2,3：主要承载 KV Cache 等动态数据（D）。

我们可以在启动 vLLM 时设置：

CUDA_VISIBLE_DEVICES=0,1,2,3 \
python -m vllm.entrypoints.api_server \
    --model /path/to/llama-2-70b \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.85 \
    --enable-chunked-prefill \
    --enforce-eager \
    --kv-cache-dtype fp16 \
    --max-num-batched-tokens 4096

这里的关键点：

• --tensor-parallel-size 2：只在 GPU 0,1 上做参数分片存放；
• --gpu-memory-utilization：控制参数占用的比例，留出余量给数据；
• --kv-cache-dtype fp16：降低 KV Cache 精度，减少数据显存占用；
• vLLM 内部的 PagedAttention 会自动把 KV Cache 分配到 GPU 2,3，如果溢出则回退到 CPU 内存。

代码示例

下面是一个 Python 调用示例：

from vllm import LLM, SamplingParams

# -------- 参数（P）分离 --------
# tensor_parallel_size=2 表示参数分布在前两张 GPU（0,1）
llm = LLM(
    model="/path/to/llama-2-70b",
    tensor_parallel_size=2,
    gpu_memory_utilization=0.85,
    enforce_eager=True,       # 避免显存碎片
    enable_chunked_prefill=True,
    kv_cache_dtype="fp16"     # 数据（D）使用更轻量的缓存精度
)

# -------- 数据（D）分离 --------
# PagedAttention 会自动管理 KV Cache 的存放位置（GPU2, 3, 甚至 CPU 内存）
sampling_params = SamplingParams(
    temperature=0.8,
    top_p=0.95,
    max_tokens=256
)

prompt = "解释一下通过 vLLM 实现 P/D 分离的好处。"

# 运行推理
outputs = llm.generate([prompt], sampling_params)

print("模型输出：")
for output in outputs:
    print(output.outputs[0].text)

验证方式

运行时可以用 nvidia-smi 观察：

• GPU 0,1 显存几乎恒定，主要承载参数；
• GPU 2,3 的显存随请求数量/序列长度波动，主要承载 KV Cache；
• 如果输入过大，KV Cache 会溢出到 CPU 内存，但仍可继续推理。

实际效果与收益

通过 P/D 分离，可以得到以下好处：

• 提升 GPU 利用率：参数和数据分工明确，避免显存冲突；
• 支持更大 batch size：数据显存可扩展，吞吐率提升显著；
• 降低成本：参数可驻留在高端 GPU，而数据可放到中低端 GPU 或 CPU 内存，形成分层存储；
• 灵活性：适配多种硬件资源组合（A100 + H100, GPU + CPU, GPU + NVMe）。

在实践中，结合 vLLM 的 PagedAttention，P/D 分离的效果尤为明显，可让大模型推理在同样硬件下实现 数倍并发提升。

总结

vLLM 框架凭借其高效的 KV Cache 管理和分布式能力，为 大模型推理的 P/D 分离 提供了坚实基础。 通过将 参数（P） 和 数据（D） 解耦，可以更好地利用硬件资源，提升推理性能与扩展性。

未来，随着 混合精度存储、分层缓存（GPU+CPU+NVMe） 的发展，P/D 分离架构将逐渐成为大模型推理的主流范式。

VibeVoice 是 Microsoft Research 发布的一套面向长篇、多说话人、对话式语音合成的研究框架，目标场景例如整集播客、有声剧或访谈：能在单次生成中维持说话人一致性并处理自然的换手（turn-taking）。模型家族包含多个规模（例如 1.5B、7B 等），并在 Hugging Face 上以 microsoft/VibeVoice-1.5B 形式开放（模型卡、模型文件、model card 中有安装/使用与责任使用说明）。

它解决了传统 TTS（Text-To-Speech）系统的一些痛点，比如：

• 难以维持长时间对话的语音一致性（speaker consistency）；
• 多说话人的切换自然性（turn-taking）差；
• 效率低 — 长文本 + 多说话人时，资源消耗大。

核心创新与架构

VibeVoice 有几个比较新的或者关键的技术设计：

架构图如下：

优点和局限

优点

1. 长篇幅对话能力 — 能生成近 90 分钟的连续对话，并维持说话人一致性。
2. 多说话人支持 — 最多支持 4 个不同说话人的切换，且对话流程自然。
3. 压缩效率高 — 用 7.5 Hz 帧率的 speech tokenizer，音频被高度压缩但仍保证质量。
4. 语义 + 声学分离 — 语义 tokenizer（semantic）负责内容，声学 tokenizer（acoustic）负责声音细节，两者协同。

局限

1. 语言支持有限 — 目前主要是英语与中文，跨语言能力还在研究中。
2. 背景音乐 / 音效不支持 — 当前专注纯语音合成，没有加入背景音或重叠说话人（speaker overlap）。
3. 仓库暂时关闭 — 官方声明因 “部分用途超出初衷 / 不符合责任使用” 的情况，仓库暂时被 disable。意味着可能无法立即拿到源码或全部功能。
4. 硬件要求 / 资源消耗 — 虽然压缩效率高，但生成长篇语音 + 多说话人 + 高保真度仍需要较好的 GPU 资源。
5. 潜在滥用风险 — 用来做语音克隆、假扮、deepfake 等可能的恶意用途。官方在文档中也提到要谨慎。

快速上手

下面给出具体实现步骤及上手流程。注意：由于官方仓库目前不包含完整脚本，实际推理通常依赖社区实现或 Hugging Face Spaces / Colab 示例。所列步骤已参考 Hugging Face 模型页与社区示例仓库。

先决条件

• Python 3.8+；建议在隔离虚拟环境（venv / conda）中操作。

• GPU：带 CUDA 的 NVIDIA GPU（具体 VRAM 与性能见第 5 节）。若使用 Apple Silicon / macOS，可参见社区讨论与专门脚本。

• 安装工具（示例）：

  • pip install huggingface_hub transformers accelerate torch soundfile torchaudio numpy einops
  • 本地需要 ffmpeg（用于音频切分/拼接与格式转换）。

  具体版本请按 PyTorch 官网或社区脚本说明选择（不同 CUDA 版本的 wheel 不同）。参考社区仓库的 requirements 列表以确保兼容。

下载模型权重

from huggingface_hub import snapshot_download
model_dir = snapshot_download("microsoft/VibeVoice-1.5B")
print("模型已下载到", model_dir)

注意：snapshot_download 会把 HF 模型文件和模型卡同步拉取到本地；若模型文件较大，请确保磁盘与网络条件。

使用社区推理脚本

很多社区仓库或 Hugging Face Spaces 提供了 demo/inference_from_file.py 之类的脚本。示例命令：

# 在 Colab / 本地环境中操作
git clone https://huggingface.co/technicalheist/vibevoice-1.5b
cd vibevoice-1.5b
# 安装 Python 依赖（按模型页 “Requirements” 部分）
pip install torch transformers soundfile ffmpeg-python  # plus 其他必要包

# 创建一个 transcript 文件，比如 transcript.txt
echo "Speaker 1: Hello, how are you doing?
Speaker 2: I'm good, thanks. What about you?" > transcript.txt

# 用 demo 脚本生成语音
python demo/inference_from_file.py \
  --model_path /path/to/technicalheist/vibevoice-1.5b \
  --txt_path transcript.txt \
  --speaker_names "Alice,Bob"

社区实现（例如 technicalheist/vibevoice-1.5b、shijincai/VibeVoice 等）提供了可运行的示例与依赖说明；使用前请仔细阅读其 README 并依据其中的依赖和指引来配置环境。示例脚本名与参数在不同实现中可能不同，请以具体仓库中的文档为准。

简单示例

Speaker 1: Hello, welcome to our podcast.
Speaker 2: Thanks — happy to be here. Let's talk about VibeVoice.
Speaker 1: Sure, start with the key idea...

将上面保存为 transcript.txt 并传入 --txt_path 即可（脚本会解析说话人标记并输出对应音轨）。社区脚本通常会把每个说话人的音色/说话风格作为参数或示例内置。

结论

微软的 VibeVoice 是当前 TTS / 语音合成领域一个非常令人兴奋的进展。它在长篇幅语音 + 多说话人上取得了突破，尤其是在对话流畅性和说话人一致性方面，技术设计（如低帧率的双 tokenizers + next-token diffusion + LLM 架构）也很前沿。

如果你正在做播客、有声书或者对话剧本的语音合成，这可能是一个非常有用的工具／研究基础。不过在商业部署或者包含敏感语音身份／法律边界用途时，需要格外注意责任使用，以及是否有完整的许可与风险评估。