Optimización del costo de las cargas de trabajo de INTELIGENCIA ARTIFICIAL en Azure

Este artículo muestra a los equipos de startups en fase inicial cómo identificar y reducir los costes de las cargas de trabajo de IA en Microsoft Azure. Está escrito para el fundador, el CTO o el primer ingeniero contratado que es responsable de la factura de la nube y del conjunto de evaluación (eval) a la vez. Abarca el etiquetado y la higiene presupuestaria, las cuatro palancas del flujo de solicitud (almacenamiento en caché, procesamiento por lotes, enrutamiento y selección de modelos), el dimensionamiento adecuado de las GPU para la inferencia autoalojada, los patrones de recuperación para múltiples inquilinos y un ciclo de cambios seguros que puede poner en práctica sin un equipo de plataforma dedicado. Cada sección está etiquetada con la etapa de la guía de arquitectura de Azure para startups en la que se aplica (Explorar, Expandir o Extraer), para que puedas evitar optimizar para problemas que todavía no tienes.

En este artículo, aprenderá a:

  • Identifique los principales factores de costo de una carga de trabajo de inteligencia artificial en Azure.
  • Haga coincidir las palancas de optimización de costos con la fase de inicio.
  • Aplique el almacenamiento en caché de mensajes, el almacenamiento en caché semántico, el procesamiento por lotes, el enrutamiento de modelos y el ajuste de tamaño correcto.
  • Diseñar patrones de recuperación de datos y de bases de datos multicliente que escalen linealmente con los ingresos, no con el uso.
  • Proteja los cambios de costes con un control de evaluación, alertas de presupuesto y límites de tasa por cliente.
  • Reconozca las primeras señales de que el enfoque de hágalo usted mismo para gestionar los costes se le ha quedado pequeño.

Prerequisites

  • Una suscripción de Azure con al menos una carga de trabajo de IA en ejecución en producción, preproducción o un prototipo funcional.
  • Permisos de propietario o colaborador en los recursos que desea medir.
  • Comodidad al abrir el portal de Azure. No se requiere ninguna experiencia previa con Cost Management o Azure Monitor. Este artículo remite a las páginas pertinentes.
  • Un pequeño conjunto de evaluación para tu función de IA, con de 10 a 50 indicaciones representativas y comportamientos esperados. Si aún no tiene una, consulte la sección Artículos relacionados. Puede compilar la primera versión por la tarde.

¿Por qué esto es importante para las startups?

En el caso de un inicio en fase temprana, el costo de la inteligencia artificial es riesgo operativo. La inferencia más barata libera horas de ingeniería para el siguiente experimento y un costo estable por usuario activo le permite planear más allá del siguiente hito de financiación en lugar de la siguiente factura. Los patrones de este artículo son deliberadamente pequeños. Cada uno de ellos es factible por un ingeniero fundador durante un fin de semana, sin que se requiera ninguna plataforma o equipo de FinOps.

Importante

No necesita un equipo dedicado de FinOps para empezar. El primer 80 % de los ahorros de costes proviene de etiquetarlo todo desde el primer día, designar a una persona responsable de una revisión semanal de Cost Management y aplicar las medidas de este artículo siguiendo el orden de las fases. Incorpore herramientas y procesos formales de FinOps solo después de que el gasto supere los 50 000 USD al mes o abarque más de cinco cargas de trabajo distintas.

¿Por qué el costo de inteligencia artificial se muestra de forma diferente al costo tradicional de la nube?

En una aplicación web tradicional, la factura mensual se compone principalmente de máquinas virtuales, bases de datos y tráfico de salida. Normalmente, puede predecirlo en un 10 por ciento sabiendo cuántos usuarios atienden. Las cargas de trabajo de IA interrumpen esa intuición. El mismo usuario puede costar 0,001 USD un minuto y 0,40 USD al minuto siguiente, en función de la longitud del contexto, la profundidad de recuperación y del modelo al que se dirigió la solicitud.

Cuatro formas de costo se repiten en la mayoría de los productos de inteligencia artificial en Azure:

  • El gasto de tokens se escala con longitud de contexto, no con el recuento de usuarios. Un prompt ingenuo de generación aumentada con recuperación (RAG) puede pasar de 800 a 12 000 tokens tras un solo cambio en el producto.
  • El tiempo de inactividad de GPU es el mayor costo oculto en la inferencia autohospedada. Dejar una A100 funcionando toda la noche cuesta más que un mes de una pequeña base de datos Postgres.
  • La ampliación de la recuperación desde bases de datos de búsqueda y vectoriales se agrava. Cada turno de chat podría emitir tres a ocho consultas ocultas que nunca vea en los registros.
  • La salida de datos y el almacenamiento se filtran poco a poco a través de artefactos del modelo, representaciones vectoriales, registros de auditoría e índices de cada cliente.

Cada controlador de costos tiene un conjunto conocido de palancas. Las secciones restantes los describen por orden de prioridad, etiquetados con la etapa de la startup en la que se aplica cada palanca, para que los equipos no sobrediseñen soluciones para problemas que todavía no tienen.

Tip

Use la guía de optimización de costos de la Azure Well-Architected Framework en la arquitectura para mantener y mejorar la rentabilidad de la inversión (ROI).

Mapa de fase: qué palancas pertenecen a dónde

La guía de arquitectura Azure para startups describe tres fases de desarrollo de productos: Explorar, Expandir y Extraer. Las palancas de optimización de costos de este artículo se alinean con esas fases. Utilice la siguiente tabla para determinar qué secciones se aplican hoy a su equipo y cuáles aplazar.

Stage Recuento de personas Objetivo de costo principal Palancas que dan resultados
Explora 1-10 ingenieros Opcionalidad y velocidad Etiquetado, almacenamiento en caché de mensajes, modelo predeterminado barato
Expandir 10-50 ingenieros Acabe con los costes lineales con respecto a los ingresos Caché semántica, escalado a cero, enrutamiento, Batch API
Extracción Más de 50 ingenieros Margen, predictibilidad, FinOps Reservas, índices dedicados, cuantificación, precios por inquilino

Identificación de los principales impulsores de costos

Antes de optimizar cualquier cosa, obtenga una vista plana de dónde va realmente el dinero. En Azure, la ruta de acceso más rápida es Cost Management, agrupada por servicio y etiqueta, durante los últimos 30 días.

Etiquete todo desde el primer día

El etiquetado es la práctica de mayor aprovechamiento para la visibilidad de los costos. Sin etiquetas coherentes, no se puede atribuir el gasto a un inquilino, una característica o un entorno. La arquitectura de referencia Startup Scale Landing Zone (SSLZ) exige el etiquetado a nivel de directiva de la zona de aterrizaje. Use el mismo enfoque para los recursos de inteligencia artificial.

costCenter = product | platform | research
tenant     = <customer-id> | shared
workload   = inference | embedding | training | eval
env        = prod | staging | dev
team       = <owning-team>

Dónde buscar primero

Determinante de costos Dónde encontrarla Proporción típica de la factura
Tokens (API de LLM) Métricas de Azure OpenAI > Tokens de solicitud/finalización procesados 30-60%
GPUs Horas de nodo de VM/AKS por SKU (familias ND, NC y NV) 20-50%
Vectores/búsqueda Unidades de consulta de búsqueda con IA, RU/s de Cosmos DB 5-20%
Almacenamiento Blob Storage, Azure Files y Azure Container Registry para artefactos del modelo 3-10%
Egress Ancho de banda fuera de la región, especialmente llamadas entre nubes 2-15%

Exporte Cost Management a una cuenta de almacenamiento diariamente y conéctela a la pila de análisis existente. Un gráfico semanal de costo por usuario activo es una señal confiable de que una optimización tenía el efecto previsto.

Palanca 1: almacenamiento en caché, procesamiento por lotes, enrutamiento y selección de modelos

Fase: Explore a través de Extract. Comenzar con la caché en Explore, añadir enrutamiento y Batch en Expand, y añadir una selección detallada de modelos por inquilino en Extract.

Tip

Almacene en caché los embeddings usando como clave el hash del contenido de origen, y utilice un modelo más pequeño y económico, como GPT-4o mini o un modelo de 7B a 13B de pesos abiertos, para la clasificación o la extracción en una primera pasada. Escale a un modelo de frontera solo en las solicitudes en las que el modelo pequeño no sea seguro. Este patrón solo a menudo reduce el costo de inferencia entre el 60 y el 80 % sin pérdida de calidad medible en las consultas rutinarias.

Caching

  • Prompt caching: Azure OpenAI desconta automáticamente los prefijos repetidos para solicitudes de al menos 1024 tokens, compatibles con GPT-4o y modelos más recientes. Los primeros 1.024 tokens deben ser idénticos para que se produzca un acierto de caché, así que mantén estables los prompts del sistema y las definiciones de herramientas.
  • Caché semántica: Almacene pares de incrustación y respuesta en Azure Cache for Redis o Cosmos DB. Devuelve la respuesta almacenada en caché cuando una nueva consulta tiene similitud de coseno por encima de aproximadamente 0,95.
  • Caché de salida: En el caso de los puntos de conexión no personalizados, como las preguntas más frecuentes y las herramientas deterministas, una caché sencilla de período de vida (TTL) reduce el tráfico en un 30 al 80 %.

Batching

Los trabajos de inserción y clasificación son los candidatos obvios. La API Batch de Azure OpenAI ofrece un descuento del 50 % frente al procesamiento en tiempo real para trabajos que pueden esperar hasta 24 horas, como actualizaciones nocturnas de índices, ejecuciones del evaluador y resumen asíncrono.

Enrutamiento

La mayoría de los productos no necesitan el modelo más caro en cada llamada. Un enrutador, ya sea basado en reglas o aprendido, puede enviar el 60 al 80 % del tráfico a un modelo más barato sin una caída de calidad medible.

Modelo Camino barato Ruta costosa
Clasificación de intenciones GPT-4o mini o Phi-4 GPT-4o para solicitudes ambiguas
Uso de herramientas o llamada a funciones Modelo de nivel medio Modelo de primer nivel en caso de reintento
Resumen de contexto extenso Ventana deslizante con modelo de nivel medio Modelo de nivel superior de contexto completo
Generación de código Modelo de gama media para plantillas Modelo de primera categoría para refactorización

Selección de modelos

Vuelva a evaluar la elección del modelo cada trimestre. Los precios y la calidad se mueven rápidamente. Un modelo que era su única opción hace seis meses podría ser ahora cinco veces más caro que una SKU más reciente que puntúa dentro de uno a dos puntos en sus evals.

Palanca 2: Infraestructura de tamaño correcto con escalabilidad automática

Fase: Expanda y extraiga. En Explorar, use sin servidor o plataforma como servicio (PaaS), como App Service, consumo de Container Apps o Azure OpenAI Service y omita esta palanca.

Si aloja usted mismo la inferencia con vLLM, Triton o Text Generation Inference (TGI) en Azure Kubernetes Service (AKS) o Azure Container Apps, el segundo factor más importante es asegurarse de que las GPU no estén inactivas.

Escalar a cero con cargas de trabajo inactivas

Establezca minReplicas: 0 en Container Apps con un perfil de carga de trabajo de GPU o use el escalado automático horizontal de pods (HPA) o KEDA en AKS para escalar grupos de nodos a cero cuando no haya solicitudes en curso. Los arranques en frío suelen durar varias decenas de segundos. Realice pruebas comparativas con el modelo y mantenga una réplica cálida durante las horas comerciales si la latencia orientada al usuario es importante.

Ajustar la SKU de la GPU al tamaño del modelo

Haz coincidir la clase de GPU con el número de parámetros. T4 o L4 es suficiente para los modelos por debajo de aproximadamente 13B parámetros. A100 o H100 solo compensa para modelos de más de aproximadamente 34 mil millones de parámetros o para una tasa alta y sostenida de consultas por segundo (QPS). La GPU sin servidor de Container Apps admite actualmente T4 y A100. L4 y H100 requieren AKS.

Entrenamiento en ráfaga y trabajos por lotes para detectar

Ejecute evaluaciones nocturnas, actualizaciones de embeddings y resúmenes sin conexión en grupos de nodos spot, que suelen ser entre un 60 y un 80 % más baratos que los nodos bajo demanda. Mantenga la inferencia de producción en la capacidad dedicada. En la tabla siguiente se resumen las estrategias de escalado automático y sus ahorros típicos.

Caution

La capacidad Spot puede ser desalojada con tan solo 30 segundos de aviso. Usa spot solo para trabajos que puedan reanudarse desde un punto de control o reiniciarse limpiamente, como evaluaciones por lotes, actualizaciones de embeddings, generación de resúmenes sin conexión y ajuste fino con puntos de control frecuentes. Nunca coloque la inferencia o los trabajos orientados al usuario sin lógica de reinicio en el lugar.

Strategy Cómo Ahorros típicos
Escala a cero minReplicas: 0 en Container Apps con perfil de carga de trabajo de GPU. Los arranques en frío suelen durar varias decenas de segundos. Compare con su modelo. Hasta 90%
KEDA basado en la profundidad de la cola Escala en función de Service Bus o de los mensajes de la cola, no de la CPU. 30-60%
SKU con el tamaño adecuado T4 o L4 para modelos con menos de 13B de parámetros. A100 o H100 solo para modelos con más de 34B parámetros o QPS altos. La GPU sin servidor de Container Apps solo admite T4 y A100. L4 y H100 requieren AKS. 40-70%
Capacidad spot Grupos de nodos spot para trabajos por lotes y evaluación. Capacidad a petición para producción. 40-80%
Cuantificación Cuantización de 4 bits con AWQ o GPTQ para ejecutar modelos más grandes en GPU más pequeñas. Ajustar 30B en 16 GB

Note

El escalado hasta cero en una interfaz de chat añade una latencia visible por arranque en frío. Un patrón común es mantener una a dos réplicas cálidas durante el horario comercial y escalar a cero durante la noche.

Palanca 3: patrones multiinquilino sin picos en los costes de recuperación

Fase: De expansión y extracción tardías. En Explorar, casi seguramente tiene un inquilino: usted mismo. Omita esta sección hasta que tenga al menos tres clientes reales.

Los productos de IA multicliente fallan al escalar cuando los patrones de recuperación y de bases de datos se eligieron para un prototipo monocliente. Tres patrones se repiten.

Un índice por inquilino frente al índice compartido con filtros

Un índice de búsqueda con IA dedicado por cliente proporciona un aislamiento claro, pero implica un coste por cada índice incluso cuando está inactivo. Un índice compartido con un filtro de inquilino es mucho más barato a pequeña y mediana escala. Cambie a dedicado solo para el nivel empresarial o cuando un inquilino supere un umbral de tamaño definido.

Opción de base de datos vectorial

Elija el almacén de vectores en función de la infraestructura y la escala existentes. En la tabla siguiente se resume cuándo encaja cada opción.

Warning

La eliminación de un índice vectorial o su almacén subyacente es irreversible y volver a insertar un corpus grande puede costar cientos a miles de dólares en llamadas modelo más horas de tiempo de ingeniería. Antes de cualquier cambio destructivo en un almacén de vectores, realice una instantánea de los documentos de origen y compruebe que la canalización de inserción se ejecuta de un extremo a otro en un pequeño subconjunto.

Opción Más adecuado para Estructura de costes
Búsqueda de Azure AI (vector) Búsqueda híbrida y facetas Por réplica, predecible
Cosmos DB (vector) Teams ya usa Cosmos DB para los datos de la aplicación RU/s, se escala según QPS
pgvector en Postgres Corpora pequeña o mediana, operaciones simples Por máquina virtual, muy barato
Base de datos vectorial dedicada 100 M+ vectores, necesidades de recuperación elevadas Por nodo, caro

Evitar recuperaciones ocultas de N+1

Cada paso del agente que llama search es una consulta facturable. Recuentos de llamadas de recuperación de registros por turno de usuario y alerta cuando la mediana supera el presupuesto. Un buen objetivo inicial es realizar dos operaciones de recuperación como máximo por turno. Los reranqueadores y los reescritores son puntos donde es fácil duplicar accidentalmente el tráfico.

Gobernanza: mantener los cambios de costos seguros

Fase: Todas las fases. La versión ligera, que incluye un presupuesto, una comprobación de eval de una sola línea antes del despliegue y un único límite de tasa, debe estar en Explore desde el primer día. La versión más completa, con controles de evaluación que bloquean la CI y límites de tasa por tenant en API Management, pertenece a Expand y posteriores.

Una optimización que interrumpe la calidad no es una optimización. Es una interrupción. Encapsula cada cambio de costo en tres barreras de protección. Cada salvaguarda puede implementarse en menos de una hora por un único ingeniero.

  1. Prueba de evaluación: Ejecuta tu conjunto de evaluación antes de desplegar cualquier cambio en el prompt, el modelo o el enrutamiento. En la fase inicial, esta comprobación puede ser un script que puedes ejecutar manualmente. Bloquear el despliegue o revertirlo si la puntuación baja más de lo que permite su tolerancia, por ejemplo, un punto en una escala de 100 puntos.
  2. Alertas de presupuesto: Configure presupuestos de Azure Cost Management para cada grupo de recursos con alertas al 50, 80 y 100 %. Envíalas al mismo canal de Slack o Teams donde recibes tus notificaciones de errores, para que los costes y los incidentes lleguen al mismo lugar.
  3. Límite de tasa de solicitudes: Incluso un solo límite por IP o por clave de API en API Management, NGINX o tu puerta de enlace evita que un cliente descontrolado agote tu saldo de crédito de la noche a la mañana. Agregue límites por inquilino más adelante cuando tenga clientes de pago.

Tenga cuidado con la agrupación de varias optimizaciones de costos en una sola versión. Cuando el conjunto de cambios se integra de golpe, la atribución se vuelve difícil y cualquier regresión resulta costosa de aislar mediante bisección.

El experimento de dos palancas: cómo comparar antes y después

Cuando decida dónde empezar, elija dos palancas de las secciones anteriores, envíelas detrás de una marca de característica y mida entre 7 y 14 días. Dos palancas son suficientes para detectar un movimiento significativo. Más de dos hace que la atribución no sea confiable.

Primer par sugerido por fase

Stage Palanca A Palanca B
Inicio previo (<100 DAU) Almacenamiento en caché de avisos Enrutamiento de modelos con un modelo predeterminado barato
Tracción temprana (100-10k DAU) Caché semántica Escala a cero en la inferencia
Escala (10 k+ DAU) Batch API para el trabajo asincrónico Estrategia de índice por inquilino
Nivel Enterprise Índices dedicados para las cuentas principales Modelos cuantificados en L4 o H100 
Baseline window:   2026-04-15 to 2026-04-28 (14 days)
Treatment window:  2026-05-01 to 2026-05-14 (14 days)
Levers shipped:    1) semantic cache on /chat
                   2) scale-to-zero on vLLM

Metrics:
  cost_per_active_user   (target: down 30%)
  p95_latency_ms         (guardrail: +<= 150 ms)
  eval_score_delta       (guardrail: >= -1.0)

Decision rule: Keep both if all guardrails hold. Otherwise, revert and ship one at a time.

Lo que trata este artículo y lo que no

Este artículo tiene un alcance limitado intencionadamente. En las secciones siguientes se enumeran los temas que están en el ámbito, los temas que están fuera del ámbito y las señales que indican cuándo agregarlos.

En el ámbito

  • Etiquetado, presupuestos y prácticas de gestión de costes adecuadas para cualquier empresa emergente.
  • Las cuatro palancas del flujo de la solicitud: almacenamiento en caché, procesamiento por lotes, enrutamiento y selección de modelos.
  • Dimensionamiento óptimo de las GPU y escalado a cero para la inferencia autoalojada.
  • Patrones de recuperación multiinquilino para productos con entre 3 y 100 inquilinos de pago.
  • Un bucle de gobernanza para cambios seguros: control de evaluación, alertas de presupuesto y límites de tasa por inquilino.

Fuera del ámbito

Tema Cuándo agregarlo
Reservas y planes de ahorro para el cómputo de IA El coste de inferencia se mantiene estable durante 90 días, normalmente hacia mediados de la fase Expand.
Herramientas dedicadas de FinOps, como Apptio Cloudability, Vantage y herramientas similares El gasto en la nube supera aproximadamente 50 000 USD al mes o opera en varias nubes. La mayoría de las startups en fase temprana no necesitan esto.
Facturación personalizada basada en tokens por cliente final Ofreces un modelo de precios basado en el uso, o un cliente supera el 25 % de la factura total.
Optimización de costos de entrenamiento, como el ajuste de DeepSpeed y FSDP Los modelos se entrenan internamente. Los productos centrados en la inferencia no necesitan esto.
Arbitraje de costos entre regiones o de varias nubes Se encuentra en la etapa Extract con una rentabilidad demostrada en una sola región.

Cuando este enfoque ya no es suficiente

Las prácticas de este artículo están diseñadas para equipos pequeños que ejecutan su propia nube. En algún momento, tu negocio los supera. Las siguientes señales no son errores. Representan crecimiento. Si se dan dos o más, prevea incorporar herramientas específicas o un responsable de la plataforma a tiempo parcial.

  • El gasto mensual Azure supera aproximadamente $50.000 y la inteligencia artificial es superior al 30 por ciento.
  • Más de 10 ingenieros pueden enviar cambios que muevan el costo en un 5 por ciento o más.
  • Al menos un cliente tiene un uso superior a 10 000 USD al mes y le paga una tarifa plana.
  • Sus inversores o socios financieros han empezado a pedir una previsión de costos mensuales.
  • El producto se ejecuta en más de una Azure región o nube.

Hasta entonces, el bucle ligero de este artículo, que incluye etiquetas, presupuestos, una puerta de evaluación y una revisión mensual, es la herramienta adecuada. Resista la tentación de adoptar las herramientas de FinOps empresariales al principio. Agrega sobrecarga de proceso antes de agregar valor.

Lista de comprobación de referencia

Use los siguientes elementos como lista de comprobación de revisión mensual. Cada elemento se asigna a una sección de este artículo.

  • Todos los recursos de IA se etiquetan con costCenter, tenant, workloady env.
  • Existe un panel de Cost Management, se agrupa por etiqueta y se revisa semanalmente.
  • Los prompts del sistema son lo bastante estables como para lograr aciertos en la caché de prompts.
  • El trabajo asincrónico, como incrustaciones, valoraciones y resúmenes, se ejecuta en Batch API.
  • El enrutador envía al menos el 60 por ciento del tráfico a un modelo más barato sin regresión de valor.
  • Las cargas de trabajo de GPU se reducen a cero fuera del horario laboral o utilizan instancias puntuales para el procesamiento por lotes.
  • La mediana del número de recuperaciones por turno es de dos o menos.
  • La estrategia multitenant se elige explícitamente: compartida con filtro o dedicada.
  • Se aplican los presupuestos y los límites de tasa por tenant.
  • Cada cambio en el prompt, el modelo o el enrutamiento pasa por la compuerta de evaluación antes de la fusión.
  • Last updated on