Azure

问题的背景 最近，一台部署在 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%； 进程占用了大量内存。 进一步执行：...

随着 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 本地磁盘 这种部署方式比较简单，但随着应用逐渐稳定运行，数据库维护也成为了新的负担。...

1. 引言 在 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....

在多模型并存的 AI 架构中（如 GPT-4 / GPT-4o / 轻量模型 / 垂直模型等），一个核心问题是： 如何在不显式指定模型 ID 的情况下，让系统自动选择最合适的模型？ 本文介绍一种工程可落地的方案： 通过 Embedding 模型计算用户意图 → 在网关层进行语义匹配 → 动态路由到最合适的上游模型服务 我们将基于： Embedding 模型：Azure OpenAI text-embedding-3-small 网关：Envoy 核心机制：向量相似度打分 + 策略路由 问题背景与动机 在真实生产环境中，大模型调用通常面临几个挑战： 1. 成本与性能权衡 模型类型 优点 缺点 大模型（如 GPT-4） 能力强 成本高 / 延迟高 小模型（如 GPT-4o-mini） 快 / 便宜 能力有限 专用模型 精准 泛化弱 不同请求应该走不同模型，而不是“一刀切”。 2. 传统做法的局限 常见策略： 手动指定 model_id ❌（不智能） 基于规则（if/else）❌（不可扩展） 基于关键词匹配 ❌（语义不鲁棒） 3. 理想目标 我们希望： 用户只输入 prompt，系统自动理解“意图”，并选择最优模型 这正是 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，而是一个“可复用的能力接口”。 对比理解 方式 特点 问题 Prompt 临时输入 不可复用、不稳定 Prompt Engineering 优化表达 仍然是一次性 Skill 能力封装 可复用、可组合、可治理 为什么 Skill 很重要？ 在实际开发中，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 的主要特性 多平台消息接入 Clawdbot 支持通过连接聊天平台 API，接收来自 WhatsApp、Telegram、Discord、Signal、Slack、Microsoft Teams 等消息，并将这些消息传递给 AI 模型进行处理。 隐私和数据控制 与云端托管的聊天 AI 不同，Clawdbot 可以运行在你自己的服务器或 VPS 上，所有对话历史、配置、凭据都可以按需存储和访问。 自动化执行能力 除了对话，Clawdbot 还能执行具体任务，包括浏览器控制、文件操作、数据处理、发送提醒等，这使其成为一个更为复杂的个人助手平台。 可扩展的模型支持 Clawdbot 支持多种 AI 模型提供者（如 OpenAI GPT、Anthropic Claude，甚至本地 LLM 服务如 Ollama）。 在 Azure VM 部署 Clawdbot 虽然 Clawdbot 支持本地运行或容器平台，但在以下场景中，Azure VM 是非常合适的部署形态：...

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 等应用 这种格式灵活性是模型在实际生产环境中落地的关键能力。...

近年来，生成式 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....

在电商和物流领域，有一个不起眼但极其耗时的痛点：将复杂的地址格式正确的输入到物流系统固定的字段中。客户发来的地址格式千奇百怪，有时是逗号分隔，有时连成一行，顺序也完全随机，经常还缺少省份或州等关键信息。 本文我想分享我是如何构建 Auto Address 的，这是一个利用 Azure OpenAI 的强大能力来解决这个问题的 Chrome 及 Edge 浏览器扩展插件，其界面和使用方式及其简单。 问题：非结构化数据 想象一下收到这段文本： “张三 13800138000 广东省深圳市南山区科技园南区R2-B三楼” 为了发货，你需要将其拆解为： 姓名: 张三 电话: 13800138000 地址: 科技园南区R2-B三楼 城市: 深圳市 省份: 广东省 国家: 中国 手动处理成百上千个订单既繁琐又容易出错。正则表达式（Regex）可以处理某些情况，但当格式变化或用户有错别字时，它们往往无能为力。 解决方案：LLM 作为解析器 像 Azure OpenAI（如：GPT-4 或 GPT-5）这样的大语言模型在理解上下文方面表现出色。它们能区分街道名称和城市名称，不是因为死板的规则，而是因为它们理解地址的语义。 我选择 Azure OpenAI 进行此项目主要有两个原因： 企业级隐私：发送到 Azure OpenAI 的数据不会用于训练公共模型。 可靠性：稳定的正常运行时间和性能。 技术揭秘：它是如何工作的 插件的核心逻辑出奇地简单。它获取用户的输入，并将其连同一组非常具体的指令发送到 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....

随着 Azure AI Foundry 开放对 **Sora 2（OpenAI 生成式视频模型）**的支持，开发者现在可以在企业级合规、可管控的环境中使用顶尖的视频生成能力。本教程将带你从零开始，通过 Playground 和 Python SDK 两种方式调用 Sora 2，完成「文本生成视频」的流程。 准备工作 在开始之前，你需要： 获取 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：...

大模型在推理部署时，往往存在显存瓶颈： 模型参数（Parameters, P）动辄上百 GB，需要长期驻留显存。 输入/输出数据（Data, D）则随请求动态变化，但往往和参数耦合在同一设备上，导致显存占用不均衡，扩展性受限。 为了解决这一问题，可以借助 vLLM 框架实现参数 / 数据（P/D）分离，提升推理系统的灵活性和吞吐。 大模型推理的资源瓶颈 以一个 70B 规模的 Transformer 模型为例： 参数权重（FP16 存储）约需 140GB 显存； 每次请求输入的序列数据、KV Cache 会消耗额外显存，并随 batch size 增长而急剧膨胀。 如果不加区分地将 P 与 D 放在同一块 GPU： 参数长期驻留，挤压了用于动态数据的显存； 多实例并发时，数据显存不足，限制了吞吐。 因此，在分布式推理系统中，业界逐渐采用 参数与数据分离（P/D Separation） 的架构思路。 vLLM 简介 vLLM 是一个高性能的大模型推理引擎，核心优势包括： PagedAttention：高效管理 KV Cache，支持大批量并发； 高吞吐率：相较于 Hugging Face Transformers 推理，吞吐提升数倍； 灵活的分布式支持：可结合 DeepSpeed、Megatron 等方案，支持参数/数据分布式存储与调度。 vLLM 的模块化架构，使其天然适合实现 P/D 分离。 P/D 分离的实现思路 在 vLLM 中，推理流程大致分为两个部分： 参数侧（P） 模型权重加载与存放； 可通过 ZeRO-3 / Tensor Parallel 等策略将参数分布在多 GPU 节点上； 参数在整个推理生命周期中保持常驻，不随请求波动。 数据侧（D）...

什么是 VibeVoice？ 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 有几个比较新的或者关键的技术设计： 组件 功能 / 目的 Continuous Speech Tokenizers（声学 + 语义两种） 用来把音频压缩成低帧率（7.5 Hz）表示，同时保留语义与音质信息。声学 token 与语义 token 分别负责声音细节和内容表达。 LLM 基础模型（Large Language Model） 在该版本里用的是 Qwen2.5-1.5B，用来处理文本、说话人信息以及上下文对话流。 Diffusion Head 对声学 VAE 的特征进行预测，是生成高保真声音细节的模块。这个模块较轻 (大致 4 层结构)，在推理阶段使用 diffusion 的技术（包括去噪等）。 上下文长度 & 多说话人 支持高达 90 分钟语音生成，最多 4 个说话人。 架构图如下： 优点和局限 优点 长篇幅对话能力 — 能生成近 90 分钟的连续对话，并维持说话人一致性。 多说话人支持 — 最多支持 4 个不同说话人的切换，且对话流程自然。 压缩效率高 — 用 7....

随着大语言模型热度的升级，企业和个人使用者的研究重心逐步从训练转移至推理（说白了是由造轮子转变为务实的使用）。而在模型推理领域，最炙手可热的两大框架无疑是 vLLM 和 SGLang，而作为后起之秀的 SGLang，其表现也值得大家关注，今天就基于 SGLang 为大家带来一篇入门教程文章，希望能帮助更多希望了解大语言模型及 SGLang 框架的朋友。 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....

DeepSeek 的爆火让人们再一次看到了 AI 的魅力，而随之而来的不仅不是对算力需求的减少，而是在低成本亲民化人工智能中构建更多 AI 业务场景带来的另一波算力需求。今天我们来通过 Azure AI Foundry（原 Azure AI Studio）快速体验 DeepSeek 的风采。 先决条件 首先需要拥有 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 蒸馏版：...

日常使用 ChatGPT 来帮助我们解决工作和生活中的问题已经变成习惯，但偶尔重度使用官方 GPT-4o 后发现会出现临时限额问题，今天我们就来手把手教大家如何轻松通过 Azure OpenAI 服务构建一个专属 ChatGPT 应用。 先决条件 在开始之前，请确保您拥有 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 区域的使用便利性更佳。...