Cómputo administrado en Microsoft Foundry (versión preliminar)

Note

El proceso administrado en Foundry se encuentra actualmente en versión preliminar pública y se requiere el registro para usarlo. Esta versión preliminar se ofrece sin acuerdo de nivel de servicio y no se recomienda para las cargas de trabajo de producción. Es posible que algunas características no se admitan o que tengan funcionalidades restringidas. Para más información, consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.

Proceso administrado (versión preliminar) es un tipo de implementación en Microsoft Foundry que hospeda modelos de código abierto en capacidad de GPU dedicada sin necesidad de aprovisionar máquinas virtuales, operar un clúster de Kubernetes, crear imágenes de contenedor o poseer un entorno de ejecución de servicio de modelos. Microsoft se encarga de la topología de las GPU, el entorno de ejecución, la imagen del contenedor y la aplicación de parches de seguridad. Elija el modelo, la plantilla de implementación, la familia de aceleradores y el comportamiento de escalado que se ajusten a la carga de trabajo.

El cómputo administrado usa el mismo recurso de Foundry, proyecto, punto de conexión, autenticación, configuración de red, SDK, observabilidad y experiencia de facturación que cualquier otro tipo de implementación en Foundry. Después de implementar un modelo con proceso administrado, el código de la aplicación es el mismo que cualquier otro modelo foundry; solo cambia el nombre de implementación.

En este artículo se explica el tipo de implementación de cómputo administrado en Foundry, los conceptos con los que trabajas (instancias de modelo, plantillas de implementación, familias de aceleradores y entornos de ejecución), el catálogo desde el que puedes implementar, los puntos de conexión para inferencia, el escalado, la facturación y las cuotas, el control de acceso y las limitaciones actuales. Para obtener instrucciones de implementación paso a paso, consulte Implementación de modelos de código abierto con proceso administrado.

Dónde encaja el cómputo administrado en Foundry

Foundry ofrece tres tipos de implementación. La computación administrada es el tipo de implementación que se debe usar para modelos de código abierto en capacidad de GPU dedicada.

Tipo de implementación Qué sirve Billing Más adecuado para
Pago por token estándar Modelos de Foundry comercializados por Azure Por cada token de entrada y salida Ruta de fricción más baja para empezar; tráfico de ráfaga en modelos hospedados sin planeamiento de capacidad.
Rendimiento aprovisionado Modelos de Foundry comercializados por Azure Unidades de rendimiento reservadas Carga predecible y sostenida en determinados Modelos Foundry vendidos por Azure, con latencia constante.
Cómputo administrado Modelos de código abierto y de comunidad del catálogo foundry Por hora, por familia de aceleradores Hospedar modelos de código abierto en GPU dedicadas con entornos de ejecución administrados por Foundry, redes privadas y los mismos SDK que los otros tipos de implementación.

Los tres tipos de implementación comparten un único punto de conexión de Foundry, los mismos patrones de autenticación (Microsoft Entra ID y clave), los mismos SDKs, el mismo entorno de observabilidad y una sola factura. Puede mezclar los tres tipos de implementación en un único proyecto foundry y llamarlos desde el mismo código de cliente.

Conceptos clave

En esta sección se describen los conceptos clave que se deben comprender antes de usar la implementación de proceso administrada en Foundry.

Instancia de modelo

Una instancia de modelo es la unidad de despliegue en el cómputo administrado. No eliges una SKU de máquina virtual ni defines el tamaño de un nodo; en su lugar, describes la carga de trabajo en términos de modelo, y Foundry elige la topología de GPU subyacente. Una instancia puede usar un acelerador o varios, según el modelo y la plantilla de implementación que elija. Para escalar una implementación, cambie el número de instancias del modelo (el capacity valor de la SKU de implementación).

Plantilla de implementación

Una plantilla de implementación es un recurso con nombre con control de versiones que codifica cómo se debe ejecutar un modelo específico. Anclajes de plantilla:

  • Tiempo de ejecución de servicio (por ejemplo, vLLM o SGLang).
  • Familia de aceleradores y recuento por instancia (por ejemplo, un H100 80 GB o dos A100 80 GB).
  • Longitud de contexto admitida y opciones de cuantificación.
  • Ajuste específico del entorno de ejecución, como analizadores de llamada a herramientas y razonamiento, ruta de puntuación, sondeos de estado, simultaneidad de solicitudes y cualquier configuración de extensión de contexto específica del modelo.

Al crear un script de implementación, hace referencia al identificador de plantilla y Foundry controla el resto. Cada modelo del catálogo suele incluir varias plantillas que equilibran la familia de aceleradores, la longitud del contexto y la latencia frente a la capacidad de procesamiento. Por ejemplo, el qwen3-32b modelo expone cuatro plantillas en paralelo:

Template Runtime Acelerador Contexto
qwen--qwen3-32b--40k-nvidia-a100 vLLM 1 × A100 80 GB 40 K
qwen--qwen3-32b--40k-nvidia-h100 vLLM 1 × H100 80 GB 40 K
qwen--qwen3-32b--128k-nvidia-2xa100 vLLM 2 × A100 80 GB 128 K
qwen--qwen3-32b--128k-nvidia-2xh100 vLLM 2 × H100 80 GB 128 K

Elegir una plantilla es el único ajuste que controlas para cómo se ejecuta un modelo.

Familias de aceleradores

Las implementaciones de proceso administradas tienen como destino una familia de aceleradores, no una SKU de máquina virtual específica. Las familias admitidas son:

  • NVIDIA A100 80 GB (A100_80GB)
  • NVIDIA H100 80 GB (H100_80GB)
  • AMD MI300X 192 GB (MI_300_192GB)

Se concede cuota por familia de aceleradores por región.

Entornos de ejecución de modelos

La capacidad de proceso administrada ejecuta cada modelo en un entorno de ejecución para inferencia que Microsoft crea, analiza, firma y actualiza con parches. No ejecutas ni reconstruyes contenedores. El portafolio de entornos de ejecución se selecciona según la arquitectura del modelo:

Runtime Usado para Notas
vLLM Servicio LLM de alto rendimiento Procesamiento por lotes continuo, PagedAttention, paralelismo de tensores, intercambio en caliente de LoRA. Valor predeterminado para la mayoría de los modelos de lenguaje grandes.
SGLang Servicio de LLM con salida estructurada Generación de JSON, regex y gramática restringida para cargas de trabajo agente y de uso de herramientas.
TensorRT-LLM Servicio LLM optimizado para NVIDIA Inferencia de NVIDIA de baja latencia para familias de modelos en las que TRT-LLM gana en la latencia o el rendimiento.
NVIDIA NIM Microservicios de inferencia de NVIDIA TensorRT-LLM back-end con compatibilidad con la API NIM para modelos publicados por NVIDIA.
Inferencia de incrustaciones de texto (TEI) Incrustaciones, reordenadores, clasificadores Núcleos específicos para aceleradores para las rutas críticas de embebido y recuperación.
llama.cpp CPU y ejecución en GPU pequeñas Modelos cuantizados en formato GGUF a través de una misma API compatible con OpenAI.
hf-serve Visión, audio, segmentación y otros flujos de procesamiento nativos de Transformers Servidor multimodelo de Hugging Face para modalidades fuera de las rutas rápidas de LLM y embeddings.

Las actualizaciones en tiempo de ejecución y las revisiones CVE se aplican automáticamente a las implementaciones de clientes activas. No es necesario volver a implementar el modelo para aplicar una actualización del entorno de ejecución.

Modelos compatibles

Puede usar el proceso de inferencia administrado en Foundry para implementar modelos de la Hugging Face Collection del catálogo de modelos de Foundry, que se sirven desde el registro azure-huggingface. Estos modelos tienen los siguientes atributos:

  • Mantenido y actualizado semanalmente. Los modelos de tendencia del ecosistema Hugging Face se agregan continuamente a medida que la comunidad las publica. El catálogo abarca modelos de texto, visión, audio y multiplataforma (LLM y modelos de lenguaje de visión para chat y agentes), reconocimiento automático de voz (ASR), traducción de voz, incrustaciones, segmentación e generación de imágenes.
  • SafeTensors solo, sin código que no sea de confianza. Todos los modelos de la colección se someten a revisión. Los repositorios que requerirían ejecutar Python de terceros durante la carga (patrones trust_remote_code) se subsanan o se excluyen.
  • Pesos preconfigurados. Los pesos del modelo se obtienen de Hugging Face una sola vez, se validan y se almacenan en el almacenamiento de Azure administrado por Microsoft en las regiones donde se sirve el modelo. Las imágenes de contenedor están en un registro administrado por Microsoft. Como resultado, los despliegues de cómputo administrado no necesitan acceso saliente a la red hacia Hugging Face Hub — puede desplegarlo en una red totalmente privada, sin tráfico saliente.
  • Metadatos de licencia conservados. Cada tarjeta de modelo de catálogo captura y expone la licencia ascendente. La revisión de licencias con respecto a la política de distribución empresarial de Microsoft se lleva a cabo durante el proceso de selección.

Flujo de trabajo de selección de modelos

Todos los modelos de la colección de Hugging Face pasan por un proceso de depuración de cinco etapas antes de aparecer en el catálogo:

  1. Identificar modelos de tendencia: Microsoft identifica los modelos de tendencia basados en señales de la comunidad, solicitudes de asociados y demanda de clientes.
  2. Revisión de cumplimiento normativo y seguridad: Cada modelo se somete a una revisión de licencias y a una inspección de trust_remote_code patrones y código ejecutable personalizado.
  3. Compilar, analizar y publicar imágenes de contenedor en tiempo de ejecución: Compiladas por Microsoft, analizadas en busca de CVE, firmadas y publicadas en un registro administrado por Microsoft.
  4. Cargar los pesos del modelo en un almacenamiento seguro de Azure: Validados según la tarjeta del modelo y almacenados en las regiones donde se sirve el modelo.
  5. Validar y publicar: cada combinación de modelo, tiempo de ejecución y acelerador se prueba para la conformidad y el rendimiento de la API y, a continuación, se publica en el catálogo con una ruta de acceso de implementación con un solo clic.

Puntos de conexión de inferencia

Implementar un modelo en un proceso de cálculo administrado pone el modelo a disposición para realizar inferencias en el mismo punto de conexión unificado del proyecto de Foundry que utilizan las implementaciones de pago por token y con rendimiento aprovisionado. El punto de conexión base tiene el patrón https://<account>.services.ai.azure.com.

Rutas de punto de conexión

Una implementación de cómputo gestionada puede invocarse a través de dos familias de rutas en el endpoint unificado. La ruta que elija depende de si el modelo subyacente y el entorno de ejecución exponen una API compatible con OpenAI.

Route Camino Se aplica a Comportamiento
Ruta de despliegues gestionados (OSS) <endpoint>/managed-deployments/<deployment-name>/ Todos los despliegues de cómputo administrado Funciona con todos los modelos implementados en infraestructura de computación administrada, incluidos los modelos a medida que incorporan su propio SDK. Los modelos que exponen /chat/completions también se pueden invocar a través de esta ruta con el SDK de OpenAI, configurando el cliente base_url para que apunte a esta ruta.
Ruta compatible con OpenAI <endpoint>/openai/v1/ Despliegues administrados de computación cuyo tiempo de ejecución expone una API compatible con OpenAI (por ejemplo, vLLM, SGLang, TensorRT-LLM, llama.cpp para chat o representaciones vectoriales) El SDK de OpenAI puede invocar la implementación configurando base_url con esta ruta y pasando el nombre de implementación en el campo model del cuerpo de la solicitud. Si una solicitud tiene como destino esta ruta con un nombre de implementación cuyo modelo subyacente o tiempo de ejecución no admite la superficie compatible con OpenAI, el entorno de ejecución devuelve HTTP 404.

Conclusiones clave:

  • Cada implementación de computación administrada es accesible a través de la ruta https://<account>.services.ai.azure.com/managed-deployments/<deployment-name>/.
  • Cualquier implementación cuyo entorno de ejecución sea compatible con OpenAI también es accesible en la https://<account>.services.ai.azure.com/openai/v1/ ruta.
  • Use la ruta de OpenAI cuando quiera compartir código de cliente con otras implementaciones de Foundry.
  • Use la ruta de implementaciones administradas para los modelos que envían un SDK personalizado o una API que no es de OpenAI.

Tip

También se puede agregar una implementación administrada de capacidad de proceso de finalización de chat a un agente de Foundry como modelo conectado por el administrador, e invocarse a través de la API de respuestas de Foundry con el mismo SDK de OpenAI, usando la misma autenticación, el mismo punto de conexión y la misma observabilidad que cualquier otro modelo de Foundry.

Autenticación de punto de conexión

Las implementaciones de cómputo administrado utilizan los mismos patrones de autenticación que el resto del endpoint de Foundry:

  • Microsoft Entra ID (recomendado). Adquiera un token para el https://ai.azure.com/.default ámbito y páselo como token de portador en el Authorization encabezado. Para invocar una implementación de proceso administrado con Entra ID, la identidad que realiza la llamada necesita el rol Foundry User en el ámbito de la cuenta de Foundry. El SDK de OpenAI en modo basado en tokens y DefaultAzureCredential funcionan sin ninguna configuración específica del cómputo administrado.
  • Clave de API de cuenta. Pase la clave de cuenta de Foundry como Authorization: Bearer <key>. El SDK de OpenAI envía la clave de este formulario automáticamente al establecer el api_key argumento. Las claves conceden el mismo acceso en las implementaciones de proceso administradas que en las implementaciones de pago por token y PTU en la misma cuenta.

Ambas opciones de autenticación funcionan en ambas rutas de punto de conexión. Para obtener ejemplos de código de cliente de un extremo a otro (SDK de OpenAI con Entra ID o clave de API), consulte Enviar una solicitud de prueba.

Scaling

Puede escalar una implementación de proceso administrado cambiando el número de instancias del modelo. Al establecer el capacity valor en la SKU de implementación, Foundry ajusta el recuento de GPU en consecuencia. El número total de GPU es igual al número de instancias del modelo multiplicadas por las GPU por instancia definidas por la plantilla de implementación elegida. Foundry no le pide que cambie el tamaño de un nodo ni elija una familia de máquinas virtuales.

Ámbitos de facturación, cuotas e implementación

La capacidad de cómputo administrada se factura por hora y por acelerador. A diferencia de la infraestructura basada en máquinas virtuales, en la que se alquilan servidores completos con GPU y se paga por cada GPU del servidor tanto si el modelo la utiliza como si no, la computación administrada se cobra por instancias de modelo. Foundry ajusta el tamaño de cada modelo al número de GPU que realmente necesita (una, dos, cuatro u ocho), para que no pagues por aceleradores inactivos asignados a tu carga de trabajo. El costo de una implementación es:

Aceleradores por instancia de modelo × instancias de modelo × horas de ejecución × tarifa por hora

Las tarifas por hora varían según la familia de aceleradores (A100, H100, MI300X) y por ámbito de implementación. Para obtener los precios actuales, consulte la calculadora de precios de Azure.

Ámbito de la implementación

El proceso de cómputo administrado (versión preliminar) admite actualmente la implementación Global, establecida mediante el nombre de SKU de implementación GlobalManagedCompute. El despliegue global le ofrece la mayor capacidad de aceleradores al menor coste.

Quota

La cuota de proceso administrado se concede por cada familia de aceleradores y por región a través del proceso de cuotas de Foundry. La cuota de cómputo administrado es independiente de la cuota de VM de Azure. Aunque la cuota de VM de Azure es una asignación de infraestructura como servicio (IaaS) vinculada a SKU de VM regionales específicas, la capacidad de proceso administrada es una oferta PaaS administrada. La cuota de máquina virtual Azure existente no se puede aplicar a una implementación de proceso administrada.

Para obtener más información sobre cómo ver el uso, asignar costos a un proyecto y solicitar cuota, consulte Planar y administrar los costos de Microsoft Foundry y Administrar y aumentar cuotas.

Control de acceso

El cómputo administrado usa el modelo de control de acceso basado en roles (RBAC) de Foundry. El conjunto de operaciones del proveedor de recursos de Azure necesarias para crear, leer, actualizar y eliminar una implementación de proceso administrado se documenta en Control de acceso basado en roles para Microsoft Foundry: operaciones del plano de control del proceso administrado, junto con los roles integrados que conceden cada una de las operaciones.

De un vistazo:

  • Colaborador de Cognitive Services (o Propietario de Foundry / Propietario de la cuenta de Foundry) otorga permisos completos de creación, lectura, actualización y eliminación en implementaciones de proceso administrado.
  • Usuario de Cognitive Services y Usuario de Foundry otorgan acceso de solo lectura a las implementaciones.
  • Foundry Project Manager concede acceso de lectura a las implementaciones y a los datos de uso del acelerador, pero no crea ni elimina.

La inferencia (plano de datos) en el punto de conexión unificado de Foundry sigue el patrón estándar de Foundry al asignar Foundry User en el ámbito de la cuenta de Foundry para invocar implementaciones con Microsoft Entra ID.

Limitaciones

El proceso de cómputo administrado está en vista previa pública. Tenga en cuenta lo siguiente antes de implementar cargas de trabajo de producción:

  • Filtrado de contenido: Los filtros integrados de Seguridad del contenido de Azure AI no forman parte de la ruta de datos del proceso administrado en la versión preliminar pública. Si necesita filtrado de nivel de solicitud o de nivel de respuesta, llame a las API Seguridad del contenido de Azure AI directamente desde la aplicación.
  • Disponibilidad regional: la computación administrada se lanza con ámbito global. Implementaciones de zona de datos y regiones adicionales que se están implementando: consulte la matriz de disponibilidad general para la cobertura actual.
  • Precios: Las tarifas por hora según la familia de aceleradores y la región, la capacidad reservada y los descuentos por compromiso de uso están evolucionando para la implementación administrada de recursos de computación en versión preliminar. Para conocer las tarifas actuales, consulte la calculadora de precios de Azure.

Contenido relacionado

  • Last updated on