引言

上个月我写了一篇 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 决策模型的对比与选型

最近，一台部署在 Azure 上的 Linux 服务器突然出现 CPU 持续 100% 的情况。排查后发现，服务器上存在一个以 postgres 用户身份运行的恶意程序，并通过 cron 定时任务维持运行。

这台服务器上的 PostgreSQL：

• 没有通过 Azure NSG 向公网开放 5432；
• 没有被当前业务使用；
• 业务实际使用的是本机 MySQL；
• 但 PostgreSQL 服务仍然安装并运行；
• 系统中保留了 postgres 用户、主目录、cron 和历史脚本。

这次事件说明：

PostgreSQL 没有向公网开放，并不代表服务器上与 PostgreSQL 相关的组件完全没有风险。

需要特别说明的是，目前的证据只能证明恶意程序利用了 postgres 操作系统用户及其目录进行持久化，不能证明攻击者一定是通过 PostgreSQL 的 5432 端口进入服务器的。初始入口也可能是历史配置、SSH、Web 应用、容器、旧镜像或其他漏洞。

如果生产环境确实需要 PostgreSQL，但没有必须自建数据库服务器的特殊要求，建议优先使用：

Azure Database for PostgreSQL，并通过私有网络访问，关闭公共网络入口。

这样可以减少自建数据库所带来的操作系统用户、SSH、cron、systemd、补丁、备份和主机入侵等风险。

发现问题：服务器 CPU 持续占满

最初是在服务器上执行 htop 时发现异常。

从截图中可以看到：

• 服务器共有 4 个 CPU 核心；
• 4 个核心全部达到 100%；
• Load Average 长期维持在 4 左右；
• 多个进程以 postgres 用户运行；
• 进程名称为随机字符串 dzZ7yVrxv7；
• 单个进程的 CPU 使用率超过 200%；
• 进程占用了大量内存。

进一步执行：

sudo ps -eo user,pid,ppid,lstart,etime,%cpu,%mem,stat,comm,args \
  --sort=-%cpu | head -20

其中一个主要进程如下：

USER       PID   PPID  %CPU  %MEM  STAT  COMMAND
postgres   9918     1   377  29.8  Ssl   dzZ7yVrxv7

这不是正常的 PostgreSQL 进程。

正常情况下，PostgreSQL 进程名称通常类似：

postgres
postgres: checkpointer
postgres: background writer
postgres: walwriter
postgres: autovacuum launcher

而本次进程具有以下异常特征：

• 名称为随机字符串；
• 以 postgres 用户运行；
• CPU 使用率接近 4 个核心；
• 父进程已经变成 PID 1；
• 内存占用异常高。

因此，初步判断这不是正常数据库负载，而是疑似挖矿程序或其他恶意程序。

分析问题：确认恶意程序来源

1. 检查进程真实文件

Linux 进程名称可以被修改或伪装，所以不能只看 COMMAND，需要检查 /proc/<PID>/exe。

执行：

sudo sh -c '
echo "EXE:"
ls -l /proc/9918/exe

echo "CWD:"
ls -l /proc/9918/cwd

echo "CMDLINE:"
tr "\0" " " < /proc/9918/cmdline
echo

echo "CGROUP:"
cat /proc/9918/cgroup
'

输出如下：

EXE:
/proc/9918/exe -> /dev/shm/gJppJl6TbG (deleted)

CWD:
/proc/9918/cwd -> /var/lib/postgresql

CMDLINE:
dzZ7yVrxv7

CGROUP:
0::/system.slice/cron.service

这几项信息非常关键。

可执行文件位于 /dev/shm

真实程序路径为：

/dev/shm/gJppJl6TbG

/dev/shm 是基于内存的临时文件系统。恶意程序经常将文件下载到这里，再从内存文件系统中执行，以减少在磁盘上的痕迹。

原文件已经被删除

路径末尾显示：

(deleted)

说明程序启动后，磁盘上的原文件已被删除。但由于进程仍然持有该文件，程序依然可以继续运行。

这种“启动后删除自身”的行为是常见的恶意程序隐藏手段。

工作目录属于 PostgreSQL 用户

进程工作目录是：

/var/lib/postgresql

这说明恶意程序与 postgres 用户的主目录有关。

进程由 cron 启动

cgroup 显示：

/system.slice/cron.service

这说明程序是通过定时任务启动的。

2. 从运行中的进程保存样本

因为原始文件已经被删除，如果立即结束进程，可能无法再提取样本。因此先从 /proc 保存程序：

sudo mkdir -p /root/incident
sudo chmod 700 /root/incident

sudo cp -L /proc/9918/exe \
  /root/incident/suspect-9918.bin

sudo chmod 600 \
  /root/incident/suspect-9918.bin

检查文件类型：

sudo file /root/incident/suspect-9918.bin

结果如下：

ELF 64-bit LSB shared object, x86-64,
statically linked, no section header

计算 SHA-256：

sudo sha256sum /root/incident/suspect-9918.bin

得到：

d32f9eef63c496a146a6a811677dd27e337db993d6f1a4b1af145c3135d391b3

该文件具有以下特征：

• 随机文件名；
• 位于 /dev/shm；
• 静态链接；
• 没有节区表；
• 启动后删除原文件；
• 持续占用全部 CPU。

这些行为进一步证明它不是正常的 PostgreSQL 组件。

3. 检查 PostgreSQL 用户的定时任务

由于进程是从 cron.service 启动的，继续检查 postgres 用户的 crontab：

sudo crontab -u postgres -l

发现如下任务：

24 * * * * /var/lib/postgresql/.dbus-XGodM5jOyL

该任务会在每小时第 24 分钟执行一次隐藏脚本：

/var/lib/postgresql/.dbus-XGodM5jOyL

文件名使用了以点开头的隐藏形式，并模仿了 D-Bus 的命名方式，很容易被误认为系统文件。

检查 cron 日志：

sudo journalctl -u cron.service \
  --since "2026-08-15 07:15:00" \
  --until "2026-08-15 09:15:00" \
  --no-pager

日志中可以看到：

Aug 15 07:24:01 CRON: (postgres) CMD (/var/lib/postgresql/.dbus-XGodM5jOyL)
Aug 15 08:24:01 CRON: (postgres) CMD (/var/lib/postgresql/.dbus-XGodM5jOyL)

这证明恶意脚本至少在 07:24 和 08:24 被执行过。

4. 分析恶意启动脚本

检查文件：

sudo file /var/lib/postgresql/.dbus-XGodM5jOyL
sudo stat /var/lib/postgresql/.dbus-XGodM5jOyL
sudo sha256sum /var/lib/postgresql/.dbus-XGodM5jOyL

结果显示它是一个 Bash 脚本：

Bourne-Again shell script, ASCII text executable,
with very long lines

对应 SHA-256：

36b1dcf43876f55aae2b8be7dada848b41f60ec61cd4ca7ab2a1278193f286f0

这份脚本负责下载、启动或恢复恶意程序，也是恶意进程能够周期性出现的主要持久化机制。

如果只结束高 CPU 进程，而不清理这条 cron，恶意程序会在下一个小时的第 24 分钟再次出现。

5. 在用户目录中发现第二个恶意下载器

停止并卸载 PostgreSQL 后，我继续检查 /var/lib/postgresql 的残留文件：

sudo find /var/lib/postgresql \
  -xdev -maxdepth 10 -ls

发现了另一个可疑文件：

/var/lib/postgresql/.config/systemd/user/
└── systemd-tmpfiles-cleanup/
    └── systemd-tmpfiles-cleanup-TNWow7.sh

这个文件使用了：

systemd-tmpfiles-cleanup

作为目录名，试图伪装成正常的 systemd 临时文件清理组件。

检查文件类型和哈希：

sudo file \
  /var/lib/postgresql/.config/systemd/user/systemd-tmpfiles-cleanup/systemd-tmpfiles-cleanup-TNWow7.sh

sudo sha256sum \
  /var/lib/postgresql/.config/systemd/user/systemd-tmpfiles-cleanup/systemd-tmpfiles-cleanup-TNWow7.sh

结果为：

Bourne-Again shell script, ASCII text executable,
with very long lines

SHA-256：

9962de5e0c68ea6e85879c5f62f2d0806360dbe186dc15e1d59abf8e4209de11

脚本内容经过 Base64 编码，末尾直接执行：

base64 -d | bash

解码后的逻辑显示，它具备以下行为：

• 通过 Tor、SOCKS5 或 Tor2web 连接外部地址；
• 获取服务器公网 IP；
• 收集当前用户名、主机名和内核版本；
• 读取机器 ID；
• 从外部下载其他程序；
• 在 /dev/shm、/tmp、/var/tmp 等目录测试和执行文件；
• 启动程序后删除临时文件。

这已经不只是一个单纯的高 CPU 进程，而是一套包含下载、执行、隐藏和持久化能力的恶意程序。

为什么 PostgreSQL 没有开放公网端口，仍然存在风险？

Azure 网络安全组当时只允许公网访问：

• TCP 22；
• TCP 80；
• TCP 443。

并没有允许公网直接访问 PostgreSQL 的 5432 端口。

但检查服务器本机监听状态时发现：

sudo ss -lntp | grep ':5432'

输出为：

LISTEN 0 244 0.0.0.0:5432 0.0.0.0:*
LISTEN 0 244 [::]:5432    [::]:*

这说明 PostgreSQL 在操作系统层面监听了所有 IPv4 和 IPv6 网卡。

虽然 Azure NSG 没有向公网放行 5432，但以下风险依然存在。

1. 同一虚拟网络中的主机仍可能访问

Azure NSG 默认存在 AllowVnetInBound 规则，同一虚拟网络中的其他服务器可能访问该端口。

如果同一 VNet 内的其他服务器被入侵，攻击者就可能通过内网继续攻击数据库服务器。

2. 本机应用或容器仍可能访问

即使公网无法连接，服务器本机运行的以下组件仍然可能访问 PostgreSQL：

• Web 应用；
• Docker 容器；
• CI/CD Agent；
• 其他被攻陷的服务；
• 本机恶意程序。

网络安全组无法阻止服务器本机进程访问本机数据库。

3. 风险不只来自数据库端口

本次恶意程序的实际持久化位置是：

• postgres 用户的 crontab；
• /var/lib/postgresql 用户目录；
• 用户级 systemd 配置目录；
• /dev/shm 临时执行目录。

即使 PostgreSQL 服务停止，只要这些用户、目录和定时任务仍然存在，恶意程序就可能继续运行。

所以，数据库的安全边界不只是 5432 端口，还包括：

• 操作系统账户；
• 数据目录；
• 用户主目录；
• cron；
• systemd；
• SSH；
• 软件包；
• 配置文件；
• 历史镜像和备份。

4. 未使用的软件往往更容易被忽略

这台服务器的业务实际使用 MySQL，PostgreSQL 并没有业务用途。

由于“不使用”，它反而容易长期处于以下状态：

• 没有人检查配置；
• 没有人检查系统用户；
• 没有人检查数据库日志；
• 没有人检查用户的 cron；
• 没有人检查相关目录；
• 没有人确认是否仍然需要；
• 没有人关注其补丁和版本。

因此：

未使用但仍然安装和运行的软件，并不是备用能力，而是未被管理的攻击面。

解决问题：清除恶意程序并卸载 PostgreSQL

1. 暂停恶意进程

取证完成后，先暂停进程：

sudo kill -STOP 9918

检查进程状态：

ps -p 9918 \
  -o user,pid,ppid,%cpu,%mem,stat,comm,args

状态中出现 T，说明进程已暂停。

暂停的好处是：

• 立即停止继续占用 CPU；
• 暂时停止潜在网络行为；
• 保留进程，便于继续调查；
• 避免在完成取证前丢失内存中的样本。

2. 备份并删除恶意 cron

先保存 crontab：

sudo crontab -u postgres -l \
  > /root/incident/postgres-crontab.txt

然后删除：

sudo crontab -u postgres -r

确认已删除：

sudo crontab -u postgres -l

预期输出：

no crontab for postgres

3. 隔离恶意启动脚本

先备份脚本：

sudo cp -a \
  /var/lib/postgresql/.dbus-XGodM5jOyL \
  /root/incident/cron-payload

再从原位置移走：

sudo mv \
  /var/lib/postgresql/.dbus-XGodM5jOyL \
  /root/incident/original-dbus-XGodM5jOyL

限制证据文件权限：

sudo chown root:root \
  /root/incident/original-dbus-XGodM5jOyL \
  /root/incident/cron-payload

sudo chmod 600 \
  /root/incident/original-dbus-XGodM5jOyL \
  /root/incident/cron-payload

4. 结束恶意进程

确认恶意 cron 和启动脚本已隔离后，结束进程：

sudo kill -KILL 9918

检查进程是否消失：

ps -p 9918 \
  -o user,pid,ppid,%cpu,%mem,stat,comm,args

随后查看系统负载：

uptime

清理后的负载变为：

load average: 0.36, 2.71, 3.68

1 分钟负载已经从 4 以上下降到 0.36。

5 分钟和 15 分钟负载仍然较高是正常的，因为它们反映的是一段时间内的平均值，会逐渐下降。

5. 停止并禁用 PostgreSQL

因为业务并不使用 PostgreSQL，所以先停止并禁止开机启动：

sudo systemctl disable --now postgresql

确认服务状态：

systemctl status postgresql --no-pager

确认端口不再监听：

sudo ss -lntp | grep ':5432' \
  || echo "5432 端口未监听"

最终结果为：

5432 端口未监听

6. 卸载 PostgreSQL

确认业务没有受到影响后，卸载 PostgreSQL 相关软件包：

sudo apt-get purge -y \
  postgresql \
  postgresql-14 \
  postgresql-client-14 \
  postgresql-client-common \
  postgresql-common \
  postgresql-contrib

需要注意：

卸载软件包不等于完成恶意程序清理。

还应继续检查以下位置：

/var/lib/postgresql
/etc/postgresql
/etc/postgresql-common
/var/spool/cron
/tmp
/var/tmp
/dev/shm
/home/*/.config/systemd

本次发现的第二个恶意下载器，就是在卸载 PostgreSQL 后检查残留目录时找到的。

7. 隔离第二个恶意下载器

将伪装成 systemd 清理任务的脚本移入证据目录：

sudo mv \
  /var/lib/postgresql/.config/systemd/user/systemd-tmpfiles-cleanup/systemd-tmpfiles-cleanup-TNWow7.sh \
  /root/incident/systemd-tmpfiles-cleanup-TNWow7.sh

限制权限：

sudo chown root:root \
  /root/incident/systemd-tmpfiles-cleanup-TNWow7.sh

sudo chmod 600 \
  /root/incident/systemd-tmpfiles-cleanup-TNWow7.sh

然后搜索是否存在同类文件：

sudo grep -RIlE \
  'TNWow7|XGodM5jOyL|tor2socks|tor2web|relay\.tor2socks' \
  /etc \
  /var/spool/cron \
  /var/lib/postgresql \
  /tmp \
  /var/tmp \
  /dev/shm \
  /home \
  2>/dev/null

Azure 网络安全配置整改

1. 不需要删除不存在的 5432 入站规则

Azure NSG 中原本没有允许公网访问 5432 的规则，所以不需要专门删除 PostgreSQL 入站规则。

停止并卸载 PostgreSQL 后，本机也已经不再监听 5432。

但是，不能因为 NSG 没有开放 5432 就认为服务器已经安全。

2. 收紧 SSH 入站范围

排查过程中，SSH 日志中出现了多个公网 IP 对 postgres 用户进行密码尝试：

Failed password for postgres from 172.83.83.194
Failed password for postgres from 101.36.110.41

这些记录显示的是失败登录，不能说明对方已经通过 SSH 登录成功。但它们说明服务器的 SSH 正在被公网持续扫描。

原 Azure SSH 规则为：

Source: Any
Destination port: 22
Action: Allow

建议改为：

Source: 管理员固定公网 IP/32
Destination port: 22
Protocol: TCP
Action: Allow

更安全的方式包括：

• Azure Bastion；
• VPN；
• Just-In-Time VM Access；
• 禁止 SSH 密码登录；
• 只使用 SSH Key；
• 禁止 root 远程登录；
• 配置失败登录告警。

3. 限制服务器出站访问

恶意脚本需要连接外部地址下载程序，而当时 Azure NSG 允许任意出站访问。

如果业务条件允许，应限制服务器的出站范围：

• 只允许必要的 DNS；
• 只允许必要的软件源；
• 只允许业务需要访问的 API；
• 使用 Azure Firewall 或集中式代理；
• 记录 DNS 和出站网络日志；
• 对 Tor、代理、矿池和异常域名建立告警。

仅限制入站流量是不够的。恶意程序一旦进入服务器，通常还需要通过出站网络下载载荷、连接控制服务器或矿池。

为什么建议使用 Azure 托管 PostgreSQL？

如果业务确实需要 PostgreSQL，建议优先使用：

Azure Database for PostgreSQL

而不是直接在 Azure VM 上安装 PostgreSQL。

1. 减少操作系统层面的攻击面

在 VM 上自建 PostgreSQL，需要自行维护：

• Linux 操作系统；
• PostgreSQL 软件包；
• postgres 系统用户；
• SSH；
• cron；
• systemd；
• 数据目录权限；
• 安全补丁；
• 版本升级；
• 网络防火墙；
• 日志；
• 备份；
• 高可用；
• 恶意进程检测。

使用 Azure 托管 PostgreSQL 后，用户不会直接管理数据库所在主机的 root 权限，也不会在数据库主机上创建 cron、systemd 服务或运行 /dev/shm 中的程序。

这可以显著减少本次事件中出现的主机级风险。

2. 使用私有网络，关闭公网访问

建议采用以下网络架构：

Azure VM / App Service / AKS
          |
      Private Network
          |
Azure Database for PostgreSQL

数据库应配置为：

• 禁止公共网络访问；
• 使用 Private Endpoint 或私有网络集成；
• 只允许应用所在子网访问；
• 不向公网开放数据库端口；
• 数据库管理也通过 VPN、Bastion 或受控网络完成。

3. 自动备份和维护

Azure 托管 PostgreSQL 可以提供：

• 自动备份；
• 时间点恢复；
• 高可用选项；
• 数据加密；
• 监控指标；
• 日志与告警；
• 平台维护；
• 安全更新；
• 版本支持。

这些能力可以降低因长期无人维护而产生的风险。

4. 责任边界更清晰

自建 PostgreSQL 经常出现这种情况：

为了测试临时安装，后来业务不用了，但服务、用户和目录一直留在服务器上。

托管数据库的资源边界更加清晰：

• 需要时创建；
• 通过私有网络连接；
• 不再使用时导出数据；
• 删除数据库实例；
• 删除访问权限和私有连接；
• 不会在业务 VM 上留下数据库系统用户和历史脚本。

5. 托管服务并不等于绝对安全

Azure 托管 PostgreSQL 可以减少操作系统和基础设施维护风险，但仍需要正确管理：

• 数据库账号；
• 强密码或身份认证；
• 最小权限；
• 网络访问范围；
• SQL 注入；
• 连接字符串；
• Azure Key Vault；
• 日志审计；
• 数据加密；
• 应用依赖；
• 凭据轮换。

正确的理解是：

Azure 托管 PostgreSQL 缩小了需要自己负责的安全范围，但不会消除应用和账号层面的安全责任。

本次事件的 IOC

以下指标可用于内部服务器排查。

可疑进程及文件名

dzZ7yVrxv7
gJppJl6TbG
.dbus-XGodM5jOyL
systemd-tmpfiles-cleanup-TNWow7.sh

SHA-256

恶意 ELF 程序：

d32f9eef63c496a146a6a811677dd27e337db993d6f1a4b1af145c3135d391b3

恶意 cron 启动脚本：

36b1dcf43876f55aae2b8be7dada848b41f60ec61cd4ca7ab2a1278193f286f0

恶意下载器：

9962de5e0c68ea6e85879c5f62f2d0806360dbe186dc15e1d59abf8e4209de11

行为特征

• 以 postgres 用户运行；
• 从 /dev/shm 执行随机名称文件；
• 启动后删除原文件；
• 利用用户 crontab 定时启动；
• Base64 解码后直接交给 Bash 执行；
• 使用 Tor、SOCKS5 或 Tor2web；
• 收集公网 IP、用户名、主机名和机器 ID；
• 从外部下载其他程序；
• 在 /tmp、/var/tmp 和 /dev/shm 中执行程序；
• 持续占用全部 CPU；
• 伪装成 D-Bus 或 systemd 组件。

最终总结

本次事件从表面上看，是一次服务器 CPU 占用过高的问题。

但深入排查后发现，真正的问题包括：

• 以 postgres 用户运行的恶意程序；
• 位于 /dev/shm 的随机 ELF 文件；
• postgres 用户的恶意 cron；
• /var/lib/postgresql 下的隐藏启动脚本；
• 伪装成 systemd 组件的恶意下载器；
• 可连接 Tor 和外部下载地址的恶意逻辑。

最值得关注的是：

这台服务器没有通过 Azure NSG 向公网开放 PostgreSQL 的 5432 端口，而且业务也没有使用 PostgreSQL，但与 PostgreSQL 有关的系统用户、主目录、cron 和残留文件仍然构成了安全风险。

当然，现有证据并不能证明初始入侵入口就是 PostgreSQL。恶意程序使用 postgres 用户运行，不等于攻击者一定通过 PostgreSQL 端口进入服务器。

但这次事件依然说明了几个重要原则。

第一，不使用的服务应立即停止和卸载

不要因为“没有向公网开放”就长期保留闲置服务。

不使用的软件应当：

• 停止服务；
• 禁止开机启动；
• 卸载软件包；
• 检查系统用户；
• 检查 cron；
• 检查 systemd；
• 检查残留目录和脚本。

第二，云安全组不是唯一安全边界

NSG 没有开放 5432，只能说明公网无法通过该规则直接连接数据库，不能防止：

• 内网访问；
• 本机访问；
• 容器访问；
• 历史持久化；
• 用户级 cron；
• 本机恶意程序；
• SSH 和应用漏洞。

第三，生产 PostgreSQL 优先使用 Azure 托管服务

如果没有必须自建数据库服务器的明确需求，建议使用：

Azure Database for PostgreSQL + 私有网络 + 禁止公共访问。

这样可以减少数据库主机操作系统、SSH、系统用户、cron、systemd、补丁、备份和高可用等方面的维护风险。

第四，杀掉恶意进程不等于完成安全恢复

结束高 CPU 进程只解决了当前资源占用问题，还应继续：

• 查找持久化；
• 调查入侵入口；
• 检查 SSH 成功登录记录；
• 检查 Web 应用和容器；
• 轮换服务器上的全部凭据；
• 检查同一 VNet 中的其他主机；
• 保存日志和磁盘快照；
• 必要时从可信镜像重建服务器。

最终可以将这次事件概括为一句话：

不使用的数据库不要留在服务器上；需要 PostgreSQL 时，优先使用 Azure 托管 PostgreSQL，并通过私有网络访问。

随着 OpenWebUI 中的用户、对话、文件和知识库数据不断增长，原先部署在 Azure VM 上的自建 PostgreSQL 带来了越来越多的运维工作，包括数据库补丁、备份、故障恢复、存储监控和安全维护。

为了降低维护成本并提高数据库可靠性，我将 OpenWebUI 的业务数据库从 VM 本地 PostgreSQL 迁移到了 Azure Database for PostgreSQL Flexible Server。

这次迁移采用了：

在线全量迁移 + 数据一致性验证 + 活跃对话增量同步 + 快速切换

全量数据库导出和恢复期间，OpenWebUI 始终保持在线。最终切换仅涉及一次很短的 Docker 容器重建，用户侧基本无感。

本文中的服务器地址、数据库名称、用户名、密码和资源标识均已隐藏或替换为占位符。

迁移背景

OpenWebUI 以 Docker 容器形式运行在 Azure VM 中，最初使用安装在同一台 VM 上的 PostgreSQL。

迁移前的架构如下：

用户
  │
  ▼
Azure VM
  ├── OpenWebUI Docker 容器
  │      └── 连接 VM 宿主机 PostgreSQL
  │
  └── PostgreSQL
         └── 数据保存在 VM 本地磁盘

这种部署方式比较简单，但随着应用逐渐稳定运行，数据库维护也成为了新的负担。

需要自行处理的工作包括：

• PostgreSQL 安全更新和补丁
• 数据库备份及备份轮换
• 数据恢复和恢复演练
• 磁盘容量监控
• 数据库服务监控
• PostgreSQL 版本升级
• 故障处理
• 网络和访问权限管理

对于 OpenWebUI 这样的应用来说，数据库是重要的状态组件，但并不是应用的核心运维目标。因此，将 PostgreSQL 迁移到 Azure 托管服务是一个更合理的选择。

迁移后的架构

迁移后的架构如下：

用户
  │
  ▼
Azure VM
  └── OpenWebUI Docker 容器
          │
          ├── Private Endpoint
          │       └── Azure Database for PostgreSQL
          │
          └── 宿主机持久化目录
                  ├── uploads
                  ├── vector_db
                  └── cache

最终实现了：

• OpenWebUI 使用 Azure 托管 PostgreSQL
• 数据库通过 Private Endpoint 私网访问
• 数据库连接启用 TLS
• PostgreSQL 不再占用 VM 本地端口和磁盘
• OpenWebUI 上传文件和向量数据实现持久化挂载
• Azure 自动执行数据库备份
• VM 上只保留 PostgreSQL 客户端，用于日常管理 Azure 数据库

为什么选择 Azure Database for PostgreSQL

1. 降低数据库运维成本

Azure Database for PostgreSQL Flexible Server 是一项托管数据库服务。

与 VM 自建 PostgreSQL 相比，Azure 可以帮助处理大量底层工作，例如：

• 数据库基础设施维护
• 自动备份
• 事务日志备份
• 时间点恢复
• 监控指标采集
• 存储管理
• 计划性维护
• 可选高可用
• 可选只读副本

迁移完成后，VM 只需要负责运行 OpenWebUI，数据库生命周期则交给 Azure 管理。

2. 自动备份和时间点恢复

Azure PostgreSQL 提供内置自动备份，并持续备份事务日志，支持时间点恢复（Point-in-Time Restore，PITR）。

当前环境配置了自动备份保留策略。发生误操作时，可以在保留期内创建一台恢复到指定时间点的新服务器。

与自行编写 pg_dump 和 Cron 脚本相比，Azure 托管备份具有以下优势：

• 不需要维护备份脚本
• 不需要手动轮换备份文件
• 不会占用 VM 本地磁盘
• 可以恢复到保留期内的特定时间
• 备份操作由平台统一管理

需要注意的是，Azure 内置备份主要用于平台恢复，不等同于可随意下载的逻辑备份文件。

如果有以下需求，仍建议额外定期执行 pg_dump：

• 长期离线归档
• 跨平台恢复
• 数据审计
• 跨订阅或跨云迁移
• 保留期超过平台备份策略

3. 使用 Private Endpoint 私网访问

本次迁移没有将 PostgreSQL 直接暴露到公网，而是为 Azure PostgreSQL 配置了 Private Endpoint。

OpenWebUI 访问数据库时，数据库域名通过 Private DNS 解析到 VNet 中的私有 IP：

Azure PostgreSQL FQDN
        ↓
Private DNS
        ↓
Private Endpoint 私有 IP

从 OpenWebUI 容器内部进行了两层验证：

1. DNS 是否解析到私有地址
2. TCP 5432 是否可以通过私网访问

示例：

docker exec -i open-webui python3 - <<'PY'
import socket

host = "<AZURE_POSTGRESQL_PRIVATE_FQDN>"
port = 5432

addresses = sorted({
    item[4][0]
    for item in socket.getaddrinfo(
        host,
        port,
        type=socket.SOCK_STREAM
    )
})

print("Resolved addresses:", addresses)

with socket.create_connection((host, port), timeout=5) as sock:
    print("TCP connection: OK")
    print("Connected peer:", sock.getpeername())
PY

数据库安全性并不只是来自 Private Endpoint，而是来自以下措施的组合：

• Private Endpoint
• Private DNS
• VNet 隔离
• NSG 和路由控制
• 禁用或限制公网访问
• PostgreSQL 身份认证
• TLS 链路加密
• 最小权限数据库账号

4. 数据库连接启用 TLS

OpenWebUI 的数据库连接串启用了：

sslmode=require

脱敏后的连接串格式如下：

postgresql://<APP_USER>:<PASSWORD>@<AZURE_POSTGRESQL_FQDN>:5432/<APP_DATABASE>?sslmode=require

迁移前还通过 OpenWebUI 使用的 Python 和 SQLAlchemy 环境实际验证了 TLS：

import os
from sqlalchemy import create_engine, text

engine = create_engine(os.environ["DATABASE_URL"])

with engine.connect() as conn:
    ssl_enabled = conn.execute(text("""
        SELECT ssl
        FROM pg_stat_ssl
        WHERE pid = pg_backend_pid()
    """)).scalar_one()

print("TLS enabled:", ssl_enabled)

如果安全要求更高，可以进一步使用：

sslmode=verify-full

这种模式不仅加密连接，还会验证证书和服务器主机名，但需要正确配置 CA 证书，并使用与证书匹配的服务器 FQDN。

5. 更容易扩展可靠性能力

迁移到 Azure PostgreSQL 后，可以根据 OpenWebUI 的使用规模继续配置：

• 计算规格扩缩容
• 存储扩容
• 可用区高可用
• 只读副本
• 慢查询分析
• 数据库连接监控
• CPU、内存和存储告警
• 更长的备份保留期
• 异地恢复策略

这使 OpenWebUI 的数据库层从“单 VM 上的本地服务”升级为独立、可管理的托管数据服务。

迁移目标：让 OpenWebUI 尽量保持在线

传统迁移通常采用以下流程：

停止应用
  ↓
导出数据库
  ↓
恢复目标数据库
  ↓
修改连接配置
  ↓
重新启动应用

这种方式虽然简单，但数据库越大，停机时间越长。

本次迁移采用了不同策略：

在线全量备份
  ↓
在线恢复到 Azure PostgreSQL
  ↓
验证结构、权限和数据
  ↓
同步迁移期间新增的活跃对话
  ↓
快速重建 OpenWebUI 容器

在以下阶段，OpenWebUI 都保持在线：

• 全量 pg_dump
• Azure PostgreSQL 数据恢复
• 表结构验证
• 数据量对比
• Private Endpoint 验证
• TLS 验证
• 增量数据同步

最终只有更换 DATABASE_URL 并重建容器时发生了短暂连接中断。

因此，更准确地说，这是一种：

近零停机、用户侧近乎无感知的 OpenWebUI 数据库迁移方案。

迁移前检查 OpenWebUI

1. 确认 OpenWebUI 使用的数据库类型

首先检查 OpenWebUI 容器环境变量：

docker inspect open-webui \
  --format '{{range .Config.Env}}{{println .}}{{end}}' |
grep -E 'DATABASE_URL|DATA_DIR|WEBUI_SECRET_KEY'

确认 OpenWebUI 已经使用 PostgreSQL，而不是默认 SQLite：

DATABASE_URL=postgresql://<LOCAL_USER>:***@<LOCAL_HOST>:5432/<LOCAL_DATABASE>

由于源端和目标端都是 PostgreSQL，因此可以直接使用：

pg_dump → pg_restore

不需要使用 SQLite 到 PostgreSQL 的转换工具。

2. 检查源数据库

检查 PostgreSQL 版本和数据库大小：

sudo -u postgres psql \
  -d <LOCAL_DATABASE> \
  -c "
SELECT
  current_database(),
  current_setting('server_version'),
  pg_size_pretty(
    pg_database_size(current_database())
  );
"

同时检查源数据库使用了哪些扩展：

sudo -u postgres psql \
  -d <LOCAL_DATABASE> \
  -c "
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;
"

本次源数据库没有使用额外的第三方扩展，因此降低了跨环境迁移的兼容性风险。

3. 检查 OpenWebUI 的本地文件

数据库并不是 OpenWebUI 的全部数据。

检查容器挂载后发现，原容器没有配置持久化 volume，而 /app/backend/data 中已经存在大量数据：

/app/backend/data
├── cache
├── uploads
└── vector_db

这些内容包括：

• 用户上传文件
• 向量数据库
• 缓存
• 其他应用本地状态

它们不会进入 PostgreSQL 的 pg_dump，因此必须单独处理。

这也是本次迁移中一个非常重要的发现：

迁移 OpenWebUI 的 PostgreSQL，并不等于迁移了 OpenWebUI 的全部数据。

准备 Azure PostgreSQL

1. 创建独立应用账号

不建议让 OpenWebUI 长期使用 Azure PostgreSQL 管理员账号。

在目标服务器中创建专用角色：

CREATE ROLE <APP_USER> LOGIN;

通过 psql 交互方式设置密码，可以避免密码出现在 Shell 历史记录中：

\password <APP_USER>

然后创建目标数据库：

CREATE DATABASE <APP_DATABASE>
OWNER <APP_USER>;

2. 验证应用账号

psql \
  "host=<AZURE_POSTGRESQL_FQDN> \
   port=5432 \
   dbname=<APP_DATABASE> \
   user=<APP_USER> \
   sslmode=require" \
  -W \
  -c "SELECT current_user, current_database();"

同时确认目标数据库为空：

SELECT count(*)
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_type = 'BASE TABLE';

3. 处理 public schema 权限

第一次测试恢复时遇到了：

ERROR: permission denied for schema public

原因是应用账号虽然可以连接数据库，但没有在 public schema 中创建对象的权限。

使用管理员账号连接目标数据库后执行：

ALTER SCHEMA public OWNER TO <APP_USER>;

GRANT USAGE, CREATE
ON SCHEMA public
TO <APP_USER>;

这个问题说明，仅验证账号“能否登录”还不够，还需要确认该账号能否：

• 创建表
• 创建索引
• 创建序列
• 创建约束
• 执行 OpenWebUI 的 Alembic 数据库迁移

在线执行全量数据库迁移

1. 在线导出 OpenWebUI 数据库

PostgreSQL 的 pg_dump 会基于一致性事务快照导出数据，因此可以在 OpenWebUI 继续运行时执行。

sudo -u postgres pg_dump \
  --dbname=<LOCAL_DATABASE> \
  --format=custom \
  --no-owner \
  --no-acl \
  --file=/tmp/openwebui-pre-migration.dump

参数含义：

• --format=custom：使用 PostgreSQL 自定义归档格式
• --no-owner：不恢复源端对象 owner
• --no-acl：不恢复源端权限
• --file：指定备份文件

检查归档是否有效：

pg_restore \
  --list \
  /tmp/openwebui-pre-migration.dump |
head -30

自定义格式会保留：

• 表结构
• 表数据
• 主键
• 唯一约束
• 索引
• 外键
• 序列
• Alembic 迁移版本

2. 恢复到 Azure PostgreSQL

pg_restore \
  --host=<AZURE_POSTGRESQL_FQDN> \
  --port=5432 \
  --username=<APP_USER> \
  --dbname=<APP_DATABASE> \
  --no-owner \
  --no-acl \
  --exit-on-error \
  --verbose \
  /tmp/openwebui-pre-migration.dump

使用：

--exit-on-error

可以确保遇到恢复错误时立即停止，避免忽略关键问题。

恢复成功后更新统计信息：

psql \
  "host=<AZURE_POSTGRESQL_FQDN> \
   port=5432 \
   dbname=<APP_DATABASE> \
   user=<APP_USER> \
   sslmode=require" \
  -W \
  -c "ANALYZE;"

对比源端与目标端数据

恢复完成后，需要对 OpenWebUI 的核心表进行对比。

示例查询：

SELECT
  (SELECT count(*) FROM "user") AS users,
  (SELECT count(*) FROM chat) AS chats,
  (SELECT count(*) FROM chat_message) AS chat_messages,
  (SELECT count(*) FROM file) AS files,
  (SELECT count(*) FROM knowledge) AS knowledge,
  (
    SELECT count(*)
    FROM information_schema.tables
    WHERE table_schema = 'public'
      AND table_type = 'BASE TABLE'
  ) AS tables;

重点检查：

• 用户数量
• 对话数量
• 消息数量
• 文件记录数量
• 知识库数量
• 业务表数量
• Alembic 版本
• 表 owner
• 序列状态

对比时发现，目标端的对话消息比源端少了少量记录。

这并不是恢复失败，而是因为：

在全量备份和恢复过程中，OpenWebUI 仍然在线，当前迁移操作的对话还在不断产生新消息。

因此，下一步需要同步全量快照之后新增的数据。

同步迁移期间新增的活跃对话

本次迁移期间，主要只有当前操作对话仍在更新，因此没有再次恢复整个数据库，而是只同步当前活跃对话。

涉及两张表：

chat
chat_message

1. 找到最近更新的对话

SELECT
  c.id,
  c.title,
  to_timestamp(c.updated_at) AS updated_at,
  count(cm.id) AS message_count
FROM chat c
LEFT JOIN chat_message cm
  ON cm.chat_id = c.id
GROUP BY
  c.id,
  c.title,
  c.updated_at
ORDER BY c.updated_at DESC
LIMIT 5;

确定活跃对话后，后续脚本通过环境变量或参数接收对话 ID，而不是将其直接写入公开文档：

CHAT_ID="<ACTIVE_CHAT_ID>"

2. 使用一致性快照导出对话数据

为了保证 chat 和 chat_message 来自同一个时间点，使用只读、可重复读事务：

BEGIN TRANSACTION
ISOLATION LEVEL REPEATABLE READ
READ ONLY;

然后在同一事务中导出：

\copy (
  SELECT *
  FROM chat
  WHERE id = '<ACTIVE_CHAT_ID>'
) TO '/tmp/chat.csv'
WITH (FORMAT CSV);

\copy (
  SELECT *
  FROM chat_message
  WHERE chat_id = '<ACTIVE_CHAT_ID>'
  ORDER BY created_at, id
) TO '/tmp/chat-messages.csv'
WITH (FORMAT CSV);

最后提交：

COMMIT;

需要注意：psql 的 \copy 是客户端元命令，复杂字段列表最好写在同一行，否则可能出现：

\copy: parse error at end of line

3. 在 Azure 中使用临时表和 UPSERT

目标端创建临时 staging 表：

CREATE TEMP TABLE stage_chat
(LIKE public.chat INCLUDING DEFAULTS);

CREATE TEMP TABLE stage_chat_message
(LIKE public.chat_message INCLUDING DEFAULTS);

将 CSV 导入临时表后，对 chat 主记录执行 UPSERT：

INSERT INTO public.chat (...)
SELECT ...
FROM stage_chat
ON CONFLICT (id) DO UPDATE SET
  title              = EXCLUDED.title,
  updated_at         = EXCLUDED.updated_at,
  chat               = EXCLUDED.chat,
  meta               = EXCLUDED.meta,
  current_message_id = EXCLUDED.current_message_id;

对消息表执行类似操作：

INSERT INTO public.chat_message (...)
SELECT ...
FROM stage_chat_message
ON CONFLICT (id) DO UPDATE SET
  content         = EXCLUDED.content,
  output          = EXCLUDED.output,
  status_history  = EXCLUDED.status_history,
  error           = EXCLUDED.error,
  usage           = EXCLUDED.usage,
  done            = EXCLUDED.done,
  updated_at      = EXCLUDED.updated_at,
  context_summary = EXCLUDED.context_summary;

为了让 Azure 中该对话的消息集合与源快照完全一致，还会删除目标端多余记录：

DELETE FROM public.chat_message target
WHERE target.chat_id = '<ACTIVE_CHAT_ID>'
  AND NOT EXISTS (
    SELECT 1
    FROM stage_chat_message staged
    WHERE staged.id = target.id
  );

整个导入和 UPSERT 过程放在一个事务中执行：

BEGIN;

-- 创建临时表
-- 导入数据
-- UPSERT
-- 清理多余记录

COMMIT;

如果任何步骤失败，事务会自动回滚，不会留下部分同步数据。

最终快速切换 OpenWebUI

完成在线全量迁移后，最终操作为：

最后同步一次当前活跃对话
              ↓
重建 OpenWebUI 容器
              ↓
新容器连接 Azure PostgreSQL

示例：

./sync-active-chat-to-azure.sh && \
docker compose \
  -f run-with-azure-pg.yml \
  up -d --force-recreate

完整数据库已经提前迁移并验证，因此最终阶段不需要再次等待几百 MB 数据恢复，只需要同步少量增量记录并快速重建容器。

这将切换窗口缩短到了容器启动所需的时间。

安全保存 OpenWebUI 数据库连接串

数据库连接串没有直接写入 Compose 文件，而是放在独立环境文件中：

open-webui-azure-db.env

文件内容形式：

DATABASE_URL=postgresql://<APP_USER>:<URL_ENCODED_PASSWORD>@<AZURE_POSTGRESQL_FQDN>:5432/<APP_DATABASE>?sslmode=require

文件权限设置为：

chmod 600 open-webui-azure-db.env

如果密码包含特殊字符，需要先进行 URL 编码：

python3 - <<'PY'
import getpass
import urllib.parse

password = getpass.getpass("Database password: ")
print(urllib.parse.quote(password, safe=""))
PY

新的 Compose 文件示例：

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:<VERSION>
    container_name: open-webui
    restart: always

    ports:
      - "8080:8080"

    env_file:
      - ./open-webui.env
      - ./open-webui-azure-db.env

    volumes:
      - /opt/open-webui/data:/app/backend/data

持久化 OpenWebUI 本地文件

迁移前，OpenWebUI 的 /app/backend/data 没有挂载到宿主机。

先将数据复制出来：

sudo install \
  -d \
  -m 700 \
  -o "$(id -un)" \
  -g "$(id -gn)" \
  /opt/open-webui/data

docker cp \
  open-webui:/app/backend/data/. \
  /opt/open-webui/data/

在 Compose 中加入：

volumes:
  - /opt/open-webui/data:/app/backend/data

这样，即使未来重建或升级 OpenWebUI 容器，以下内容仍会保留：

• 上传文件
• 向量数据库
• 缓存
• 其他本地应用数据

迁移后验证：

docker inspect open-webui \
  --format '{{range .Mounts}}{{println .Source "->" .Destination "rw=" .RW}}{{end}}'

预期：

/opt/open-webui/data -> /app/backend/data rw=true

迁移后的验证

1. OpenWebUI 健康检查

curl \
  -sS \
  -o /dev/null \
  -w 'HTTP %{http_code}\n' \
  --max-time 10 \
  http://127.0.0.1:8080/health

预期：

HTTP 200

2. 验证 OpenWebUI 当前数据库

为了避免输出密码，只解析连接串中的非敏感部分：

docker exec -i open-webui python3 - <<'PY'
import os
from urllib.parse import urlsplit

u = urlsplit(os.environ["DATABASE_URL"])

print("Database host configured:", bool(u.hostname))
print("Database port:", u.port)
print("TLS required:", "sslmode=require" in u.query)
PY

验证重点：

• Host 已不再指向 VM 本地 PostgreSQL
• 端口为 5432
• 已启用 sslmode=require

3. 检查启动日志

docker logs \
  --since 15m \
  open-webui 2>&1 |
grep -Ei \
  'error|fatal|exception|traceback|permission denied|database|postgres|alembic|ssl|timeout'

正常情况下只会看到类似：

INFO [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO [alembic.runtime.migration] Will assume transactional DDL.

不应出现：

• 数据库连接失败
• 密码认证失败
• TLS 错误
• Schema 权限错误
• Alembic 迁移失败
• Python Traceback

卸载 VM 本地 PostgreSQL

确认 OpenWebUI 已稳定连接 Azure PostgreSQL 后，可以删除 VM 上的本地 PostgreSQL。

首先确认：

• OpenWebUI 健康检查正常
• 数据库连接已切换
• Azure PostgreSQL 中存在最新数据
• 自动备份策略已经启用
• 本地 PostgreSQL 不再有应用连接

停止并删除本地集群：

sudo pg_dropcluster \
  --stop \
  <POSTGRESQL_VERSION> \
  main

卸载 PostgreSQL 服务端：

sudo apt-get purge -y \
  postgresql \
  postgresql-<POSTGRESQL_VERSION> \
  postgresql-contrib

删除遗留数据和配置：

sudo rm -rf \
  /var/lib/postgresql \
  /etc/postgresql \
  /var/log/postgresql

可以继续保留 PostgreSQL 客户端：

postgresql-client
postgresql-client-common

这样仍然可以从 VM 使用 psql 管理 Azure PostgreSQL。

最终检查本地 5432：

if sudo ss -lntp | grep -q ':5432'; then
  sudo ss -lntp | grep ':5432'
else
  echo "No local PostgreSQL listener"
fi

迁移过程中的经验总结

1. 数据库迁移不等于 OpenWebUI 全部数据迁移

OpenWebUI 除了 PostgreSQL，还可能在 /app/backend/data 中保存：

• 上传文件
• 向量数据库
• 缓存
• 本地状态文件

只执行 pg_dump 并不能迁移这些内容。

2. 不要只测试端口连通

nc 成功只能证明 TCP 5432 可达，并不能证明：

• PostgreSQL 用户可以登录
• 密码正确
• TLS 正常
• 数据库权限正确
• OpenWebUI 使用的驱动兼容

应至少完成以下验证：

DNS → TCP → PostgreSQL 登录 → TLS → SQL 查询 → OpenWebUI 实际连接

3. 数据库 owner 不代表一定拥有 schema 创建权限

即使应用用户是数据库 owner，也可能遇到：

permission denied for schema public

迁移前应验证应用账号是否具备：

• USAGE
• CREATE
• 表和序列所有权
• Alembic DDL 权限

4. 在线全量备份后必须处理增量写入

pg_dump 提供的是开始备份时的一致性快照。

备份期间 OpenWebUI 新产生的对话和消息不会自动进入已经完成的 dump。因此在线迁移必须增加以下机制之一：

• 最终停写后重新完整备份
• 逻辑复制
• CDC
• 应用双写
• 按业务对象执行增量同步

本次采用的是“全量快照 + 活跃对话 UPSERT”。

5. 不要在迁移时顺便升级 OpenWebUI

本次迁移始终保持 OpenWebUI 镜像版本不变。

如果同时升级应用和迁移数据库，一旦发生问题，很难快速判断原因来自：

• PostgreSQL 版本
• 数据迁移
• Azure 网络
• 数据库权限
• OpenWebUI 版本
• Alembic schema 变化

更稳妥的做法是：

先迁移数据库并稳定运行
          ↓
再单独升级 OpenWebUI

这算不算真正的零停机？

从用户体验看，这次迁移接近零停机：

• 在线完成全量备份
• 在线恢复目标数据库
• 在线完成数据验证
• 在线同步活跃对话
• 仅在最后重建了一次 OpenWebUI 容器

但如果采用严格工程定义，真正的零停机还需要满足：

• 任意时刻都能接受新连接
• 最后时刻写入绝不丢失
• 没有单实例容器重启窗口
• 客户端连接完全不中断
• 具备自动流量切换能力

更大规模的 OpenWebUI 部署可以考虑：

• PostgreSQL 逻辑复制
• Azure Database Migration Service
• CDC 增量迁移
• 应用双写
• 蓝绿部署
• 多个 OpenWebUI 实例
• 反向代理健康检查
• 连接排空和流量切换

对于单 VM、单 OpenWebUI 容器和中小规模数据库，本次采用的方案在复杂度、风险和停机时间之间取得了较好的平衡。

迁移后的日常运维

启动 OpenWebUI：

docker compose \
  -f run-with-azure-pg.yml \
  up -d

查看状态：

docker compose \
  -f run-with-azure-pg.yml \
  ps

查看日志：

docker compose \
  -f run-with-azure-pg.yml \
  logs -f --tail=200

健康检查：

curl \
  -sS \
  -o /dev/null \
  -w 'HTTP %{http_code}\n' \
  http://127.0.0.1:8080/health

日常还应重点监控 Azure PostgreSQL 的：

• CPU 使用率
• 内存使用情况
• 存储空间
• 活跃连接数
• 失败连接数
• 查询延迟
• 自动备份状态
• 维护事件
• Private Endpoint 状态

总结

这次迁移将 OpenWebUI 的数据库从 Azure VM 自建 PostgreSQL 平滑迁移到了 Azure Database for PostgreSQL Flexible Server。

最终实现了：

• OpenWebUI 数据库由 Azure 托管
• 通过 Private Endpoint 私网访问
• 数据库连接启用 TLS
• 自动备份和时间点恢复
• OpenWebUI 本地文件持久化
• VM 本地 PostgreSQL 完全下线
• 本地 5432 端口关闭
• 全量迁移期间应用持续在线
• 最终切换对用户影响极低

本次最关键的经验是：

对 OpenWebUI 进行低停机数据库迁移，不应只关注 pg_dump 和 pg_restore，还必须同时考虑增量写入、Private Endpoint、TLS、数据库权限、Alembic 迁移以及 /app/backend/data 中的本地文件。

通过“在线全量迁移、目标端预验证、活跃数据增量同步、快速容器切换”，可以在不引入复杂 CDC 平台的情况下，将中小规模 OpenWebUI 平滑迁移到 Azure 托管 PostgreSQL。

在 vLLM Semantic Router 的设计中，Embedding 推理是驱动语义路由的核心信号之一。

官方教程已经演示了如何使用远程 Embedding 推理提供商（Remote Embedding Providers）替代本地 Embedding 推理服务：

👉 https://vllm-sr.ai/docs/tutorials/global/remote-embeddings/

然而，在实际生产环境中，一个更为关键的问题随之而来：

如何使用企业级、可扩展的 Embedding 推理服务来支持语义路由？

本文基于官方教程中的场景，并结合 Microsoft Foundry Embedding 模型，演示如何构建一个具备以下特性的智能路由系统：

• 无需 GPU
• 无需在本地部署 Embedding 模型
• 生产就绪

2. 回顾：远程 Embedding 推理提供商

在 vLLM Semantic Router 中，路由器运行在 CPU 上，不依赖 GPU 推理能力。

通过远程 Embedding 推理提供商：

路由器 → 远程 Embedding 推理 API → 向量

我们可以：

• 将嵌入计算完全卸载到云服务
• 统一多模型的语义能力
• 解耦路由与推理

3. 教程场景（沿用官方测试场景）

在官方教程中，核心流程如下：

第 1 步：定义语义路由

routing:
  decisions:
    - name: math
      when:
        semantic_similarity:
          text: "math question"
          threshold: 0.8

    - name: general

第 2 步：发送请求

curl http://localhost:8888/v1/chat/completions \
  -d '{
    "model": "MoM",
    "messages": [{"role": "user", "content": "What is 1+1?"}]
  }'

路由器将执行以下操作：

1. 生成嵌入向量
2. 执行语义匹配
3. 选择目标模型

4. 第 0 步：在 Microsoft Foundry 中创建 Embedding 模型

在与 vLLM Semantic Router 集成之前，我们首先需要在 Microsoft Foundry 中部署一个 Embedding 模型。

4.1 创建 Foundry 项目

1. 前往 Microsoft Foundry 门户
2. 创建新项目（或选择现有项目）
3. 确保该项目已关联 Azure 订阅

4.2 部署嵌入模型

在模型目录中：

1. 搜索 Embedding 模型
2. 选择受支持的模型（例如 text-embedding-3-small）
3. 单击 Deploy（部署）

部署完成后，你将获得：

• Endpoint URL
• API Key
• Model Name

示例：

Endpoint: https://<your-foundry-resource>.inference.ai.azure.com
Model: text-embedding-3-small
API Key: ******

4.3 验证 Embedding 推理 API

你可以直接测试该终结点：

curl https://<your-foundry-endpoint>/v1/embeddings \
  -H "api-key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Hello world"
  }'

如果调用成功，你将收到包含向量的响应。

5. 升级：使用 Microsoft Foundry 替代本地 Embedding 模型

现在，我们将教程中的 Embedding 推理提供商替换为：

✅ Microsoft Foundry Embedding 模型

6. 为什么选择 Microsoft Foundry Embedding 模型

Microsoft Foundry 提供：

• 高质量 Embedding 模型（更强的语义理解能力）
• 托管 API（无需自行部署）
• 全球可用性与企业级 SLA
• 与 Azure AI 生态系统无缝集成

更重要的是：

它可以直接充当 Semantic Router 的“语义大脑”

7. 集成：将 Microsoft Foundry 用作远程 Embedding 推理提供商

7.1 配置 Embedding 推理提供商

providers:
  embedding:
    type: remote
    provider: openai-compatible
    base_url: https://<your-foundry-endpoint>
    api_key: <your-api-key>
    model: text-embedding-3-small

说明：

• Foundry 提供兼容 OpenAI 的 API
• 可以直接复用 Semantic Router 的远程 Embedding 推理提供商
• 无需额外适配

7.2 路由器工作流

用户请求
   ↓
Semantic Router
   ↓
Microsoft Foundry Embedding 推理 API
   ↓
向量相似度计算
   ↓
路由决策
   ↓
目标模型（vLLM / API）

8. 相比官方教程的主要改进

9. 实际价值

🚀 1. 真正的“无 GPU 架构”

路由器本身运行在 CPU 上。

Embedding 模型与推理能力完全外部化：

• Foundry → Embedding 模型
• vLLM / API → 推理

🧠 2. 更准确的语义路由

在教程场景中：

"What is 1+1?" → math 路由
"Tell me a joke" → general 路由

使用 Foundry 嵌入后，可以获得：

• 更稳定的语义理解
• 更好的多语言支持
• 对边界场景更准确的判断

🌐 3. 统一的多模型入口

结合 Semantic Router：

• Microsoft Foundry（Embedding 模型）
• vLLM（自托管推理）
• OpenAI / 其他 API

从而实现真正的：

多提供商智能路由

10. 架构洞察

此次升级的本质是：

升级前：
路由器 = 基础设施 + 智能

升级后：
路由器 = 智能
Foundry = AI 能力

由此形成清晰的分层架构：

[ AI 能力层 ] → Microsoft Foundry
[ 路由层    ] → Semantic Router
[ 推理层    ] → vLLM / APIs

11. 总结

通过将 Microsoft Foundry 与官方远程 Embedding 模型教程相结合，我们实现了一套生产就绪的架构：

• 无需本地 Embedding 模型
• 无需 GPU
• 高质量的语义能力
• 企业级可靠性

这不仅是一次功能增强，更是 Semantic Router 的一次关键演进：

从“本地工具”演进为“云原生 AI 路由层”

如何在不显式指定模型 ID 的情况下，让系统自动选择最合适的模型？

本文介绍一种工程可落地的方案：

通过 Embedding 模型计算用户意图 → 在网关层进行语义匹配 → 动态路由到最合适的上游模型服务

我们将基于：

• Embedding 模型：Azure OpenAI text-embedding-3-small
• 网关：Envoy
• 核心机制：向量相似度打分 + 策略路由

问题背景与动机

在真实生产环境中，大模型调用通常面临几个挑战：

1. 成本与性能权衡

不同请求应该走不同模型，而不是“一刀切”。

2. 传统做法的局限

常见策略：

• 手动指定 model_id ❌（不智能）
• 基于规则（if/else）❌（不可扩展）
• 基于关键词匹配 ❌（语义不鲁棒）

3. 理想目标

我们希望：

用户只输入 prompt，系统自动理解“意图”，并选择最优模型

这正是 Embedding 可以发挥作用的地方。

核心原理：Embedding 驱动的语义路由

1. Embedding 本质

Embedding 模型（如 text-embedding-3-small）可以将文本映射为高维向量：

"写一段 Python 排序代码"
→ [0.012, -0.98, ..., 0.33]  (1536维向量)

语义相似的文本，其向量距离更近。

2. 路由思路

核心逻辑可以抽象为：

用户请求 → Embedding → 与“意图模板库”计算相似度 → 选择最佳匹配 → 路由模型

3. 意图模板（Intent Prototypes）

我们预先定义一组“意图向量”：

这些文本会提前计算 embedding 并缓存。

4. 相似度计算

常用方法：

• Cosine Similarity（推荐）

similarity = cosine(query_embedding, intent_embedding)

选择最高分：

argmax(similarity_i)

系统架构设计

整体架构如下：

                ┌──────────────┐
                │   Client     │
                └──────┬───────┘
                       │
               ┌───────▼────────┐
               │    Envoy 网关   │
               │   (智能路由层)   │
               └───────┬────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
 ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐
 │ GPT-4      │ │ GPT-4o-mini│ │ 专用模型    │
 └────────────┘ └────────────┘ └────────────┘

实现逻辑拆解

1. 请求流程

Step 1：获取用户请求

{
  "input": "帮我写一段 Go 的 HTTP server 示例"
}

Step 2：调用 Embedding API

使用 Azure OpenAI：

POST https://{endpoint}/openai/deployments/text-embedding-3-small/embeddings?api-version=2024-02-15-preview

请求体：

{
  "input": "帮我写一段 Go 的 HTTP server 示例"
}

Step 3：计算相似度

伪代码：

def route(query_embedding):
    best_score = -1
    best_model = None

    for intent in intents:
        score = cosine_similarity(query_embedding, intent.embedding)
        if score > best_score:
            best_score = score
            best_model = intent.model

    return best_model

Step 4：Envoy 动态路由

将结果写入 Header：

x-llm-route: gpt-4

Envoy 根据 Header 路由：

routes:
- match:
    prefix: "/v1/chat"
    headers:
      - name: x-llm-route
        exact_match: gpt-4
  route:
    cluster: gpt4_service

Envoy 网关实现方式

Envoy 本身不直接支持向量计算，因此需要扩展：

方案 1：External Processing（推荐）

Envoy 调用外部服务（ext_proc）：

Envoy → ext_proc 服务 → 返回路由决策 → Envoy 转发

ext_proc 负责：

• 调用 embedding
• 计算相似度
• 返回 header

方案 2：WASM 插件

在 Envoy 内嵌逻辑：

• 优点：低延迟
• 缺点：开发复杂（Rust/CPP）

方案 3：Sidecar Router（简单）

Client → Router Service → Envoy → Model

Router 服务负责所有智能逻辑。

优化策略

1. 向量缓存

避免重复调用 embedding：

cache[input_hash] = embedding

2. 意图分层

避免单层分类过粗：

一级：代码 / 问答 / 写作
二级：语言 / 长度 / 难度

3. 阈值控制

if best_score < threshold:
    fallback_model = "gpt-4"

防止误判。

4. 多模型融合（Ensemble）

可扩展为：

• Top-K 模型候选
• A/B 测试
• 加权路由

5. 成本感知路由

结合：

• token 预算
• 用户等级
• SLA

做策略增强：

if user == "free":
    prefer_small_model()

优势分析

相比规则路由

相比手动指定模型

• 用户体验更好（无需关心模型）
• 自动最优成本
• 支持动态策略

落地建议

1. 初始阶段

• 5~10 个意图模板即可
• 手动标注 + 调优

2. 数据驱动优化

记录：

• 用户请求
• 路由结果
• 用户反馈

持续优化 intent embedding。

3. 与 LLM Router 结合

未来可以升级为：

用小模型 + embedding 混合决策（Hybrid Router）

总结

本文方案的本质是：

用 Embedding 替代规则，用向量相似度驱动模型选择

关键收益：

• 降低成本（智能选择轻量模型）
• 提升效果（复杂任务走强模型）
• 架构解耦（路由逻辑与模型解耦）

在多模型时代，这种“语义驱动的网关”会成为标准架构组件。

在过去一年里，AI 编程的主流交互方式经历了一个明显演进：

Prompt → Prompt Engineering → Context Engineering → Skill（能力封装）

如果说 Prompt 是一次性调用模型能力，那么 Skill 本质上是在构建“可复用的智能能力模块”，它让 AI 从“会回答问题”，进化为“能执行任务”。

这篇文章将系统讲清：

• 什么是 AI 编程中的 Skill
• Skill 与 Prompt 的本质区别
• 如何在 VS Code + GitHub Copilot Chat 中使用 Skill 思维
• 实战案例（工程级）

什么是 Skill？

在 AI 编程语境下，Skill = 结构化提示 + 上下文 + 执行约束 + 输出格式

可以用一个更工程化的定义：

Skill = f(Instruction, Context, Constraints, Output Schema)

它不是一句 prompt，而是一个“可复用的能力接口”。

对比理解

为什么 Skill 很重要？

在实际开发中，AI 使用很快会遇到几个瓶颈：

1. Prompt 不稳定

同一个问题，换个说法结果不同

2. 团队无法复用经验

每个人都有自己的“私有 prompt”

3. AI 输出不可控

格式、风格、边界难以统一

Skill 的价值

• 标准化能力
• 沉淀团队最佳实践
• 降低认知负担
• 提升输出一致性

本质上：Skill 是 AI 时代的“函数”或“API”

VS Code 中的 Skill 实现方式

虽然 VS Code 本身没有官方“Skill”概念，但可以通过以下机制实现：

1. .github/copilot-instructions.md

这是最接近“全局 Skill”的机制。

作用：

• 为 Copilot 提供长期上下文
• 约束 AI 的行为方式

示例：

# Backend Coding Guidelines

- Use clean architecture
- Follow RESTful API design
- Add unit tests for all services
- Use dependency injection

# Code Style

- Prefer TypeScript over JavaScript
- Use async/await instead of callbacks

这相当于一个“全局 Skill 注入器”

2. 项目级 Skill（README / project.md）

你可以在项目中定义：

# AI Skill: API Generator

When generating APIs:
- Use OpenAPI 3.0 spec
- Include request/response schema
- Add validation rules
- Provide curl examples

3. 会话级 Skill（Copilot Chat）

在 Chat 中你可以定义一次性 Skill：

You are a senior backend architect.

Task:
- Refactor code to hexagonal architecture
- Keep business logic pure
- Extract adapters

Output:
- Folder structure
- Example code

GitHub Copilot Chat 中的 Skill 用法

Copilot Chat 是 Skill 最直接的使用场景。

下面给你几个工程级实战例子。

示例 1：代码重构 Skill

输入（Skill）

Act as a senior software architect.

Refactor this code:
- Apply clean architecture
- Separate domain, application, infrastructure
- Add dependency inversion

Output:
1. Folder structure
2. Refactored code
3. Explanation

效果

AI 不再只是“改代码”，而是：

• 输出结构设计
• 给出分层方案
• 解释设计决策

从“补全工具”变成“架构助手”

示例 2：测试生成 Skill

You are a QA engineer.

Generate unit tests:
- Use Jest
- Cover edge cases
- Include mocks
- Ensure >80% coverage

Output:
- Test file
- Coverage explanation

优势：

• 输出结构稳定
• 测试风格统一
• 可团队复用

示例 3：API 文档生成 Skill

Act as an API documentation generator.

Given code:
- Extract endpoints
- Generate OpenAPI spec
- Add request/response examples

Output in YAML

直接产出可用 API 文档

示例 4：代码评审 Skill（强烈推荐）

Act as a senior code reviewer.

Review this code:
- Check performance issues
- Identify security risks
- Suggest improvements

Output:
- Issues list
- Severity level
- Fix suggestions

这个 Skill 在团队中极其高价值

进阶：Skill 组合（Skill Pipeline）

真正强大的不是单个 Skill，而是Skill 组合：

需求 → API Skill → 实现 Skill → 测试 Skill → Review Skill

形成一个 AI 开发流水线：

1. 生成 API
2. 生成实现
3. 生成测试
4. 自动 review

本质：AI 驱动的 Dev Pipeline

最佳实践

1. Skill 必须结构化

不要写：

帮我优化代码

要写：

Optimize code:
- Reduce time complexity
- Improve readability
- Add comments

Output:
- Before/After
- Explanation

2. 强制输出格式

Output in JSON:
{
  "issues": [],
  "fixes": []
}

这对自动化极其重要

3. 限定角色（Role Prompting）

Act as:
- Staff Engineer
- Security Expert
- Performance Engineer

4. Skill 应该可复制

建议统一放在：

• .github/copilot-instructions.md
• docs/ai-skills.md
• 内部 wiki

Skill vs Agent（很多人会混淆）

Skill 是积木 Agent 是机器人

总结

AI 编程正在从：

“怎么问 AI” → “怎么设计 AI 能力”

Skill 的出现意味着：

• Prompt 不再是核心
• 能力设计才是核心
• AI 正在变成“开发基础设施”

未来优秀的工程师，不只是写代码的人，而是设计 AI 能力的人

随着生成式 AI 与智能代理的快速发展，自托管的智能系统正变得越来越受开发者和技术团队关注。Clawdbot 就是这样一款开源、可自托管的个人 AI 助手，它不仅能与用户进行对话，还能执行任务、集成消息平台、提供自动化能力，并可部署在云平台上如 Azure。本文将逐步介绍 Clawdbot 的能力、架构以及如何在 Microsoft Azure 上部署并开始使用它。

什么是 Clawdbot

Clawdbot 是一个开源的个人 AI 助手项目，本质上是一个智能代理框架，它可以：

• 与多种消息平台进行交互，包括 WhatsApp、Telegram、Discord、Slack、Microsoft Teams 等。
• 承担智能对话、任务执行、自动化工作流的角色，而非单纯聊天机器人。
• 支持在本地或自托管服务器上运行，数据默认保存在本地，增强隐私保护。
• 通过插件/技能扩展，实现日程提醒、文件管理、邮件处理、代码生成等功能。

Clawdbot 的核心由 Gateway、Providers（平台接入）、Agents/Skills（智能任务执行单元）构成。Gateway 负责消息总线、Providers 负责与各消息平台对接，Agents/Skills 则实际执行用户请求。

Clawdbot 的主要特性

1. 多平台消息接入 Clawdbot 支持通过连接聊天平台 API，接收来自 WhatsApp、Telegram、Discord、Signal、Slack、Microsoft Teams 等消息，并将这些消息传递给 AI 模型进行处理。

2. 隐私和数据控制 与云端托管的聊天 AI 不同，Clawdbot 可以运行在你自己的服务器或 VPS 上，所有对话历史、配置、凭据都可以按需存储和访问。

3. 自动化执行能力 除了对话，Clawdbot 还能执行具体任务，包括浏览器控制、文件操作、数据处理、发送提醒等，这使其成为一个更为复杂的个人助手平台。

4. 可扩展的模型支持 Clawdbot 支持多种 AI 模型提供者（如 OpenAI GPT、Anthropic Claude，甚至本地 LLM 服务如 Ollama）。

在 Azure VM 部署 Clawdbot

虽然 Clawdbot 支持本地运行或容器平台，但在以下场景中，Azure VM 是非常合适的部署形态：

1. 完全控制运行环境

   • 自由选择 OS（Ubuntu / Debian）
   • 自由安装 Node.js、Docker、GPU 驱动等

2. 数据与隐私可控

   • 所有对话记录、日志、配置文件仅存在于 VM 内
   • 不依赖第三方 PaaS

3. 适合长期运行的 Agent

   • 7×24 小时在线
   • 可通过 systemd 或 Docker 保证自动重启

4. 可扩展性良好

   • 可横向扩容（多 VM + 负载均衡）
   • 可纵向扩容（更大规格 CPU / GPU）

整体部署架构概览

在 Azure VM 上运行 Clawdbot 的典型架构如下：

创建 Azure VM

VM 基础配置建议

• OS：Ubuntu 22.04 LTS
• 规格：
  • 轻量使用：Standard B2s / B4ms
  • 多 Agent：D4s_v5 及以上
• 磁盘：至少 64 GB
• 网络：
  • 入站：22（SSH）
  • 入站：3000（或自定义 Clawdbot 端口）

登录 VM

ssh azureuser@<VM_PUBLIC_IP>

安装运行时环境

系统依赖

sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl build-essential

安装 Node.js（推荐 20 LTS）

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
node -v
npm -v

安装 Clawdbot

全局 CLI + 本地运行目录

sudo npm install -g clawdbot

创建运行目录：

mkdir ~/clawdbot
cd ~/clawdbot

初始化配置：

clawdbot onboard

跟着步骤完成各类配置即可：

启动 Clawdbot

手动启动验证

clawdbot gateway

确认日志中出现：

🦞 Clawdbot 2026.1.24-3 (885167d) — I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.
...
16:18:27 [heartbeat] started
16:18:27 [gateway] agent model: openai-codex/gpt-5.1
16:18:27 [gateway] listening on ws://127.0.0.1:18789 (PID 36888)
16:18:27 [gateway] listening on ws://[::1]:18789
16:18:27 [gateway] log file: \tmp\clawdbot\clawdbot-2026-01-27.log
16:18:27 [browser/server] Browser control listening on http://127.0.0.1:18791/
...

通过浏览器打开：http://127.0.0.1:18789/

即可开始使用！

结语

Clawdbot 是一款功能强大的开源 AI 个人助手，可将 AI 交互扩展到多种消息平台，并集成丰富的执行能力。通过将 Clawdbot 部署到 Azure，你可以将它打造成一个企业级、自托管的 AI 服务，提高可用性、安全性和可扩展性。上述步骤覆盖了从创建 Azure Bot 到完整部署 Clawdbot 的全流程，希望能帮助你快速搭建并运行自己的智能助理。

2025 年末，微软研究院发布了一个面向 3D 内容创作的开源大模型项目 TRELLIS，并伴随学术论文《Structured 3D Latents for Scalable and Versatile 3D Generation》。该项目通过统一的结构化潜在空间与先进的流模型技术，显著提升了文本/图像到 3D 资产生成的质量与灵活性，同时拓展了 3D 模型的多格式输出与编辑能力，成为当前 3D AI 模型生态中的重要技术之一。

官方 Github 仓库地址：https://github.com/microsoft/TRELLIS

TRELLIS 是什么？——核心概念与架构

TRELLIS 是微软构建的大型 3D 资产生成模型，支持输入文本提示或图像，并输出高质量的三维模型资产。其技术创新点主要包括：

• 统一结构化潜在表示（SLAT）：将三维信息编码为一种可扩展的结构化潜在空间表示，使模型能够以统一方式理解和生成不同表现形式的 3D 结果。
• 整流流（Rectified Flow Transformers）：专为 SLAT 设计的生成骨干网络，通过适应 sparse 表示提升生成效率与质量。
• 大规模训练与预训练模型：模型规模最高达约 20 亿参数，并在包含 50 万多样化三维资产的数据集上训练，具备强泛化能力。

TRELLIS 不仅能生成三维几何，还能捕获复杂纹理与外观信息，使得生成的资产更贴近真实世界中可用的三维内容。

主要功能特性

以下是 TRELLIS 的核心功能模块及技术亮点：

多模态输入能力

TRELLIS 支持以下输入条件：

• 文本提示（Text-to-3D）：通过自然语言描述生成三维资产（提示须清晰准确）。
• 图像条件（Image-to-3D）：根据一张或多张图片生成对应三维模型。

这种多模态输入支持，使 TRELLIS 适用于从概念设计到真实原型的全流程创作。

灵活的输出格式

根据下游需求，TRELLIS 输出包括：

• 辐射场（NeRF/Radiance Fields）：适合渲染与展示
• 3D 高斯表示：一种可渲染密度表示
• 传统网格 Mesh：可导出为标准 3D 文件格式（例如 GLB/OBJ）用于游戏、AR/VR 等应用

这种格式灵活性是模型在实际生产环境中落地的关键能力。

本地三维编辑与变体生成

与早期单一生成模型不同，TRELLIS 能：

• 局部编辑：在已有模型上进行细部修改
• 生成变体：在保持基本结构不变的前提下，创建风格、细节不同的多版本输出

这种能力特别适合迭代式 3D 内容设计。

支持大规模数据集训练与可扩展性

TRELLIS 在包含多种来源（如 Objaverse、ABO 等）的大规模 3D 数据集上进行训练，使其具备：

• 强泛化能力
• 更丰富的几何与纹理表现
• 多任务适配能力

这样的数据基础是其较竞品更具优势的根本原因之一。

与其他竞品对比：优势与提升点

目前市场上其他比较知名的 3D 生成模型（例如 OpenAI Shap-E、或研究型模型如 MeshGen 等）多存在以下局限：

• 有的只能输出单一 3D 表示（如内隐函数或点云）
• 多数不支持本地编辑与多种格式输出
• 在复杂纹理、细节表现上效果有限

相比之下：

TRELLIS 的主要优势包括

1. 结构化潜在表示（SLAT）框架：支持统一的生成与解码机制，同时兼顾几何与纹理细节。
2. 多格式生成输出：与只生成单种数据结构的竞品相比更通用。
3. 本地编辑与变体生成：提升了设计迭代效率。
4. 大规模预训练与更丰富数据集支撑：提升了模型对稀有或复杂对象的生成能力。

总的来说，TRELLIS 更偏向工业级 3D 生成工具，而不只是科研展示或单一生成模型。

部署和使用

目前，微软尚未在 Azure AI Foundry / Microsoft Foundry 中以 Serverless 或托管模型的形式直接提供 TRELLIS。因此，在 Azure 云环境中使用 TRELLIS 的最可行、也是最稳定的方式，是基于 Azure GPU 虚拟机（VM）进行自托管部署。

这种方式具备以下优势：

• 完全控制模型版本与推理流程
• 支持大显存 GPU，适合 3D 模型生成场景
• 可与企业现有 Azure 网络、安全、存储体系无缝集成

1. Azure GPU VM 规格选型建议

TRELLIS 属于显存与算力敏感型 3D 生成模型，对 GPU 资源要求较高，推荐如下规格：

推荐 VM 系列

• Standard_NC A100 v4（A100 80GB，首选）
• Standard_NC A100 v5（A100 80GB，新一代）
• Standard_ND H100 v5（H100，若需要更高吞吐）

实践建议：

• 推理 / Demo：单卡 A100 80GB 即可
• 高分辨率 / 批量生成 / 编辑任务：建议单机多卡或更高规格

2. 操作系统与基础环境

推荐环境组合如下：

• OS：Ubuntu 20.04 / 22.04 LTS
• CUDA：与 VM 驱动匹配的官方版本
• Python：3.8 或以上
• PyTorch：官方 CUDA 版本

Azure Marketplace 中可直接选择 CUDA + NVIDIA Driver 预装镜像，可显著降低环境准备成本。

3. TRELLIS 安装与依赖配置

拉取代码

git clone --recurse-submodules https://github.com/microsoft/TRELLIS.git
cd TRELLIS

创建独立 Python 环境并安装依赖

官方已提供自动化脚本：

./setup.sh --new-env --basic

如需支持训练、编辑或高级功能，可根据官方说明启用对应参数。

4. 基于 Azure VM 的推理运行方式

方式一：命令行推理（适合批量任务）

文本或图像驱动生成 3D 模型：

python example_text.py \
  --prompt "a futuristic electric motorcycle" \
  --output_dir outputs/

或多图像条件输入：

python example_multi_image.py \
  --input_images images/ \
  --output_dir outputs/

生成结果可直接导出为 Mesh / Radiance Field 等格式，用于后续渲染或工具链集成。

方式二：Gradio Web UI（推荐用于演示与验证）

TRELLIS 官方提供基于 Gradio 的 Web Demo，适合：

• 团队内部体验
• 产品验证
• 算法效果对比

python app.py

然后通过 Azure VM 公网 IP 或内网负载均衡访问 Web UI。

5. Azure 上的工程化部署建议

为了更好地在 Azure 上长期运行 TRELLIS，建议采用以下架构实践：

存储解耦

• 模型权重：Azure Blob Storage
• 生成结果：Blob / Azure Files
• 日志与元数据：Azure Monitor / Log Analytics

服务化封装

• 使用 FastAPI / Flask 将 TRELLIS 推理封装为 HTTP API
• GPU VM 作为推理节点
• 前端或工作流通过 REST 调用

安全与网络

• VM 置于 VNet 内
• Web UI / API 通过 Application Gateway 或内部访问
• 支持私有部署，满足企业安全要求

总结与展望

微软 TRELLIS 代表了当前 3D AI 生成技术的重要进步，它在生成质量、格式多样性与本地编辑能力方面具备显著优势。对于希望自动化 3D 内容创建的开发者与设计者而言，它是一个有实力的开源方案。部署方面，虽然目前官方尚未将其作为 Foundry 的 serverless 模型，但可通过 Azure 的常规模型部署管道与 GPU 计算能力在云端高效运行 TRELLIS 推理与自定义训练。

近年来，生成式 AI 技术迅速演进。在自然语言处理之外，图像生成与编辑能力成为 AI 创新的重要前沿。在这一趋势下，OpenAI 推出了 GPT Image 系列模型，在 Azure OpenAI 服务内同样可用。而其中最新发布的 GPT-Image-1.5 可视为图像生成领域的新旗舰，在性能、效率和可控性方面均有显著提升。

什么是 GPT-Image-1.5

GPT-Image-1.5 是 OpenAI 最新发布的多模态图像生成模型，属于 GPT Image 系列，目前是效果最佳的版本。与前代（如 GPT-Image-1）相比，它在指令遵循能力、图像质量、生成速度和成本效率方面都有明显提升。

官方定义上，GPT Image 模型是原生多模态语言模型（natively multimodal），能接收文本和图像输入，并生成图像输出。在功能上，它不仅支持从纯文本生成图像，还可以对已有图像进行编辑、修改、风格化转换等操作。

简而言之：

• 多模态：同时理解文本和图像输入。
• 图像生成与编辑：支持从文本生成全新图像，也支持对已有图像进行局部修改和增强。
• 高质量与高效：相比前代生成更精细、更快速，同时成本更低。

核心能力与特点

1. 指令遵循及表达精准

GPT-Image-1.5 在理解自然语言提示方面得到显著提升，尤其擅长：

• 对复杂描述的视觉表达，细节理解更准确
• 在图像中生成清晰可读的文本内容
• 遵循用户指令进行定制化修改和组合

相比最初的图像生成模型（例如 DALL·E 系列），这类 GPT Image 系列模型对于提示语的响应更直观、可控性更高。

2. 图像质量与生成速度提升

GPT-Image-1.5 的生成速度比上一代快得多（据报道最高可达大约 4 倍提升），这对于需要快速迭代视觉内容的场景（如设计、产品原型等）尤为重要。

此外，图像生成结果在细节、现实感和一致性方面表现更好，尤其是在脸部、纹理、光影等关键元素上有显著进步。

3. 编辑与增强功能

GPT-Image-1.5 同时支持图像编辑，包括：

• 局部修改：对选中区域进行变更
• 添加或移除元素
• 风格化调整与概念转换

无需完全重新生成整幅图像，大幅提升工作流效率。

4. 成本与效率优化

GPT-Image-1.5 在 API 调用成本上较前代降低约 20%，使得高质量图像生成在更大范围内可持续使用，特别适合企业级批量生成需求。

5. 安全性与合规性

作为 Azure OpenAI 服务的一部分，GPT-Image-1.5 的使用受 Azure 的安全性、合规性和内容过滤体系保障，支持多种定制化审核与责任使用防护。

在 Microsoft Foundry 中部署与使用 GPT-Image-1.5

随着 Microsoft Foundry 的推出（当前为预览版），微软正在将 Azure OpenAI、模型目录、推理端点、Playground 与企业治理能力整合为统一的 AI 应用构建平台。在该预览版中，GPT-Image-1.5 已作为一等模型（first-class model）被直接纳入 Foundry 的模型体系，无需再通过传统的 “Azure AI Foundry / Azure AI Studio” 路径进行管理。

1. 在 Microsoft Foundry 中部署 GPT-Image-1.5

在 Preview 版 Foundry 中，模型部署流程更接近“产品级模型托管”而非传统 Azure 资源配置：

首先进入 Microsoft Foundry（Preview）控制台。在左侧选择 Models（模型库）。在模型列表中找到 GPT-Image-1.5（Image / Multimodal 分类）。

打开模型详情页后，点击 Deploy，创建一个新的推理部署。

选择默认部署，简单选择 Region 后即可完成部署，整个过程非常简单：

部署完成后会自动进入 GPT-Image-1.5 的 Playground：

完成后，Foundry 会自动生成：

• 一个可调用的 Inference Endpoint
• 与之绑定的身份、配额与监控策略

这一流程强调的是模型即服务（Model as a Service），开发者不再需要直接关心底层 Azure OpenAI 资源的复杂配置。

2. 使用 Foundry Playground 进行图像生成与 Prompt 验证

Microsoft Foundry（Preview）内置了统一的 Playground，用于对 GPT-Image-1.5 进行交互式试验。

在 Playground 中，你可以：

• 直接输入文本 Prompt 生成图像
• 调整图像尺寸、质量等级等参数
• 快速验证复杂描述、风格化指令的效果
• 对比不同 Prompt 的生成结果

这一能力特别适合以下角色协作使用：

• 产品经理：验证视觉创意可行性
• 设计师：探索生成风格与构图
• 工程师：在写代码前固化 Prompt 模板

Playground 在 Preview 版 Foundry 中的定位是 Prompt 即资产，验证通过的 Prompt 可以直接迁移到生产代码中使用。

生成图片后效果如下：

3. 从 Foundry 到应用代码的集成方式

在应用层面，Microsoft Foundry（Preview）部署的 GPT-Image-1.5 本质上仍然以标准推理 Endpoint 的形式对外提供服务：

• 代码侧只需要关心：

  • Endpoint URL
  • Deployment Name
  • 身份认证方式

• 不再直接依赖模型原始名称或版本号

在企业实践中，常见模式是：

• 开发 / 测试 / 生产环境使用不同 Deployment
• 模型版本升级（例如 GPT-Image-1.5 → 后续版本）在 Foundry 层完成
• 应用代码保持不变，仅消费稳定的 Endpoint

这种模式显著降低了 模型演进对业务系统的侵入性。

在 Azure OpenAI 中如何使用 GPT-Image-1.5

你可以通过 Azure OpenAI 提供的 API、SDK 或 Azure AI Foundry 平台来调用 GPT-Image-1.5。基本流程如下：

1. 获取访问权限与部署模型

在模型的详情页可以查看通过代码嗲用 GPT-Image-1.5 的所有信息：

2. 使用 REST API 生成图像

使用 POST 请求调用图像生成端点：

POST https://<your_resource>.openai.azure.com/openai/deployments/<your_deployment>/images/generations?api-version=<api_version>
Content-Type: application/json
api-key: <your_api_key>

{
  "prompt": "一位穿宇航服的猫在火星表面散步",
  "size": "1024x1024",
  "n": 1,
  "quality": "high"
}

常见参数说明：

• prompt: 文本描述
• size: 图像尺寸（如 1024x1024）
• n: 生成图像数量
• quality: 生成质量（low/medium/high）

3. 图像编辑（若支持）

上传已有图片并通过 prompt 指令结合修改：

POST /images/edits

此类调用可以指定 mask、输入图片等字段来控制局部变化。

4. SDK 与开发环境

Azure 支持多种语言 SDK（例如 Python、C#），可借助 Azure Identity 认证库、安全地调用 API 并处理生成结果。

总结

GPT-Image-1.5 在图像生成领域代表了下一阶段 AI 创意工具的能力边界。它在指令理解、生成速度、图像质量、成本效率与多模态处理方面均显著提升，为开发者和企业提供了一套强大且可扩展的视觉 AI 解决方案。

对于希望构建中长期 AI 能力平台的团队而言，Foundry + GPT-Image-1.5 是比直接裸用 API 更具工程化和可持续性的选择。

Azure OpenAI 服务结合了模型能力与企业级安全合规，让 GPT-Image-1.5 不仅适用于实验探索，也能支撑生产级应用。

如果你正在构建需要视觉理解或自动创意生成的应用，无论是批量生成还是交互式体验，GPT-Image-1.5 都值得深入实践。

本文我想分享我是如何构建 Auto Address 的，这是一个利用 Azure OpenAI 的强大能力来解决这个问题的 Chrome 及 Edge 浏览器扩展插件，其界面和使用方式及其简单。

问题：非结构化数据

想象一下收到这段文本：

“张三 13800138000 广东省深圳市南山区科技园南区R2-B三楼”

为了发货，你需要将其拆解为：

• 姓名: 张三
• 电话: 13800138000
• 地址: 科技园南区R2-B三楼
• 城市: 深圳市
• 省份: 广东省
• 国家: 中国

手动处理成百上千个订单既繁琐又容易出错。正则表达式（Regex）可以处理某些情况，但当格式变化或用户有错别字时，它们往往无能为力。

解决方案：LLM 作为解析器

像 Azure OpenAI（如：GPT-4 或 GPT-5）这样的大语言模型在理解上下文方面表现出色。它们能区分街道名称和城市名称，不是因为死板的规则，而是因为它们理解地址的语义。

我选择 Azure OpenAI 进行此项目主要有两个原因：

1. 企业级隐私：发送到 Azure OpenAI 的数据不会用于训练公共模型。
2. 可靠性：稳定的正常运行时间和性能。

技术揭秘：它是如何工作的

插件的核心逻辑出奇地简单。它获取用户的输入，并将其连同一组非常具体的指令发送到 Azure OpenAI API。

1. System Prompt (系统提示词)

“魔法”在于系统提示词。我们需要确切地告诉模型要做什么，更重要的是，如何格式化输出。

这是代码中实际使用的提示词：

{
  role: "system", 
  content: "You are an address parser. Return ONLY a raw JSON object (no markdown code blocks) with keys: name, province, city, address, zip_code, country. If province/state is missing in the input, infer it from the city. Do not separate house number, include it in the address field."
}

这里使用的关键技巧：

• 角色定义: “You are an address parser.” (你是一个地址解析器)
• 输出约束: “Return ONLY a raw JSON object”. (仅返回原始 JSON 对象)。这防止模型添加像 “这是您的 JSON：” 这样的废话。
• Schema 定义: 我们明确列出了我们想要的键 (name, province 等)。
• 逻辑注入: “If province/state is missing… infer it.” (如果省/州缺失…推断它)。这将逻辑处理卸载给了 AI。

2. API 调用

扩展使用标准的 fetch API 与您的 Azure 部署进行通信。

const url = `${baseUrl}openai/deployments/${azureDeployment}/chat/completions?api-version=2024-05-01-preview`;

const response = await fetch(url, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'api-key': azureApiKey
  },
  body: JSON.stringify({
    messages: [ /* ... prompt ... */ ],
    temperature: 0.1 // 以获得一致、确定的结果
  })
});

我们使用低 temperature (0.1)，因为我们不需要创造力；我们需要精确度。

3. 智能省份推断（“双重检查”）

有时，即使是最好的模型也会遗漏细节，或者输入太模糊。一个常见的问题是缺少省/州信息。

我在 popup.js 中实现了一个“回退”机制。如果解析结果有城市但没有省份，扩展程序会发起第二次定向 API 调用：

if ((!addr.province || addr.province === '') && addr.city) {
  // ... 二次调用 ...
  messages: [
    {
      role: "system", 
      content: "You are a geography helper. Return ONLY the province/state name for the given city. Do not return JSON, just the name."
    },
    {
      role: "user", 
      content: `Which province/state is the city "${addr.city}"${countryContext}?`
    }
  ]
}

这确保了在用户看到数据之前，数据尽可能完整。

Chrome / Edge 扩展架构

Manifest V3 与 Side Panel (侧边栏)

该扩展基于 Manifest V3 构建，这是 Chrome / Edge 扩展平台的最新迭代。

我没有使用点击后就会关闭的传统弹出窗口，而是使用了 Side Panel API ("permissions": ["sidePanel"])。这允许扩展程序停留在浏览器窗口的一侧。这对工作流程至关重要：用户可以在左侧查看发货单页面，同时在右侧查看解析出的地址数据。

隐私优先

首先使用前需要通过配置界面设置您要使用的 Azure OpenAI 信息：

主要的设计决策是零中间服务器。

• 扩展程序使用 chrome.storage.sync 将您的 API 密钥本地存储在浏览器中。
• 请求直接从您的浏览器 -> Azure OpenAI。
• 扩展开发者不收集任何数据。

结语

通过结合 Chrome / Edge 扩展的灵活性和 Azure OpenAI 的智能，我们可以将繁琐的数据录入任务转化为一键操作。

代码已开源。欢迎查看、Fork 并构建您自己的 AI 驱动工具！

GitHub Repo: https://github.com/wilsonwu/autoaddr

如果您使用的是 Microsoft Edge 浏览器，可以通过扩展插件市场安装本插件的最新版本：Edge 浏览器扩展插件

准备工作

在开始之前，你需要：

获取 Azure 订阅

拥有一个 Azure 订阅，如果您不清楚如何获取 Azure 订阅，可以参考之前文章中的注册 Azure 订阅内容进行操作。

创建 Azure AI Foundry

首先进入您的 Azure 订阅中的 AI Foundry，展开左侧 All Resources，找到 Azure AI Foundry，点击 Create 创建一个 Azure AI Foundry：

创建时注意区域选择，由于 Sora 2 模型并未在所有 Azure 区域开放预览，这里建议选择 East US 2 区域：

1. 创建 Azure AI Foundry Project

创建完成后进入您的 Azure AI Foundry 在 All Resources 中找到 Projects，点击 New 创建一个新的 Project：

2. 打开 Azure AI Foundry Protal

创建完成 Project 后，打开您的 Project，点击 Go to Azure AI Foundry protal：

正常情况下 Azure AI Foundry Protal 如下：

3. 启用和部署 Sora 2 模型

又有 Sora 2 模型在本文发布时仍然处于预览状态，所以我们首先需要申请权限，后续开放使用后可调过本步骤，首先点击左侧的 Model catalog，可以看到 Sora 2 模型的标签，点击 Check out model：

也可以在下方的模型列表找到想要的模型进行使用。

如果您没有使用 Sora 2 模型的权限，进入 Sora 2 模型介绍界面后将如下所示：

请点击 Request access 链接进行权限申请。

如您已经拥有 Sora 2 访问权限，可以点击 Use this model 进行模型部署：

部署过程非常简单，默认保持各类选项即可进行创建部署：

部署完成后，切换左侧菜单至 Models + endpoints，查看模型列表：

至此您就拥有了属于自己的 Sora 2 模型，可以开始使用！

通过 Azure AI Foundry Playground 使用 Sora 2

Azure AI Foundry 提供了强大的可视化界面，你可以无需写代码就生成视频。

1. 进入 Playground

打开 Azure AI Foundry 左侧菜单中的 Playgrounds，选择 Video playground：

进入 Playground 后选择 Sora 2 模型：

2. 填写提示词 Prompt

示例 Prompt：

A high-energy cyberpunk chase in the rain with neon reflections on wet streets. A futuristic motorcycle speeds through, dynamic motion blur capturing its sleek design and vibrant city lights.

3. 设置选项

可调节选项包括：

4. 生成视频

设置好后，点击 Generate 进行视频生成，视频生成成功后，你可以在 Generation history 中预览或下载视频：

通过 Python 调用 Sora 2

Azure 为 OpenAI 模型提供统一的接口，可以直接在你的后端调用。

1. 安装 SDK

pip install azure-ai-openai
pip install python-dotenv

2. 配置环境变量

创建 .env 文件：

AZURE_OPENAI_ENDPOINT=https://<your-resource-name>.openai.azure.com/
AZURE_OPENAI_KEY=<your-key>
AZURE_OPENAI_API_VERSION=2024-10-01-preview

3. Python 调用示例：文生视频

下面是最简可运行示例：

import os
from dotenv import load_dotenv
from azure.ai.openai import OpenAIClient
from azure.core.credentials import AzureKeyCredential

load_dotenv()

client = OpenAIClient(
    endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
    credential=AzureKeyCredential(os.getenv("AZURE_OPENAI_KEY")),
    api_version=os.getenv("AZURE_OPENAI_API_VERSION")
)

prompt = """
A cinematic shot of a spaceship flying through a nebula filled with colorful cosmic clouds.
"""

response = client.get_video(
    model="sora-2",
    prompt=prompt,
    duration=5,              # seconds
    resolution="1080p",
)

# 保存视频
video_bytes = response.video
with open("output.mp4", "wb") as f:
    f.write(video_bytes)

print("Video generated: output.mp4")

4. 使用结构化 payload

Sora 还支持更多控制，例如镜头、分镜头脚本、环境细节。

payload = {
    "prompt": "A cute corgi running on a beach during sunset.",
    "duration": 8,
    "resolution": "720p",
    "motion": "medium",
    "style": "realistic"
}

response = client.get_video(
    model="sora-2",
    **payload
)

with open("corgi_beach.mp4", "wb") as f:
    f.write(response.video)

生成最佳视频的技巧

1. 提示词结构推荐（General Prompt Template）

[主体对象] + [场景环境] + [动作] + [镜头效果] + [光影] + [风格]

示例：

A high-energy cyberpunk chase in the rain with neon reflections on wet streets. A futuristic motorcycle speeds through, dynamic motion blur capturing its sleek design and vibrant city lights.

2. 控制一致性

• 使用 seed 可重复生成风格一致的视频
• 合理设置 motion level 获得更自然的动作
• 提供清晰场景描述可减少模型误解

常见问题（FAQ）

1. 我试了但看不到 Sora 2？

目前需要访问权限。你需要：

• 联系 Azure 管理员
• 到模型页面确认已启用

2. 视频最大时长是多少？

具体限制依区域会有不同，通常为 ≤ 10 秒。

3. Python 生成的视频过小或无内容？

确保保存时使用 response.video 而不是错误字段。

总结

本文介绍了在 Azure AI Foundry 中使用 Sora 2 文生视频模型的两种方式：

• 使用可视化 Playground 快速体验
• 使用 Python SDK 在生产环境自动生成视频

Azure 的企业级安全合规能力让 Sora 2 成为企业落地视频生成的重要选择。

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

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

SGLang 简介

SGLang 是一款面向大语言模型（LLM）和视觉语言模型（VLM）的高性能推理框架，通过精心设计的后端运行时与前端语言协同工作，使模型交互更加高效且可控。其核心优势包括：

• 高效后端运行时：采用创新的 RadixAttention 技术实现前缀缓存，支持跳跃式受限解码、零开销 CPU 调度、连续批处理、令牌注意力（分页注意力）、张量并行、FlashInfer 内核、分块预填充以及多种量化技术（FP8/INT4/AWQ/GPTQ），显著提升推理效率。
• 灵活前端语言：提供直观且强大的 LLM 编程接口，支持链式生成调用、高级提示工程、复杂控制流、多模态输入、并行处理及外部系统交互。
• 广泛模型兼容性：支持多种主流生成式模型（Llama、Gemma、Mistral、QWen、DeepSeek、LLaVA 等）、嵌入模型（e5-mistral、gte）及奖励模型（Skywork），并提供简便的新模型扩展机制。
• 活跃开源生态：拥有蓬勃发展的社区支持，已获得广泛业界认可（截至 2025 年 3 月 17 日，GitHub 累计星标超过 12,000）。

其技术架构如下：

除此之外，对于初学者，需要了解其以下特性：

• OpenAI 兼容 API：直接用 openai Python SDK 或 cURL 调用，不用改你的上层业务代码。
• 高吞吐与低延迟：结合连续批处理与前缀缓存等技巧，让相同前缀的请求复用计算。
• 生产友好：支持多并发、流式输出、可与 Hugging Face 模型库直接对接。

环境准备

工欲善其事必先利其器，要完成本文的新手实验，需准备如下环境：

• 操作系统：建议 Linux（常用为 Ubuntu 20.04+）。WSL2 也可尝试。
• Python：建议 3.10 或 3.11。
• GPU：建议 NVIDIA 显卡，24GB 显存可跑 7B/8B 级（如 Llama 3.1 8B）。没有 GPU 也能跑小模型或量化模型，但性能有限。
• 模型来源：Hugging Face（如 meta-llama/Llama-3.1-8B-Instruct）或本地路径。

安装 SGLang

环境就绪后，使用 pip 安装 SGLang（确保已安装 pip、可选创建虚拟环境）。

pip install sglang openai huggingface-hub

如果你需要从 Hugging Face 自动下载私有或受限模型，请先登录或设置 Token：

huggingface-cli login
# 或
export HF_TOKEN=您的Token

启动 SGLang 服务

可以通过以下两种启动方式进行 SGLang 服务的启动。不同版本的 SGLang 命令行参数可能略有差异，如果出现参数名称不匹配，先执行 –help 查看本机版本支持的参数。

通过 launcher 启动

python -m sglang.launcher \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 30000 \
  --tp 1 \
  --max-model-len 8192

其中常用参数说明如下：

• –model：Hugging Face 模型名称或本地模型权重路径
• –host/–port：服务监听地址与端口
• –tp：Tensor Parallel 并行度（单卡设为 1；多卡可根据需要设为 2、4 等）
• –max-model-len：上下文最大长度

另外需要注意以下两点：

• 如果使用的是 Hugging Face 模型，首次运行会下载模型权重，请确保网络通畅。
• 如果显存吃紧，可优先尝试更小模型，或减少 –max-model-len。

通过 sglang 命令启动

如果您使用的版本提供 sglang serve 命令，也可使用如下命令进行启动：

sglang serve -m meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000

快速验证

服务启动后，OpenAI 兼容接口即可使用：

curl http://127.0.0.1:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer EMPTY" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "用两句话介绍一下你自己。"}
    ],
    "max_tokens": 128,
    "temperature": 0.2
  }'

如果运行正常，将返回标准的 ChatCompletion JSON 响应。

使用 Python OpenAI SDK 进行调用

非流式调用（最简单的问答）：

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:30000/v1",
    api_key="EMPTY"  # 本地服务通常不校验
)

messages = [
    {"role": "system", "content": "You are a helpful assistant who answers in Chinese."},
    {"role": "user", "content": "请用三句话介绍帕累托最优。"}
]

resp = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=messages,
    temperature=0.2,
    max_tokens=256
)

print(resp.choices[0].message.content)

流式输出（边生成边打印）：

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:30000/v1", api_key="EMPTY")

messages = [
    {"role": "system", "content": "You are a helpful assistant that speaks Chinese."},
    {"role": "user", "content": "简述 Transformer 的核心思想，并给出一个现实类比。"}
]

stream = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=messages,
    temperature=0.2,
    max_tokens=300,
    stream=True
)

for chunk in stream:
    if chunk.choices and chunk.choices[0].delta:
        delta = chunk.choices[0].delta.content
        if delta:
            print(delta, end="", flush=True)

print("\n[Done]")

通过以上两种方式，我们可以构建自己的推理服务应用，也可以通过市面上开源的软件来接入您部署的推理服务，如 Open-WebUI 等。

常见问题与排错

• 启动时报显存不足（CUDA OOM）
  • 尝试更小的模型（如 7B/8B）、减小 --max-model-len、或降低并发。
  • 如果有多卡，增加 –tp 并用多卡分摊显存。
• 拉取模型失败或速度慢
  • 先执行 huggingface-cli login；或提前手动把模型权重下载到本地路径，并在 --model 里填本地路径。
• API 报 Unknown argument
  • 不同版本的命令行参数可能有差异。请运行：python -m sglang.launcher --help
  • 根据你安装的版本调整参数名，如 --model / --model-path、--tp / --tensor-parallel-size 等。
• Python 客户端 401/Key 错误
  • 本地服务通常不校验 Key，只要带上一个占位即可（如 EMPTY）。
• 流式输出不打印
  • 确认传了 stream=True；迭代 chunk 时取 choices[0].delta.content。
• 并发性能不达预期
  • 尝试用 Async 客户端并发请求；避免在单线程里串行等待。
  • 检查 GPU 利用率；确认没有 CPU/GPU 数据传输瓶颈。

总结

至此，你已经完成了：

• 安装与启动 SGLang 服务
• 用 OpenAI 兼容接口进行非流式与流式推理

祝你上手顺利，玩得开心！如果遇到命令行参数或 API 的小差异，参考本地版本的 –help 与官方文档进行快速适配即可。

先决条件

首先需要拥有 Azure 订阅，新用户参考玩转大语言模型：无需任何代码通过 Azure OpenAI 服务构建个人专属 ChatGPT中步骤进行开通。然后在 Azure 订阅中创建 AI Foundry 及相关资源，可以参考创建 Azure AI Foundry 服务中的步骤，这里不再赘述。

一切完成后进入 Azure AI Foundry 首页，并打开名为 main 的 Project，界面如下：

部署 DeepSeek-R1 大语言模型

点击左侧菜单中的 Model catalog 进入模型列表页：

这里可以看到 Azure 提供了超过 1800 种模型，满足用户全方位的需求。

在搜索框输入 DeepSeek 来查看 Azure 支持的 DeepSeek 模型种类：

其中，第一个是全量版 DeepSeek-R1 671B 模型：

另一个是经过 NPU 优化的基于 Qwen 的 DeepSeek-R1 1.5B 蒸馏版：

我们选择 671B 版本进行部署尝试，进入模型详情后点击 Deploy 进行部署确认：

再点击 Deploy 完成部署，部署结束后会自动跳转至 My assets 中的 Models + endpoints 详情中：

至此 DeepSeek-R1 671B 部署完成，整个过程非常简单。

调用 DeepSeek-R1 进行推理

接下来我们尝试调用一下刚才部署的模型进行对话，进入刚才部署的模型详情中，点击 Consume Tab：

这里我们选择 Python 代码来进行尝试，代码如下：

# pip install azure-ai-inference
import os
from azure.ai.inference import ChatCompletionsClient
from azure.core.credentials import AzureKeyCredential

api_key = os.getenv("AZURE_INFERENCE_CREDENTIAL", '这里填写该部署在详情页面看到的 Key 值')
if not api_key:
  raise Exception("A key should be provided to invoke the endpoint")

client = ChatCompletionsClient(
    endpoint='https://DeepSeek-R1-gxmog.eastus.models.ai.azure.com',
    credential=AzureKeyCredential(api_key)
)

model_info = client.get_model_info()
print("Model name:", model_info.model_name)
print("Model type:", model_info.model_type)
print("Model provider name:", model_info.model_provider_name)

payload = {
  "messages": [
    {
      "role": "user",
      "content": "我即将前往北京，我能在那里看到什么景色？"
    },
    {
      "role": "assistant",
      "content": "北京，中国的首都"
    },
    {
      "role": "user",
      "content": "关于 #1 有哪些令人惊叹的内容？"
    }
  ],
  "max_tokens": 2048
}
response = client.complete(payload)

print("Response:", response.choices[0].message.content)
print("Model:", response.model)
print("Usage:")
print("	Prompt tokens:", response.usage.prompt_tokens)
print("	Total tokens:", response.usage.total_tokens)
print("	Completion tokens:", response.usage.completion_tokens)

创建一个 .py 文件（如：ds-demo.py），将上面的代码粘贴到其中，替换部署自身的 Key 到 api_key 变量中，然后执行如下命令安装依赖包：

pip install azure-ai-inference

然后执行代码：

python ds-demo.py

正常情况下输出结果类似如下内容：

Model name: deepseek-r1
Model type: chat-completion
Model provider name: DeepSeek
Response: <think>

</think>

北京作为中国的首都，拥有悠久的历史和丰富的文化遗产，同时也是现代化大都市的典范。以下是一些您在北京可以体验到的精彩内容：

1. **历史文化景点**：
   - **故宫（紫禁城）**：明清两代的皇家宫殿，世界文化遗产，展示了中国古代建筑和宫廷文化的精华。
   - **天坛**：明清皇帝祭天的场所，以其独特的建筑风格和象征意义闻名。
   - **长城（如八达岭、慕田峪段）**：世界奇迹之一，是中华民族的象征，登临可感受壮丽的山川与历史厚重感。

2. **现代都市风貌**：
   - **北京CBD**：国贸大厦、中央电视台总部大楼（“大裤衩”）等现代建筑群，体现了北京的经济发展活力。
   - **奥林匹克公园**：2008年奥运会主会场，鸟巢、水立方等标志性建筑夜晚灯光璀璨。

3. **文化体验**：
   - **胡同与四合院**：南锣鼓巷、什刹海周边保留了老北京的传统居住形态，可体验胡同骑行或品尝京味小吃。
   - **京剧与杂技表演**：老舍茶馆、梨园剧场等地可欣赏中国传统艺术。

4. **自然景观**：
   - **颐和园**：皇家园林典范，融合江南园林设计与北方山水，适合泛舟昆明湖或漫步长廊。
   - **香山公园**：秋季红叶漫山，是赏秋热门目的地。

5. **美食推荐**：
   - **北京烤鸭**：全聚德、大董等名店提供地道的烤鸭体验。
   - **涮羊肉**：东来顺等老字号以铜锅涮肉为特色。
   - **小吃街**：牛街、簋街汇聚各类京味及全国风味小吃。

6. **其他亮点**：
   - **798艺术区**：旧工厂改造的当代艺术聚集地，适合摄影和艺术爱好者。
   - **国家博物馆**：馆藏丰富，可系统了解中华文明五千年历史。

北京融合了古老与现代，传统与创新，无论是对历史感兴趣，还是想感受都市繁华，都能在这里找到独特的体验。建议根据季节选择合适的游览时间（如秋季气候宜人），并提前规划行程以避开高峰人流。
Model: deepseek-r1
Usage:
        Prompt tokens: 31
        Total tokens: 522
        Completion tokens: 491

总结

DeepSeek 的优势在于其强大的自然语言处理能力和高效的推理性能。通过 Azure AI Foundry 部署，用户可以快速上手并体验其强大的功能。DeepSeek-R1 提供了多种模型版本，满足不同需求，从全量版到经过优化的蒸馏版，用户可以根据实际应用场景选择合适的模型。

先决条件

在开始之前，请确保您拥有 Azure 国际版订阅服务，如果您还没有 Azure 订阅，可以通过 Pay-as-you-go 轻松开启一个 Azure 订阅：

注意：开启 Pay-as-you-go Azure 订阅必须绑定国际信用卡，对于新用户还有 200 美金的免费额度，我们完全可以使用这些额度充分使用 Azure 的各项服务。

下面介绍的内容除了与 GPT-4o 交互产生的费用外，其他都是免费的，日常不适用的话不会产生任何费用，GPT-4o 的费用也可以完全使用免费额度覆盖，所以大家不用担心信用卡被刷爆。

成功拥有 Azure 订阅后，然我们开始吧！

步骤 1：创建 Azure AI Studio 服务

在 Azure 订阅主页上方搜索栏中输入 azure ai，找到 Azure AI Studio：

点击进入 Azure AI Studio 资源页面：

点击 + New Azure AI Hub 进入创建页面：

从界面可以看到创建 Azure AI Hub 共分为 7 个步骤，这里按照指引一路 Next 都选择默认即可，其中需要注意的是区域建议选择 East US，由于免费订阅有一些资源使用限制，目前根据经验来看 East US 区域的使用便利性更佳。

另外是费用问题，可以参考 Azure OpenAI 费用详情页面来查看各个模型的收费情况：

创建完成后返回 Azure AI Studio 资源页面：

可以看到我们创建了一个 Azure AI hub 和一个配套的 Azure AI services 资源。

步骤 2：开始使用 Azure AI Studio

点击打开我们在第一步中创建的 Azure AI Hub 资源，我们会看到详情中醒目的 Launch Azure AI Studio 按钮：

点击后进入一个全新的 Azure AI Studio 界面：

这里将是我们主要工作的区域，点击列表中我们刚创建好的 AI Hub，当然在这里我们依然可以创建新的 AI Hub：

在 AI Hub 中，我们可以看到其相关联的所有资源：

首先我们需要创建一个 Project，点击左侧菜单中的 All projects，然后选择列表上方的 + New Project 按钮：

创建 Project 非常简单，只需要输入名称即可：

创建完成后将自动进入 Project 详情页面：

现在可以熟悉一下 AI Studio，Hub，Project 的界面，接下来我们来部署大语言模型！

步骤 3：部署 GPT-4o 大语言模型

依然在 Project 界面，在左侧菜单栏下放找到 Deployments 菜单，点击进入后选择 + Create Deployment 按钮：

在创建界面中我们看到 Azure 为我们提供了 1000 多重大语言模型可供使用，当然，它们要求的计算资源也各不相同，有兴趣可以逐个尝试（注意信用卡不要刷爆），这里我们选择 GPT-4o 模型：

选定后进入部署页面，按需修改相关选项，确认后点击 Deploy 进行部署：

部署成功后我们可以看到 GPT-4o 已经出现在我们的部署列表中：

步骤 4：部署专属 ChatGPT Web 应用

确认模型部署正常后，我们进入项目左侧菜单中的 Chat，并选择我们刚才创建的 GPT-4o 模型：

在 Chat 界面我们可以选择大语言模型，简单测试问答功能等，确认一些无误后，我们就可以开始创建专属 Web App 了，选择顶部菜单中的 Deploy to a web app：

在部署配置中输入名称，选择 Web App 想要部署的订阅，区域等信息，如果希望保存 ChatGPT 的聊天历史，可以开启最下方的选项，但会额外创建 CosmosDB 数据库服务，会产生额外费用：

确认部署后等待完成即可，如果部署正确，那么在 Chat 界面中会有一个 Launch 按钮：

点击后会打开您的专属 ChatGPT Web 界面：

注意：默认情况下我们部署的 Web App 是基于您订阅中的账户（IAM）来做用户验证的，如果您自己使用可以保持这个默认行为。

如果您有技术能力且希望对这个专属 ChatGPT Web App 做定制开发，可以前往 Git Repo 查看所有实现细节，可以按需修改为适合自己使用的版本。

总结

通过 Azure AI 相关的服务我们可以实现很多人工智能相关的实用业务场景，让我们对 AI 和 大语言模型的了解不仅只停留在铺天盖地的消息和无尽的想象，也可以亲身接触实践！

总览

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 都提供了灵活的定价模型，以满足不同规模和需求的项目。