引言

上个月我写了一篇 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

微软研究院最近发布了 Fara-7B，这是一款专为电脑操作（Computer Use）设计的代理小语言模型（Agentic SLM）。与传统的聊天模型不同，Fara-7B 旨在通过像人类一样使用鼠标和键盘来完成任务。

什么是 Fara-7B？

Fara-7B 是一个拥有 70 亿参数的模型，基于 Qwen2.5-VL-7B 构建。它的主要特点包括：

• 视觉感知：它通过视觉感知网页（截图）来操作，不需要依赖辅助功能树（Accessibility Trees）或额外的解析模型。
• 高效紧凑：尽管只有 7B 参数，但在同类模型中实现了最先进的性能，甚至在某些基准测试中可以与更大的模型竞争。
• 端侧运行：由于体积小，它可以在设备上本地运行，从而降低延迟并提高隐私安全性。

核心技术

Fara-7B 的训练利用了微软开发的合成数据生成管道，该管道基于 Magentic-One 框架。它通过“观察-思考-行动”（observe-think-act）的循环来执行任务。

在每个步骤中，模型会接收：

1. 用户指令
2. 完整的操作历史
3. 最近的三张屏幕截图

然后，它会输出一个推理信息（“思考”下一步行动），随后调用工具（如 click(x,y)、type() 等）来执行操作。

性能表现

在 WebVoyager、Online-Mind2Web 等基准测试中，Fara-7B 展现了强大的性能。例如在 WebVoyager 上，它的任务成功率达到了 73.5%，超过了 UI-TARS-1.5-7B (66.4%) 和 GPT-4o (SoM Agent, 65.1%)。

如何通过 vLLM 使用 Fara-7B

Fara-7B 已经发布在 Hugging Face 上。由于它是基于 Qwen2.5-VL 的，我们可以使用 vLLM 来高效地部署和推理。

安装 vLLM

首先确保你安装了最新版本的 vllm：

pip install vllm

Python 代码示例

以下是一个使用 vLLM 加载 Fara-7B 并进行推理的 Python 脚本示例：

from vllm import LLM, SamplingParams
from PIL import Image
import requests
from io import BytesIO

def run_fara_7b():
    # 模型名称
    model_name = "microsoft/Fara-7B"

    # 初始化 LLM
    # Fara-7B 基于 Qwen2.5-VL，因此使用类似的配置
    llm = LLM(
        model=model_name,
        trust_remote_code=True,
        max_model_len=4096,  # 根据显存大小调整
        limit_mm_per_prompt={"image": 1},
        mm_processor_kwargs={
            "min_pixels": 28 * 28,
            "max_pixels": 1280 * 28 * 28,
        },
    )

    # 加载示例图片（这里仅作演示，实际使用中应为屏幕截图）
    image_url = "https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Gfp-wisconsin-madison-the-nature-boardwalk.jpg/2560px-Gfp-wisconsin-madison-the-nature-boardwalk.jpg"
    response = requests.get(image_url)
    image = Image.open(BytesIO(response.content))

    # 构建 Prompt
    # 注意：Fara-7B 使用特定的 Prompt 格式
    prompt = (
        "<|im_start|>system\nYou are a helpful assistant.<|im_end|>\n"
        "<|im_start|>user\n<|vision_start|><|image_pad|><|vision_end|>"
        "Describe this image in detail.<|im_end|>\n"
        "<|im_start|>assistant\n"
    )

    # 准备输入
    inputs = {
        "prompt": prompt,
        "multi_modal_data": {
            "image": image
        },
    }

    # 采样参数
    sampling_params = SamplingParams(temperature=0.2, max_tokens=512)

    # 生成结果
    outputs = llm.generate([inputs], sampling_params=sampling_params)

    for o in outputs:
        print(f"Generated text: {o.outputs[0].text}")

if __name__ == "__main__":
    run_fara_7b()

命令行启动 API 服务

如果你想启动一个兼容 OpenAI API 的服务，可以使用以下命令：

vllm serve microsoft/Fara-7B \
  --trust-remote-code \
  --limit-mm-per-prompt image=1 \
  --mm-processor-kwargs '{"min_pixels": 784, "max_pixels": 1003520}'

注意：min_pixels 对应 28x28，max_pixels 对应 1280x28x28。

总结

Fara-7B 是微软在代理小模型领域的一次重要尝试，它证明了小模型在复杂的电脑操作任务中也能有出色的表现。通过开源权重，开发者可以更轻松地探索和构建基于 GUI 的自动化代理。

• 模型参数（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 架构）也很前沿。

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

总览

Azure 提供了广泛的功能和服务，包括虚拟机、存储、数据库、人工智能、机器学习、区块链、物联网、容器、Serverless 计算等。它还提供了全球范围的数据中心网络，使用户能够在全球范围内部署和扩展应用程序。

Azure 拥有数百项自身提供或合作伙伴提供的服务，截止至 2024 年 6 月 19 日，其拥有 19 个大分类，共计 413 项服务：

使用 Azure，您可以轻松地创建和管理虚拟机，存储和管理数据，构建和部署 Web 应用程序，进行大规模数据分析，实现自动化和监控等。Azure 还提供了强大的安全性和合规性功能，以确保您的数据和应用程序的安全性。

无论您是个人开发者、创业公司还是大型企业，Azure 都提供了灵活的定价模型，以满足不同规模和需求的项目。您可以根据实际使用情况付费，避免了高额的固定成本。

以下将总体介绍 19 个大分类的服务概述。

AI + Machine Learning

Azure 提供了强大的 AI + 机器学习功能，使用户能够构建和部署智能应用程序和解决方案。通过 Azure 的 AI + 机器学习服务，您可以利用先进的机器学习算法和模型来处理和分析大规模数据，从而获得有价值的洞察和预测能力。

通过这些 AI + 机器学习服务，您可以实现各种应用场景，如智能推荐、欺诈检测、情感分析、语音识别和自动化决策等。无论您是初学者还是专业人士，Azure 的 AI + 机器学习功能都能帮助您轻松构建和部署智能应用程序。

Analytics

Azure Analytics 是 Azure 平台下的一个重要分类，提供了一系列强大的数据分析和洞察服务。这些服务可以帮助用户从海量数据中提取有价值的信息，并进行深入的数据分析和可视化展示。

Azure Analytics 提供了丰富的数据分析和洞察服务，帮助用户从海量数据中提取有价值的信息，并进行深入的数据分析和可视化展示。无论是处理结构化数据还是非结构化数据，无论是批处理还是实时处理，Azure Analytics 都能满足用户的各种数据分析需求。

Compute

Compute 计算服务是 Azure 平台下的一个庞大分类，提供了各种计算资源和服务，用于构建、部署和管理应用程序和服务。

Azure Compute 提供了多种计算选项，包括虚拟机、容器、Serverless 计算和批处理等。您可以根据应用程序的需求选择适合的计算资源，并根据实际使用情况进行弹性扩展和收缩。

Containers

Containers 容器分类，提供了一系列容器相关的服务和工具，用于构建、部署和管理容器化应用程序。

Azure Containers 提供了强大的容器编排和管理功能，使用户能够轻松地创建、部署和扩展容器化应用程序。通过 Azure 的容器服务，您可以使用 Docker 容器技术来打包应用程序及其依赖项，并在云端或本地环境中运行。

Azure Containers 提供了多种容器服务选项，包括 Azure Kubernetes Service (AKS)、Azure Container Instances (ACI) 和 Azure Container Registry (ACR) 等。这些服务提供了灵活的容器部署和管理方式，适用于不同规模和需求的项目。

使用 Azure Containers，您可以实现容器化应用程序的高可用性、弹性扩展和自动化管理。无论是单个容器应用程序还是复杂的微服务架构，Azure Containers 都能提供可靠的容器化解决方案。

Databases

Databases 数据库服务提供了多种数据库服务和解决方案，用于存储和管理结构化数据。

Azure Databases 提供了多种数据库选项，包括关系型数据库、NoSQL 数据库和缓存服务等。您可以根据应用程序的需求选择适合的数据库类型，并根据实际使用情况进行弹性扩展和收缩。

无论您是需要传统的关系型数据库、灵活的 NoSQL 数据库还是高性能的缓存服务，Azure Databases 都能提供适合您的数据库服务和解决方案。 通过 Azure Databases，您可以轻松地创建和管理数据库实例，进行数据的读写和查询，实现高可用性和数据的持久性。Azure Databases 还提供了强大的安全性和合规性功能，以确保您的数据的安全性和隐私保护。

DevOps

在 DevOps 中提供了一系列强大的工具和服务，用于实现持续交付和持续集成的 DevOps 实践。

DevOps 中提供了全面的 DevOps 解决方案，包括混沌测试，持续集成、持续交付、测试自动化、应用程序监控和故障排除等。

General

Azure General 分类提供了一系列通用的云服务和工具，是使用 Azure 整个平台的最基础功能。

通过 Azure General，您可以找到一系列帮助您快速熟悉和使用 Azure 的工具，并且有效的管理您的各类资源以及计划您的支出，如果您对云计算服务不是特别熟悉或刚刚开始从事相关工作，在 General 中获取帮助是您的很好选择。

Hybrid + Multicloud

Azure Hybrid + Multicloud 分类提供了一系列强大的混合云和多云解决方案，帮助用户在不同的云环境中构建、部署和管理应用程序和服务。

Azure Hybrid + Multicloud 提供了多种混合云和多云服务选项，包括混合云连接、数据集成、应用程序迁移和多云管理等。这些服务使用户能够在不同的云环境中灵活地部署和管理应用程序，实现资源的共享和协同工作。

通过 Azure Hybrid + Multicloud，您可以实现混合云环境中的数据集成和应用程序迁移，实现跨云平台的协同工作和资源的共享。Azure Hybrid + Multicloud 还提供了强大的多云管理功能，帮助用户统一管理和监控不同云环境中的资源和服务。

Identity

Azure Identity 分类提供了一系列身份验证和访问管理服务，用于保护应用程序和数据的安全性。

Azure Identity 提供了多种身份验证和访问管理服务选项，包括 Azure Active Directory (Azure AD)、Azure AD B2C 和 Azure AD Domain Services 等。这些服务提供了全面的身份验证和访问管理解决方案，帮助用户建立安全的身份验证和访问控制机制。

通过 Azure Identity，您可以实现用户身份验证和访问管理，保护应用程序和数据的机密性和完整性。Azure Identity 还提供了强大的身份验证和访问管理功能，如多因素身份验证、单一登录、角色基于访问控制和身份联合等，帮助用户确保只有授权的用户能够访问应用程序和数据。

Integration

Azure Integration 提供了一系列强大的集成服务和工具，用于实现应用程序和系统之间的无缝集成和数据交换。

Azure Integration 提供了多种集成服务选项，包括消息队列、事件网格、逻辑应用程序和数据工厂等。这些服务使用户能够轻松地构建、部署和管理应用程序和系统之间的集成解决方案。

通过 Azure Integration，您可以实现应用程序和系统之间的实时数据交换和协同工作。Azure Integration 还提供了强大的消息传递和事件处理功能，帮助用户实现高效的数据流和业务流程。

Internet of Things

Azure Internet of Things (IoT) 分类提供了一系列强大的物联网服务和解决方案，用于连接、监控和管理物理设备和传感器。

Azure IoT 提供了多种物联网服务选项，包括设备连接、数据采集、实时分析和远程监控等。这些服务使用户能够轻松地构建、部署和管理物联网解决方案，实现设备之间的互联和数据的实时处理。

通过 Azure IoT，您可以实现设备的连接和管理，监控设备的状态和性能，并进行实时数据分析和预测。Azure IoT 还提供了强大的远程监控和控制功能，帮助用户实现远程设备管理和操作。

使用 Azure IoT，您可以构建各种物联网应用场景，如智能家居、智能工厂、智能农业和智能城市等。无论是个人用户还是企业客户，Azure IoT 都能提供可靠的物联网解决方案，帮助您实现设备的互联和数据的实时处理。

Management and Governance

Azure Management and Governance 分类提供了一系列强大的管理和治理服务，帮助用户有效地管理和监控 Azure 资源和应用程序。

Azure Management and Governance 提供了多种管理和治理服务选项，包括资源管理、访问控制、成本管理、策略和合规性等。这些服务使用户能够轻松地管理和监控 Azure 资源和应用程序，实现资源的优化和合规性的保证。

通过 Azure Management and Governance，您可以实现资源的集中管理和监控，优化资源的使用和成本的控制。Azure Management and Governance 还提供了强大的访问控制和权限管理功能，帮助用户确保只有授权的用户能够访问和操作资源。

使用 Azure Management and Governance，您可以定义和实施策略和合规性规则，确保应用程序和数据的合规性和安全性。Azure Management and Governance 还提供了丰富的监控和报告功能，帮助用户实时了解资源的状态和性能。

Migration

Azure Migration 分类提供了一系列强大的迁移服务和工具，帮助用户将现有应用程序和数据迁移到 Azure 平台上。

Azure Migration 提供了多种迁移服务选项，包括虚拟机迁移、数据库迁移、应用程序迁移和数据迁移等。这些服务使用户能够轻松地将现有的应用程序和数据迁移到 Azure 平台上，实现平滑的迁移过程和无缝的应用程序转换。

通过 Azure Migration，您可以实现虚拟机的迁移和转换，将现有的虚拟机环境迁移到 Azure 虚拟机中。Azure Migration 还提供了强大的数据库迁移功能，帮助用户将现有的数据库迁移到 Azure 数据库服务中，实现数据的平滑迁移和无缝连接。

使用 Azure Migration，您可以轻松地将现有的应用程序迁移到 Azure 平台上，实现应用程序的云化和弹性扩展。Azure Migration 还提供了强大的数据迁移功能，帮助用户将现有的数据迁移到 Azure 存储服务中，实现数据的安全存储和高可用性。

Mixed Reality

Azure Mixed Reality 分类提供了一系列强大的混合现实服务和解决方案，用于构建、部署和管理混合现实应用程序和体验。

Azure Mixed Reality 提供了多种混合现实服务选项，包括混合现实开发工具、混合现实内容管理和分发、混合现实设备管理和监控等。这些服务使用户能够轻松地构建、部署和管理混合现实应用程序和体验，实现沉浸式的交互和创新的用户体验。

通过 Azure Mixed Reality，您可以利用先进的混合现实技术和工具来创建逼真的虚拟场景和交互体验。Azure Mixed Reality 还提供了强大的混合现实内容管理和分发功能，帮助用户将混合现实应用程序和体验推送到不同的设备和平台上。

使用 Azure Mixed Reality，您可以构建各种混合现实应用场景，如虚拟培训、虚拟会议、虚拟展览和虚拟旅游等。无论是个人用户还是企业客户，Azure Mixed Reality 都能提供创新的混合现实解决方案，帮助您实现沉浸式的交互和创新的用户体验。

Monitor

Azure Monitor 分类提供了一系列强大的监控和日志管理服务，帮助用户实时监测和分析应用程序和基础设施的性能和健康状况。

Azure Monitor 提供了多种监控和日志管理服务选项，包括应用程序性能监视、基础设施监视、日志分析和警报管理等。这些服务使用户能够实时监测和分析应用程序和基础设施的性能和健康状况，及时发现和解决潜在的问题。

通过 Azure Monitor，您可以实时监测应用程序的性能和可用性，了解应用程序的负载和响应时间。Azure Monitor 还提供了强大的基础设施监视功能，帮助用户监控服务器、虚拟机和容器等基础设施的性能和资源使用情况。

使用 Azure Monitor，您可以收集和分析应用程序和基础设施的日志数据，了解应用程序的运行状况和事件发生情况。Azure Monitor 还提供了灵活的警报管理功能，帮助用户设置和管理警报规则，及时通知和响应关键事件。

Networking

Azure Networking 提供了一系列强大的网络服务和解决方案，用于构建、部署和管理网络基础设施和连接。

Azure Networking 提供了多种网络服务选项，包括虚拟网络、负载均衡、应用网关、VPN 网关和 ExpressRoute 等。这些服务使用户能够轻松地构建和管理灵活、可靠的网络架构，实现应用程序和服务之间的高速连接和通信。

通过 Azure Networking，您可以创建和管理虚拟网络，定义网络拓扑和子网划分，实现应用程序和服务之间的隔离和安全性。Azure Networking 还提供了强大的负载均衡和应用网关功能，帮助用户实现应用程序的高可用性和性能优化。

使用 Azure Networking，您可以轻松地创建和管理 VPN 网关和 ExpressRoute 连接，实现安全、可靠的远程连接和混合云环境的扩展。Azure Networking 还提供了强大的网络安全和防火墙功能，帮助用户保护网络和应用程序的安全性和隐私保护。

Security

在 Azure Security 分类中提供了一系列强大的安全性和合规性服务。这些服务可以帮助用户保护应用程序和数据的安全性，防止恶意攻击和数据泄露。

Azure Security 提供了多种安全性和合规性服务选项，包括身份验证和访问管理、数据保护和加密、威胁检测和防御、安全监控和审计等。这些服务提供了全面的安全性解决方案，帮助用户建立安全的云环境和应用程序。

通过 Azure Security，您可以实现身份验证和访问管理，保护应用程序和数据的机密性和完整性。Azure Security 还提供了强大的威胁检测和防御功能，帮助用户及时发现和应对安全威胁。

Storage

Azure Storage 提供了可扩展的云存储解决方案，用于存储和管理大规模的结构化和非结构化数据。

Azure Storage 提供了多种存储服务选项，包括 Blob 存储、文件存储、表存储和队列存储等。这些服务使用户能够轻松地存储和访问各种类型的数据，实现数据的持久性和可靠性。

通过 Azure Storage，您可以存储和管理大规模的结构化和非结构化数据，如图像、视频、文档和日志等。Azure Storage 还提供了强大的数据复制和备份功能，帮助用户保护数据的安全性和可用性。

使用 Azure Storage，您可以实现数据的高可用性和弹性扩展，根据实际使用情况进行存储容量的调整。Azure Storage 还提供了灵活的访问控制和权限管理功能，帮助用户控制数据的访问和使用权限。

Web + Mobile

Azure Web + Mobile 分类提供了一系列强大的云服务和工具，用于构建、部署和管理 Web 和移动应用程序。

Azure Web + Mobile 提供了多种服务选项，包括 Web 应用程序、移动应用程序、API 管理和通知服务等。这些服务使用户能够轻松地构建和部署高性能、可扩展的 Web 和移动应用程序。

使用 Azure Web + Mobile，您可以构建各种 Web 和移动应用场景，如电子商务网站、社交媒体应用、企业门户和移动客户端等。无论是个人开发者还是企业客户，Azure Web + Mobile 都能提供可靠的云服务和工具，帮助您构建和部署高性能、可扩展的 Web 和移动应用程序。

总结

本文介绍了 Azure 101 系列课程中的 Microsoft Azure 概览。Azure 是由 Microsoft 提供的云计算平台和服务，提供了广泛的功能和服务，包括虚拟机、存储、数据库、人工智能、机器学习、区块链、物联网、容器、Serverless 计算等。Azure 还提供了全球范围的数据中心网络，使用户能够在全球范围内部署和扩展应用程序。本文还介绍了 Azure 19 个大分类的服务概述，包括 AI + 机器学习、数据分析、计算、容器、数据库、DevOps、通用云服务、混合云和多云、身份验证和访问管理、集成、物联网、管理和治理、迁移、混合现实、监控、网络、安全、存储、Web 和移动应用程序。这些服务和解决方案可以帮助用户构建、部署和管理各种类型的应用程序和服务，并提供了强大的安全性和合规性功能。无论是个人开发者、创业公司还是大型企业，Azure 都提供了灵活的定价模型，以满足不同规模和需求的项目。