Hugging Face 模型支持 Foundry 托管计算

平台：Microsoft Foundry 与 Managed Compute

Microsoft Foundry 是一个用于构建和运行 Agentic AI 应用的平台。Foundry 首先提供了云平台中最广泛的模型选择——包括来自 Microsoft、OpenAI、Anthropic、Meta、Mistral、DeepSeek、Hugging Face 等厂商和社区的模型，覆盖前沿模型、开源模型和自定义权重模型——所有模型都可以通过一个统一端点，以及一套适用于 Python、C#、JavaScript 和 Java 的统一 SDK 访问。

在这些模型之上，是 Foundry Agent Service：它支持多 Agent 编排，内置记忆能力，通过 Foundry IQ 实现知识 grounding，并提供一个可通过 Agentic 协议连接的工具目录，让 Agent 能够使用企业数据。Agent 开始运行后，Foundry 还会提供端到端追踪、实时监控、持续评估，以及一个能够根据评估结果改善 Agent 行为的 prompt 优化器——可观测性与质量反馈闭环都是平台本身的一部分。

除此之外，开发者还可以使用：

• 内容安全过滤器
• 任务遵循 guardrail
• 用于对抗性测试的 AI Red Teaming Agent
• 直接集成在平台内的 Azure Policy

除了按 token 付费（门槛最低的入门方式）和预配吞吐量（面向前沿模型、性能可预测的高性能生产工作负载），Foundry Managed Compute 是 Foundry 提供的第三种部署方式：一个面向开源模型和自定义模型的托管 GPU 平台即服务。

你只需要根据工作负载真正关心的指标描述并部署一个模型实例——参数量、上下文长度，以及希望针对延迟还是吞吐量进行优化——Foundry 会处理底层 GPU 拓扑。无论实例最终运行在一个还是多个加速器上，你都可以从模型的角度思考和规划。

Microsoft 会负责管理机器：在受支持的 runtime——vLLM、SGLang、TensorRT-LLM、NIM、TEI、llama.cpp——上，容器更新、runtime 升级和安全补丁都会自动完成，不需要重新部署模型；而模型配置、部署行为和路由仍由你掌控。

这种一致性也贯穿开发者使用的各个层面——按 token 付费、预配吞吐量和 Managed Compute 共享：

• 相同的身份验证
• 相同的可观测性

开源模型与 Foundry Agents 的集成方式和前沿模型完全相同，因此你可以在同一个 Agent 中混用不同类型的模型，不需要额外的集成路径。

Managed Compute 提供：

• Global 部署——容量最广、价格最优
• Data Zone 部署——满足数据驻留和主权要求

相同的代码，相同的工作流。配额与加速器家族对齐，因此今天基于 H100 家族制定的方案，在新一代硬件上线后仍然可以延续使用。

Hugging Face 是开放 AI 的公共广场：拥有 1,500 万名构建者、40 万个组织，以及超过 300 万个已发布的开放模型。Agentic coding、视频分割、语音、embedding 等新的前沿能力每周都会在这里出现。它就像开放模型领域的 GitHub，社区成员在这里发布权重、编写 model card、比较评估结果，并拉取模型进行实验。

在一个又一个 benchmark 上，开放模型已经缩小了与专有模型的差距，而且还能提供专有端点无法实现的能力：

• 最先进的能力如今已经开放。领先的开放权重模型在最常用的 benchmark 上，已经可以与顶尖的闭源前沿模型竞争。
• 深度定制。完整权重让你能够进行 fine-tune、蒸馏、量化，以及通过 LoRA 适配——针对你的领域、数据、延迟和成本目标定制模型。
• 你的模型，你来托管。权重运行在你的租户中，部署于你所控制的基础设施之上，位于你的推理端点之后，并遵循你的身份和网络边界。
• 成本塑形。按小时为加速器付费，空闲时缩容至零，并根据具体模型选择尺寸适合的 GPU——这对于稳定、高吞吐量或延迟敏感型工作负载尤其有用，因为这些场景下按 token 定价的成本更难预测。
• 版本控制。固定某个具体的模型版本，对其进行评估和部署，并按照自己的发布节奏向前升级或回滚。

问题一直出在运维层：模型发现、许可证审查、安全筛查、runtime 选择、GPU 规格评估、镜像构建、CVE 补丁，以及将模型部署到企业级端点之后。Hugging Face 本身并不是一个企业级模型服务平台。Foundry 上的 Hugging Face 模型提供的正是这一运维层，并由 Microsoft 负责运行。

Foundry 上的 Hugging Face 模型

Hugging Face Collection 将经过筛选的模型子集直接引入 Foundry Model Catalog：

• 每周更新——随着社区不断发布新模型，来自 Hugging Face 生态系统的热门模型会持续加入。
• 覆盖所有模态——文本、视觉、音频和多模态：用于聊天和 Agent 的 LLM 与 VLM、ASR 与语音翻译、embedding、分割、图像生成。
• 仅使用 Safetensors，不包含不受信任的代码——Collection 中的每个模型都经过安全筛查，并以 SafeTensors 权重格式提供；除非经过严格审查，否则不会包含任何 trust_remote_code 执行路径。
• 为模型选择合适的 runtime——LLM 使用 vLLM 和 SGLang，适用时使用 TensorRT-LLM 和 NIM，embedding 使用 TEI，CPU 使用 llama.cpp——Foundry 会选择与模型相匹配的引擎。

对你而言，Hugging Face Collection 中的开放权重模型看起来和使用起来都与 Foundry Model Catalog 中的其他模型一样。Collection 中的每个模型在出现在目录中之前，都已经经过多阶段发布流水线。

筛选流水线

Hugging Face 与 Microsoft 携手合作，通过一套系统化的筛选流程，将 Hugging Face 生态系统中最受欢迎的开放权重模型引入 Microsoft Foundry，并使其达到可在企业环境中投入生产的标准：

1. 识别 Hugging Face 生态系统中的热门模型——根据社区信号、合作伙伴请求和客户需求，选择具备企业就绪潜力的候选模型。
2. 进行合规与安全筛查——依据 Microsoft 的企业分发政策审查模型许可证，并将许可证元数据记录和保留在目录的 model card 中；同时检查仓库是否存在 trust_remote_code 模式和自定义可执行代码。任何需要在加载时执行第三方 Python 代码的模型，要么经过修复，要么被排除。
3. 构建、扫描并发布 runtime——Microsoft 基于受支持的 runtime（vLLM、SGLang、TensorRT-LLM、NIM、TEI、llama.cpp）构建推理容器镜像，对其执行 CVE 扫描，然后签名并发布到由 Microsoft 管理的容器注册表。
4. 将权重上传到安全的 Azure 存储——模型权重只从 Hugging Face 拉取一次，按照已发布的 model card 进行验证，然后存储在由 Microsoft 管理的 Azure 存储中，覆盖提供该模型服务的区域。
5. 验证并发布到目录——每种模型、runtime 与加速器组合都会接受 API 一致性测试（chat completions、embedding、rerank 等）和性能测试（延迟、吞吐量、首 token 时间、token 间解码时间）。随后，经过验证的模型及其模板、runtime 镜像和权重会发布到 Foundry Model Catalog，并提供一键部署到 Managed Compute 的路径。

由于权重已经预先存放在 Azure 存储中，runtime 镜像也位于 Microsoft 管理的注册表内，因此你的部署不需要通过出站网络访问 Hugging Face Hub——你可以在私有网络中部署到生产环境。

Foundry 上的 Hugging Face 模型由一组功能多样、由社区构建的开源推理 runtime 提供支持。每种 runtime 都针对 Foundry Managed Compute 进行了选择和调优，并与其最擅长服务的模型架构相匹配。在所有 runtime 中，系统化的筛选流程意味着新版本和补丁能够迅速进入 Foundry，现有模型部署也会自动升级——不需要你重新部署。

• vLLM——开放大型语言模型默认使用的高吞吐量服务引擎，针对生产级 GPU 工作负载进行了调优。由于 Hugging Face 是 vLLM 的直接贡献者，Transformers 库中的任何模型都可以直接在 vLLM 上运行——因此，当新模型登陆 Hugging Face 时，它当天就能在 Foundry 上提供服务，无须等待自定义集成。

• vLLM——开放大型语言模型默认使用的高吞吐量服务引擎，针对生产级 GPU 工作负载进行了调优。由于 Hugging Face 是 vLLM 的直接贡献者，Transformers 库中的任何模型都可以直接在 vLLM 上运行——因此，当新模型登陆 Hugging Face 时，它当天就能在 Foundry 上提供服务，无须等待自定义集成。

• SGLang——面向语言和多模态模型的服务引擎，对结构化输出（JSON、regex、受 grammar 约束的生成）提供强大支持，而 Agentic 工作负载和使用工具的工作负载正依赖这些能力。Hugging Face 和 SGLang 团队为 SGLang 构建了 Transformers backend 集成，因此 Transformers 库中的任何模型都可以直接在 SGLang 上运行——并且可以在登陆 Hugging Face 的当天进入 Foundry。

• SGLang——面向语言和多模态模型的服务引擎，对结构化输出（JSON、regex、受 grammar 约束的生成）提供强大支持，而 Agentic 工作负载和使用工具的工作负载正依赖这些能力。Hugging Face 和 SGLang 团队为 SGLang 构建了 Transformers backend 集成，因此 Transformers 库中的任何模型都可以直接在 SGLang 上运行——并且可以在登陆 Hugging Face 的当天进入 Foundry。

• Text Embeddings Inference（TEI）——用于 embedding、reranker 和序列分类模型的 runtime。针对不同加速器构建的镜像，包含为 Foundry 支持的每个 GPU 和 CPU 家族编译的 kernel，使 RAG 和语义搜索工作负载中的 embedding 关键路径保持精简高效。

• Text Embeddings Inference（TEI）——用于 embedding、reranker 和序列分类模型的 runtime。针对不同加速器构建的镜像，包含为 Foundry 支持的每个 GPU 和 CPU 家族编译的 kernel，使 RAG 和语义搜索工作负载中的 embedding 关键路径保持精简高效。

• llama.cpp——面向 GGUF 量化模型的 CPU 和小型 GPU 方案。适用于成本优化型部署、较小的模型和仅支持 CPU 的区域，并提供与 vLLM 和 SGLang 相同的 OpenAI-compatible API。

• llama.cpp——面向 GGUF 量化模型的 CPU 和小型 GPU 方案。适用于成本优化型部署、较小的模型和仅支持 CPU 的区域，并提供与 vLLM 和 SGLang 相同的 OpenAI-compatible API。

• TensorRT-LLM 和 NIM——用于 NVIDIA 硬件。在特定模型家族上，当 NVIDIA 优化过的 kernel 和基于 Triton 的服务方式能够显著改善延迟或吞吐量时，就会采用它们。

• TensorRT-LLM 和 NIM——用于 NVIDIA 硬件。在特定模型家族上，当 NVIDIA 优化过的 kernel 和基于 Triton 的服务方式能够显著改善延迟或吞吐量时，就会采用它们。

• hf-serve——Hugging Face 自己的多模型推理服务器，用于 LLM 和 embedding 快速路径之外的模型架构（视觉、音频、分割以及其他 Transformers 原生 pipeline），让 Collection 能够通过统一的服务层覆盖所有模态。

• hf-serve——Hugging Face 自己的多模型推理服务器，用于 LLM 和 embedding 快速路径之外的模型架构（视觉、音频、分割以及其他 Transformers 原生 pipeline），让 Collection 能够通过统一的服务层覆盖所有模态。

部署开放权重模型并进行推理

第一步是进入 Foundry Model Catalog 中的 Hugging Face Collection，整个部署过程分为五步：

1. 浏览目录并选择模型——部署向导还会显示 model id、deployment template id 和 acceleratorType；如果你要通过 SDK 或 REST 编写部署脚本，就需要用到这些信息。
2. 选择 deployment template——可选择延迟优化或吞吐量优化，以及加速器家族、上下文长度和量化方式。
3. 配置实例数量——通过增加模型实例来扩展吞吐量。
4. 部署——可以通过 portal、CLI、SDK 或 REST 完成。
5. 使用你已经在用的 SDK，通过统一的 Foundry 端点进行推理。

deployment template 是第 2 步中的选择单元：它是一个具名且带版本的资产，固定了 runtime、加速器家族与数量、上下文长度，以及高质量服务该模型所需的 runtime 专属调优配置——因此，要决定“我希望这个模型如何运行”，你只需要选择一个模板。

例如，qwen3-32b 提供四种模板，部署向导会将它们并排列出：

每个模板都已经针对模型预先调优——runtime 设置、工具调用和推理 parser、推理路径、健康探针、请求并发度，以及所有模型特定的上下文扩展设置，都由 Microsoft 预先配置；相关取舍则会直接写在模板描述中。通过脚本部署时，你只需要引用模板，其余工作由 Foundry 处理。

from azure.identity import DefaultAzureCredential
from azure.mgmt.cognitiveservices import CognitiveServicesManagementClient

client = CognitiveServicesManagementClient(DefaultAzureCredential(), SUBSCRIPTION_ID)

deployment = client.managed_compute_deployments.begin_create_or_update(
    resource_group_name=RESOURCE_GROUP,
    account_name=ACCOUNT_NAME,
    deployment_name="qwen3-32b",
    resource={
        "sku": {"name": "GlobalManagedCompute", "capacity": 1},
        "properties": {
            "model": "azureml://registries/azure-huggingface/models/qwen--qwen3-32b/versions/1",
            "deploymentTemplate": "azureml://registries/azure-huggingface/deploymenttemplates/qwen--qwen3-32b--40k-nvidia-h100/labels/latest",
            "acceleratorType": "H100_80GB",
        },
    },
).result()

你可以使用 OpenAI SDK，通过统一的 Foundry 端点访问该部署——model 字段填写刚刚创建的部署名称：

from openai import OpenAI

api_key  = client.accounts.list_keys(RESOURCE_GROUP, ACCOUNT_NAME).key1
endpoint = f"https://{ACCOUNT_NAME}.services.ai.azure.com/openai/v1"

openai_client = OpenAI(base_url=endpoint, api_key=api_key)

completion = openai_client.chat.completions.create(
    model=deployment.name,
    messages=[{"role": "user", "content": "What is the capital of France?"}],
)

print(completion.choices[0].message)

Collection 中的 chat-completions 模型可以作为由管理员连接的模型接入 Foundry Agents，并通过 Foundry Responses API 使用同一个 OpenAI SDK 调用——相同的身份验证、相同的端点、相同的可观测性。

当前可用能力

目前已提供预览版：Microsoft Foundry Model Catalog 中的 Hugging Face Collection——包含覆盖所有模态的数千个模型，每周更新，可使用 NVIDIA A100、NVIDIA H100 或 AMD MI300X 加速器部署到 Global 和 Data Zone 范围内的 Foundry Managed Compute；通过统一的 Foundry 端点提供服务，并支持 Playground、原生 Azure Monitor 指标、按部署设置的计费标签，以及自动应用于部署的精选 runtime 升级和 CVE 补丁。

路线图包括：覆盖更广泛的 Hugging Face 生态系统、支持更多加速器家族，以及提供 Bring Your Own Weights，让 fine-tune 变体和专有变体能够通过与 Collection 模型相同的模板和治理机制进行部署。

Hugging Face 是开放模型发布和发现的地方。Microsoft Foundry 则是企业将这些模型投入实际运营的地方——经过筛选、许可证审查和安全筛查的权重托管在 Azure 中；使用由社区构建且经过 CVE 扫描的 runtime；位于一个统一端点之后，并在其上提供企业身份、网络、可观测性和 Agent 集成能力。这既有开源生态系统的广度，也有 Microsoft 在底层运行的运维层。要深入了解 Foundry Managed Compute——包括定价、加速器 SKU、数据驻留、企业就绪能力、可观测性，以及完整的 Responses API 与 memory 模式——请参阅 Managed Compute 发布博客。

此作者的更多文章

• Differential Transformer V2
• OptiMind：专为优化而设计的研究模型

· 注册或登录后发表评论