微软 Decision-1 深度拆解：83.5% 准确率背后的开源底座，以及“能不能本地部署”这个真问题

2026 年 10 月 10 日凌晨 2:37（北京时间），Satya Nadella 在 X 上发了一张对比图动画，配文只有一句："Introducing Microsoft-Decision-1, our new model for fast decision-making."

图里有六个模型、三个指标。Microsoft-Decision-1 准确率 83.5% 排第一、中位延迟 85 毫秒排第一、校准度 92.2 排第二。对手包括 JevBench 榜单第一的 Quyet-1.0-Large、以及 3.01 秒延迟的 GPT-6 Sol。

但真正扎眼的不是这张图，而是底座那一行小字：Alibaba 开源权重 Qwen3.5-9B。

于是本文要回答两个问题：它到底是什么；以及——能不能本地部署？

先说结论

问题	结论
Microsoft-Decision-1 能本地部署吗	不能。官方只有托管 API，模型权重未分发，Hugging Face 上搜不到
那能本地跑什么	同定位的开源决策模型：H2O-Lightning-4B（4.5B，Apache-2.0，JevBench 开放权重第一）、Quyet-1.0 系列（31.3B/4.66B/328M/183M）
自己拿 Qwen3.5-9B 复刻一个 Decision-1	技术上可行（Apache-2.0 允许），但拿不到微软的后训练数据和校准参数，大概率达不到 83.5%
什么场景必须用托管版	需要官方 SLA、GA 合同条款、审计合规背书时；且要先解决"标签写 GA、条款链接却指向 preview"的矛盾
怎么调用	不走 OpenAI 兼容端点，用 OpenRouter Decisions API：`POST https://openrouter.ai/api/alpha/decisions`，模型 `microsoft/microsoft-decision-1`
对你的实际价值	$0.042/百万输入 token、输出免费，1 万条 500 token 请求约 $0.21；比 GPT-6 Sol 快 35 倍

一、决策模型（Decision Model）到底是什么

先把这个品类说清楚，否则后面的数字都没有参照系。

普通大模型的交互方式是"你问一句、它写一段字"，你再想办法把这段字解析成结构化数据。而决策模型跳过生成环节：给它一个状态（state）和一组固定的选项，它一次性为每个选项输出一个校准过的概率，不生成任何文字。

微软官方给的调用形态大致是：

输入：state（任意文本/JSON/对话）
      questions（类型化问题）
        - choice:  从多个标签里选一个
        - noul:    判断某个陈述是否为真
        - score:   在有序量表上打分
输出：JSON，每个选项的概率 + confidence

这里最关键的一个词是校准（calibrated）。它决定了分数能不能拿去自动决策：

如果模型输出的是	意味着	能不能自动执行
排序分数（rank score）	只是"在这次比较里相对更优"，数值本身无意义	❌ 不能，得自己定阈值
校准概率	说 90% 的时候，大约真的对 90%	✅ 能。>90% 自动处理，<60% 转人工

微软在这一点上做了专门测试：校准度 92.2 分排第二，落后 Quyet-1.0-Large 的 93.1 约 0.9 分。这个"第二"很关键——它在准确率和速度上都第一，却在最重要的"概率可信"这一项只排第二。下面是完整对比：

模型	参数量	平均准确率（36 项）	中位延迟 p50	校准度
Microsoft-Decision-1	未公开（底座 9B）	83.5%	85 ms（p95 125 ms）	92.2（第 2）
Quyet-1.0-Large	31.3B	81.9%	380 ms	93.1（第 1）
Surogate Rune 26B-A4B	26B-A4B	79.7%	380 ms	91.8
GPT-6 Luna Decisions	未公开	79.4%	300 ms	89.9
deck-31B	31B	77.8%	400 ms	83.5
H2O-Lightning-4B v1.1	4.5B	77.2%	210 ms	91.8
Jev 1.13.0	未公开	未评分	240 ms	未评分
Strands-Decider 2B（AWS）	2B	54.8%（仅测 23 项）	未测	未评分
GPT-6 Sol（参考）	未公开	未评分	3.01 s	未评分

数据来源：微软官方博客图表，JevBench v1.6 口径（读数 2026-10-07/10-09）

微软给的理由很实在：每加 100 毫秒延迟，20 步串行决策就多等 2 秒。对工单路由、审核分级、检索排序这类"每请求要判断几十次"的场景，延迟是结构性的，不是锦上添花。

二、⚠️ 关于"快 35 倍"，有三个必须知道的坑

这是这条新闻最容易被误读的部分，微软自己的图表里其实标了注，但没人看：

坑一：延迟不是同一套测法。 图注写得很清楚：对手的延迟取自 JevBench 的校正后中位数（10 月 7 日），而 Microsoft-Decision-1 是微软自己在 Foundry 同区域实测的。两边测法不完全一致。独立分析给出的换算是：按原始计时，与亚军差距约 1.4 倍，不是 4.5 倍。35 倍对 GPT-6 Sol 的差距也是同理。

坑二：没有任何独立复现。 截至 2026-10-09 22:30（英国时间），第三方核查的结论是： - JevBench 官方榜单 v1.6.1 结果文件、v1.6.2 页面当时都没有 Decision-1 的行 - Artificial Analysis、Vals AI 都没有该条目 - OpenRouter 公开模型列表（458 个）在 10-09 22:28 BST 快照时也没有它的条目（注意：这是快照时点状态，官方博客现已确认 OpenRouter 上线，见第五章） - 多篇报道明确指出：这些数字全是微软自己测的，且"公告未提供复现该对比所需的完整数据集与延迟测试条件"

坑三：GA 标签和条款链接自相矛盾。 Foundry 目录页的 Quick facts 写 "Generally available (GA)"，但 License 标签页指向的是 Azure 的 preview supplemental terms（链接路径明确以 preview-supplemental-terms 结尾）。这是微软同一页面上的两处自相矛盾。采购或法务评审应当在进生产前，要求微软书面确认适用哪套条款——这句话不是我说，是核查报告给采购/法务读者的建议。

其他需要打问号的地方： - 参数量未公开，只说了底座是 9B 的 Qwen3.5-9B - 训练数据只有区间：1B–1T tokens，具体数据集清单和截止日期没给 - 训练时间 2026 年 9 月到 10 月 - 区域只有一个：Global Standard / WESTCENTRALUS，无 Data Zone、EU、UK 部署 - 语言：针对英语优化，在另外 22 种语言上做了评估，但没给分语种成绩

三、本地部署：直接给答案

Microsoft-Decision-1 本体：❌ 不能本地部署

这是本文最重要的一段。逐条给证据：

查证项	结论
Foundry 模型卡原文	"is available through a hosted API in Microsoft Foundry"
模型权重	Not distributed（不分发）
自有租户 / 离线运行	模型卡明确列为"未提供"
Hugging Face 搜索	搜不到 Decision-1 权重
第三方核查方判定	"Treat it as a hosted model"（按托管模型对待）
开源底座 ≠ 开源产物	Qwen3.5-9B 是 Apache-2.0，但微软基于它做出来的 Decision-1 是闭源 API

"开源底座进、闭源服务出" —— 这是一笔算得很顺的账。许可协议不看出身，底座开源不构成成品开源的义务。有第三方评论把这层关系说得更直白：微软是 OpenAI 最大的外部靠山，自家 MAI 系列也在迭代，而阿里云与 Azure 在云市场贴身竞争——但这场"合作"没有任何签约仪式，全靠一条开源许可证撮合。

那么能本地跑什么？三条路

路线 A：直接用同定位的开源决策模型（推荐）

这是最实用的路径。决策模型这个赛道开源生态已经很成熟，而且接口形态高度统一——都叫 TypeSafe /v1/systemone，意味着上层代码基本不用改，只换模型名。

模型	参数	底座	许可	本地部署门槛	JevBench 位置
H2O-Lightning-4B	4.5B	Qwen3.5-4B	Apache-2.0	单卡 16GB 起步（4-bit 量化约 2.7GB）	开放权重第一（v1.6.1 综合分 72.5）
Quyet-1.0-Large	31.3B	Gemma-4-31B-it	Apache-2.0	bf16 需 80GB GPU；GGUF 4-bit 约 18.8GB	榜单第 1（71.4）
Quyet-1.0-Medium	4.66B	Qwen3.5-4B	Apache-2.0	单卡消费级可跑	—
Quyet-1.0-Small / Tiny	328M / 183M	encoder	Apache-2.0	CPU 即可	—

H2O-Lightning-4B 的几个数字值得单独说：

指标	H2O-Lightning-4B v1.1	Jev 1.13.0（托管参考）	Quyet-1.0-Large
综合分	72.5	71.5	71.4
校准度	60.0	63.6	73.4
速度分	90.0	90.6	90.0
每 1000 次决策成本	$0.021（估）	$0.032	$0.045（估）

4B 的模型，打过了 31B 的模型。 H2O 自己的解释是：31B 那批在原始智力上领先，但这个 4B 用一小部分成本和延迟追平了它们的校准度。注意这里的取舍——H2O 的校准度 60.0 明显低于 Quyet 的 73.4，如果你的场景对概率可信度要求极高（比如直接决定放款额度），Quyet 31B 才是更稳的选择，但要多付 3 倍硬件成本。

它的部署路径是未经修改的 vLLM 0.30.0 + 一个标准库 shim：

pip install "vllm==0.30.0+cu129" "torchcodec==0.16.0+cu129" \
  --extra-index-url https://wheels.vllm.ai/0.30.0/cu129 \
  --extra-index-url https://download.pytorch.org/whl/cu129

hf download h2oai/h2o-lightning-4b --revision v1.2.1 --local-dir h2o-lightning-4b

# 起 vLLM，再起 shim，bash serve.sh 可一步到位
bash h2o-lightning-4b/serve.sh

# 预热到返回 HTTP 200
curl -s http://127.0.0.1:8741/v1/systemone \
  -H 'Content-Type: application/json' \
  -d '{"state":"warm-up","questions":{"decision":{"type":"noul","instructions":"Is this a warm-up?","criteria":{"true":"yes","false":"no"}}}}'

真实性能参考：H100 上标准档 p50/p95 为 0.038/0.047 秒，平均每次决策输入 654 token；一张 RTX PRO 4500 Blackwell（32GB）上跑三个实测——1000 条理赔分诊（32 条一批）63 秒、8 个浏览器对 192 家供应商 145 秒全对。

路线 B：拿 Qwen3.5-9B 自己复刻

技术上完全可行——Apache 2.0 允许商用和改版。但要清醒认识你要补的差距：

你要做的	难度	说明
跑起基座	✅ 简单	见下方规格
加"选项打分"输出头	⚠️ 中等	Quyet 的做法是读选项字母（A/B/C）的 next-token 概率，配温度校准
复现校准	❌ 难	这是微软没公开的核心资产，JevBench 上 Quyet 校准 86.9 / H2O 60.0 / Decision-1 92.2，差距极大
复现 36 项盲测成绩	❌ 做不到	没有它的后训练数据和评测集

Qwen3.5-9B 本身的本地部署条件（这是基座，不是 Decision-1）：

精度	权重	运行时内存需求	最低配置
BF16	19.3 GB	~23.2 GB	单卡 24GB（如 RTX 4090 / A5000）
8-bit	9.7 GB	~11.6 GB	单卡 12GB（如 RTX 3060 12G）
4-bit	4.8 GB	~5.8 GB	RTX 3060 12G / 4060Ti 16G 绰绰有余，8GB 卡也行

模型规格：9.7B 参数、262,144 token 原生上下文（RoPE 扩展可到 1M+）、248K 词表、201 语言、Gated DeltaNet + Gated Attention 混合架构、原生工具调用。GGUF 量化版在 Hugging Face 上有 bartowski 等多个量化源：

# llama.cpp 路径（推荐，量化后 6GB 上下）
huggingface-cli download bartowski/Qwen_Qwen3.5-9B-GGUF Qwen3.5-9B-Q4_K_M.gguf
./llama-cli -m Qwen3.5-9B-Q4_K_M.gguf -ngl 99 --jinja

# Ollama 路径（最省事）
ollama pull qwen3.5:9b

# vLLM 路径（生产）
vllm serve Qwen/Qwen3.5-9B-Instruct --max-model-len 131072 --tensor-parallel-size 1 --dtype auto

补充一点：llama.cpp 从 b9180 版本起支持 MTP 推测解码，Qwen3.5-9B 的 GGUF 已内置 MTP 层，用 --spec-type draft-mtp 可以进一步加速。

路线 C：CPU 上跑小号决策模型

如果你的场景只是想给几百上千条记录做分类，不追求高并发：

Quyet-1.0-Small（328M）/ Tiny（183M） 是 encoder 架构，CPU 即可运行
Quyet 全家族通过一个 pip install quyet 的包提供，接口统一，支持 device="cpu"
限制要记住：编码器读 8,192 token；LLM 版本保留 6,000 token 状态；每题最多 10 个选项（超出会被拒绝而非截断）

pip install quyet
python -c "
import quyet
m = quyet.load('chinhnc/Quyet-1.0-Small')
r = m.predict(
    {'message': 'Please close my card, I lost it yesterday.'},
    {'intent': {'type':'choice','instructions':'What does the customer want?',
                'criteria':{'cancel':'close the card','limit':'change the limit','other':None}},
     'mood': {'type':'score','instructions':'How upset is the customer?',
              'criteria':['calm','annoyed','angry']}},
)
print(r['answers'])
"

⚠️ Quyet 作者自己的免责声明：该模型未经安全、偏见或对抗鲁棒性评估，不得作为高风险决策的唯一控制手段。 这句话同样适用于微软和 H2O 的模型——所有决策模型都是。

四、成本对比：本地 vs API

假设场景是"每天 50 万次决策，每次输入 650 token"（H2O 实测的平均值）：

方案	月成本	一次性硬件	说明
Decision-1 托管	≈$11.9	0	50万 × 650 token = 32.5 亿 token/月 × $0.042/百万，输出免费
Jev 1.13.0 托管	≈$22.4	0	$0.032/千次决策 × 50 万次
自建 H2O-Lightning-4B	电费 + 折旧	约 ¥3000–8000（单卡 16GB 级）	32.5 亿 token/月在单卡 16GB 上可行
自建 Quyet-1.0-Large	电费 + 折旧	需 24GB+ 双卡或量化方案	硬件成本约为上一项 3 倍

算术我自己做的，不是官方案例。在中小流量下，本地部署的经济性并不突出——Decision-1 的 $0.042 定价已经低到"自己买卡不如付 API"。本地部署真正的理由是另外三个：

数据主权：敏感数据不出内网。这是国网场景下最硬的理由。
无单次调用上限：批量处理不受配额约束。
可微调：可以在自己的历史标注数据上继续训练。

如果第一条是你的主要诉求，那直接看路线 A 的 H2O-Lightning-4B，别绕微软。

五、怎么调用：三个最容易踩的坑

⚠️ 坑一：它不走 OpenAI 兼容端点

这是 99% 的人会栽的地方。/v1/chat/completions 对它无效——它不生成文本。OpenRouter 文档写得很明确：

It runs on the OpenRouter Decisions API rather than the OpenAI-compatible chat endpoint, so the request and response shapes below are specific to structured decisions — chat completions SDKs will not work with it.

也就是说，你用 OpenAI SDK、LangChain 的 ChatOpenAI、LiteLLM 的 completion() 去调，全部会失败。

端点与模型标识

项目	值
端点	`POST https://openrouter.ai/api/alpha/decisions`
模型标识	`microsoft/microsoft-decision-1`
认证	`Authorization: Bearer $OPENROUTER_API_KEY`
可选请求头	`HTTP-Referer`（站点 URL）、`X-Title`（站点名，仅用于上榜统计）
上下文	33K
单提供方	Azure（OpenRouter 直连，不做路由）

cURL 最小可运行示例

export OPENROUTER_API_KEY=sk-or-v1-...

curl -s https://openrouter.ai/api/alpha/decisions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "microsoft/microsoft-decision-1",
    "state": "Help! My payouts have been failing for 3 days.",
    "questions": {
      "is_urgent": {
        "type": "noul",
        "instructions": "Does this message convey urgency?",
        "criteria": { "true": "Explicitly time-sensitive", "false": "No urgency expressed" }
      },
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "Payments, invoicing, refunds",
          "technical": "Bugs, outages, integrations",
          "sales": "Pricing, upgrades, new accounts"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "How frustrated is the customer?",
        "criteria": ["Calm", "Frustrated", "Very angry"]
      }
    }
  }'

Python（TypeScript SDK 同理）

from openrouter import OpenRouter

client = OpenRouter(api_key="<OPENROUTER_API_KEY>")

decision = client.alpha.decisions.create(
    decisions_request={
        "model": "microsoft/microsoft-decision-1",
        "state": "Help! My payouts have been failing for 3 days.",
        "questions": {
            "is_urgent": {
                "type": "noul",
                "instructions": "Does this message convey urgency?",
                "criteria": {"true": "Explicitly time-sensitive",
                             "false": "No urgency expressed"},
            },
            "department": {
                "type": "choice",
                "instructions": "Which team should handle this?",
                "criteria": {"billing": "Payments, invoicing, refunds",
                             "technical": "Bugs, outages, integrations",
                             "sales": "Pricing, upgrades, new accounts"},
            },
            "frustration": {
                "type": "score",
                "instructions": "How frustrated is the customer?",
                "criteria": ["Calm", "Frustrated", "Very angry"],
            },
        },
    }
)

a = decision.answers
# noul 返回 0(否)~1(是) 的概率；choice/score 携带完整分布
if a["is_urgent"].noul > 0.8 and a["department"].choice == "billing":
    escalate_to_billing()   # 阈值判断逻辑在你这边

三种题型与返回结构

题型	请求写法	返回	用途
noul（是否）	`criteria: {true: "...", false: "..."}`	`noul`：0~1 概率	二分判断、是否需要人工复核
choice（选择）	`criteria: {标签: 说明}`	`choice` + `probabilities`	路由、分类、模型选择
score（打分）	`criteria: ["档位1", "档位2"]`	`score` + `probabilities` + `legend`	优先级、情绪强度、严重度

confidence 字段是判断"要不要转人工"的依据。

⚠️ 坑二：state 里可以塞结构化 JSON，并用反引号路径引用

这是文档里最有价值但最容易忽略的能力——不需要把所有内容拼成一大段字符串：

{
  "state": {
    "ticket": { "message": "I was charged twice for order A-104." },
    "order": {
      "id": "A-104",
      "charges": [
        { "amount_usd": 49, "status": "captured" },
        { "amount_usd": 49, "status": "captured" }
      ]
    }
  },
  "questions": {
    "duplicate_charge": {
      "type": "noul",
      "instructions": "Do `ticket.message` and `order.charges` indicate a duplicate charge?"
    }
  }
}

反引号里的 ticket.message、order.charges 就是路径引用。官方建议是：每个问题只给它需要的那部分上下文，既省 token 又避免"上下文腐烂"。

instructions 也可以是对象而非字符串——当问题需要额外背景或示例时：

"instructions": {
  "potential_duplicate": { "name": "John Smith", "location": "Oakland" },
  "question": "Is the resume for the same person as `potential_duplicate`?"
}

⚠️ 坑三：一次请求要问多个问题，而不是循环问

官方明确指出："这是最大化每美元效果的方式——问题并行运行，代码再组合它们的信号，而不必增加串行的模型往返。"

❌ 错误做法：循环发 5 次请求（5 倍延迟） ✅ 正确做法：一次请求带 5 个问题，然后在你自己的代码里组合

这也解释了为什么它这么快——85ms 的 p50 是整批问题的时间，不是单个问题。

⚠️ 附带一条：Foundry 与 OpenRouter 的可用性差异

渠道	状态（2026-10-10）	备注
Microsoft Foundry	✅ 可用	需 Azure 账号；部署区域仅 Global Standard / WESTCENTRALUS
OpenRouter	✅ 已上线	模型页实测可用，`https://openrouter.ai/microsoft/microsoft-decision-1`

补充更正：本文早前版本曾写"OpenRouter 尚未上线"——那是 10-09 22:30 BST 的核查快照。官方博客现已更新，明确写"available in Microsoft Foundry and through OpenRouter"，且 OpenRouter 模型页已有完整的 Playground、定价与调用示例。第三方观察到的真实生产流量（AI Engine、meuemprego-ranking-embedding-unico、ZakazPro 等应用）也印证它已在被使用。

六、本地方案的调用方式（顺带对照）

本地方案的好处是接口形态几乎一致，上层代码基本不用改：

# H2O-Lightning-4B：vLLM + shim，暴露在 8741 端口
bash h2o-lightning-4b/serve.sh
curl -s http://127.0.0.1:8741/v1/systemone \
  -H 'Content-Type: application/json' \
  -d '{"state":"warm-up","questions":{"decision":{"type":"noul","instructions":"Is this a warm-up?","criteria":{"true":"yes","false":"no"}}}}'

方案	端点	路径差异
Decision-1（OpenRouter）	`/api/alpha/decisions`	带 `model` 字段，Bearer 认证
H2O-Lightning-4B（本地）	`http://127.0.0.1:8741/v1/systemone`	不带 `model`，本地直连
Quyet（本地）	`quyet.load(...)` + `m.predict(state, questions)`	Python 包调用

⚠️ 路径不同（/v1/systemone vs /api/alpha/decisions），但请求体里的 state / questions / type / instructions / criteria 这套结构三者一致。要做"托管版跑不动就切本地"的降级方案，只需封装一层适配器。

七、成本速算（按输入 token）

计费公式：输入 token × $0.042 / 1,000,000，输出免费。

场景	输入 token	单次/单月费用
1 万条 × 500 token	500 万	$0.21
50 万条 × 650 token	3.25 亿	$13.65
100 万条 × 1000 token	10 亿	$42.00

八、开通与充值：门槛与成本

是的，需要一个 OpenRouter 账号并创建 API Key。但门槛比想象低：

项目	规则
充值最低额	$10（充值到账 $9.20，扣 $0.80 手续费）
充值手续费	5.5%，最低 $0.80；USDC 加密货币再加 5%
推理加价	无——OpenRouter 不对模型定价加价
支付方式	主要信用卡、支付宝、USDC（PayPal 接入中）
额度有效期	购买后 1 年可能过期
退款	24 小时内可退未用额度，手续费不退；加密货币一律不退

$10 充值在 Decision-1 上约可调用 34.7 万次决策（按单次 650 输入 token 估算，输出免费不计）。

业务量	月成本	建议充值
个人测试 1 万次	$0.27	$10 够用一年
小项目 50 万次	$13.65	$25
中型 500 万次	$136.50	$150 + 自动充值

国内建议直接用支付宝、避开 USDC（多 5% 且不可退）。到账延迟属正常，Stripe 集成官方处理窗口是最多 1 小时。

另一条路：有 Azure 账号可直接走 Microsoft Foundry 用自己的订阅，跳过 OpenRouter 就没有 5.5% 充值费；代价是只有 Global Standard / WESTCENTRALUS 一个区域，且要走 Azure 的账号与合规流程。

九、Azure 账号就是微软账号吗？

是。不需要额外注册一个"Azure 账号"——用微软账号（或 GitHub 账号）登录后，Azure 会自动为你创建一个租户，你只需在里面建一个订阅。

层级	是什么	说明
微软账号（MSA）	身份凭证，`xxx@outlook.com`	✅ 你已经有了
Azure AD / Entra ID 租户	身份与访问管理边界（128 位 GUID）	首次登录自动创建
订阅 Subscription	计费单位，模型调用挂在它下面	⚠️ 必须有
资源组 → 资源	实际部署的东西	在订阅下创建

账号管"你是谁"，订阅管"谁付钱"。

注册还需要手机号 + 信用卡/借记卡（非预付卡）。卡只用于验证真人，注册时不扣费，但可能有 1 美元预授权，之后自动移除。可用个人微软账号、工作/学校账号或 GitHub 账号注册。

⚠️ 国内用户最关键的坑

官方明确写：Azure 免费帐户、免费服务和 $200 额度不含 Azure 中国（世纪互联）区域的主权云产品。

注册哪一版	结果
全球版 Azure	✅ 有 $200 额度 + 免费服务层
Azure 中国（partner.microsoftazure.cn）	❌ 无额度、无免费层

Decision-1 只部署在 Global Standard / WESTCENTRALUS（美国中西部），说明它就是全球版服务——你必须走全球版，别选 Azure 中国。

于是 OpenRouter vs Azure 该选哪个

维度	OpenRouter	Azure Foundry
开通成本	最低 $10 + 5.5% 手续费	$200 免费额度，无充值费
试用额度	无（只有免费模型）	$200 / 30 天
身份验证	无	手机号 + 信用卡
合规路径	境外服务，法务需评估	微软云，国内单位更易接受
适合	立刻跑通、验证效果	已有订阅、或走单位合规

建议：想快速验证效果就 $10 走 OpenRouter；如果是给单位用、需要过合规，Azure 反而更顺——$200 免费额度可以先测，且国内单位对微软云的接受度通常高于境外聚合平台。

十、官方适用范围：比宣传口径窄得多

你的判断是对的

Foundry 模型卡有一节 "Out of scope use cases"，原文克制到有点反宣传：

not designed for text generation, open-ended question answering, conversation, translation, or summarization. not intended for tasks that do not provide a closed question and a defined set of answer options, or for tasks that require knowledge not present in the input.

not designed or evaluated for use as the sole automated decision-maker in consequential decisions about people.

should not be used for surveillance, profiling, or tracking individuals; suppression of lawful speech...

The model is text-only... It does not generate explanations or rationales.

维度	❌ 不做 / 禁止	✅ 仅限
输出	不给解释与理由	JSON 概率
模态	纯文本，不接图像/音视频	text → json
任务	不生成、开放式问答、对话、翻译、摘要	闭合问题 + 固定选项
知识	不能用输入里没有的知识	仅凭输入内证据
决策权	不得作为涉人重大决定的唯一决策者	只给概率，阈值你定
禁域	信贷、就业、住房、保险、教育、医疗、法律权利	—
禁行	监控、画像、跟踪、压制合法言论	—

结论：不能写文章、不能写代码、不能对话、不能翻译、不能摘要、不给理由、不处理图像。剩下能干的只有一件——在给定选项里打分。

官方列出的 6 类用途

用途	你的对应场景
AI 输出评估（按 rubric 打分、判断是否有依据）	✅ 月报/材料初稿质量把关
分类与路由	✅ 工单分类、材料归档
Agent 护栏（评估提议的工具调用）	⚠️ 可用于 CodeWhale/WorkBuddy 链路
内容安全筛查（应用自定义阈值）	⚠️ 阈值需自定
搜索/文档相关性判断	✅ 知识库检索后过滤
基于置信度的自动化（高置信自动、低置信转人工）	✅ 这是它省人的地方

两个容易被忽略但很实用的能力：

能力	价值
显式弃权（Explicit abstention）	支持 "cannot tell" 选项，证据不足时主动说"判不了"——避免了低置信度硬给答案这个最常见的自动化事故
有依据性评估（Groundedness）	拿输入里给的证据核验回答，不引用外部知识

⚠️ 责任归属：微软把决策权推给了应用方

模型卡最关键的一句：

The integrating application is responsible for defining appropriate answer options, confidence thresholds, escalation paths, human oversight, and safeguards for downstream actions.

选项怎么定、阈值卡多少、何时升级人工、下游动作怎么保护，全是你的代码负责。 这一句分量比前面所有限制都重：

微软不为你的阈值选择负责——把"置信度 >90% 自动执行"设成 80%，出事责任在集成方。
你必须自建人工复核通道，模型只要求你提供、不提供。
92.2 的校准分是通用基准，不是"你的业务上它有多准"。上线前必须用自己的历史数据重测校准。

微软内部四例：全是"打分"，没有一例"做事"

团队	用途	结果（微软自报）
Xbox Research	10,000+ 条反馈按主题归类	与 GPT-6 Sol 相当，快 14 倍、便宜 200 倍
Copilot 团队	给聊天与智能体回答打质量分	与 GPT-5.6 Luna 相当，快 100 倍
值班工程师	故障时检索日志/工单/消息	比通用 LLM 更好更快（无数字）
Microsoft Discovery	科研智能体按 rubric 评分并重规划	一致性 46 倍，速度 3 倍

共同点：全部是"给别人的输出打分"。它是流水线的质检环节，不是生产环节。

赛道现状（同月玩家）

玩家	动作	权重
Cloudflare Clef	10-01 发布，开放权重，部署在 Workers AI	开源
OpenAI Decisions API	公测，返回类型化答案	闭源
Microsoft Decision-1	Foundry 上线，计划 rebasing 到 MAI/OpenAI	闭源
Perplexity / Liquid AI	同赛道已有布局	部分开源

一个值得注意的信号：微软和 OpenAI 都把 OpenRouter 当分发渠道——微软说要 rebasing 到 OpenAI 模型，OpenAI 自己也开了 Decisions API。这两家在"决策层"已不是竞争关系，而是同层不同供应商。

十一、防追问要点（路演/汇报用）

如果要在正式场合讲这件事，这几个点建议提前准备：

可能的追问	建议答法
"35 倍快是真的吗"	官方口径。对手用 JevBench 校正中位数、自己用 Foundry 实测，按原始计时对亚军约 1.4 倍
"有没有第三方验证"	截至 10-09 无。JevBench 官方榜单、Artificial Analysis、Vals AI 均无条目
"能私有化部署吗"	不能，只有托管 API，权重未分发
"是国产模型吗"	底座是阿里的 Qwen3.5-9B，但成品是微软的闭源后训练，国产替代路径下拿不到它
"GA 了吗"	标签写 GA，但 Azure 条款链接指向 preview supplemental terms，需书面确认
"能用在信贷/用工决策上吗"	不能。微软明确禁止将其作为信贷、就业、住房、保险、教育、医疗、法律权利决定的唯一依据，也禁止用于监控和给个人画像
"为什么微软选 Qwen"	官方未解释。可合理推测：Apache 2.0 许可干净、9B 规模适合低延迟单次前向、且不必自研基座

最后一条关于合规的提醒值得单独强调——微软在自家文档里列了明确的禁用场景。如果你的业务场景涉及对个人的自动化判定，这个限制要提前过法务。

十二、一句话总结

微软用一个 Apache-2.0 的国产开源底座，做出了一个准确率 83.5%、延迟 85 毫秒、售价 $0.042/百万 token 的闭源托管服务，证明了两件事：决策模型这个品类已经跑通了商业化；开源底座 + 闭源后训练，是大厂做垂直模型的标准打法。

对使用者来说，Decision-1 是一个价格极低但无法私有化的选项；对想要数据自主可控的人来说，H2O-Lightning-4B（4.5B，Apache-2.0，JevBench 开放权重第一，4-bit 量化后约 2.7GB 显存）是目前更现实的落地方案。

数据来源

来源	用途	时间
Microsoft Command Line 官方博客	模型机制、性能数据、内部用例	2026-10-09 发布
Microsoft Foundry 模型卡	托管方式、权重状态、训练数据、区域、许可条款	2026-10-09 读取
pk-sharma 独立核查	权重未分发、测法差异、第三方榜单缺失、GA/条款矛盾	2026-10-09 22:30 BST
H2O-Lightning-4B 模型卡 · 官方博客	开源替代方案、部署命令、JevBench 成绩	2026-10-07/08
Quyet-1.0 GitHub · Hugging Face	家族规格、CPU 运行方案、许可	2026-10-08 更新
Qwen3.5-9B 模型页 · bartowski GGUF	基座规格、量化体积、部署命令	2026-10-08 读取
AIHOT 事件详情	发布时点、信源汇总、定价	2026-10-10 02:37
OpenRouter 模型页	调用端点、请求/响应格式、示例代码、线上实测延迟与可用性	2026-10-10 读取
TypeSafe System One 官方文档	状态/问题结构化设计、反引号路径引用、并行提问范式	2026-10-10 读取
OpenRouter FAQ	充值手续费、最低充值额、额度有效期、退款与支付方式	2026-10-10 读取
Azure 免费帐户官方页	账号类型（MSA/GitHub）、信用卡验证、$200 额度 30 天、Azure 中国不含免费额度	2026-10-10 读取
Microsoft Foundry 模型目录页	官方适用范围原文（Key capabilities / Out of scope use cases / 责任归属声明）	2026-10-10 读取

免责声明

本文所有数据来自上述公开来源，其中性能数字均为微软官方口径，截至 2026-10-10 尚无独立第三方复现。成本测算为笔者自行推算，非官方数据。开源模型的许可条款以各自仓库为准，商业使用前请自行核对。决策模型普遍未经高风险场景的对抗鲁棒性评测，请勿作为信贷、就业、医疗等重大决策的唯一依据。

本文由 WorkBuddy 生成 · 数据核实时间 2026-10-10 09:30（北京时间）

posted on 2026-10-10 10:12 fox_charon 阅读(79) 评论(0) 收藏举报

刷新页面返回顶部